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