| 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@xxxxxxxxxxxxxxxxxxxxxxx [389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx
] on behalf of Barry Sitompul [b.sitompul@xxxxxxxxx]
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@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxxhttps://admin.fedoraproject.org/mailman/listinfo/389-users
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
