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 E04BF52806 for ; Mon, 30 May 2005 14:15:21 -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 76704-02 for ; Mon, 30 May 2005 17:15:12 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 9810252816 for ; Mon, 30 May 2005 14:15:10 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j4UHF8e0024604; Mon, 30 May 2005 13:15:08 -0400 (EDT) To: "Steinar H. Gunderson" Cc: pgsql-performance@postgresql.org Subject: Re: Postgresql and xeon. In-reply-to: <20050530165447.GA9708@uio.no> References: <200505300919.40827.josh@agliodbs.com> <20050530165447.GA9708@uio.no> Comments: In-reply-to "Steinar H. Gunderson" message dated "Mon, 30 May 2005 18:54:47 +0200" Date: Mon, 30 May 2005 13:15:08 -0400 Message-ID: <24603.1117473308@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/441 X-Sequence-Number: 12605 "Steinar H. Gunderson" writes: > I must admit I still haven't really understood it -- I know that it appears > on multiple operating systems, on multiple architectures, but most with Xeon > CPUs, and that it's probably related to the poor memory bandwidth between the > CPUs, but that's about it. I've read the threads I could find on the list > archives, but I've yet to see somebody pinpoint exactly what in PostgreSQL is > causing this. The problem appears to be that heavy contention for a spinlock is extremely expensive on multiprocessor Xeons --- apparently, the CPUs waste tremendous amounts of time passing around exclusive ownership of the memory cache line containing the spinlock. While any SMP system is likely to have some issues here, the Xeons seem to be particularly bad at it. In the case that was discussed extensively last spring, the lock that was causing the problem was the BufMgrLock. Since 8.0 we've rewritten the buffer manager in hopes of reducing contention, but I don't know if the problem is really gone or not. The buffer manager is hardly the only place with the potential for heavy contention... regards, tom lane