From: 李彦 Ian Li <liyan82@gmail.com>
To: Jason Lustig <lustig@brandeis.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: Autovacuum running out of memory
Date: Wed, 17 Oct 2007 00:00:57 +0800
Message-ID: <4714E039.9000005@gmail.com> (raw)
In-Reply-To: <A727D61D-09FC-4174-B120-18D5C3D5D475@brandeis.edu>
References: <374EB3D1-EE74-4B8C-9EEC-104ADD097568@brandeis.edu>
<4714A458.5060408@archonet.com>
<E8328FA1-800E-4684-93D2-A1002BB72396@brandeis.edu>
<4714AD30.6000103@archonet.com>
<57031F92-40D5-4832-8B76-FB73E510C735@brandeis.edu>
<4714C426.3080207@archonet.com>
<A727D61D-09FC-4174-B120-18D5C3D5D475@brandeis.edu>
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
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: liyan82@gmail.com, lustig@brandeis.edu
Subject: Re: Autovacuum running out of memory
In-Reply-To: <4714E039.9000005@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox