From owner-freebsd-performance@FreeBSD.ORG Mon Nov 22 00:22:22 2010 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA54F106566C for ; Mon, 22 Nov 2010 00:22:22 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 53BFF8FC14 for ; Mon, 22 Nov 2010 00:22:21 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKKAi-0003rn-8D for freebsd-performance@freebsd.org; Mon, 22 Nov 2010 01:22:16 +0100 Received: from cpe-188-129-98-75.dynamic.amis.hr ([188.129.98.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2010 01:22:16 +0100 Received: from ivoras by cpe-188-129-98-75.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2010 01:22:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Mon, 22 Nov 2010 01:21:58 +0100 Lines: 46 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-98-75.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 Cc: freebsd-hackers@freebsd.org Subject: PostgreSQL performance scaling X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 00:22:22 -0000 This is not a request for help but a report, in case it helps developers or someone in the future. The setup is: AMD64 machine, 24 GB RAM, 2x6-core Xeon CPU + HTT (24 logical CPUs) FreeBSD 8.1-stable, AMD64 PostgreSQL 9.0.1, 10 GB shared buffers, using pgbench with a scale factor of 500 (7.5 GB database) with pgbench -S (SELECT-queries only, no disk IO) the performance curve is: -c# result 4 33549 8 64864 12 79491 16 79887 20 66957 24 52576 28 50406 32 49491 40 45535 50 39499 75 29415 After 16 clients (which is still good since there are only 12 "real" cores in the system), the performance drops sharply, and looking at the processes' state, most of them seem to eat away system call (i.e. executing in the kernel) in states "semwait" and "sbwait", i.e. semaphore wait and socket buffer wait, for example: 3107 pgsql 1 62 0 10533M 439M CPU1 0 0:02 13.57% postgres 3105 pgsql 1 63 0 10533M 438M CPU9 9 0:02 13.57% postgres 3109 pgsql 1 62 0 10533M 440M sbwait 13 0:02 13.48% postgres 3106 pgsql 1 61 0 10533M 445M sbwait 8 0:02 13.48% postgres 3118 pgsql 1 62 0 10533M 431M sbwait 21 0:02 13.48% postgres 3114 pgsql 1 63 0 10533M 434M sbwait 19 0:02 13.38% postgres 3122 pgsql 1 63 0 10533M 428M sbwait 15 0:02 13.28% postgres 3108 pgsql 1 63 0 10533M 439M sbwait 5 0:02 13.18% postgres 3116 pgsql 1 62 0 10533M 432M sbwait 11 0:02 13.18% postgres 3113 pgsql 1 62 0 10533M 430M semwai 20 0:02 13.18% postgres 3115 pgsql 1 62 0 10533M 428M RUN 14 0:02 13.18% postgres The "semwait" part is from PostgreSQL - probably shared buffer locking, but there's a large number of processes regularly in sbwait - maybe something can be optimized here? This is IPC over Unix sockets.