Ciao 2012/1/11 Michele Codutti <michele.codu...@uniud.it>
> Innanzitutto grazie per le solerti risposte. > Mi ero dimenticato di dirvi che il mio setup è un cluster di due nodi con > openldap configurato in multimaster e le letture e le scritture vengono > fatte solo su di un nodo alla volta tramite lo spostamento da un'host > all'altro dell'ip di servizio tramite il software pacemaker. > Ok > Rispondo inline. > > Il giorno 10/gen/2012, alle ore 09:40, Luca Scamoni ha scritto: > > > Ciao Michele, > > un carico così elevato potrebbe essere dovuto a qualche problema con > il db (penso a indici che si sono corrotti). > > Se vuoi analizzare le query l'unica strada è abilitare il log di slapd > (il livello stats potrebbe essere sufficiente). > > Anche abilitare il monitor backend potrebbe aiutare conteggiando le > connessioni e le query e suddividendole per tipologia. > > Un'altra cosa che può avere impatti di questo tipo è lo stacking di > overlays (soprattutto se usi overlays tipo memberOf o altri che fanno query > dinamiche) > Come faccio a capire se ci sono corruzioni degli indici? Al mio livello di > log (stats e sync) non vedo nulla che possa essere ricondotto a ciò. > Ok, allora non e' un problema di indici corrotti. Te lo dovrebbe dire abbastanza esplicitamente :-) > Il backend cn=Monitor è già attivo e sto cercando di capire i dati che mi > espone. > Da quello che vedo ho una decina di host connessi (che conosco bene, > nessun host strano) e le connessioni totali al server sono circa una > 60-ina. Alcuni aprono e chiudono connessioni con rapidità altri tengono > aperta la connessione per giorni e fanno tutte le loro query senza mai > disconnettersi. > 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"? > Gli unici overlays che ho attivato sono: > ppolicy > syncprov. > Una domanda: sono tanti 60 waiters in cn=Read,cn=Waiters,cn=Monitor? > Sinceramente non ti so rispondere perche' non ho esperienza diretta su cn=monitor > Il giorno 10/gen/2012, alle ore 09:37, Marco Pizzoli ha scritto: > > > Ciao, > > non e' detto che il carico che hai sia direttamente proporzionale al > carico effettivo. > > Io tempo fa ero andato incontro ad un bug tale per cui "ad un certo > punto" la percentuale di cpu di 1 processore andava al 100% e ci rimaneva > finche' non riavviavo. Che versione usi? L'hai compilata te o usi una in > bundle con una distribuzione Linux? > Ok me ne sono proprio scordato di mettere i dati delle versioni: uso > Debian Squeeze 6 con il pacchetto slapd 2.4.23-7.2 (dovrebbe essere > l'ultimo aggiornamento stabile fornito dalla distribuzione ed oggi). > 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. 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. Riesci a pubblicare tutta la sezione inerente al database in questione? Ovviamente mascherando la password di manager. > Il 100% e un evento raro, come ti dicevo il problema è che il carico e > costante oltre il 60% ma quasi mai sopra l'80%. Riavviando il problema non > scompare spostando l'ip "di servizio" i valori tornano sotto il 10% ma è > mormale perché le query passano all'altro host che ripresenta il fenomeno. > > > Usando cn=monitor puoi indagare che tipo di carico viene fatto sul > server LDAP. Se pensi che l'aumento di carico possa davvero essere dovuto > ad un aumento di richieste, la prima cosa che devi verificare e' se percaso > *non* hai definito degli indici. > > Oltre alla verifica nella conf, nei log ti dovrebbe dire quando sta > soddisfacendo una search su attributi non indicizzati. > Ho dato un'occhiata a cn=Monitor ma non riesco a trovare un dato che mi > faccia capire chi si sta "approfittando" del server LDAP. Ogni suggerimento > è benvenuto. > Non vedo nei log warning relativi ad attributi non indicizzati, il log è a > livello stat e sync. > > Altra domanda: i server LDAP sono virtualizzati ed hanno a disposizione > una sola CPU se, per abbassare il livello di carico, gli fornissi > un'ulteriore CPU il carico potrebbe essere ripartito equamente fra le CPU > (slapd dovrebbe essere multi-threaded) o non vale la pena? > 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*. 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. Ciao Marco
_______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
