X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 8C4B052BAA for ; Sat, 30 Jul 2005 04:57:53 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 85800-03 for ; Sat, 30 Jul 2005 07:57:44 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id 3F92E528C7 for ; Sat, 30 Jul 2005 04:57:43 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 39AF230B42; Sat, 30 Jul 2005 10:05:38 +0200 (MET DST) From: William Yu X-Newsgroups: pgsql.performance Subject: Re: Performance problems on 4/8way Opteron (dualcore) Date: Sat, 30 Jul 2005 00:57:38 -0700 Organization: Hub.Org Networking Services Lines: 20 Message-ID: References: <200507291046.10318.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en In-Reply-To: To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.018 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200507/492 X-Sequence-Number: 13733 I've been running 2x265's on FC4 64-bit (2.6.11-1+) and it's been running perfect. With NUMA enabled, it runs incrementally faster than NUMA off. Performance is definitely better than the 2x244s they replaced -- how much faster, I can't measure since I don't have the transaction volume to compare to previous benchmarks. I do see more consistently low response times though, can run apache also on the server for faster HTML generation times and top seems to show in general twice as much CPU power idle on average (25% per 265 core versus 50% per 244.) I haven't investigated the 2.6.12+ kernel updates yet -- I probably will do our development servers first to give it a test. > The problem as I remember it boiled down to the Linux kernel handling > memory/process management very badly on large dual core systems -- > pathological NUMA behavior. However, this problem has apparently been fixed > in Linux v2.6.12+, and using the more recent kernel on large dual core > systems generated *massive* performance improvements on these systems for > the individuals with this issue. Using the patched kernel, one gets the > performance most people were expecting.