Maybe it really is my program. I will look at the Monitor next time they
re****t 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@[EMAIL PROTECTED]
> wrote in message
news:8bGdnREmn668WRranZ2dnUVZ_viunZ2d@[EMAIL PROTECTED]
> 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@[EMAIL PROTECTED]
> wrote in message
>> news:4787a658$0$504$815e3792@[EMAIL PROTECTED]
>> > 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@[EMAIL PROTECTED]
> wrote in message
>> news:9fOdnXtQqLVMPhvanZ2dnUVZ_oOnnZ2d@[EMAIL PROTECTED]
>> > > 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 re****t 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@[EMAIL PROTECTED]
>> > > http://www.goldstarsoftware.com
>> > > *** Chicago: Pervasive Service & Sup****t 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 re****t 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@[EMAIL PROTECTED]
> wrote in message
>> > > > news:F6ydncx-w-I-1hjanZ2dnUVZ_hOdnZ2d@[EMAIL PROTECTED]
>> >>>> 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@[EMAIL PROTECTED]
>> >>>> http://www.goldstarsoftware.com
>> >>>> *** Chicago: Pervasive Service & Sup****t Class - March 2008 ***
>> > > > >
>> > > > >
>> > > > >
>> >>>> michael last wrote:
>> > > > >
>> >>>> > From: "michael last" <shop@[EMAIL PROTECTED]
>
>> >>>> > Subject: Performance PSQL 10
>> >>>> > Date: Wed, 9 Jan 2008 17:55:02 +0100
>> >>>> > Message-ID: <fm2u9d$3bk$1@[EMAIL PROTECTED]
>
>> >>>> > Lines: 39
>> >>>> >
>> >>>> > Hi,
>> >>>> >
>> >>>> > We have just upgraded a customer from Pervasive 2000 to
>> Pervasive >>>> > 10. This customer is now re****ting, 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
>> > > > >
>> > > > >
>> > > > >
>> >>>> --
>> > >
>> > >
>> > >
>> > > --
>> >
>> >
>
>
>
> --
>
|
