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@[EMAIL PROTECTED]
> wrote in message
news:0ZednW676-mZ8BbanZ2dnUVZ_qWtnZ2d@[EMAIL PROTECTED]
> 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 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
>> >>> > > >
>> >>> > > >
>> >>> > > >
>> >>>>>> --
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> > > >
>> > > >
>> >
>> >
>> >
>> > --
>
>
>
> --
>
|
