Date: Tue, 17 Apr 2007 14:51:55 -0400 From: Kevin Way <kevin@insidesystems.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-performance@freebsd.org Subject: Re: Anyone interested in improving postgresql scaling? Message-ID: <4625174B.5090208@insidesystems.net> In-Reply-To: <20070417174825.X42234@fledge.watson.org> References: <461B0CD0.8090404@insidesystems.net> <20070417174825.X42234@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Robert Watson wrote: > > On Tue, 10 Apr 2007, Kevin Way wrote: > >> Kris Kennaway wrote: >>> If so, then your task is the following: >>> >>> Make SYSV semaphores less dumb about process wakeups. Currently >>> whenever the semaphore state changes, all processes sleeping on the >>> semaphore are woken, even if we only have released enough resources >>> for one waiting process to claim. i.e. there is a thundering herd >>> wakeup situation which destroys performance at high loads. Fixing >>> this will involve replacing the wakeup() calls with appropriate >>> amounts of wakeup_one(). >> Could this cause problem cause a situation where an 8-Core system was >> 50-75% slower than an otherwise equivalent 2-Core system? >> >> I have a graph of my sysbench/pgsql results here: >> >> http://blog.insidesystems.net/files/sysctl-pgsq-amd64-wtf.png >> >> As the graph shows, the 8-core system is about half the speed of the >> 2-core system at 2 simultaneous threads, and it decays down to >> approximately 1/4 the speed of the 2-core system as the # of threads >> hits 5. >> >> All other (non-pgsql, non-sysv) tests came back approximately as >> expected, but I'm left wondering if I did something wrong, or if 8 >> cpus are slower than 2, when it comes to Postgres on currently >> available FreeBSD. >> >> Kevin Way Inside Systems, Inc. >> >> (Full detail of what I did is available at: >> http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong ) > > Would you be able to re-run these tests trying a recent 7.x kernel? > If so, make sure you build a non-debugging kernel, and try two > variants: one with SCHED_4BSD, and one with SCHED_ULE. > > Another experiment that would be interesting is to try using > device.hints to disable various numbers of CPUs on your 8-core system, > and see how the performance graph changes as the number of enabled > CPUs changes. > > Robert N M Watson > Computer Laboratory > University of Cambridge I built 7.0 as of 6 days ago, and ran the same test using 8-cores, ULE and 4BSD. The results are available at: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 Unfortunately, I can't run the additional tests, as the machines in question have now been deployed to production. I should have similar equipment available in a few weeks, and will try the other tests at that point. Kevin Way Inside Systems, Inc. [-- Attachment #2 --] 0 *H 01 0 + 0 *H 0b0ˠ ? tz.30 *H 0_1 0 UUS10U VeriSign, Inc.1705U .Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H 0 ZDUz-Ox6 JoTw*h1ApzKHV-BD\B/;' ]6B3nTOJ ƚj$e~7jJ 00U 0 0GU @0>0< `HE0-0++ www.verisign.com/repository/RPA01U *0(0&$" http://crl.verisign.com/pca1.crl0 U 0 `HB0 *H }oEK8Sd!L+ @ 9j2!,Yb}U87sfcbSpRR[-Ϭ1Tԋ#+2}, |.wDe Mtst.;5r@1ӲīV00^ RVX#0 *H 010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 070308000000Z 070507235959Z010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)981 0 U Persona Not Validated1&0$U Digital ID Class 1 - Netscape10U Kevin Way1&0$ *H kevin@insidesystems.net0"0 *H 0 0'۵6Wr<0yPw;!d5 b"z% g?C@t5ㄻ##lRu8011!WC9Ǿl p PGZBLۨNMw_#O4 N=@y: 3pL瓝%B!p dmeshd~CB Z~+jp)d{K8(}IYxy2ȧKr}?2zgCkxbɡ( j;KY 00 U 0 0DU =0;09 `HE0*0(+ https://www.verisign.com/rpa0 U 0 U %0++03U ,0*0(&$"http://crl.verisign.com/class1.crl0 *H $uMspZhkl-t!6ޠ=2#D佻 ⎖sWl \,s]t'E(;v L: QKKo"Ka3bcrR00^ RVX#0 *H 010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 070308000000Z 070507235959Z010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)981 0 U Persona Not Validated1&0$U Digital ID Class 1 - Netscape10U Kevin Way1&0$ *H kevin@insidesystems.net0"0 *H 0 0'۵6Wr<0yPw;!d5 b"z% g?C@t5ㄻ##lRu8011!WC9Ǿl p PGZBLۨNMw_#O4 N=@y: 3pL瓝%B!p dmeshd~CB Z~+jp)d{K8(}IYxy2ȧKr}?2zgCkxbɡ( j;KY 00 U 0 0DU =0;09 `HE0*0(+ https://www.verisign.com/rpa0 U 0 U %0++03U ,0*0(&$"http://crl.verisign.com/class1.crl0 *H $uMspZhkl-t!6ޠ=2#D佻 ⎖sWl \,s]t'E(;v L: QKKo"Ka3bcrR100010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated^ RVX#0 + 0 *H 1 *H 0 *H 1 070417185155Z0# *H 1l˪*N@eGD0R *H 1E0C0 *H 0*H 0 *H @0+0 *H (0 +710010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated^ RVX#0 *H 1䠁010U VeriSign, Inc.1 0 U VeriSign Trust Network1F0DU =www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated^ RVX#0 *H v ţ+F7YٓybC {̖ 8I?Muc pwG_hJ:P(. v;>tzpvRSֳ: Z@/!3,8| Kj-yܒ<,+Fbf ^Zي'SIs.WՌ6xLmYZ@ΫT}BTʿԶu$P ǻs2.b50tm 1ATbyR_ZVHإI͆0\Vć
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4625174B.5090208>