Re: [PERFORM] shared_buffers 284263 on OS X

2006-11-19 Thread Guido Neitzer
Am 19.11.2006 um 04:13 schrieb Brian Wipf: It certainly is unfortunate if Guido's right and this is an upper limit for OS X. The performance benefit of having high shared_buffers on our mostly read database is remarkable. I hate to say that, but if you want best performance out of

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Ron Mayer
Tom Lane wrote: Craig A. James [EMAIL PROTECTED] writes: Here's something I found googling for memory overcommitment+linux http://archives.neohapsis.com/archives/postfix/2000-04/0512.html That might have been right when it was written (note the reference to a 2.2 Linux kernel), but it's

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Ron Mayer
Tom Lane wrote: Craig A. James [EMAIL PROTECTED] writes: Here's something I found googling for memory overcommitment+linux http://archives.neohapsis.com/archives/postfix/2000-04/0512.html That might have been right when it was written (note the reference to a 2.2 Linux kernel), but it's

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Michael Stone
On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote: On linux you can use the sysctl utility to muck with vm.overcommit_memory; You can disable the feature. Be aware that there's are reasons the feature exists before you cast aspersions and quote marks all over the place, and the

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Richard Broersma Jr
(Maybe other people are just better at configuring their memory usage?) I don't mean to hijack the thread, but I am interested in learning the science behind configuring memory usage. A lot of the docs that I have found on this subject speak in terms of generalities and rules of thumb.

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Michael Stone
On Sun, Nov 19, 2006 at 12:42:45PM -0800, Richard Broersma Jr wrote: I don't mean to hijack the thread, but I am interested in learning the science behind configuring memory usage. There isn't one. You need experience, and an awareness of your particular requirements. If it were easy, it

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Craig A. James
Michael Stone wrote: At one point someone complained about the ability to configure, e.g., IRIX to allow memory overcommit. I worked on some large IRIX installations where full memory accounting would have required on the order of 100s of gigabytes of swap, due to large shared memory

PostgreSQL with 64 bit was: Re: [PERFORM] shared_buffers 284263 on OS X

2006-11-19 Thread Guido Neitzer
Am 18.11.2006 um 19:44 schrieb Guido Neitzer: It might be, that you hit an upper limit in Mac OS X: [galadriel: memtext ] cug $ ./test test(291) malloc: *** vm_allocate(size=2363490304) failed (error code=3) test(291) malloc: *** error: can't allocate region test(291) malloc: *** set a

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Michael Stone
On Sun, Nov 19, 2006 at 02:12:01PM -0800, Craig A. James wrote: And speaking of SGI, this very issue was among the things that sank the company. As the low-end graphics cards ate into their visualization market, they tried to become an Oracle Server platform. Their servers were *fast*. But

Re: [PERFORM] Postgres server crash

2006-11-19 Thread Craig A. James
You realize that it had to be turned on explicitly on IRIX, right? But don't let facts get in the way of a good rant... On the contrary, with Irix 4 and earlier it was the default, but it caused so many problems that SGI switched the default to OFF in IRIX 5. But because it had been available