From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Alex Sharp Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: Strange quit behavior Date: Tue, 16 Aug 2011 21:26:28 -0700 Message-ID: References: <20110802215412.GA12725@dcvr.yhbt.net> <20110805080729.GA6602@dcvr.yhbt.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1313556676 8451 80.91.229.12 (17 Aug 2011 04:51:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 17 Aug 2011 04:51:16 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Wed Aug 17 06:51:12 2011 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=+As8dz4t+MC/o15uWXG6cmdynPipj9euLlzFzDSL62I=; b=gx785pJxxAvAgf+mUE5vLFJ744NDJ8FSMGcbKz/8jgN97ha9oUM1SwPV28/MyLfryw MkmaIqVZj7O+II46sOTzFQVBVqNsx9F9Mvn4uKafDK0NYHwWCoLMYIxsz7mJ5AFD5TGj ODzzy4syQM8ECcTe+ypaRRy1bjm3I6HP1wJqU= In-Reply-To: <20110805080729.GA6602@dcvr.yhbt.net> X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Xref: news.gmane.org gmane.comp.lang.ruby.unicorn.general:1110 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QtY5v-00038i-Ow for gclrug-mongrel-unicorn@m.gmane.org; Wed, 17 Aug 2011 06:51:12 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 363EE1D78102; Wed, 17 Aug 2011 00:51:08 -0400 (EDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by rubyforge.org (Postfix) with ESMTP id A2DED1858386 for ; Wed, 17 Aug 2011 00:26:48 -0400 (EDT) Received: by iye1 with SMTP id 1so1118508iye.41 for ; Tue, 16 Aug 2011 21:26:48 -0700 (PDT) Received: by 10.42.156.74 with SMTP id y10mr395988icw.164.1313555208107; Tue, 16 Aug 2011 21:26:48 -0700 (PDT) Received: by 10.231.39.132 with HTTP; Tue, 16 Aug 2011 21:26:28 -0700 (PDT) On Fri, Aug 5, 2011 at 1:07 AM, Eric Wong wrote: > Is this Unicorn 3.x? =A0Which 3.x version exactly? =A0Maybe give 4.0.1 > or the 4.0.2 git prerelease a try, too. We're using version 3.6.2 with ruby 1.9.2-p180 on ubuntu 11.x. I know the kernel on this version of ubuntu has a know signal trapping bug, but I don't think that's what happening here. The processes respond after I send the restart signal to them again (USR2 + QUIT). > Can I get more? (until the next select() call, at least). =A0I'd like to > see the timeout argument that gets passed to the next select(). Here's some more output. This is from the old master though, not a new master that is pegging the CPU. In this instance it's almost like the old master just ignores the signal. select(4, [3], NULL, NULL, {8, 129984}) =3D 0 (Timeout) wait4(-1, 0x7fff16b82e4c, WNOHANG, NULL) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 259408364}) =3D 0 fstat(12, {st_dev=3Dmakedev(202, 1), st_ino=3D20373, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:20, st_mtime=3D2011/08/12-23:14:20, st_ctime=3D2011/08/17-04:22:21}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 259775504}) =3D 0 fstat(13, {st_dev=3Dmakedev(202, 1), st_ino=3D20381, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:20, st_mtime=3D2011/08/12-23:14:20, st_ctime=3D2011/08/17-04:22:17}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 259936816}) =3D 0 fstat(14, {st_dev=3Dmakedev(202, 1), st_ino=3D20382, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:21, st_mtime=3D2011/08/12-23:14:21, st_ctime=3D2011/08/17-04:22:19}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260086380}) =3D 0 fstat(15, {st_dev=3Dmakedev(202, 1), st_ino=3D20185, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:21, st_mtime=3D2011/08/12-23:14:21, st_ctime=3D2011/08/17-04:22:17}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260235797}) =3D 0 fstat(16, {st_dev=3Dmakedev(202, 1), st_ino=3D20255, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:21, st_mtime=3D2011/08/12-23:14:21, st_ctime=3D2011/08/17-04:22:19}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260384849}) =3D 0 fstat(17, {st_dev=3Dmakedev(202, 1), st_ino=3D20383, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:21, st_mtime=3D2011/08/12-23:14:21, st_ctime=3D2011/08/17-04:22:19}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260534792}) =3D 0 fstat(18, {st_dev=3Dmakedev(202, 1), st_ino=3D20384, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/12-23:14:21, st_mtime=3D2011/08/12-23:14:21, st_ctime=3D2011/08/17-04:22:19}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260684278}) =3D 0 fstat(10, {st_dev=3Dmakedev(202, 1), st_ino=3D20196, st_mode=3DS_IFREG, st_nlink=3D0, st_uid=3D1001, st_gid=3D1001, st_blksize=3D4096, st_blocks=3D= 0, st_size=3D0, st_atime=3D2011/08/16-16:33:46, st_mtime=3D2011/08/16-16:33:46, st_ctime=3D2011/08/17-04:22:19}) =3D 0 clock_gettime(CLOCK_REALTIME, {1313554942, 260833725}) =3D 0 select(4, [3], NULL, NULL, {8, 976047} > If you see select() with very small timeout, use "strace -v" to get the > st_ctime from fstat()s... > > I could have a math bug in murder_lazy_workers (please read/review the > logic in that method, I haven't noticed issues myself). > > I made some tweaks to the master sleep strategy within the past year to > reduce wakeups during idle hours. =A0This is intended to go with Ruby > 1.9.3 which will have /much/ better thread wakeup strategy that reduces > power consumption during idle times. > >> The first line was when the master was idle, and then I threw a few >> requests at it. > > Are all workers responding as expected and not dying? The old workers appear to be serving requests. - Alex _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying