Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0C9C463522E for ; Sun, 15 Mar 2009 17:42:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 83474-01-2 for ; Sun, 15 Mar 2009 17:42:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.postgresql.org (Postfix) with ESMTP id 82C356347B1 for ; Sun, 15 Mar 2009 17:42:42 -0300 (ADT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2FKgfxw005577 for ; Sun, 15 Mar 2009 20:42:41 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGK00700ERXQ900@mail-amer.sun.com> for pgsql-performance@postgresql.org; Sun, 15 Mar 2009 14:42:41 -0600 (MDT) Received: from Macintosh-8.home ([unknown] [96.237.55.23]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGK00E2QEV46I60@mail-amer.sun.com>; Sun, 15 Mar 2009 14:42:41 -0600 (MDT) Date: Sun, 15 Mar 2009 16:42:40 -0400 From: "Jignesh K. Shah" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-reply-to: To: decibel Cc: "pgsql-performance@postgresql.org" Message-id: <49BD6840.4000403@sun.com> References: <49BA53CF.4020702@sun.com> <49BA742D.3050203@sun.com> <49BA8CF6.6090604@sun.com> <49BABBCE.8090501@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/201 X-Sequence-Number: 33123 decibel wrote: > On Mar 13, 2009, at 3:02 PM, Jignesh K. Shah wrote: >> vmstat seems similar to wakeup some >> kthr memory page disk faults >> cpu >> r b w swap free re mf pi po fr de sr s0 s1 s2 sd in sy cs >> us sy id >> 63 0 0 45535728 38689856 0 14 0 0 0 0 0 0 0 0 0 163318 334225 >> 360179 47 17 36 >> 85 0 0 45436736 38690760 0 6 0 0 0 0 0 0 0 0 0 165536 347462 >> 365987 47 17 36 >> 59 0 0 45405184 38681752 0 11 0 0 0 0 0 0 0 0 0 155153 326182 >> 345527 47 16 37 >> 53 0 0 45393816 38673344 0 6 0 0 0 0 0 0 0 0 0 152752 317851 >> 340737 47 16 37 >> 66 0 0 45378312 38651920 0 11 0 0 0 0 0 0 0 0 0 150979 304350 >> 336915 47 16 38 >> 67 0 0 45489520 38639664 0 5 0 0 0 0 0 0 0 0 0 157188 318958 >> 351905 47 16 37 >> 82 0 0 45483600 38633344 0 10 0 0 0 0 0 0 0 0 0 168797 348619 >> 375827 47 17 36 >> 68 0 0 45463008 38614432 0 9 0 0 0 0 0 0 0 0 0 173020 376594 >> 385370 47 18 35 >> 54 0 0 45451376 38603792 0 13 0 0 0 0 0 0 0 0 0 161891 342522 >> 364286 48 17 35 >> 41 0 0 45356544 38605976 0 5 0 0 0 0 0 0 0 0 0 167250 358320 >> 372469 47 17 36 >> 27 0 0 45323472 38596952 0 11 0 0 0 0 0 0 0 0 0 165099 344695 >> 364256 48 17 35 > > > The good news is there's now at least enough runnable procs. What I > find *extremely* odd is the CPU usage is almost dead constant... Generally when there is dead constant.. signs of classic bottleneck ;-) We will be fixing one to get to another.. but knocking bottlenecks is the name of the game I think -Jignesh -- Jignesh Shah http://blogs.sun.com/jkshah The New Sun Microsystems,Inc http://sun.com/postgresql