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.
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ò. 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? Gli unici overlays che ho attivato sono: ppolicy syncprov. Una domanda: sono tanti 60 waiters in cn=Read,cn=Waiters,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 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? 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
