Re: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Noah,

thanks for the report and especially the testcase.  It took me a while
to debug that, but I think I fixed it now.  At least your testcase is
working for me now.  It also got faster, albeit always slower than Linux
because of the communication overhead between processes and cygserver.

On Mar 21 02:56, Noah Misch wrote:
> On Tue, Aug 03, 2004 at 12:06:12PM +0200, Corinna Vinschen wrote:
> > On Aug  2 20:33, sarbx-cygwin6344@mailblocks.com wrote:
> > > This time around, cygserver does not eat CPU. But after 5 to 6 
> > > concurrent
> > > connections nothing seem to work, looks kind of hung. There is no 
> > > activity in the Postgres
> > > log file. Opening a new database connection also hangs. There is no 
> > > activity on the machine.
> 
> > Any chance to create a simple testcase which uncovers that behaviour
> > without involving a whole database system?
> 
> Attached test program reproduces it on Cygwin 2.7.0, Cygwin 1.7.5, and a few
> intermediate versions.  The program creates sixteen processes that each
> perform a tight loop over the following:
> 
> - select one of four semaphores
> - reduce semaphore's value from 1 to 0 ("lock" it)
> - raise semaphore's value from 0 to 1 ("unlock" it)
> 
> On GNU/Linux, AIX, and Solaris, the processes keep busy and finish one million
> lock/unlock cycles apiece in a few minutes.  On Cygwin, they hang within a few
> seconds and under one hundred cycles apiece.  At that point, cygserver is
> unresponsive to other clients; for example, "strace /bin/true", opening a new
> Cygwin terminal, "cat /proc/sysvipc/sem" and "cygserver -S" all hang.  In most
> tests, cygserver was not consuming CPU while unresponsive.

There are two problems here.

- cygserver is using a defined number of threads in a thread pool for
  application requests.  Every request is added to a request submission
  queue and handled by the next free thread in the pool.

  The default number of threads in the pool is 10.  Each wait for a
  semaphore is blocking one thread.  If more than the number of threads
  in the pool are supposed to wait on a semaphore the pool starves.

  Raising the pool size fixes this part, but the situation is still a bit
  unsatisfying.  You may not know the load and the number of competing
  processes in every scenario beforehand, but raising cygservers thread
  pool to some really big value doesn't always make sense either.

  So what I did now is to allow cygserver to raise the number of worker
  threads on demand.  That is, if a request is in the queue and all
  worker threads are busy, just create a new one.

  There's no way yet to drop threads again, but this should be a minor
  problem in scenarions which really have a lot of contention.

- The code emulating BSD msleep/wakeup wasn't quite up to speed.
  I rewrote a major part of the code to be more robust and faster.

I pushed a patchset now, and uploaded new developer snapshots for
testing to https://cygwin.com/snapshots/

I'm also going to create a 2.8.0-0.4 test release later today.

Please give it a try, and please note that *all* patches affect
cygserver itself, so you have to test the new cygserver in the
first place.  The Cygwin DLL is not affected by the changes.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature