openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 10:31 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, please find the below db_stat output of whole db, i think > which has all the cache details. The settings I'm talking about all come from slapd.conf/cn=config. They are for the back-hdb backend, not for the underlying BDB library. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, Thank you, please find the below db_stat output of whole db, i think which has all the cache details. sudo db_stat -h /var/lib/ldap/ -m *8GB Total cache size* 1 Number of caches 1 Maximum number of caches 8GB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 3653M Requested pages found in the cache (97%) 108M Requested pages not found in the cache (108847411) 12025 Pages created in the cache 108M Pages read into the cache (108846747) 904893 Pages written from the cache to the backing file 108M Clean pages forced from the cache (108193873) 25799 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 632880 Current total page count 632684 Current clean page count 196 Current dirty page count 1048573 Number of hash buckets used for page location 3816M Total number of times hash chains searched for a page (3816725185) 4 The longest hash chain searched for a page 1138M Total number of hash chain entries checked for page (1138407303) 22M The number of hash bucket locks that required waiting (0%) 3853441 The maximum number of times any hash bucket lock was waited for (0%) 20M The number of region locks that required waiting (5%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 112M The number of page allocations (112558585) 411M The number of hash buckets examined during allocations (411746763) 817981 The maximum number of hash buckets examined for an allocation 108M The number of pages examined during allocations (108226732) 45 The max number of pages examined for an allocation *1059517 Threads waited on page I/O* Pool File: labeledURI.bdb 4096 Page size 0 Requested pages mapped into the process' address space 1208388 Requested pages found in the cache (98%) 12848 Requested pages not found in the cache 0 Pages created in the cache 12848 Pages read into the cache 58547 Pages written from the cache to the backing file Pool File: entryUUID.bdb 4096 Page size 0 Requested pages mapped into the process' address space 861152 Requested pages found in the cache (87%) 121983 Requested pages not found in the cache 715 Pages created in the cache 121983 Pages read into the cache 87555 Pages written from the cache to the backing file Pool File: entryCSN.bdb 4096 Page size 0 Requested pages mapped into the process' address space 8632364 Requested pages found in the cache (97%) 194590 Requested pages not found in the cache 540 Pages created in the cache 194590 Pages read into the cache 5284 Pages written from the cache to the backing file Pool File: mail.bdb 4096 Page size 0 Requested pages mapped into the process' address space 160116 Requested pages found in the cache (96%) 5158 Requested pages not found in the cache 8 Pages created in the cache 5158 Pages read into the cache 779 Pages written from the cache to the backing file Pool File: o.bdb 4096 Page size 0 Requested pages mapped into the process' address space 20658 Requested pages found in the cache (84%) 3786 Requested pages not found in the cache 2 Pages created in the cache 3786 Pages read into the cache 611 Pages written from the cache to the backing file Pool File: uid.bdb 4096 Page size 0 Requested pages mapped into the process' address space 337280 Requested pages found in the cache (82%) 72796 Requested pages not found in the cache 286 Pages created in the cache 72796 Pages read into the cache 35684 Pages written from the cache to the backing file Pool File: objectClass.bdb 4096 Page size 0 Requested pages mapped into the process' address space 9471473 Requested pages found in the cache (99%) 1007 Requested pages not found in the cache 0 Pages created in the cache 1007 Pages read into the cache 11899 Pages written from the cache to the backing file Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 1589M Requested pages found in the cache (97%) 42M Requested pages not found in the cache (42465108) 4226 Pages created in the cache 42M Pages read into the cache (42464602) 15359 Pages written from the cache to the backing file Pool File: roleOccupant.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2593856 Requested pages found in the cache (99%) 18997 Requested pages not found in the cache 0 Pages created in the cache 18997 Pages read into the cache 7577 Pages written from the cache to the backing file Pool File: sn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38868 Requested pages found in the cache (94%) 2238 Requested pages not found in the cache 10 Pages created in the cache 2238 Pages read into the cache 1969 Pages written from the cache to the backing file Pool File: ou.bdb 4096 Page size 0 Requested pages mapped into the process' address space 66618 Requested pages found in the cache (97%) 1869 Requested pages not found in the cache 5 Pages created in the cache 1869 Pages read into the cache 3387 Pages written from the cache to the backing file Pool File: dn2id.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2003M Requested pages found in the cache (96%) 65M Requested pages not found in the cache (65777491) 5705 Pages created in the cache 65M Pages read into the cache (65777333) 19992 Pages written from the cache to the backing file Pool File: cn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38M Requested pages found in the cache (99%) 169540 Requested pages not found in the cache 528 Pages created in the cache 169540 Pages read into the cache 656250 Pages written from the cache to the backing file On Fri, Sep 29, 2017 at 8:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > >> [root@localhost ldap]# db_stat -d id2entry.bdb >> Thu Sep 21 22:16:15 2017 Local time >> >> >> date >> ^CKilled >> > > > I can tell you that doing the above is very bad, as it can leave > unfinished read transactions alive in the database, causing problems. So > doing the db_recover you did after that was a good thing to do. > > What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree > parameters are for slapd, nor what the total number of DNs are in your > database. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 1:07 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 10:47:48 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > >> >> >> SASL is a "glue" between LDAP and Kerberos, that translates an identity >> established through Kerberos AuthN to an LDAP Distinguished Name (among >> other possible uses). When communications between Kerberos and LDAP >> happen, SASL also provides encryption. >> >> I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all >> works. I dont have to muck with SSL/TLS and the different >> implementations with their specific nuances. > > Don't you still need a SSL Certificate? That is, SSL/TLS is still there > someplace? No. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > [root@localhost ldap]# db_stat -d id2entry.bdb > Thu Sep 21 22:16:15 2017 Local time > > > date > ^CKilled I can tell you that doing the above is very bad, as it can leave unfinished read transactions alive in the database, causing problems. So doing the db_recover you did after that was a good thing to do. What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree parameters are for slapd, nor what the total number of DNs are in your database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 29 Sep '17

29 Sep '17

SSSD should be configured to bind TLS with ldap:389 not ldaps:636. Increase SSSD log verbosity to get more information. I have also found that slapd logging can help determine bind issues. How does one estalish their own CA that's trusted by other Root CA's? Perhaps try disabling verification of the chain then see if bind happens. On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > >> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > >> <heller(a)deepsoft.com> wrote: > > >> > > >> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I > guess > > >> > something is wrong with slapd's TLS configuration -- it is failing > to > > >> > do TLS Negotiation, either it is just not doing it or it is doing > it > > >> > wrong (somehow). Unless SSSD is not configured properly. > > >> > > >> You need to start with the following: > > >> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > >> > > >> to test startTLS > > >> > > >> and > > >> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > >> > > >> to test without startTLS > > >> > > >> If you can get those to work, then you can move on to SSSD. > > > > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > > > additional info: TLS error -8157:Certificate extension not > found. > > > > This may be of help: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__serverfault.com_questions_640910_my-2Dcertificate- > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s= > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=> > > > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard > > to know for sure). It may also simply be a different manifistation of > the > > error above. > > I added a -d option (picked 10), and discovered that it wanted the full > name > as specificed in the certificate. That fixed ldapwhoami and I put that in > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving > (samba > is though, mostly -- it might also be having issues since sssd is not > working)... > > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip- > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=> > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > https://urldefense.proofpoint.com/v2/url?u=http-3A__www. > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo- > N7aXcKoRAXfrPUE&e= -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > > >

2 1

Re: Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Thank you, from the provided stack trace, can any one tell what is the issue? Ram On Thu, Sep 28, 2017 at 11:46 PM, Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> rammohan ganapavarapu <rammohanganap(a)gmail.com> schrieb am 29.09.2017 > um 04:33 > in Nachricht > <CALm_VjjtxJM+dEDbERPKQOz3pO84ONddvC+EzwznH2=gNwgNMw(a)mail.gmail.com>: > > Still looking for help > > Hi! > > If you have a lot of disk space and you are willing to slow don slapd > while debugging, you could try to use ltrace instead of strace to get some > more details. Depending on the compiler's optimizations you may miss some > string and memory functions, however. > > Regards, > Ulrich > > > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by brendan kearney 29 Sep '17

29 Sep '17

SASL is a "glue" between LDAP and Kerberos, that translates an identity established through Kerberos AuthN to an LDAP Distinguished Name (among other possible uses). When communications between Kerberos and LDAP happen, SASL also provides encryption. I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all works. I dont have to muck with SSL/TLS and the different implementations with their specific nuances. Though you dont know much about Kerberos, its not too difficult to implement. You seem to have the aptitude to do so. Might just be a matter of reading up on how to. On Sep 29, 2017 10:00 AM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 07:52:34 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > > > > > > > Late ti the thread, so forgive the stupid question, but why arent you > using > > SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have > OpenLDAP > > and SSSD going on, surely Kerberos is something you are able to setup. > > Does SASL replace TLS/SSL? I thought SASL had to do with password hashing > and > not anything to do with the connection protocol. I know basicly nothing > about > Kerberos. > > > > > On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote: > > > > > On 28.09.2017 21:41, Robert Heller wrote: > > > > Will these spit out useful error messages? If I just get "TLS > > > Negotiation > > > > failure" it is not going to be helpful. > > > > > > > > > > You can make it a little bit more verbose with the option "-d -1" > > > > > > It is only a suggestion, but can you test the parameter > > > > > > TLS_REQCERT allow > > > > > > in your /etc/openldap/ldap.conf > > > > > > This ist not a good option for production systems, but it seems you > come > > > in trouble with your certificates. > > > > > > You have to set your > > > > > > TLS_CACERT > > > xor > > > TLS_CACERTDIR > > > > > > correctly in your /etc/openldap/slapd.conf to work stressless with your > > > ssl/tls. > > > > > > best regards > > > Michael > > > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > > > >> > > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > > >> <heller(a)deepsoft.com> wrote: > > > >> > > > >> > > > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > > to > > > >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > > > >>> something is wrong with slapd's TLS configuration -- it is > failing to > > > do > > > >>> TLS Negotiation, either it is just not doing it or it is doing it > > > wrong > > > >>> (somehow). Unless SSSD is not configured properly. > > > >> > > > >> You need to start with the following: > > > >> > > > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > > >> > > > >> to test startTLS > > > >> > > > >> and > > > >> > > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > > >> > > > >> to test without startTLS > > > >> > > > >> If you can get those to work, then you can move on to SSSD. > > > >> > > > >> --Quanah > > > >> > > > >> -- > > > >> > > > >> Quanah Gibson-Mount > > > >> Product Architect > > > >> Symas Corporation > > > >> Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > > > >> <http://www.symas.com> > > > >> > > > >> > > > > > > > > > > > > > -- > > > Michael Wandel > > > Braakstraße 43 > > > 33647 Bielefeld > > > > > > > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > http://www.deepsoft.com/ -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Slapd is reporting TLS Negotiation failure when SSSD tries to connect to > it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > something is wrong with slapd's TLS configuration -- it is failing to do > TLS Negotiation, either it is just not doing it or it is doing it wrong > (somehow). Unless SSSD is not configured properly. You need to start with the following: >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w to test startTLS and ldapwhoami -x -H ldaps://myhost:636 -D binddn -w to test without startTLS If you can get those to work, then you can move on to SSSD. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 29 Sep '17

29 Sep '17

I went with SSSD instead as it allows offline auth and autofs caching. On Sep 28, 2017 4:51 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 5:37 PM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > > > What would you recommend as a replacement for SSSD? I am running it > > across Centos 6 and 7 clients without any issue using TLS. > > There is nss-pam-ldapd/nslcd. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > LzcKRiZzvWOzEj0Z8e60eBR_Ko8L_x3Z2raLoWXdyUA&s= > CyClJ9BrAhTZzEZ72MrchueJLdrQJoYUs-edF8f0Uw8&e=> > >

1 0

Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Hi, I have two node MMR ldap cluster with hdb, but for some reason one of the servers CPU get spiked every minute, I am not sure what is causing this spike every minute, we have same server configuration in both the server. Also when i do db_stat on *.bdb files this server is taking too long to respond for db_stat, i am pasting top and strace out put of that thread here. Also attach a graph shows cpu spikes and active threads spikes in both the servers (green and yellow lines), *Openldap Version: openldap-2.4.43* [root@localhost ldap]# db_stat -d id2entry.bdb Thu Sep 21 22:16:15 2017 Local time date ^CKilled [root@localhost ldap]# date Thu Sep 21 22:27:54 UTC 2017 * du -sh id2entry.bdb* *7.6G id2entry.bdb* DB_CONFIG sudo cat /var/lib/ldap/DB_CONFIG |grep -v "^#" set_cachesize 8 0 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_locks 3000 set_lk_max_objects 1500 set_lk_max_lockers 1500 *Top output of busy thread at the time of cpu spike:* ldap_top..20170922.165808.886367620: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165811.390769103: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165813.895158022: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165816.399627768: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165818.903936890: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165821.408275241: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165823.912707039: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.05 slapd ldap_top..20170922.165826.417287284: 61437 ldap 20 0 14.8g 13g 8.2g R 101.8 47.5 18:02.51 slapd ldap_top..20170922.165828.922186726: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:05.01 slapd ldap_top..20170922.165831.427101922: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:07.51 slapd ldap_top..20170922.165833.931996934: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:09.92 slapd ldap_top..20170922.165836.436814788: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:12.42 slapd ldap_top..20170922.165838.941597309: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:14.92 slapd ldap_top..20170922.165841.446448385: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:17.18 slapd ldap_top..20170922.165843.951329579: 61437 ldap 20 0 14.8g 13g 8.2g R 97.8 47.5 18:19.67 slapd ldap_top..20170922.165846.456172321: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:21.85 slapd ldap_top..20170922.165848.961017603: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:24.35 slapd ldap_top..20170922.165851.465897714: 61437 ldap 20 0 14.8g 13g 8.2g R 101.8 47.5 18:26.49 slapd ldap_top..20170922.165853.970797751: 61437 ldap 20 0 14.8g 13g 8.2g S 57.9 47.5 18:28.77 slapd ldap_top..20170922.165856.475641225: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165858.980268851: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165901.485817704: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165903.990499397: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165906.495260168: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165909.078879876: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165911.583657585: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165914.088384025: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165916.593114635: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165919.097562041: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165921.602221629: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165924.106739600: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165926.611115008: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165929.115600777: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165931.620082217: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165934.124916755: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd *strace output on that thread around that time:* grep "16:58:26" ldap_strace.61437 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x560271548120, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x560271548120, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 *Here is the disk activity metrics and corresponding pstack ouput captured at different time when the system is not serving any traffic other than replication:* 04:20:32 PM 19169 0.00 10042.00 0.00 slapd 04:20:34 PM 19169 0.00 45850.00 0.00 slapd 04:20:36 PM 19169 0.00 35706.00 0.00 slapd 04:20:38 PM 19169 0.00 37096.00 0.00 slapd 04:20:40 PM 19169 0.00 43654.00 0.00 slapd 04:20:40 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:20:42 PM 19169 0.00 42948.00 0.00 slapd 04:20:44 PM 19169 0.00 43272.00 0.00 slapd 04:20:46 PM 19169 0.00 37084.00 0.00 slapd 04:20:48 PM 19169 0.00 22740.00 0.00 slapd 04:20:50 PM 19169 0.00 23540.00 0.00 slapd 04:20:52 PM 19169 0.00 23540.00 0.00 slapd 04:20:54 PM 19169 0.00 7458.00 0.00 slapd 04:20:56 PM 19169 0.00 0.00 0.00 slapd 04:20:58 PM 19169 0.00 0.00 0.00 slapd 04:21:00 PM 19169 0.00 0.00 0.00 slapd 04:21:02 PM 19169 0.00 0.00 0.00 slapd 04:21:04 PM 19169 0.00 0.00 0.00 slapd 04:21:06 PM 19169 0.00 0.00 0.00 slapd 04:21:08 PM 19169 0.00 0.00 0.00 slapd 04:21:10 PM 19169 0.00 30.00 0.00 slapd 04:21:12 PM 19169 0.00 0.00 0.00 slapd 04:21:14 PM 19169 0.00 0.00 0.00 slapd 04:21:16 PM 19169 0.00 0.00 0.00 slapd 04:21:18 PM 19169 4.00 346.00 0.00 slapd 04:21:20 PM 19169 24.00 1012.00 0.00 slapd 04:21:20 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:21:22 PM 19169 0.00 14.00 0.00 slapd 04:21:24 PM 19169 6.00 1098.00 0.00 slapd 04:21:26 PM 19169 24.00 302.00 0.00 slapd 04:21:28 PM 19169 82.00 598.00 0.00 slapd 04:21:30 PM 19169 82.00 582.00 0.00 slapd 04:21:32 PM 19169 10.00 114.00 0.00 slapd 04:21:34 PM 19169 14.00 1854.00 0.00 slapd 04:21:36 PM 19169 6.00 608.00 0.00 slapd 04:21:38 PM 19169 6.00 502.00 0.00 slapd 04:21:40 PM 19169 10.00 992.00 0.00 slapd 04:21:42 PM 19169 28.00 5620.00 0.00 slapd 04:21:44 PM 19169 0.00 0.00 0.00 slapd 04:21:46 PM 19169 0.00 0.00 0.00 slapd 04:21:48 PM 19169 0.00 0.00 0.00 slapd 04:21:50 PM 19169 0.00 0.00 0.00 slapd 04:21:52 PM 19169 0.00 0.00 0.00 slapd 04:21:54 PM 19169 0.00 1018.00 0.00 slapd 04:21:56 PM 19169 0.00 44146.00 0.00 slapd 04:21:58 PM 19169 0.00 39188.00 0.00 slapd 04:22:00 PM 19169 0.00 43206.00 0.00 slapd 04:22:00 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:22:02 PM 19169 0.00 39266.00 0.00 slapd 04:22:04 PM 19169 0.00 43240.00 0.00 slapd 04:22:06 PM 19169 0.00 44358.00 0.00 slapd 04:22:08 PM 19169 0.00 43790.00 0.00 slapd 04:22:10 PM 19169 0.00 38186.00 0.00 slapd 04:22:12 PM 19169 0.00 36304.00 0.00 slapd 04:22:14 PM 19169 0.00 42903.48 0.00 slapd 04:22:16 PM 19169 0.00 42246.00 0.00 slapd 04:22:18 PM 19169 0.00 9720.00 0.00 slapd *Thu Sep 21 16:20:40 UTC 2017* Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00007fc704acce6c in __db_tas_mutex_unlock () from /lib64/libdb-4.7.so #1 0x00007fc704b74738 in __dbc_close () from /lib64/libdb-4.7.so #2 0x00007fc704b7492d in ?? () from /lib64/libdb-4.7.so #3 0x00007fc704b750da in __dbc_get () from /lib64/libdb-4.7.so #4 0x00007fc704b7f9dd in __dbc_get_pp () from /lib64/libdb-4.7.so #5 0x00005638f67a458c in hdb_id2entry () #6 0x00005638f679b6f8 in hdb_cache_find_id () #7 0x00005638f675041d in hdb_search () #8 0x00005638f67304c2 in overlay_op_walk () #9 0x00005638f6730624 in ?? () #10 0x00005638f66c69e9 in fe_op_search () #11 0x00005638f66c62b6 in do_search () #12 0x00005638f66c3ad4 in ?? () #13 0x00005638f66c3e3b in ?? () #14 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #15 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fc4e9d79700 (LWP 19174)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fc4e9578700 (LWP 19175)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fc4e8d77700 (LWP 19176)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fc4d7fff700 (LWP 19179)): #0 0x00007fc7032229ad in connect () from /lib64/libpthread.so.0 #1 0x00007fc705458d0c in ldap_connect_to_host () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc705442ece in ldap_int_open_connection () from /lib64/libldap_r-2.4.so.2 #3 0x00007fc705455f1d in ldap_new_connection () from /lib64/libldap_r-2.4.so.2 #4 0x00007fc7054424bf in ldap_open_defconn () from /lib64/libldap_r-2.4.so.2 #5 0x00007fc705457458 in ldap_send_initial_request () from /lib64/libldap_r-2.4.so.2 #6 0x00007fc70544c63f in ldap_sasl_bind () from /lib64/libldap_r-2.4.so.2 #7 0x00007fc70544ca19 in ldap_sasl_bind_s () from /lib64/libldap_r-2.4.so.2 #8 0x00005638f66baf52 in slap_client_connect () #9 0x00005638f672997d in ?? () #10 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #11 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fc4d77fe700 (LWP 19293)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc4d6ffd700 (LWP 23630)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fc4d67fc700 (LWP 23631)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc4d5ffb700 (LWP 23632)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc4d57fa700 (LWP 23633)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc4d4ff9700 (LWP 23634)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc705895780 (LWP 19169)): #0 0x00007fc70321cf17 in pthread_join () from /lib64/libpthread.so.0 #1 0x00005638f66c0dc9 in slapd_daemon () #2 0x00005638f66a7d68 in main () *Thu Sep 21 16:20:42 UTC 2017* Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00005638f66cfa88 in entry_decode () #1 0x00005638f67a44a2 in hdb_id2entry () #2 0x00005638f679b6f8 in hdb_cache_find_id () #3 0x00005638f675041d in hdb_search () #4 0x00005638f67304c2 in overlay_op_walk () #5 0x00005638f6730624 in ?? () #6 0x00005638f66c69e9 in fe_op_search () #7 0x00005638f66c62b6 in do_search () #8 0x00005638f66c3ad4 in ?? () #9 0x00005638f66c3e3b in ?? () #10 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #11 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fc4e9d79700 (LWP 19174)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fc4e9578700 (LWP 19175)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fc4e8d77700 (LWP 19176)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fc4d7fff700 (LWP 19179)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fc4d77fe700 (LWP 19293)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc4d6ffd700 (LWP 23630)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fc4d67fc700 (LWP 23631)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc4d5ffb700 (LWP 23632)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc4d57fa700 (LWP 23633)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc4d4ff9700 (LWP 23634)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc705895780 (LWP 19169)): #0 0x00007fc70321cf17 in pthread_join () from /lib64/libpthread.so.0 #1 0x00005638f66c0dc9 in slapd_daemon () #2 0x00005638f66a7d68 in main () Thu Sep 21 16:20:44 UTC 2017 Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00005638f6706b30 in ad_keystring () #1 0x00005638f6706c6e in slap_bv2ad () #2 0x00005638f66cf9d6 in entry_decode () #3 0x00005638f67a44a2 in hdb_id2entry () #4 0x00005638f679b6f8 in hdb_cache_find_id () #5 0x00005638f675041d in hdb_search () #6 0x00005638f67304c2 in overlay_op_walk () #7 0x00005638f6730624 in ?? () #8 0x00005638f66c69e9 in fe_op_search () #9 0x00005638f66c62b6 in do_search () #10 0x00005638f66c3ad4 in ?? () #11 0x00005638f66c3e3b in ?? () #12 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #13 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #14 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): After i did db_recover db_stat is responding fast but cpu spikes are still there, is there any way to find if my db is bad? Thanks, Ram

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical