Luca Polidoro wrote:
Salve, volevo sottoporre una problematica che stiamo riscontrando sulla nostra infrastruttura ldap. L'architettura è composta da 1 master e da 16 repliche. Sono tutte Solaris 9 Sparc, e la versione di OpenLdap usata è la 2.3.39. La replica è affidata al syncrepl di tipo refreshOnly, e avviene ogni 15 minuti. I thread sono settati a 16, per tutte le macchine. La scrittura dei dati è abilitata soltanto sul master, mentre le repliche fanno solamente lettura dei vari client che fanno accesso ai sistemi. Come dicevo prima, da qualche giorno stiamo avendo dei problemi con lo slapd sul master. Infatti analizzando i dati forniti dal prstat, vediamo che, mentre l'occupazione della cpu si mantiene su valori normali (tra il 2% e il 17%), i valori della memoria occupata dal processo, Size e la RSS, salgono continuamente, sino ad arrivare ad un valore, 3942 per il Size e 2262 per l'RSS, dopo il quale il processo muore (appena partito il processo sale velocemente a valori alti solo sul master, sulle repliche no).. Abbiamo notato che ogni 7 ore circa il processo va giù. E' possibile che questo comportamento anomalo sia dovuto all' numero elevato di Repliche che si collegano direttamente al Master con il syncrepl? Esiste per il syncrepl, un numero massimo, o comunque un numero massimo consigliato, di repliche che possono collegarsi al Master, oltre il quale possono sussistere problemi come quello sopra evidenziato?
Non esiste alcun limite al numero di repliche, se non appunto legato all'esaurimento delle risorse. In ogni caso, non dovrebbero esserci particolari ragioni per cui la presenza di connessioni da parte di consumer syncrepl debba risultare in un uso spropositato di risorse sul producer. Questo puo' essere una conseguenza di una memory leak o di una malconfigurazione di slapd, che consente a back-bdb e Berkeley DB un ammontare di memoria eccessivo rispetto a quanto effettivamente disponibile. Per verificare la presenza di memory leak ti consiglio di eseguire slapd producer sotto un memory profiler (ti direi valgrind, se non fosse intel-specific; non ho suggerimenti per Solaris/sparc).
Inoltre, abbiamo notato anche un comportamento strano del syncrepl. Infatti in alcune situazioni, ancora non abbiamo capito con esattezza quali, il processo di replica risulta non funzionante. Per farlo riandare dobbiamo passare i vari consumer a refreshAndPersist, e successivamente ritornare alla situazione refreshOnly. In questa maniera il processo di replica torna a funzionare correttamente.
Modificare il "type" non e' una soluzione valida (anche se funziona come "rattoppo"). Il motivo per cui la replicazione non avviene correttamente non e' chiaro, ma se la replicazione e' parziale o errata, e syncrepl non si accorge di dover fare un full resync, dovrebbe essere sufficiente riavviare gli slapd consumer, eventualmente resettando il cookie da usare (opzione -c "rid=<rid>"). Questa operazione non richiede necessariamente il riavvio di slapd se usi back-config. In tale caso, basta cancellare e riaggiungere l'attributo olcSyncRepl relativo. Nota che si tratta comunque di un workaround per un problema che syncrepl dovrebbe trovare da solo.
In ogni caso, dato che 2.3.39 e' piuttosto vecchia, ti consiglio un aggiornamento, preferibilmente a 2.4.12/14 (quest'ultima prossima all'uscita; verifica il changelog per la quantita' di fixes in quest'area sia in 2.3 che in 2.4).
Ciao, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: a...@sys-net.it ----------------------------------- _______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
