Marco Gaiarin wrote: > Credo di aver capito; sarebbe bello sapere se, visto che sono presenti > entrambi, quali vengono poi alla fine considerati se differenti... > bah, quisquilie! ;)
La cosa funziona cosi': - se DB_CONFIG non e' presente nella cartella del database e i dbconfig sono presenti nello slapd.conf, il DB_CONFIG equivalente viene generato e usato; - se DB_CONFIG e' presente nella cartella del database e i dbconfig sono presenti nello slapd.conf, questi ultimi vengono bellamente ignorati - diversa e' la cosa infine se i dbconfig vengono definiti mediante back-config, ovvero modificando il database cn=config mediante operazioni LDAP: in questo caso, le modifiche hanno effetto immediato, risultando in un recover del database. > Da tutto questo ambaradan mi pare che si faccia comunque riferimento a > tre 'classi' di parametri: > > 1) cache size Fondamentale: se il tuo db ha meno di 100/1000 entries, puoi fare a meno del DB_CONFIG e basta; altrimenti almeno la cache e' fondamentale per avere prestazioni decenti > 2) lock, che come segnala debian, possono essere un grosso problema se > finiscono Ma in pratica e' raro che finiscano, a meno che tu non faccia tonnellate di operazioni, e soprattutto modifiche, concorrenti > 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). Vedi sopra. Ma (almeno secondo noi) e' piu' probabile che uno debba toccare i log, ad esempio mandandoli su un altro disco, che il numero di lock. > 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. Solo che 2MB di cache va bene forse per chi su LDAP mette un centinaio di utenti e non li cambia mai. In questo caso, non si capisce perche' sia necessario toccare il numero di lock (forse non serve neppure modificare la cache...) > 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. Sono d'accordo sul fatto che una distribuzione faccia bene a fornire default propri tarati sul presunto default della sua utenza, mentre OpenLDAP fa bene a non farlo perche' non ha una utenza tipo e quindi rischia di essere fuorviante. >> 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... Si, ma il punto critico e' che se anche allochi cache sufficiente per contenere tutti i files degli indici (e se ti scappa la mano con gli indici possono essere grandi), poi non sai che cosa Berkeley effettivamente metta nella cache... 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 Email: [EMAIL PROTECTED] --------------------------------------- _______________________________________________ OpenLDAP mailing list OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
