> > [mi è arrivata una richiesta di approvazione del mio precedente > messaggio, che però vedo essere passato. Problemi? Sto stressando > troppo e meditate di buttarmi fuori? ;) ]
Tranquillo; non so bene a seguito di quale aggiornamento, ma tutti gli utenti risultano moderati (me compreso, sigh!). Via via che postate vi smodero. >> debian prima metteva un DB_CONFIG strapieno di commenti e opzioni, >> sostanzialmente la documentazione che si trovava nel faq'o'matic >> condensata in un file. Tra l'altro abbastanza incomprensibile. > > Mi sono riguardato a bocce ferme la documentazione fornita da debian, e > aggiungo altra carne al fuoco. > > 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). > Ma debian fornisce anche un DB_CONFIG commentato che è sostanzialmente > quello citato di 5 righe, ma con ulteriori spiegazioni e indicazioni: > > /usr/share/doc/slapd/examples/DB_CONFIG > > e che è sostanzialmente quello di sarge, mentre nel file (anche questo > sembra identico a quello di sarge) > /usr/share/doc/slapd/README.DB_CONFIG.gz > cita/riporta due documenti, ovvero: > > http://www.openldap.org/faq/data/cache/893.html > http://www.openldap.org/faq/data/cache/1075.html > > in cui si danno delle indicazioni per il calcolo della cache e per la > gestione del lock, ma non si dice molto su altri parametri. > > L'unico altro documento sembra essere: > > http://www.openldap.org/faq/data/cache/1072.html > > questo ovviamente senza saltare a leggere la documentazione di > BerkleyDB. 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. > Tra l'altro il secondo, sul calcolo della cache, mi lascia allibito: ok > che uso LDAP essenzialmente come repository di account, ma: > > rita:~# for db in /var/lib/ldap/*.bdb; do db4.2_stat -d $db | grep "Number > of tree internal pages"; done > 1 Number of tree internal pages. > 0 Number of tree internal pages. > 1 Number of tree internal pages. > 1 Number of tree internal pages. > 0 Number of tree internal pages. > 1 Number of tree internal pages. > 1 Number of tree internal pages. > 1 Number of tree internal pages. > 0 Number of tree internal pages. > 1 Number of tree internal pages. > 0 Number of tree internal pages. > 0 Number of tree internal pages. > 0 Number of tree internal pages. > 1 Number of tree internal pages. > 1 Number of tree internal pages. > 1 Number of tree internal pages. > 0 Number of tree internal pages. > 0 Number of tree internal pages. > > che facendo i conti larghi con pagine da 16K per tutto, sono 160K di > cache. Sbaglio qualcosa? 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. Ad esempio (tratto da un cliente su cui stiamo lavorando ora): db_stat -m 1GB Total cache size. 1 Number of caches. 1GB Pool individual cache size. 0 Requested pages mapped into the process' address space. 19M Requested pages found in the cache (96%). 844472 Requested pages not found in the cache. 0 Pages created in the cache. 844477 Pages read into the cache. 80 Pages written from the cache to the backing file. 769526 Clean pages forced from the cache. 6 Dirty pages forced from the cache. 0 Dirty pages written by trickle-sync thread. 74944 Current total page count. 74944 Current clean page count. 0 Current dirty page count. 131071 Number of hash buckets used for page location. 20M Total number of times hash chains searched for a page. 3 The longest hash chain searched for a page. 21M Total number of hash buckets examined for page location. 44M The number of hash bucket locks granted without waiting. 3 The number of hash bucket locks granted after waiting. 2 The maximum number of times any hash bucket lock was waited for. 2526654 The number of region locks granted without waiting. 6035 The number of region locks granted after waiting. 844513 The number of page allocations. 1553466 The number of hash buckets examined during allocations 10123 The max number of hash buckets examined for an allocation 769529 The number of pages examined during allocations 4728 The max number of pages examined for an allocation =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pool File: entryCSN.bdb 4096 Page size. 0 Requested pages mapped into the process' address space. 46 Requested pages found in the cache (66%). 24 Requested pages not found in the cache. 0 Pages created in the cache. 24 Pages read into the cache. 8 Pages written from the cache to the backing file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pool File: dn2id.bdb 4096 Page size. 0 Requested pages mapped into the process' address space. 8334140 Requested pages found in the cache (99%). 90655 Requested pages not found in the cache. 0 Pages created in the cache. 90655 Pages read into the cache. 14 Pages written from the cache to the backing file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pool File: id2entry.bdb 16384 Page size. 0 Requested pages mapped into the process' address space. 10M Requested pages found in the cache (93%). 753723 Requested pages not found in the cache. 0 Pages created in the cache. 753728 Pages read into the cache. 13 Pages written from the cache to the backing file. Come vedi, la cache e' di 1 GB, mentre le dimensioni dei files sono ls -l db/ -rw-r--r-- 1 ldapbe ldap 4096 Sep 13 11:13 alock -rw------- 1 ldapbe ldap 12288 Sep 4 15:26 certificateRevocationList.bdb -rw------- 1 ldapbe ldap 237015040 Sep 13 10:35 cn.bdb -rw------- 1 ldapbe ldap 16384 Sep 13 09:30 __db.001 -rw------- 1 ldapbe ldap 1073741824 Sep 13 09:30 __db.002 -rw------- 1 ldapbe ldap 2359296 Sep 13 09:30 __db.003 -rw------- 1 ldapbe ldap 450560 Sep 13 09:30 __db.004 -rw------- 1 ldapbe ldap 24576 Sep 13 09:30 __db.005 -rw-r--r-- 1 ldapbe ldap 168 Sep 4 15:27 DB_CONFIG -rw------- 1 ldapbe ldap 125644800 Sep 13 11:13 dn2id.bdb -rw------- 1 ldapbe ldap 4464640 Sep 13 11:13 entryCSN.bdb -rw------- 1 ldapbe ldap 8204288 Sep 13 10:35 entryUUID.bdb -rw------- 1 ldapbe ldap 1912897536 Sep 13 11:13 id2entry.bdb -rw------- 1 ldapbe ldap 3362816 Sep 13 10:35 objectClass.bdb -rw------- 1 ldapbe ldap 167936 Sep 4 15:26 ou.bdb Quindi la cache ideale sarebbe di piu' di 3 GB, ma gia' cosi' arriviamo ad una percentuale di hit del 96% e quindi basta. 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
