Hi,

We have just upgraded a customer from Pervasive 2000 to Pervasive 10. This
customer is now reporting, that our application is lagging very often for
5-20 seconds. That means that it looks like the software is not reacting
anymore and all of the sudden it starts working again. This happens about 10
times a day on moreless all of the 50 workstations and it is has not behaved
like that with PVSW 2000.

The current performance settings are as follows:
Cache Allocation: 409MB
Max Microkernal Memory Usage: 0%
System Cache: on

We have also noted that NTDBSMGR takes about 50% CPU from time to time and
also at the same time we notice about 40 communication threads and about 60
worker threads (These values are going back to 0 after about 5 seconds)

We have checked other installations with near the same setup and never
noticed that high CPU utilization and also note seeing that amount of
threads being used. What can be the reason for that?

We have also tried with System Cache=off and Max Microkernal Memory Usage =
60 without any changes. Are there any other settings which have impact to
the performance?

Any suggenstions will be very appreciated.

Environment:
Windows Server 2003 Intel Xeon Dual 3,2 GHz
Memory 4GB
Databases: 50 with total amount 108 GB via Transactional Btrieve (largest
single DB=60GB)
Persavive 10 - 50 user

Thanks and regards

Michael

We have seen this at several sites running Pervasive PSQL v9.5. The
"pauses", as they have come to be known, are periodic in nature, and do
not seem to be based on a specific function call or activity. As you
have seen, ALL database functionality seizes up for the duration of the
pause, and new requests get queued up in the comm threads. When it
releases, everything catches up, and no requests are lost.

We have not been able to duplicate this in a test environment, although
when examining production environments, we have seen an abnormally high
number of disk writes to the Windows pagefile. You may wish to monitor
disk writes to the C: drive (and the pagefile in particular, if you can
run FileMon) when this occurs. (It is especially obvious when the C:
drive is NOT where the data is located.

For the few sites that have been majorly impacted, optimization of the
disk subsystem, including the swapfile, seems to help. Using a RAID10
array has provided huge gains for several users.

What we REALLY need is a long enough pause and a site willing to crash
out the engine and take a complete core dump of the engine while it is
in one of these "pause" states. Unfortunately, the sites seeing this
problem are usually running mission-critical applications for which
downtime is not an option.

If you have an option of doing this, please let me know. You may need
to open an incident directly with Pervasive to get the results
analyzed, but I think this will be a good idea.

Honestly, I was really hoping that the issue was NOT going to exist in
PSQLv10...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***



michael last wrote:



--

We have seen this at several sites running Pervasive PSQL v9.5. The
"pauses", as they have come to be known, are periodic in nature, and do
not seem to be based on a specific function call or activity. As you
have seen, ALL database functionality seizes up for the duration of the
pause, and new requests get queued up in the comm threads. When it
releases, everything catches up, and no requests are lost.

We have not been able to duplicate this in a test environment, although
when examining production environments, we have seen an abnormally high
number of disk writes to the Windows pagefile. You may wish to monitor
disk writes to the C: drive (and the pagefile in particular, if you can
run FileMon) when this occurs. (It is especially obvious when the C:
drive is NOT where the data is located.

For the few sites that have been majorly impacted, optimization of the
disk subsystem, including the swapfile, seems to help. Using a RAID10
array has provided huge gains for several users.

What we REALLY need is a long enough pause and a site willing to crash
out the engine and take a complete core dump of the engine while it is
in one of these "pause" states. Unfortunately, the sites seeing this
problem are usually running mission-critical applications for which
downtime is not an option.

If you have an option of doing this, please let me know. You may need
to open an incident directly with Pervasive to get the results
analyzed, but I think this will be a good idea.

Honestly, I was really hoping that the issue was NOT going to exist in
PSQLv10...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***



michael last wrote:



--

We have seen this at several sites running Pervasive PSQL v9.5. The
"pauses", as they have come to be known, are periodic in nature, and do
not seem to be based on a specific function call or activity. As you
have seen, ALL database functionality seizes up for the duration of the
pause, and new requests get queued up in the comm threads. When it
releases, everything catches up, and no requests are lost.

We have not been able to duplicate this in a test environment, although
when examining production environments, we have seen an abnormally high
number of disk writes to the Windows pagefile. You may wish to monitor
disk writes to the C: drive (and the pagefile in particular, if you can
run FileMon) when this occurs. (It is especially obvious when the C:
drive is NOT where the data is located.

For the few sites that have been majorly impacted, optimization of the
disk subsystem, including the swapfile, seems to help. Using a RAID10
array has provided huge gains for several users.

What we REALLY need is a long enough pause and a site willing to crash
out the engine and take a complete core dump of the engine while it is
in one of these "pause" states. Unfortunately, the sites seeing this
problem are usually running mission-critical applications for which
downtime is not an option.

If you have an option of doing this, please let me know. You may need
to open an incident directly with Pervasive to get the results
analyzed, but I think this will be a good idea.

Honestly, I was really hoping that the issue was NOT going to exist in
PSQLv10...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***



michael last wrote:



--

Hi Bill,

thanks very much for your info. "Good" to know that we are not the only one
with that problem.

Today we have checked disk writes to pagefile with Filemon - NO disk writes
to pagefile, also nothing during high cpu utilization on ntdbsmgr.

We have already opened an incident directly with pervasive and sent them a
user dump. The analyze result from Pervasive:
"The dump only showed three active threads, and one of those was getting an
MKDE Stat on a file. There was no IO going on either, which led him to
believe that the dump was taken just after the pause cleared up."

I think getting a dump containing these "pause" states is moreless
impossible since the pauses are not long enough.

Just to let you know - we have also disabled new XIO feature in PSQL 10
without any changes.

Could the problem be a network communication issue? Faulty network cards,
routers, switches or outdated network drivers?

Any help is highly appreciated since we have to update a lot more clients to
PSQL 10.

Michael

Hi Bill,

thanks very much for your info. "Good" to know that we are not the only one
with that problem.

Today we have checked disk writes to pagefile with Filemon - NO disk writes
to pagefile, also nothing during high cpu utilization on ntdbsmgr.

We have already opened an incident directly with pervasive and sent them a
user dump. The analyze result from Pervasive:
"The dump only showed three active threads, and one of those was getting an
MKDE Stat on a file. There was no IO going on either, which led him to
believe that the dump was taken just after the pause cleared up."

I think getting a dump containing these "pause" states is moreless
impossible since the pauses are not long enough.

Just to let you know - we have also disabled new XIO feature in PSQL 10
without any changes.

Could the problem be a network communication issue? Faulty network cards,
routers, switches or outdated network drivers?

Any help is highly appreciated since we have to update a lot more clients to
PSQL 10.

Michael

Hi Bill,

thanks very much for your info. "Good" to know that we are not the only one
with that problem.

Today we have checked disk writes to pagefile with Filemon - NO disk writes
to pagefile, also nothing during high cpu utilization on ntdbsmgr.

We have already opened an incident directly with pervasive and sent them a
user dump. The analyze result from Pervasive:
"The dump only showed three active threads, and one of those was getting an
MKDE Stat on a file. There was no IO going on either, which led him to
believe that the dump was taken just after the pause cleared up."

I think getting a dump containing these "pause" states is moreless
impossible since the pauses are not long enough.

Just to let you know - we have also disabled new XIO feature in PSQL 10
without any changes.

Could the problem be a network communication issue? Faulty network cards,
routers, switches or outdated network drivers?

Any help is highly appreciated since we have to update a lot more clients to
PSQL 10.

Michael

I also have a client where they tell me that their program periodically
freezes up then starts working again. They are using v9.5 on a Netware
server with XP Pro clients. There are 12 users but only the 2 data entry
people report the problem. One says that it will slow down for a minute or
so. The other says that the slow down can last a long time (hours). It may
be that this user is getting a series of slowdowns but are describing it as
hours. What they usually say is that the mouse won't click. From this
thread it looks like it is really the database.

The problem program uses transactional access. Occasionally, other users
will do SQL queries to pull data into a spreadsheet. If I happen to be
there when one of these slowdowns occurs, how would I create a dump that can
be analyzed to hopefully fix this?

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar (AT) speakeasy (DOT) net> wrote

I also have a client where they tell me that their program periodically
freezes up then starts working again. They are using v9.5 on a Netware
server with XP Pro clients. There are 12 users but only the 2 data entry
people report the problem. One says that it will slow down for a minute or
so. The other says that the slow down can last a long time (hours). It may
be that this user is getting a series of slowdowns but are describing it as
hours. What they usually say is that the mouse won't click. From this
thread it looks like it is really the database.

The problem program uses transactional access. Occasionally, other users
will do SQL queries to pull data into a spreadsheet. If I happen to be
there when one of these slowdowns occurs, how would I create a dump that can
be analyzed to hopefully fix this?

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar (AT) speakeasy (DOT) net> wrote

I also have a client where they tell me that their program periodically
freezes up then starts working again. They are using v9.5 on a Netware
server with XP Pro clients. There are 12 users but only the 2 data entry
people report the problem. One says that it will slow down for a minute or
so. The other says that the slow down can last a long time (hours). It may
be that this user is getting a series of slowdowns but are describing it as
hours. What they usually say is that the mouse won't click. From this
thread it looks like it is really the database.

The problem program uses transactional access. Occasionally, other users
will do SQL queries to pull data into a spreadsheet. If I happen to be
there when one of these slowdowns occurs, how would I create a dump that can
be analyzed to hopefully fix this?

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar (AT) speakeasy (DOT) net> wrote