Re: (ITS#4702) out-of-memory on huge DB ?

[Paolo.Rossi.con@h3g.it]

> No. As I already mentioned, there is no reason for slapcat to use  
> large amounts of RAM, it should use whatever size your BDB cache is  
> configured for and that's about it. It's possible there is a memory  
> leak, but since no such leak appears under Linux that would point  
> to either the Solaris C library or some other library specific to  
> your platform.

Today I've finished a cross test on a suse 10.0 linux

Athlon XP 2200+ 768MB RAM + 1GB swap



loaded huge db with same config, shared mem and  set_cachesize 0  
384000000 1

slapcat -f slapd.conf

and some hours later..


kernel: Out of Memory: Killed process 8915 (slapcat).
kernel: oom-killer: gfp_mask=0xd2, order=0
kernel: Mem-info:
kernel: DMA per-cpu:
kernel: cpu 0 hot: low 2, high 6, batch 1 used:3
kernel: cpu 0 cold: low 0, high 2, batch 1 used:1
kernel: Normal per-cpu:
kernel: cpu 0 hot: low 62, high 186, batch 31 used:92
kernel: cpu 0 cold: low 0, high 62, batch 31 used:26
kernel: HighMem per-cpu: empty
kernel: Free pages:        6464kB (0kB HighMem)
kernel: Active:75306 inactive:111212 dirty:0 writeback:0 unstable:0  
free:1616 slab:2595 mapped:134308 pagetables:589
kernel: DMA free:3076kB min:72kB low:88kB high:108kB active:5132kB  
inactive:4348kB present:16384kB pages_scanned:10531  
all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 751 751
kernel: Normal free:3388kB min:3468kB low:4332kB high:5200kB active: 
296092kB inactive:440500kB present:769984kB pages_scanned:737960  
all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 0 0
kernel: HighMem free:0kB min:128kB low:160kB high:192kB active:0kB  
inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0
kernel: DMA: 1*4kB 0*8kB 2*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB  
0*1024kB 1*2048kB 0*4096kB = 3076kB
kernel: Normal: 1*4kB 3*8kB 2*16kB 0*32kB 2*64kB 1*128kB 0*256kB  
0*512kB 1*1024kB 1*2048kB 0*4096kB = 3388kB
kernel: HighMem: empty
kernel: Swap cache: add 19238177, delete 19238170, find  
2371332/4902129, race 0+0
kernel: Free swap  = 0kB
kernel: Total swap = 1052216kB
kernel: Free swap:            0kB
kernel: 196592 pages of RAM
kernel: 0 pages of HIGHMEM
kernel: 2823 reserved pages
kernel: 811 pages shared
kernel: 7 pages swap cached
kernel: 0 pages dirty
kernel: 0 pages writeback
kernel: 134308 pages mapped
kernel: 2595 pages slab
kernel: 589 pages pagetables


free system swap was 0k and free mem about 6000K

the out file about 40% of DB.


I've tried also with

echo 1 > /proc/sys/vm/overcommit_memory

trying to avoid oom-killer to kill the fat slapd,
same result.

out-of-memory but, not malloc error or core dump this time.


"Dura Murphy lex, sed lex"  :)

Any program will expand to fill available memory.


Paolo