Subject: Re: [vserver] Shared Memory
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Thu, 29 Oct 2009 01:23:41 +0100

On Wed, Oct 28, 2009 at 01:32:04AM +0100, Holger Amann wrote:
> 
> Am 27.10.2009 um 09:54 schrieb Herbert Poetzl:
> 
> >please try with a working kernel and not with the
> >known-broken debian kernel, and recent util-vserver,
> >if the issue persists, please run an 'strace -fF' of
> >postgress for some activity, so that we can take a
> >look what happens on the query ...
> 
> 
> Ok, now I'm testing in VMware with a new kernel..
> 
> host:~# uname -a
> Linux host 2.6.31.5-vs2.3.0.36.21-beng #1 SMP Mon Oct 26 11:23:38 GMT  
> 2009 x86_64 GNU/Linux
> host:~# vserver --version
> vserver 0.30.216-pre2849
> host:~# ipcs
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x0052e2c1 0          postgres  600        378953728  4
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 0x0052e2c1 0          postgres  600        17
> 0x0052e2c2 32769      postgres  600        17
> 0x0052e2c3 65538      postgres  600        17
> 0x0052e2c4 98307      postgres  600        17
> 0x0052e2c5 131076     postgres  600        17
> 0x0052e2c6 163845     postgres  600        17
> 0x0052e2c7 196614     postgres  600        17
> 
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
> 
> host:~# vserver guest1 enter
> guest1:/# /etc/init.d/postgresql-8.4 start
> Starting PostgreSQL 8.4 database server: main.
> guest1:/# ipcs
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
> 
> The guest has following flags set:
> VIRT_MEM
> VIRT_UPTIME
> VIRT_LOAD
> VIRT_CPU

> 1. Try with no rss.soft and rss.hard set:
> Within the guest, I can open up as many connections to it's Postgres  
> as I want and execute the same query on every connection. After a  
> while, the guest's "top" shows a complete filled memory, no swapping,  
> and no kill to any process. Further connections and queries are ok,  
> available memory stays the same (filled). Almost the same result as  
> with Postgres on the host, except that the host's "top" shows the  
> amount of used memory at about +/- Postgres' shm, it never got filled  
> (shm set to about 25% of available memory)

> 2. Try with rss.soft set to 75% of hosts memory, no rss.hard set:
> Same as above, except swap got also filled. No kill, further  
> connections and queries made no difference. Everything is working.

> 3. Try with rss.soft set to 75% of host memory, rss.hard set to  
> rss.soft + 100MB:
> Memory got filled, swap got filled and then comes a kill and a  
> complete freeze (incl host!):

> Kernel panic - not syncing: Out of memory and no killable process

actually, I'd like to get that panic, preferably of
a kernel with DEBUG_INFO enabled so that we can
resolve the stack trace (if there is any)

> I don't know if the complete freeze is due to the lack of installed  
> vmware tools, but I think, it shouldn't.

nope, that actually sounds like a minor bug in the
Linux-VServer OOM handler ...

> Do you still need the strace logs? If I strace Postgres' main process,  
> the got very very big!?

well, it seems to behave exactly as on the host,
except for the OOM case (which would look similar
if it caused an unkillable OOM there), do you agree?

TIA,
Herbert