2012/1/13 Michele Codutti <michele.codu...@uniud.it> > Il giorno 11/gen/2012, alle ore 19:17, Marco Pizzoli ha scritto: > > >> Non riesco a capire pero a parità di connessione che impatto hanno > sulla loro esecuzione sul server, ovvero: quali query mi stanno occupando > la maggior parte del tempo di esecuzione? > >> > > Nei log dovresti vedere quanto tempo ti ci ha messo a soddisfare ogni > query.Lo ricavi dalla sequenza di bind/search/[unbind|abort]. Riesci a fare > una grep "intelligente"? > Ho "spulciato" il ramo cn=Operations di cn=Monitor dove trovo le quattro > entry di cui mi hai parlato. > I dati che espongono non sono di tipo temporale ma di tipo "contatore", es: > dn: cn=Search,cn=Operations,cn=Monitor > objectClass: monitorOperation > cn: Search > createTimestamp: 20111222084912Z > creatorsName: cn=monitoring,cn=Monitor > entryDN: cn=Search,cn=Operations,cn=Monitor > hasSubordinates: FALSE > modifiersName: cn=monitoring,cn=Monitor > modifyTimestamp: 20111222084912Z > monitorOpCompleted: 100811850 <--- > monitorOpInitiated: 100811851 <--- > structuralObjectClass: monitorOperation > subschemaSubentry: cn=Subschema > Qui mi riporta il numero delle operazioni di ricerca effettuate e quelle > in attesa ma non riesco a capire (ad esempio) come ottenere il tempo medio > di esecuzione. >
Io intendevo nei log testuali. > > Il suggerimento migliore che ti posso dare e' sicuramente di aggiornare. > Mi pare che su sid tu abbia gia' a disposizione l'ultima 2.4.28. > Potrei farlo, andando a pescare nei backports, ma non credo che darebbe > dei risultati perché questo fenomeno perdura da quando avevo installato lo > slapd di lenny. Successivamente ho reinstallato la macchina con squeeze e > l'ho sincronizzata tramite syncrepl. Appena l'IP di servizio è passato alla > nuova macchina squeeze il carico è risalito ai livelli della lenny. E' > proprio questo elemento che mi ha convinto a scrivere alla ML. > Allora potrebbe essere un problema di corruzione dei metadati di sincronizzazione. Mi e' capitato anche questo almeno fino alla versione 2.4.23... Verifica che la sincronizzazione dell'orologio tra i sistemi del multi-master funzioni sia ok. Se il problema del picco di cpu e' la corruzione dei metadati, il picco di cpu lo avresti a prescindere dall'aggiornamento futuro di versione... Lo potresti risolvere droppando (e facendolo ricreare) uno dei 2 db, dopo che li hai aggiornati entrambi all'ultima versione che puoi/vuoi installare. Tieni conto che dalla versione tua a quella attuale sono state patchate parecchie cose relative al sync-repl. Eviteresti cosi' che il problema si ripresenti. > > Sicuramente anche la conf sarebbe da guardare. Avendo una sola cpu ad > esempio dovresti abbassare il numero di thread generato. Il default e' 16. > Il suggerimento e' di averne 4 per processore, quindi nel tuo caso proprio > 4. > Ho lasciato il default (ovvero non ho configurato il parametro). Ma come > workaround temporaneo volevo aumentare i processori (virtuali) assegnati > alla macchina per cui il suggerimento è prezioso. > > > Riesci a pubblicare tutta la sezione inerente al database in questione? > Ovviamente mascherando la password di manager. > Ti riporto più dati possibile nell'ordine in cui sono presenti nel config > (che è lungo): > database bdb > suffix "dc=example,dc=com" > directory /var/lib/ldap > rootdn "cn=replicator,dc=example,dc=com" > > index objectClass,entryUUID,entryCSN > eq > index departmentNumber,employeeNumber,employeeType,title > eq,sub > index uid,cn,sn,gn,mail,displayName,telephoneNumber > pres,eq,sub > > dbconfig set_cachesize 0 4194304 0 > dbconfig set_lg_bsize 524288 > dbconfig set_lg_max 10485760 > dbconfig set_flags DB_LOG_AUTOREMOVE > dbconfig mutex_set_max 10000 > > checkpoint 102400 10 > cachesize 4000 > idlcachesize 20000 > Un po' di cose su questa tua configurazione. - C'e' un motivo particolare per cui usi "bdb" anziche' "hdb" ? Se no, ti suggerisco calorosamente di cambiare. "bdb" e' ormai praticamente fuori manutenzione. Dovrai poi droppare/ricreare il db - ti suggerisco di passare ad usare la shared memory: usa la direttiva "shm_key 1000". Dovresti poter apprezzare un miglioramento delle prestazioni. Ci sarebbe altro che puoi fare, ma penso che una buona partenza potrebbe essere questa. Fammi sapere Ciao > Il resto sono ACL (molte), direttive per il syncrepl, altre cose per il > tls/ssl. > > > OpenLDAP e' fortemente thread-izzato, quindi se necessario i processori > lui li usa. Una volta appurato che hai gli indici creati *e usati*, non e' > tanto normale un carico di cpu cosi' elevato... > > Quante entry ha il tuo database? Quanta memoria (virtuale) ha il sistema? > > Quello che fa sicuramente la differenza in OpenLDAP e' la memoria e la > cache. In particolare OpenLDAP mette 3 livelli di cache in gioco. Prima di > andare avanti, ti chiedo di pubblicare la conf del db in questione ed il > file DB_CONFIG di quel database. > Il database è relativamente piccolo circa 4000 entry in tutto tra foglie e > nodi intermedi. > Le query sono principalmente composte da search su uid e autenticazioni, > ovviamente non mancano altre query sugli attributi che ho indicizzato. > Il server ha assegnato 512 MB di RAM di cui il report del comando free è > il seguente: > total used free shared buffers cached > Mem: 521052 467860 53192 0 19920 164988 > -/+ buffers/cache: 282952 238100 > Swap: 1004020 88492 915528 > > Il contenuto del DB_CONFIG è il seguente (che in realtà riprende le > direttive specifiche dello slapd.conf): > set_cachesize 0 4194304 0 > set_lg_bsize 524288 > set_lg_max 10485760 > set_flags DB_LOG_AUTOREMOVE > mutex_set_max 10000 > > > Se mi invii anche le righe di log di startup dello slapd riesco ad avere > qualche info in piu'. > > Potrebbe magari interessarti anche mascherare il tuo suffix. > Purtroppo non le ho più il rotate ha oramai rimosso i log contenenti > quelle informazioni. > > Michele Codutti > Area Servizi Informatici e Telematici (AINF) > Universita' degli Studi di Udine > via Delle Scienze, 208 - 33100 UDINE > tel: +39 0432 558928 > fax: +39 0432 558911 > e-mail: michele.codutti at uniud.it > > > > _______________________________________________ > OpenLDAP mailing list > OpenLDAP@mail.sys-net.it > https://www.sys-net.it/mailman/listinfo/openldap > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison
_______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
