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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Noah Misch
On Tue, Aug 03, 2004 at 12:06:12PM +0200, Corinna Vinschen wrote:
> On Aug  2 20:33, [hidden email] 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.

Thanks,
nm


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

sema_parallel.c (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
On 21/03/2017 03:56, Noah Misch wrote:

> On Tue, Aug 03, 2004 at 12:06:12PM +0200, Corinna Vinschen wrote:
>> On Aug  2 20:33, [hidden email] 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:

same on x86_64 2.8.0-0.1

>
> - 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.

confirmed

> Thanks,
> nm
>

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen-2
In reply to this post by Noah Misch
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, [hidden email] 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
On 24/03/2017 18:11, Corinna Vinschen wrote:
> Hi Noah,
>

>>
>> 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.
>
>
> 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
>
Hi Corinna,
just noted a small glitch.

Attached a modification of Noah's test, it now accepts the number of
workers and semaphore are as before workers/4

./sema_parallel-2 32
  worker ....
  OK

./sema_parallel-2 64
semget
semget: Invalid argument

If I restart the cygserver

./sema_parallel-2 64
  worker ....
  OK

./sema_parallel-2 128
semget
semget: Invalid argument


It seems that the number of max available semaphores is frozen to first
call value.











--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

sema_parallel-2.c (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen-2
On Mar 25 09:09, Marco Atzeri wrote:

> On 24/03/2017 18:11, Corinna Vinschen wrote:
> > Hi Noah,
> >
>
> > >
> > > 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.
> >
> >
> > 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
> >
>
> Hi Corinna,
> just noted a small glitch.
>
> Attached a modification of Noah's test, it now accepts the number of workers
> and semaphore are as before workers/4
>
> ./sema_parallel-2 32
>  worker ....
>  OK
>
> ./sema_parallel-2 64
> semget
> semget: Invalid argument
>
> If I restart the cygserver
>
> ./sema_parallel-2 64
>  worker ....
>  OK
>
> ./sema_parallel-2 128
> semget
> semget: Invalid argument
>
>
> It seems that the number of max available semaphores is frozen to first call
> value.
That's normal and documented.  An existing semaphore set using the same
key has the number of semaphores defined in the first call, until you
remove the semaphore set with, for instance, ipcrm -s.  POSIX has this
to say:

   [EINVAL]
      The value of nsems is either less than or equal to 0 or greater
      than the system-imposed limit, or a semaphore identifier exists
      for the argument key, but the number of semaphores in the set
      associated with it is less than nsems and nsems is not equal to 0.

Linux doesn't care, but BSD does, and our XSI IPC code is 95% BSD.


Corinna

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
On 25/03/2017 12:30, Corinna Vinschen wrote:
> On Mar 25 09:09, Marco Atzeri wrote:

>>
>> It seems that the number of max available semaphores is frozen to first call
>> value.
>
> That's normal and documented.  An existing semaphore set using the same
> key has the number of semaphores defined in the first call, until you
> remove the semaphore set with, for instance, ipcrm -s.  POSIX has this
> to say:
>
>    [EINVAL]
>       The value of nsems is either less than or equal to 0 or greater
>       than the system-imposed limit, or a semaphore identifier exists
>       for the argument key, but the number of semaphores in the set
>       associated with it is less than nsems and nsems is not equal to 0.
>
> Linux doesn't care, but BSD does, and our XSI IPC code is 95% BSD.
>
>
> Corinna
>

noted.

Thanks Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Noah Misch
In reply to this post by Corinna Vinschen-2
On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> - 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.

Interesting.  I can confirm that, without updating software, "cygserver -r 40"
fixes both my self-contained test and my PostgreSQL test case.  Folks can use
that workaround in released-version installations.

>   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.

Agreed.  This is nicer.

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

> Please give it a try

Self-contained test case results look good:

cygwin-20170321.tar.xz "cygserver -r40": ok
cygwin-20170324.tar.xz "cygserver -r40": ok
cygwin-20170321.tar.xz "cygserver -r10": freezes (expected)
cygwin-20170324.tar.xz "cygserver -r10": ok; cygserver output concludes with
  "cygserver: All threads busy, added one (now 21)".

I then tried my PostgreSQL test case ("pgbench -i -s 50" once to setup, then
"pgbench -S -j2 -c16 -T900 -P5" to test):

cygwin-20170321.tar.xz "cygserver -r40": ok for >3600s
cygwin-20170324.tar.xz "cygserver -r40": limited freeze in <1000s; no
  cygserver output
cygwin-20170321.tar.xz "cygserver -r10": classic freeze in <1000s (expected)
cygwin-20170324.tar.xz "cygserver -r10": limited freeze in <1000s; no
  cygserver output for most of the run, then output concluding with
  "cygserver: All threads busy, added one (now 15)" just before the freeze

I call the cygwin-20170324 freezes "limited" because the symptoms differ from
the classic freeze I described upthread.  "strace /bin/true" and "cat
/proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
waiting on a synchronization primitive.

I can distill another self-contained test case for the limited freeze seen in
cygwin-20170324, but that make take awhile.  I'm sending this early report so
you're aware of the possible regression in cygwin-20170324.

Thanks,
nm

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Noah Misch
On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
> On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> > I pushed a patchset now, and uploaded new developer snapshots for
> > testing to https://cygwin.com/snapshots/
>
> > Please give it a try

> I call the cygwin-20170324 freezes "limited" because the symptoms differ from
> the classic freeze I described upthread.  "strace /bin/true" and "cat
> /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
> waiting on a synchronization primitive.
>
> I can distill another self-contained test case for the limited freeze seen in
> cygwin-20170324, but that make take awhile.  I'm sending this early report so
> you're aware of the possible regression in cygwin-20170324.

I'm attaching a new test program that demonstrates the regression.  My previous
test program created sixteen processes that each picked a random semaphore to
lock.  Now, each process picks two semaphores and locks them in order.  This
proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz "cygserver -r 40".
It freezes within one second on cygwin-20170324.tar.xz "cygserver -r 40".


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

sema_two.c (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Noah Misch
On Sat, Apr 01, 2017 at 10:36:24PM -0400, Noah Misch wrote:

> On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
> > On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> > > I pushed a patchset now, and uploaded new developer snapshots for
> > > testing to https://cygwin.com/snapshots/
> >
> > > Please give it a try
>
> > I call the cygwin-20170324 freezes "limited" because the symptoms differ from
> > the classic freeze I described upthread.  "strace /bin/true" and "cat
> > /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
> > waiting on a synchronization primitive.
> >
> > I can distill another self-contained test case for the limited freeze seen in
> > cygwin-20170324, but that make take awhile.  I'm sending this early report so
> > you're aware of the possible regression in cygwin-20170324.
>
> I'm attaching a new test program that demonstrates the regression.  My previous
> test program created sixteen processes that each picked a random semaphore to
> lock.  Now, each process picks two semaphores and locks them in order.  This
> proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz "cygserver -r 40".
> It freezes within one second on cygwin-20170324.tar.xz "cygserver -r 40".

I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
versions can be configured to have reliable sysv semaphores, but I think no
settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you think?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Larry Hall (Cygwin)
On 05/06/2017 11:27 PM, Noah Misch wrote:

> On Sat, Apr 01, 2017 at 10:36:24PM -0400, Noah Misch wrote:
>> On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
>>> On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
>>>> I pushed a patchset now, and uploaded new developer snapshots for
>>>> testing to https://cygwin.com/snapshots/
>>>
>>>> Please give it a try
>>
>>> I call the cygwin-20170324 freezes "limited" because the symptoms differ from
>>> the classic freeze I described upthread.  "strace /bin/true" and "cat
>>> /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
>>> waiting on a synchronization primitive.
>>>
>>> I can distill another self-contained test case for the limited freeze seen in
>>> cygwin-20170324, but that make take awhile.  I'm sending this early report so
>>> you're aware of the possible regression in cygwin-20170324.
>>
>> I'm attaching a new test program that demonstrates the regression.  My previous
>> test program created sixteen processes that each picked a random semaphore to
>> lock.  Now, each process picks two semaphores and locks them in order.  This
>> proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz "cygserver -r 40".
>> It freezes within one second on cygwin-20170324.tar.xz "cygserver -r 40".
>
> I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
> versions can be configured to have reliable sysv semaphores, but I think no
> settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you think?

Just FYI, Corinna is away for a bit (in European time, "a bit" = until
June ;-) ) so don't be surprised if her response is delayed.


--
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
On 07/05/2017 05:47, Larry Hall (Cygwin) wrote:

> On 05/06/2017 11:27 PM, Noah Misch wrote:
>> On Sat, Apr 01, 2017 at 10:36:24PM -0400, Noah Misch wrote:
>>> On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
>>>> On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
>>>>> I pushed a patchset now, and uploaded new developer snapshots for
>>>>> testing to https://cygwin.com/snapshots/
>>>>
>>>>> Please give it a try
>>>
>>>> I call the cygwin-20170324 freezes "limited" because the symptoms
>>>> differ from
>>>> the classic freeze I described upthread.  "strace /bin/true" and "cat
>>>> /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process
>>>> is stuck
>>>> waiting on a synchronization primitive.
>>>>
>>>> I can distill another self-contained test case for the limited
>>>> freeze seen in
>>>> cygwin-20170324, but that make take awhile.  I'm sending this early
>>>> report so
>>>> you're aware of the possible regression in cygwin-20170324.
>>>
>>> I'm attaching a new test program that demonstrates the regression.
>>> My previous
>>> test program created sixteen processes that each picked a random
>>> semaphore to
>>> lock.  Now, each process picks two semaphores and locks them in
>>> order.  This
>>> proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz
>>> "cygserver -r 40".
>>> It freezes within one second on cygwin-20170324.tar.xz "cygserver -r
>>> 40".
>>
>> I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
>> versions can be configured to have reliable sysv semaphores, but I
>> think no
>> settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you
>> think?
>
> Just FYI, Corinna is away for a bit (in European time, "a bit" = until
> June ;-) ) so don't be surprised if her response is delayed.
>

as she is back, we can humble rise her attention to the matter.

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen-2
On Jun 15 01:32, Marco Atzeri wrote:

> On 07/05/2017 05:47, Larry Hall (Cygwin) wrote:
> > On 05/06/2017 11:27 PM, Noah Misch wrote:
> > > On Sat, Apr 01, 2017 at 10:36:24PM -0400, Noah Misch wrote:
> > > > On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
> > > > > On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> > > > > > I pushed a patchset now, and uploaded new developer snapshots for
> > > > > > testing to https://cygwin.com/snapshots/
> > > > >
> > > > > > Please give it a try
> > > >
> > > > > I call the cygwin-20170324 freezes "limited" because the symptoms
> > > > > differ from
> > > > > the classic freeze I described upthread.  "strace /bin/true" and "cat
> > > > > /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process
> > > > > is stuck
> > > > > waiting on a synchronization primitive.
> > > > >
> > > > > I can distill another self-contained test case for the limited
> > > > > freeze seen in
> > > > > cygwin-20170324, but that make take awhile.  I'm sending this early
> > > > > report so
> > > > > you're aware of the possible regression in cygwin-20170324.
> > > >
> > > > I'm attaching a new test program that demonstrates the regression.
> > > > My previous
> > > > test program created sixteen processes that each picked a random
> > > > semaphore to
> > > > lock.  Now, each process picks two semaphores and locks them in
> > > > order.  This
> > > > proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz
> > > > "cygserver -r 40".
> > > > It freezes within one second on cygwin-20170324.tar.xz "cygserver -r
> > > > 40".
> > >
> > > I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
> > > versions can be configured to have reliable sysv semaphores, but I
> > > think no
> > > settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you
> > > think?
> >
> > Just FYI, Corinna is away for a bit (in European time, "a bit" = until
> > June ;-) ) so don't be surprised if her response is delayed.
> >
>
> as she is back, we can humble rise her attention to the matter.
I can do that, but wouldn't it be nice if somebody would actually
try to debug Cygserver further, to handle this new testcase correctly
as well?  6 weeks, and nobody actually tries.  Sigh.


Corinna

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
On 20/06/2017 13:11, Corinna Vinschen wrote:

>>>>
>>>> I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
>>>> versions can be configured to have reliable sysv semaphores, but I
>>>> think no
>>>> settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you
>>>> think?
>>>
>>> Just FYI, Corinna is away for a bit (in European time, "a bit" = until
>>> June ;-) ) so don't be surprised if her response is delayed.
>>>
>>
>> as she is back, we can humble rise her attention to the matter.
>
> I can do that, but wouldn't it be nice if somebody would actually
> try to debug Cygserver further, to handle this new testcase correctly
> as well?  6 weeks, and nobody actually tries.  Sigh.
>
>
> Corinna

I agree.

To my discharge:
- I have no clue what to look for, my knowledge of cygwin inside
   is not so good.
- Real life is eating my available time for cygwin.
- The Symantec Endpoint Protection BLODA, that I can not get rid of,
   is making strace impossible and debugging a nightmare.

Sorry
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen-2
On Jun 20 19:29, Marco Atzeri wrote:

> On 20/06/2017 13:11, Corinna Vinschen wrote:
> > > > >
> > > > > I suggest reverting the cygwin-20170324 cygserver changes for now.  Older
> > > > > versions can be configured to have reliable sysv semaphores, but I
> > > > > think no
> > > > > settings render sysv semaphores reliable in Cygwin 2.8.0.  What do you
> > > > > think?
> > > >
> > > > Just FYI, Corinna is away for a bit (in European time, "a bit" = until
> > > > June ;-) ) so don't be surprised if her response is delayed.
> > > >
> > >
> > > as she is back, we can humble rise her attention to the matter.
> >
> > I can do that, but wouldn't it be nice if somebody would actually
> > try to debug Cygserver further, to handle this new testcase correctly
> > as well?  6 weeks, and nobody actually tries.  Sigh.
> >
> >
> > Corinna
>
> I agree.
>
> To my discharge:
> - I have no clue what to look for, my knowledge of cygwin inside
>   is not so good.
There are not a lot of Cygwin internals involved, it's pretty much all
in cygserver.

> - Real life is eating my available time for cygwin.
> - The Symantec Endpoint Protection BLODA, that I can not get rid of,
>   is making strace impossible and debugging a nightmare.
>
> Sorry
> Marco

No worries.  But I only have so much time on my hands either, so it
would be nice if others (not necessarily you) would try to plunge into
the code and debug it from the inside.  Sources *are* available after
all, and there's no ban on asking source code related question on
cygwin-developers.


Corinna

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

signature.asc (836 bytes) Download Attachment