Re: Pervasive SQL 9.0 performance issue on a Terminal Services server with Windows 2003
- From: "Bill Bach" <goldstar@xxxxxxxxxxxxx>
- Date: Tue, 09 May 2006 14:04:46 -0500
That's certainly an interesting combination. Let's go through one
issue at a time:
Licensing:
If you have 42 users of your Pervasive application, then you should
really have a 50-User PSQLv9 database engine license. The standard 6-U
license gives you legal right to allow 6 people to access the engine
simultaneously. Please see your license agreement text for exact
details, or contact Pervasive for clarification.
Pervasive PSQL v9:
Your post mentions v9.0 -- but you should be running v9.1 (Service Pack
1). If not, please apply Service Pack 1 to the engine and see if that
helps. There was a performance issue inside PSQLv9 that can be
addressed by a not-yet-released patch from Pervasive. On the other
hand, I do expect Pervasive to release the next full service pack
sometime in the next few weeks, and that would be a good thing to
check, if you can wait a bit longer.
Database Server:
We do not recommend running the Pervasive PSQL database on the same
server as the user environments. Pervasive, Microsoft and even Citrix
will make the same recommendation -- do NOT run background services on
Terminal Servers. A Terminal Server box is tuned for running
foreground (user) processes, and background processes may not get
sufficient CPU time or memory to do their job correctly. As such, we
would recommend moving the PSQLv9 database engine to a second server.
(I would think the same would be for Oracle as well.)
Database Configuration:
It is likely, with 16GB of physical RAM, that the Pervasive engine will
be taking up a fair chunk of it. You will want to disable the L2 cache
by setting the Max Microkernel Memory Usage setting to 0, and enable
the System Cache setting instead. These changes will reduce the memory
footprint of the engine, and may help to make it more stable.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Austin: Pervasive Service & Support Class - 05/2006 ***
*** Chicago: Pervasive Service & Support Class - 07/2006 ***
DougJ wrote:
We have an externally developed application that generally runs on a
Windows desktop (Historically this has been Windows NT - we have
recently upgraded to Windows XP).
The application stores its data locally on the desktop in what used to
be a btrieve database and is now a Pervasive database. We are running
the Prevasice workgoup Version 8 on the desktops. there is no
client/server process involved.
We have recently consolidated several (infact there are about 42) of
these desktop components onto a Windows 2003 Terminal server with
16Gbyte memory and quad 2.7Ghz/2M XEON MP Processors and with each of
the 42 apps running in their own session. We installed a Pervasive SQL
9 server license on the server with a 6 user license.
The questions are:
1. Was it really necessary to go to the server license (it was at
quite a cost to do so)
2. We are having perfomrance issues where the applications using
Pervisive suddenly stop responding. The only remedy is to kill the
app, log off all 42 Terminal service sessions and then kill the
Perviase transactional and relational services. One thing we notice
is that the "transactions" in the Microkernal Resource usage monitor
ihas a max val of 4294967295 and the PEAK value matches this value
although the current value is considerably less.
3. I admit that there we are also running ORACLE version 10g on this
server, but our Oracle DBA says the performance issues on the server
are not because of this per se.
I would appreciate any advise on how we should be using Pervasive
under this terminal services scenario and what options are at our
disposal to look at resolving the pervasive 'freeze'.
.
- References:
- Prev by Date: Delphi 2006 and ActiveX
- Next by Date: BTrieve MAGIC 8 data to MS Access 2003
- Previous by thread: Pervasive SQL 9.0 performance issue on a Terminal Services server with Windows 2003
- Next by thread: Delphi 2006 and ActiveX
- Index(es):
Relevant Pages
|
|
