From owner-freebsd-performance@FreeBSD.ORG Tue Nov 23 00:51:36 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 495E91065693 for ; Tue, 23 Nov 2010 00:51:36 +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 C03578FC26 for ; Tue, 23 Nov 2010 00:51:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKh6b-0006xC-Qa for freebsd-performance@freebsd.org; Tue, 23 Nov 2010 01:51:33 +0100 Received: from cpe-188-129-85-205.dynamic.amis.hr ([188.129.85.205]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 01:51:33 +0100 Received: from ivoras by cpe-188-129-85-205.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 01:51:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 23 Nov 2010 01:51:21 +0100 Lines: 78 Message-ID: References: <4CEA9C46.8010507@freebsd.org> 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-85-205.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 In-Reply-To: Subject: Re: 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: Tue, 23 Nov 2010 00:51:36 -0000 On 11/23/10 01:26, Ivan Voras wrote: > On 11/22/10 17:37, David Xu wrote: >> Mark Felder wrote: >>> I recommend posting this on the Postgres performance list, too. >>> >>> >>> >>> >>> Regards, >>> >>> >>> Mark >> >> I think if PostgreSQL uses semaphore for inter-process locking, >> it might be a good idea to use POSIX semaphore exits in our head >> branch, the new POSIX semaphore implementation now supports >> process-shared, and is more light weight than SYSV semaphore, >> if there is no contention, a process need not enter kernel to >> acquire/release a lock. Note that I have just fixed a bug in head >> branch. However RELENG_8 does not support process-shared semaphore >> yet. > > Another thing might be that, despite that they appear to try to avoid > it, they possibly have a large number of processes hanging on the same > semaphore, leading to thundering herd problem. > > There already is code for POSIX semaphores in PostgreSQL. It requires > some manual fiddling with the configuration to enable > (USE_UNNAMED_POSIX_SEMAPHORES). > > However, I've just tried it on 9-CURRENT and it doesn't work: > > Nov 23 01:23:02 biggie postgres[1515]: [1-1] FATAL: sem_init failed: No > space left on device Ok, I've found the p1003_1b.sem_nsems_max sysctl. It seems to help when used instead of sysv semaphores, but very little: sysv semaphores: -c# result 4 33549 8 64864 12 79491 16 79887 20 66957 24 52576 28 50406 32 49491 40 45535 50 39499 75 29415 posix semaphores: 16 79125 20 70061 24 55620 After 20 clients, sys time goes sharply up like before procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mf0 mf1 in sy cs us sy id 27 32 0 11887M 3250M 62442 0 0 0 0 0 0 0 10 255078 109047 18 73 10 30 32 0 11887M 3162M 58165 0 0 0 12 0 0 1 7 272540 114416 17 75 9 29 32 0 11887M 3105M 57487 0 0 0 0 0 0 0 8 279475 117891 15 75 10 16 31 0 11887M 3063M 59215 0 0 0 0 0 0 0 6 295342 121090 16 70 13 and the overall behaviour is similar - the processes spend a lot of time in "sbwait" and "ksem" states.