From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59228 invoked by alias); 28 Mar 2017 05:31:30 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 20719 invoked by uid 89); 28 Mar 2017 05:26:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=concluding, installations, symptoms, freezes X-HELO: mail-pg0-f41.google.com Received: from mail-pg0-f41.google.com (HELO mail-pg0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Mar 2017 05:26:57 +0000 Received: by mail-pg0-f41.google.com with SMTP id 81so47197195pgh.2 for ; Mon, 27 Mar 2017 22:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rSPnyQaYo4MpZVix8lcBxL7qnbFsIso2T59HDkTpXEg=; b=jFDYRtWlrUbh8tfDiAHJMnKRZ7+2rnd4k+1NI8uUjmcPfCl/uFTbiH/6TFDJvzT7oY AdJb1FgvvcGpwmPgKEgnq+p4bwnbx/4IVDwzpG9zHAAEI7vsHyOMA2D9KNtyDWDwctT9 On/5JvvScDiSdJdZ9e/fxesoDa6OSWJwOssu4G6JnVLBtKYjpSR1t+p4GGgIXgSU5g0+ J4yTUHJNiL+WyZhkmQg9pWNnawivwVBIRyA5qEB5U2bEC3vNTS8LWK/sZQmvTgBxGGiB 7SU9Cna2nXzyYJtvLP1OFnIx38kRPgRMHJwgBSiV7rwKXazaNkfTIy303giuG/A6Bw7Z 6wwg== X-Gm-Message-State: AFeK/H2bVqthAAABQwqIsoVI+wjiYetVffoG0HWlb3a19GE4uFsonHT98aSaz18RSSADoQ== X-Received: by 10.84.238.22 with SMTP id u22mr34002497plk.137.1490678816268; Mon, 27 Mar 2017 22:26:56 -0700 (PDT) Received: from tornado.leadboat.com (c-98-248-47-228.hsd1.ca.comcast.net. [98.248.47.228]) by smtp.gmail.com with ESMTPSA id c1sm4291310pfk.112.2017.03.27.22.26.54 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 27 Mar 2017 22:26:55 -0700 (PDT) Date: Tue, 28 Mar 2017 05:48:00 -0000 From: Noah Misch To: cygwin@cygwin.com Subject: Re: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop Message-ID: <20170328052652.GA2351961@tornado.leadboat.com> References: <200408030333.i733XEXn023894@mx3.redhat.com> <20040803100612.GP31522@cygbert.vinschen.de> <20170321025614.GA2100214@tornado.leadboat.com> <20170324171101.GI29995@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170324171101.GI29995@calimero.vinschen.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2017-03/txt/msg00354.txt.bz2 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