DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:disposition-notification-to:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=SLUE1m+xAO1q3q4LoycHd/Ut+OsYNtXcGxasJhTDSQFt3c/P3dnySb5Kubwes/ItXwX0Guay++tjdV3XEeLWaBAc2uU4ApZAC6sTUx7G4Ppe2GXAp+sepNhQ0BJSzKPRnkBDP6E1ZhCV65pujXnfg3c7sxVK9mbbYbc0XvlucrQ=
Message-ID: <4714E039.9000005@gmail.com>
Date: Wed, 17 Oct 2007 00:00:57 +0800
From: =?UTF-8?B?5p2O5b2mIElhbiBMaQ==?= <liyan82@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)
MIME-Version: 1.0
To: Jason Lustig <lustig@brandeis.edu>
CC: pgsql-performance@postgresql.org
Subject: Re: Autovacuum running out of memory
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>
In-Reply-To: <A727D61D-09FC-4174-B120-18D5C3D5D475@brandeis.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
>