Barry Sitompul wrote: > 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? I don't know. > > 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 >>>> <mailto:389-users-bounces at lists.fedoraproject.org> >>>> [389-users-bounces at lists.fedoraproject.org >>>> <mailto:389-users-bounces at lists.fedoraproject.org> >>>> ] on behalf of Barry Sitompul [b.sitompul at uq.edu.au >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto:389-users at lists.fedoraproject.org> >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>> >>> -- >>> 389 users mailing list >>> 389-users at lists.fedoraproject.org >>> <mailto:389-users at lists.fedoraproject.org> >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >> -- >> 389 users mailing list >> 389-users at lists.fedoraproject.org >> <mailto: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
