Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
От | Francois Tigeot |
---|---|
Тема | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |
Дата | |
Msg-id | 20140421162442.GA4209@sekishi.zefyris.com обсуждение исходный текст |
Ответ на | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
|
Список | pgsql-hackers |
On Mon, Apr 21, 2014 at 05:43:46PM +0200, Andres Freund wrote: > > On 2014-04-21 17:39:39 +0200, Magnus Hagander wrote: > > But do we really want a *guc* for it though? Isn't it enough (and in fact > > better) with a configure switch to pick the implementation when multiple > > are available, that could then be set by default for example by the freebsd > > ports build? That's a lot less "overhead" to keep dragging around... > > Well, we don't know at all it's just freebsd that's affected. In fact, I > would be surprised if there aren't other platforms that regressed due to > this. The only platforms affected are the BSDs. I ran (or tried to run) Pgbench on the four major ones during the last two years. My experience so far: - FreeBSD: has trouble scaling; there's some interest to improve things but nobody has done anything about it yet - NetBSD: crashes under load; this could have been fixed but when I ran the benchmarks in 2012 none of the developers seemedto care. - OpenBSD: couldn't run the benchmark; for some reason this operating system is unable to mmap() 32GB of memory on a recentPC with 128GB of RAM. - DragonFly: scales better than everything else out there even with mmap() Given these results I doubt reintroducing SysV shm memory use on PostgreSQL is worthwile; most platforms where it has a performance impact have much bigger issues to fix first. -- Francois Tigeot
В списке pgsql-hackers по дате отправления: