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.
> 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.
> 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
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
