[389-users] Re: performance tuning
Hi William,Thanks much for the quick response! This is super helpful. I’m attaching my cpu and meminfo info.dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config^ This monitors the general BDB performance.Got it.dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config^ These are monitors of unique suffixes and their indexes and othercontent like entrycaches that are per backend. Cool. One question I’ve been meaning to ask — what’s under userRoot in general?entrycachehitratio: 67^ this 5 is super important. This is saying you have only hit 67% ofthe time. You really want this to be 85% or higher, else you areconstantly importing/evicting from the entry cache. Every eviction andinclusion is costly as you have to-reread id2entry which is iointensive.I'd recommend increasing your entry cache size by double at a guess,but I'd want to see your /proc/meminfo and /proc/cpuinfo to adviseproperly. I'd also need to see your ds version and userroot config toreally advise what changes to make. Great info! I think we have plenty of RAM (64G) to make any adjustment we want.I’ve also heard of nsslapd-cachememsize — what does that control?Thanks so much, William!!Sergeicat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz stepping: 2 microcode : 0x38 cpu MHz : 2799.976 cache size : 20480 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 15 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc bogomips: 5194.03 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz stepping: 2 microcode : 0x38 cpu MHz : 2799.976 cache size : 20480 KB physical id : 1 siblings: 16 core id : 0 cpu cores : 8 apicid : 16 initial apicid : 16 fpu : yes fpu_exception : yes cpuid level : 15 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc bogomips: 5198.12 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz stepping: 2 microcode : 0x38 cpu MHz : 2799.976 cache size : 20480 KB physical id : 0 siblings: 16 core id : 1 cpu cores : 8 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 15 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc bogomips: 5194.03 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 63 model n
[389-users] Re: performance tuning
On Thu, 2017-11-16 at 21:00 -0600, Sergei Gerasenko wrote: > 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: These are all monitors for each database backend. So you have: > > dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config ^ This monitors the general BDB performance. > 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 > ^ These are monitors of unique suffixes and their indexes and other content like entrycaches that are per backend. So each of them can reveal different info. BDB can show you about the interaction between DS and the BDB on disk. So this can have some IO related impact for *all* backends. Then each backend monitor can help you understand the performance of indexes, entry cache and others. So let me help interpret yours: > 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 ^ this 5 is super important. This is saying you have only hit 67% of the time. You really want this to be 85% or higher, else you are constantly importing/evicting from the entry cache. Every eviction and inclusion is costly as you have to-reread id2entry which is io intensive. I'd recommend increasing your entry cache size by double at a guess, but I'd want to see your /proc/meminfo and /proc/cpuinfo to advise properly. I'd also need to see your ds version and userroot config to really advise what changes to make. > currententrycachesize: 10479044 > maxentrycachesize: 10485760 > currententrycachecount: 1409 > maxentrycachecount: -1 > dncachehits: 80627325 > dncachetries: 80647850 > dncachehitratio: 99 This number is good, what you want to see. > currentdncachesize: 1013607 > maxdncachesize: 10485760 > currentdncachecount: 9375 > maxdncachecount: -1 > normalizeddncachetries: 634018073 > normalizeddncachehits: 633931903 > normalizeddncachemisses: 86170 > normalizeddncachehitratio: 99 Again, also good, > 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
[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: userRoot/displayname.d
[389-users] Re: ip address based aci
On Mon, 2017-11-13 at 10:34 +0100, Jan Kowalsky wrote: > Hi William, > > thanks a lot for clearing. Sorry for the very late response! I have been quite busy :( > > Am 13.11.2017 um 00:42 schrieb William Brown: > > On Sun, 2017-11-12 at 23:06 +0100, Jan Kowalsky wrote: > > > On some comments I read that it's generally discouraged to use > > > aci's > > > with a "not" logic like: > > > > > > ip != 10.0.0.* > > > > > > or something like this. > > > > > > > The != is only an issue for targetattr, because if you do: > > > > targetattr != sn > > > > Then this includes all system attributes like nsACcountlock and > > resource limit types etc. > > > > IP addr != is fine :) > > > As long as I understood, I have to define aci's for every base dn > > > separately if I running multiple databases. Is there any way to > > > define > > > this for the whole server? > > > > If you have the databases nested IE: > > > > dc=example,dc=com > > ou=foo,dc=example,dc=com > > > > And in the mapping tree these are marked as "parent", then the aci > > of > > dc=example,dc=com should apply to ou=foo too. > > ok. So for me it doesn't work. The databases are completely > separeted. Then you can't share aci's sorry :( This is just a reality of how our aci's operate. > > > Generally, I would look at: > > > > https://research.google.com/pubs/pub43231.html > > > > IP address based security is not a good control: You should be > > using > > other factors and information to provide access I think. You could > > limit admins to using TLS user certs for identity rather than > > passwords, using minssf rules, longer password policy, etc. > > The ip based access control in my setting is only to give a > additionally > control beside the firewall. The Directory should not to be > accessible > from public internet at all. But for the case there is any error on > firewalling I want to protect the whole directory. Other access > rights > are more granular. Why not limit this based on iptables *and* your routers instead? That would be a more effective control I think than ip based access controls. Additionally, another option is remove anonymous binds (or heavily limit anonymous access), and use service accounts for applications to read attributes that they require? This could be more effective than IP controls, because when you think about an attacker, they don't just go "from internet to ldap". They'll have poped a box on your network internally, so the exfiltration route is: ds -> poped internal box -> internet. So your internet controls won't help here, because your ds is talking *internally*. Better option is limit based on service accounts and privilege than IP. I really hope this advice helps, > > Regards > Jan > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org