Hi Rich, Thanks for the reply. I've been running around hassling people here to get a physical server that I can use to replicate the problem but it has not been successful, so I'll get back to you when I have one. Another thing is, I did pmap on the ns-slapd process and it shows that there are a lot of [ anon ] blocks consuming a lot of memory, is this behaviour normal? 00002aaaabe48000 1024 988 988 rw--- [ anon ] 00002aaaac000000 64268 38772 33972 rw--- [ anon ] 00002aaaafec3000 1268 0 0 ----- [ anon ] 00002aaab0000000 65536 24688 20124 rw--- [ anon ] 00002aaab4000000 131072 99644 88160 rw--- [ anon ] 00002aaabc000000 2031616 924376 872948 rw--- [ anon ] 00002aab38000000 65536 15828 11192 rw--- [ anon ] 00002aab3c000000 2621436 598472 517272 rw--- [ anon ] 00002aabdbfff000 4 0 0 ----- [ anon ] 00002aabdc000000 524288 237020 228388 rw--- [ anon ] 00002aabfc000000 65536 16540 11952 rw--- [ anon ] 00002aac00000000 131072 33356 24332 rw--- [ anon ] 00002aac08000000 65536 14224 10136 rw--- [ anon ] 00002aac0c000000 131072 31536 22076 rw--- [ anon ] 00002aac14000000 65536 15208 10520 rw--- [ anon ] 00002aac18000000 64548 14040 11680 rw--- [ anon ] 00002aac1c000000 65536 16744 11940 rw--- [ anon ] 00002aac20000000 130612 33384 30144 rw--- [ anon ] 00002aac28000000 65536 15176 10980 rw--- [ anon ] 00002aac2c000000 65536 26216 23736 rw--- [ anon ] 00002aac30000000 131000 17800 13784 rw--- [ anon ] 00002aac37fee000 72 0 0 ----- [ anon ] 00002aac38000000 64676 32576 31408 rw--- [ anon ] 00002aac3c000000 65536 37536 36288 rw--- [ anon ] 00002aac40000000 131072 13088 9716 rw--- [ anon ] 00002aac48000000 65536 26684 26680 rw--- [ anon ] 00002aac4c000000 851512 447144 391852 rw--- [ anon ] 00002aac80000000 851968 353196 340412 rw--- [ anon ] 00002aacb4000000 524288 254504 239860 rw--- [ anon ] 00002aacd4000000 65320 35184 35184 rw--- [ anon ] 00002aacd8000000 131072 89508 87040 rw--- [ anon ] 00002aace0000000 458752 112824 96136 rw--- [ anon ] 00002aacfc000000 65536 36076 35856 rw--- [ anon ] 00002aad00000000 262144 154340 154244 rw--- [ anon ] 00002aad10000000 319968 122592 120272 rw--- [ anon ] 00002aad23878000 7712 0 0 ----- [ anon ] 00002aad24000000 64564 34044 34044 rw--- [ anon ] 00002aad28000000 130700 108392 107840 rw--- [ anon ] Thanks! On 16/07/2010, at 1:16 AM, Rich Megginson wrote: > Barry Sitompul wrote: >> Hi All, >> >> >> Thanks for the replies! >> >> I am running the DS on a RHEL 5.5 x86_64 VM. >> >> It's got 8GB of RAM and out of that I allocated 600MB for the LDBM >> plugin cache. I have four backend databases so does it mean 600 x >> 4 = >> 2.4GB in total? Plus 3.8GB in total for the database entry caches. >> >> after a closer look, the virtual memory usage spikes everytime an >> unindexed search is performed. Now I've got one sitting at 10G >> virtual >> memory usage. I would think that the usage should be limited to the >> maximum cache size above. >> > Not necessarily, if it is memory that is not used by either the entry > cache or the db caches. > > Can you reproduce this behavior on bare metal (i.e. not a vm)? >> I started with the clean install of the VM and the 389-DS 1.2.5 so I >> don't think there is a problem with the OS, but thanks for the offer >> Gerrard. >> >> What can cause the memory usage to always go up and not limited to >> the >> max cache size? >> >> >> Cheers! >> Bazza >> On 13/07/2010, at 7:06 PM, Gerrard Geldenhuis wrote: >> >> >>> Hi Barry, >>> I am running the DS on VirtualBox with only 512Mb ram and 2500 >>> users. I am using vanilla install from EPEL and Centos 5.5 fully >>> updated. Unless you have memory problems I can't see why the same >>> would not work for you. Granted I use a very clean install. I can >>> send you the package removal listings in the kickstart if you are >>> interested. Other than that, providing more information about your >>> versions as stated in another reply will be the best course of >>> action. >>> >>> Regards >>> ________________________________________ >>> From: 389-users-bounces at lists.fedoraproject.org [389-users-bounces at lists.fedoraproject.org >>> ] on behalf of Barry Sitompul [b.sitompul at uq.edu.au] >>> Sent: 13 July 2010 00:26 >>> To: General discussion list for the 389 Directory server project. >>> Subject: 389 DS 1.2.5 on RHEL VM >>> >>> Hi All, >>> >>> >>> >>> Has anyone had the experience of running the DS on a VM? >>> >>> I've got one set up running on a RHEL VM and it looks like the >>> virtual >>> memory usage keeps going up and stays up with every LDAP query (I >>> just >>> use top). >>> >>> I'm not sure if this is caused by the application problem or this is >>> expected RHEL behaviour? >>> >>> Any help is much appreciated! >>> >>> >>> >>> Thanks! >>> >>> Bazza >>> >>> >>> >>> >>> -- >>> 389 users mailing list >>> 389-users at lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> ________________________________________________________________________ >>> In order to protect our email recipients, Betfair Group use SkyScan >>> from >>> MessageLabs to scan all Incoming and Outgoing mail for viruses. >>> >>> ________________________________________________________________________ >>> -- >>> 389 users mailing list >>> 389-users at lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >> -- >> 389 users mailing list >> 389-users at lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100722/eba021b6/attachment-0001.html