From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stef <svb(at)ucs(dot)co(dot)za> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Strange problems with more memory. |
Date: | 2004-08-16 15:41:16 |
Message-ID: | 14009.1092670876@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Stef <svb(at)ucs(dot)co(dot)za> writes:
> It seems I was mistaking, as I started getting these kind of errors in dmesg :
> VM: killing process postmaster
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process postmaster
This looks like the infamous OOM-kill kernel bug^H^H^Hfeature. Turn off
memory overallocation in your kernel to get more stable behavior when
pushing the limits of available memory.
> But the database is just as slow as before. (By slow I mean not as
> fast as it should be on such a powerful machine compared to much worse
> machines running the same processes)
If your concern is with a single nightly process, then that quad Xeon is
doing squat for you, because only one of the processors will be working.
See if you can divide up the processing into several jobs that can run
in parallel. (Of course, if the real problem is that you are disk I/O
bound, nothing will help except better disk hardware. Way too many
people think they should buy a super-fast CPU and attach it to
consumer-grade IDE disks. For database work you're usually better off
spending your money on good disks...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stef | 2004-08-16 16:23:14 | Re: Strange problems with more memory. |
Previous Message | Vivek Khera | 2004-08-16 15:12:37 | Re: Replication: Slony-I vs. Mammoth Replicator vs. ? |