Communication Threads

We are using version 7.0 with all updates applied. We have 100 clients
connecting to this database. The problem I have noticed is occasionally
the communication threads jumps to about 50ish and hangs there to the
point that the clients get no response from the server. The system
resources like disk utilization and processor drop to being barely
utilized. Rebooting the server fixes the problem in the short term. Any
ideas on how to troubleshoot what is happening when the Communication
threads jump up to an abnormal amount. I have read some of Pervasive
documents on the purpose of the threads but not much information on
troubleshooting.

Thanks

This is the Windows version of Btrieve

"Btrieve user" <b.slattery (AT) comcast (DOT) net> schreef in bericht
news:1137536677.829632.65620 (AT) g43g2000cwa (DOT) googlegroups.com...

We are using version 7.0 with all updates applied. We have 100 clients
connecting to this database. The problem I have noticed is occasionally
the communication threads jumps to about 50ish and hangs there to the
point that the clients get no response from the server. The system
resources like disk utilization and processor drop to being barely
utilized. Rebooting the server fixes the problem in the short term. Any
ideas on how to troubleshoot what is happening when the Communication
threads jump up to an abnormal amount. I have read some of Pervasive
documents on the purpose of the threads but not much information on
troubleshooting.

Thanks

i have 70-90 users in a Win2K environment, and never seen that problem,
can you give more details?

greetings,

Btrieve user wrote:

We are using version 7.0 with all updates applied. We have 100 clients
connecting to this database. The problem I have noticed is
occasionally the communication threads jumps to about 50ish and hangs
there to the point that the clients get no response from the server.
The system resources like disk utilization and processor drop to
being barely utilized. Rebooting the server fixes the problem in the
short term. Any ideas on how to troubleshoot what is happening when
the Communication threads jump up to an abnormal amount. I have read
some of Pervasive documents on the purpose of the threads but not
much information on troubleshooting.

Thanks

Are you running Service Pack 5 or 6 of PSQL7?

Comm threads are the "workers" that do the work on behalf of the
workstations. When you have lots of requests coming in, these workers
get busy. If something happens that stops the workers (i.e. a
networking failure, disk failure, or other such problem), then the
workers can get halted waiting for some event. If the event never
occurs, these threads can get tied up forever.

If you can find out what is happening that causes the engine to stop
processing, then you might have a chance to fix it.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Sydney: Pervasive.SQL Service & Support Class - 02/27-03/02/2006
***
*** Chicago: Pervasive.SQL Service & Support Class - 03/27-03/30/2006
***

I have to check on the version number.

The servers are running in a 2 server clusterd environment and the
problem seems to occur on ether system. I was thinking something like a
malformed request that is causing the Btrieve kernal to hang. Is there
any way to single out a client that is making strange requests.

Btrieve user wrote:

I have to check on the version number.

The servers are running in a 2 server clusterd environment and the
problem seems to occur on ether system. I was thinking something like
a malformed request that is causing the Btrieve kernal to hang. Is
there any way to single out a client that is making strange requests.

There is a setting in the engine called "Validate Requests" that can be
set manually in the registry for newer versions. This would filter out
any mangled requests by running them through a "sanity checker" before
passing them to the engine. However, this does impact performance a
little bit.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Sydney: Pervasive.SQL Service & Support Class - 02/27/06 ***
*** Chicago: Pervasive.SQL Service & Support Class - 03/27/06 ***

It sounds almost like something is going "bump in the night" causing
all the other requests to pile up at the same time.

I know this is counterintuitive, but it may actually help to reduce
the comm thread setting. The default for that version was 3 and the
default for the current version has been bumpted all the way to 16.
You mention 50+ which sounds like the setting is too high for the
number of users you have. This is a thread pool and you definitely do
NOT need a thread per client. In fact these are real threads at the
OS level and have considerable overhead so a lower setting can
actually result in better performance and less strange behavior in
some cases.

Providing the cause is something normal like locking a smaller server
may let the server process the fewer threads and successfully recover.

For 100 users I would probably start with a setting of 8 comm threads,
although best practice is to look in the Pervasive.SQL monitor at comm
threads in use during a normal period and set the number just a little
higher. My guess is that for ~100 users the comm thread normally
hovers around 3 or so unless someone kicks off a report. If the
normal number is significantly higher than 3 for that many users then
we may need to look at why the server is sluggish. As I mentioned
there is no problem if you occasionally run into the max setting,
however sitting there for more than the occasional bump can hurt
performance.

Leonard

On 19 Jan 2006 14:56:45 -0800, "Btrieve user" <b.slattery (AT) comcast (DOT) net>
wrote:

I have to check on the version number.

The servers are running in a 2 server clusterd environment and the
problem seems to occur on ether system. I was thinking something like a
malformed request that is causing the Btrieve kernal to hang. Is there
any way to single out a client that is making strange requests.