[389-users] performance tuning
Hi, I’ve been trying to estimate how optimal our settings are. I’ve read about the cn=monitor section and I see that there are several paths that have cn=monitor: dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config First question, what’s the difference between them? Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see something abnormal? # => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’ dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: monitor objectClass: top objectClass: extensibleObject database: ldbm database readonly: 0 entrycachehits: 176959465 entrycachetries: 262445216 entrycachehitratio: 67 currententrycachesize: 10479044 maxentrycachesize: 10485760 currententrycachecount: 1409 maxentrycachecount: -1 dncachehits: 80627325 dncachetries: 80647850 dncachehitratio: 99 currentdncachesize: 1013607 maxdncachesize: 10485760 currentdncachecount: 9375 maxdncachecount: -1 normalizeddncachetries: 634018073 normalizeddncachehits: 633931903 normalizeddncachemisses: 86170 normalizeddncachehitratio: 99 currentnormalizeddncachesize: 19244372 maxnormalizeddncachesize: 20971520 currentnormalizeddncachecount: 86170 dbfilename-0: userRoot/nsds5ReplConflict.db dbfilecachehit-0: 0 dbfilecachemiss-0: 3 dbfilepagein-0: 3 dbfilepageout-0: 0 dbfilename-1: userRoot/memberOf.db dbfilecachehit-1: 188045 dbfilecachemiss-1: 4684 dbfilepagein-1: 4684 dbfilepageout-1: 1325 dbfilename-4: userRoot/cn.db dbfilecachehit-4: 234345675 dbfilecachemiss-4: 69406 dbfilepagein-4: 69406 dbfilepageout-4: 6967 dbfilename-7: userRoot/numsubordinates.db dbfilecachehit-7: 64 dbfilecachemiss-7: 143 dbfilepagein-7: 143 dbfilepageout-7: 148 dbfilename-8: userRoot/uid.db dbfilecachehit-8: 23978617 dbfilecachemiss-8: 15927 dbfilepagein-8: 15927 dbfilepageout-8: 38 dbfilename-9: userRoot/fqdn.db dbfilecachehit-9: 1719355 dbfilecachemiss-9: 187947 dbfilepagein-9: 187947 dbfilepageout-9: 440 dbfilename-10: userRoot/memberallowcmd.db dbfilecachehit-10: 1615 dbfilecachemiss-10: 492 dbfilepagein-10: 492 dbfilepageout-10: 0 dbfilename-11: userRoot/krbPrincipalName.db dbfilecachehit-11: 25458823 dbfilecachemiss-11: 484795 dbfilepagein-11: 484789 dbfilepageout-11: 9526 dbfilename-12: userRoot/member.db dbfilecachehit-12: 114136 dbfilecachemiss-12: 13041 dbfilepagein-12: 13041 dbfilepageout-12: 11865 dbfilename-13: userRoot/memberUser.db dbfilecachehit-13: 27275 dbfilecachemiss-13: 849 dbfilepagein-13: 849 dbfilepageout-13: 306 dbfilename-14: userRoot/nsuniqueid.db dbfilecachehit-14: 95501 dbfilecachemiss-14: 11980 dbfilepagein-14: 11980 dbfilepageout-14: 181 dbfilename-16: userRoot/mail.db dbfilecachehit-16: 196 dbfilecachemiss-16: 209 dbfilepagein-16: 209 dbfilepageout-16: 203 dbfilename-17: userRoot/parentid.db dbfilecachehit-17: 14494 dbfilecachemiss-17: 2956 dbfilepagein-17: 2956 dbfilepageout-17: 432 dbfilename-19: userRoot/givenName.db dbfilecachehit-19: 42 dbfilecachemiss-19: 44 dbfilepagein-19: 44 dbfilepageout-19: 38 dbfilename-20: userRoot/uidnumber.db dbfilecachehit-20: 711150 dbfilecachemiss-20: 12493 dbfilepagein-20: 12493 dbfilepageout-20: 5 dbfilename-21: userRoot/ipauniqueid.db dbfilecachehit-21: 38595230 dbfilecachemiss-21: 406501 dbfilepagein-21: 406501 dbfilepageout-21: 169 dbfilename-22: userRoot/ipasudorunasgroup.db dbfilecachehit-22: 812 dbfilecachemiss-22: 242 dbfilepagein-22: 242 dbfilepageout-22: 0 dbfilename-23: userRoot/objectclass.db dbfilecachehit-23: 1027902225 dbfilecachemiss-23: 49163 dbfilepagein-23: 49163 dbfilepageout-23: 3332 dbfilename-24: userRoot/memberdenycmd.db dbfilecachehit-24: 803 dbfilecachemiss-24: 251 dbfilepagein-24: 251 dbfilepageout-24: 0 dbfilename-25: userRoot/ipakrbprincipalalias.db dbfilecachehit-25: 7957213 dbfilecachemiss-25: 226 dbfilepagein-25: 226 dbfilepageout-25: 0 dbfilename-29: userRoot/id2entry.db dbfilecachehit-29: 255566500 dbfilecachemiss-29: 9612037 dbfilepagein-29: 9612016 dbfilepageout-29: 54967 dbfilename-30: userRoot/ancestorid.db dbfilecachehit-30: 21700375 dbfilecachemiss-30: 78004 dbfilepagein-30: 78004 dbfilepageout-30: 1112 dbfilename-31: userRoot/aci.db dbfilecachehit-31: 1 dbfilecachemiss-31: 2 dbfilepagein-31: 2 dbfilepageout-31: 0 dbfilename-32: userRoot/ipasudorunas.db dbfilecachehit-32: 1875 dbfilecachemiss-32: 512 dbfilepagein-32: 512 dbfilepageout-32: 18 dbfilename-33: userRoot/nscpEntryDN.db dbfilecachehit-33: 61 dbfilecachemiss-33: 68 dbfilepagein-33: 68 dbfilepageout-33: 69 dbfilename-35: userRoot/sn.db dbfilecachehit-35: 46 dbfilecachemiss-35: 52 dbfilepagein-35: 52 dbfilepageout-35: 46 dbfilename-36:
[389-users] Performance tuning OS side
Hi *, I'm exploring 389 after few years with OpenLDAP and I'm curious to know if some perfomance tuning tricks on Linux are valid with this product too. - having a db directory located in a dedicated filesystem mounted with the noatime option - LD_PRELOAD=tcmalloc Any other hints? Thanks in advance Marco -- _ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Performance tuning OS side
Hi Marco, This is isn't linux specific, but disabling the logs(access error) can help. If you need the logs, move them to a dedicated FS. I don't know if Linux has a FS cache, but on Solaris I've seen it is sometimes more efficient to turn the DS cache settings all the way down, and allow the OS FS cache to do everything. Best Regards, Mark On 02/01/2012 04:03 PM, Marco Pizzoli wrote: Hi *, I'm exploring 389 after few years with OpenLDAP and I'm curious to know if some perfomance tuning tricks on Linux are valid with this product too. - having a db directory located in a dedicated filesystem mounted with the noatime option - LD_PRELOAD=tcmalloc Any other hints? Thanks in advance Marco -- _ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Performance tuning OS side
Disk I/O can be the most common bottleneck, make sure you have enough physical memory to fit id2entry may be one. There are also a few recommendations at http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#system-memory You can move the BDB transaction logs (*.log) in a separate filesystem, tune db cache, add indexes. And more: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/index.html M. On 02/01/2012 03:08 PM, Mark Reynolds wrote: Hi Marco, This is isn't linux specific, but disabling the logs(access error) can help. If you need the logs, move them to a dedicated FS. I don't know if Linux has a FS cache, but on Solaris I've seen it is sometimes more efficient to turn the DS cache settings all the way down, and allow the OS FS cache to do everything. Best Regards, Mark On 02/01/2012 04:03 PM, Marco Pizzoli wrote: Hi *, I'm exploring 389 after few years with OpenLDAP and I'm curious to know if some perfomance tuning tricks on Linux are valid with this product too. - having a db directory located in a dedicated filesystem mounted with the noatime option - LD_PRELOAD=tcmalloc Any other hints? Thanks in advance Marco -- _ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Performance tuning - where to begin?
W dniu 04.02.2011 21:29, Andrew Kerr pisze: Since the machine isn't even opening up a socket, it makes me think you are hitting either a connection limit or related file limit. Have you set things such as fs.file-max, tcp keepalive, and file limits (check ulimit) per the docs? Yes, I've set ulimit and fd to 4096. max open fd's about 1500. -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of David Boreham Sent: Thursday, February 03, 2011 11:42 AM To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] Performance tuning - where to begin? On 2/3/2011 9:29 AM, Daniel Fenert wrote: There are plenty of configuration options, where should I look first? My first guess would be that you've saturated one core. The server probably still processes new connections in a single thread (it did on Unix platforms last time I looked at the code at any rate). So although the CPU load overall is not 100%, once you max out one core, it won't be able to process new connections any faster. That said, the rate you are achieving seems quite low for a modern machine. It would be worthwhile looking to see if it is doing a reverse DNS lookup on the client IP address. After that, try using pstack to see what the accept thread is spending its time on. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Daniel Fenert -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
