How about shared memory related settings of your kernel? ie.
kernel.shmall, kernel.shmmax . Have a check with sysctl, maybe they
should be raised:
http://www.postgresql.org/docs/8.2/interactive/kernel-resources.html
Regards
Jason Lustig wrote:
I ran "ulimit -a" for the postgres user, and here's what I got:
core file size (blocks, -c) 200000
data seg size (kbytes, -d) 200000
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32635
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) 200000
open files (-n) 100
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
max rt priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) 200000
file locks (-x) unlimited
--
Jason Lustig
Israel: 054-231-8476
U.S.: 716-228-8729
Skype: jasonlustig
On Oct 16, 2007, at 10:01 AM, Richard Huxton wrote:
Jason Lustig wrote:
I lowered the maintenance_work_mem to 50MB and am still getting the
same errors:
Oct 16 09:26:57 [16402]: [1-1] user=,db= ERROR: out of memory
Oct 16 09:26:57 [16402]: [1-2] user=,db= DETAIL: Failed on request
of size 52428798.
Oct 16 09:27:57 [16421]: [1-1] user=,db= ERROR: out of memory
Oct 16 09:27:57 [16421]: [1-2] user=,db= DETAIL: Failed on request
of size 52428798.
Oct 16 09:29:44 [16500]: [1-1] user=,db= ERROR: out of memory
Oct 16 09:29:44 [16500]: [1-2] user=,db= DETAIL: Failed on request
of size 52428798.
Hmm - it's now failing on a request of 50MB, which shows it is in fact
maintenance_work_mem that's the issue.
Looking at my free memory (from TOP) I find
Mem: 2062364k total, 1846696k used, 215668k free, 223324k buffers
Swap: 2104496k total, 160k used, 2104336k free, 928216k cached
So I don't think that I'm running out of memory total... it seems
like it's continually trying to do it. Is there a reason why Postgres
would be doing something without a username or database? Or is that
just how autovacuum works?
I've not seen an error at startup before, but if it's not connected
yet then that would make sense.
I'm guessing this is a per-user limit that the postgres user is
hitting. If you "su" to user postgres and run "ulimit -a" that should
show you if you have any limits defined. See "man bash" for more
details on ulimit.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
