[389-users] 389 DS 1.2.5 on RHEL VM
Barry Sitompul
b.sitompul at uq.edu.au
Thu Jul 22 02:31:46 UTC 2010
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-users] 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.html>
More information about the 389-users
mailing list