On Fri, 2007-10-26 at 12:36 +0200, Petter Reinholdtsen wrote: > > #447997: nslcd: fail to reuse and release cache memory? > > I did a test with version 0.4.1, and it seem to use even more memory: > > Runs VIRT RES > 0 47 2 > 1 84 38 > 2 113 68 > 3 145 99 > 4 (killed)
That is very strange. I tried to reproduce your situation in a test directory with 2000 directories in it owned by 2000 different users and memory usage of nslcd did not increase significantly with an ls -l in that directory (not a real-world scenario I would recommend by the way). In both my test and production environment the memory usage (virtual) is stable at 47Mbyte. Could you give some more details about your environment (basically what reportbug usually includes like versions of libraries, architecture, kernel, etc). You already mentioned using Xen. I don't have a Xen setup here with which I can test the setup, but maybe I can set up a test Xen environment at work in the coming week. Also, could you include relevant information from nsswitch.conf and nss-ldapd.conf and any relevant information about your LDAP setup? Are you using nscd? Also, could you try to run nslcd under valgrind? Note that valgrind itself can also eat up quite a lot of memory. It would even be better if you could run an un-stripped version of nslcd built from source. Run valgrind as: valgrind --leak-check=full /usr/sbin/nslcd -d > valgrind.out 2>&1 (if you compile from source the nslcd binary should be owned by root for valgrind to work) Run your test a couple of times and then terminate the valgrind command with ^C. Only the last part (after "nslcd: version 0.4.1 bailing out") is really interesting. Also, you could check the different NSS requests that were done with: sed -n 's/^nslcd: DEBUG: \(nslcd_.*\)(.*)/\1/p' valgrind.out | sort | uniq -c Thanks for your bugreport and thanks for testing nss-ldapd. This really helps a great deal. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
