Re: Performance PSQL 10

Actually, it's not what I thought it was. When a table is defined you can
define the percentage of free space that is maintained in pages that contain
variable length records. I was under the impression that key pages would be
adjusted to maintain the free space percentage but it looks like it only
applies to variable length records that are updated to a bigger size.

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar@xxxxxxxxxxxxx> wrote in message
news:0ZednW676-mZ8BbanZ2dnUVZ_qWtnZ2d@xxxxxxxxxxxxxxxx
What do you mean by "Adjust Free Space"?
BB

Brad Kunkel wrote:

Maybe it really is my program. I will look at the Monitor next time
they report a slowdown. Is it possible this could happen while the
engine adjusts a table's free space in the tree?

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar@xxxxxxxxxxxxx> wrote in message
news:8bGdnREmn668WRranZ2dnUVZ_viunZ2d@xxxxxxxxxxxxxxxx
Have NEVER seen this issue on NetWare! Interesting...
BB

Brad Kunkel wrote:

Oops, screwed that up in the spellcheck. My client is using
Netware.

"Brad Kunkel" <bkunkel@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:4787a658$0$504$815e3792@xxxxxxxxxxxxxxxxx
My client is using so it looks like the process dump is not an
option but now I know what to look for in the Monitor. Has
Pervasive ever given you suggested settings to alleviate this
problem?

Thanks,
Brad Kunkel
Integrated Business, Inc.


"Bill Bach" <goldstar@xxxxxxxxxxxxx> wrote in message
news:9fOdnXtQqLVMPhvanZ2dnUVZ_oOnnZ2d@xxxxxxxxxxxxxxxx
See our web page at www.goldstarsoftware.com/press.asp and check
towards the bottom for instructions on using UserDump to capture
a dump file.

The trick is to snapshot the process WHILE the system is not
responding. The best way to tell this is to run the PSQL
Monitor >>> > and watch the Communication Thread count. Set the
refresh rate >>> > to 1 second. Then, During a "pause", you'll see
the number of >>> > requests STOP updating (indicating that no
requests are being >>> > processed), and you'll see the number of
threads start to climb. >>> > (You may have to increase your Comm
Thread count to make enough >>> > room to grow -- figure at least one
per workstation for the best >>> > test.)

When it is climbing and NO requests are being processed, THEN
you >>> > have to snapshot it. This will probably require setting up
the >>> > command line ahead of time and sitting there watching for
it. >>> > When you see it start queueing, hit Enter!

If possible, please file a report directly with Pervasive, too.
They'll hate me for this line, but this issue is happening at
far >>> > too many sites to be a problem with the environment or
server at >>> > each site. Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Brad Kunkel 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
spread***. 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@xxxxxxxxxxxxx> wrote in message
news:F6ydncx-w-I-1hjanZ2dnUVZ_hOdnZ2d@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***



michael last wrote:

From: "michael last" <shop@xxxxxxxxxxxxxxxxxxxxx>
Subject: Performance PSQL 10
Date: Wed, 9 Jan 2008 17:55:02 +0100
Message-ID: <fm2u9d$3bk$1@xxxxxxxxxxxxxxxxxxxxx>
Lines: 39

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



--



--





--



--



.