Mandi! Pierangelo Masarati In chel di` si favelave... > Tranquillo; non so bene a seguito di quale aggiornamento, ma tutti gli > utenti risultano moderati (me compreso, sigh!). Via via che postate vi > smodero.
...non è che usate come backend della lista openldap? ];-))) > > Ancora non mi è chiaro se è meglio usare DB_CONFIG o i parametri > > annegati nello slapd.conf con 'dbconfig', supponendo che sia la stessa > > cosa. > E' la stessa cosa, non ricordo da che versione in poi. Nota che per > Berkeley DB l'unico modo di configurare e' attraverso il DB_CONFIG; > infatti, non ricordo piu' per quale motivo, se i parametri sono modificati > via API poi occorre un db_recover. Ora che OpenLDAP fa il db_recover in > automatico solo se necessario, e dal momento che si mette via i valori > correnti dei parametri, e' in grado di capire se sono cambiati e quindi se > il db_recover e' necessario, e se lo e' lo esegue. A seguito di questo, > e' divenuto possibile spostare le informazioni del DB_CONFIG all'interno > di slapd.conf(5). Credo di aver capito; sarebbe bello sapere se, visto che sono presenti entrambi, quali vengono poi alla fine considerati se differenti... bah, quisquilie! ;) > Non e' proibito, ne' porta sfiga leggere la documentazione del Berkeley. ;-) > Anzi, dato che lo fanno loro, si presume che ne sappiano di piu' e siano > piu' autoritativi di qualunque altra fonte, tant'e' che per questo motivo > OpenLDAP si rifiuta di documentare piu' del dovuto gli internals di > Berkeley. Ok, mi sta bene. ma allora non capisco il commento un pelo acido (almeno a me è parso) del tuo collega Luca Scamoni: >> Tra l'altro hanno specificato opzioni con bassissimo impatto sulle >> prestazioni (nella maggior parte dei casi, set_lk_???) mentre non fanno >> alcuna menzione di opzioni decisamente piu' significative quali >> set_lg_max, set_lg_dir e set_lg_bsize ... Da tutto questo ambaradan mi pare che si faccia comunque riferimento a tre 'classi' di parametri: 1) cache size 2) lock, che come segnala debian, possono essere un grosso problema se finiscono 3) logfile, che sono sicuramente un punto di fine tuning importante, ma che nel caso 'normale' (openldap come backend account e password) credo incida pochisismo (si legge tanto, ci si scrive mai). Ovvero mi sembra che debian non abbia fatto scelte tragicamente sbagliate, ponendo la cache a 2MB (ci stanno comodamente dentro qualche centinaio di account) e alzando il numero dei lock per precauzione. Poi ha sicuramente presunto l'uso di openldap come database (passatemi il termine improprio) write once/read many, e quindi non ha trattato di logfile. Sinceramente mi pare una scelta condivisibile e abbastanza conservativa, se qualcuno ha database enormi e/o esigenze speciali solitamente sa gia come e quanta documentazone leggersi. ;) Senza contare che poi ha fornito specifici README e puntatori a documentazione ufficiale nel README.Debian che qualsiasi sysadmin Debian sa che *deve* leggere. E questo non per voler prendere le difese per principio di Debian o altre distribuzioni, ma credo che sia impossibile per una distribuzione fornire una configurazione di openldap per tutte le situazioni, è sicuramente meglio fornire una configurazione decente per il caso 'normale' e puntatori a buona documentazione per il resto. > Veramente il calcolo si fa con db_stat -m; la dimensione della cache, > brutalmente, va confrontata con la dimensione dei fils del DB. Se riesci > a metterli tutti in cache sei a posto. Se non ci riesci, o non ti > conviene, puoi guardare a quante richieste non sono state soddisfatte > dalla cache. In base alla percentuale, vedi se ti conviene aumentare o > meno. Il secondo documento che ho citato diceva sostanzialmente (se ho capito bene) occorre perlomeno avere abbastanza memoria per contenere tutti i nodi interni di tutti i database se si vuole evitare il trashing; la cosa è assolutamente plausibile, se non è così il backend è costretto a swappare dentro/fuori la cache il database financo in fase di ricerca... Spero di non tediare nessuno. ;) -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 _______________________________________________ OpenLDAP mailing list [email protected] https://www.sys-net.it/mailman/listinfo/openldap
