Bonjour,
 
Mon slapd (2.3.30 - etch) me génère énormement de log, bien que la directive loglevel soit à 0.
 
Ces logs proviennet des transactions et sont de la forme log.0000xxxx.
 
J'ai la directive " checkpoint 512 30 ".
 
J'ai rajouté également " dbconfig log_archive DB_ARCH_REMOVE " pour auto-purger les logs mais ca ne marche pas !
 
Des idées ??
 
merci

up

loglevel c'est les log dans le sens "messages de openldap".
les fichiers log.0000XYZ c'est des fichiers de logs du backend berkeley DB.
Donc 2 choses complètement différentes

Pour le checkpoint je ne saurais quoi te conseiller, je suis tombé sur ton post en cherchant justement à savoir si ca s'optimisait ou pas

Pour la suppression auto des logs, il faut mettre ça dans le DB_CONFIG de ta base :
set_flags DB_LOG_AUTOREMOVE

(nécessite un db4.2_recover pour être pris en compte).

Sinon tu fais un db4.2_archive dans le repertoire de ta base, cela va te donner tous les log.* qui ne sont plus utiles, tu peux les virer

Bon pour le checkpoint je vais pas y toucher, je pense pas que ce soit quelque chose de bien critique, enfin si mais pas au niveau des perfs, donc...

 
Oui, j'avais un peu creusé la question après mon message
 
Mais finalement, je ne pense pas que ce soit très safe... J'ai donc laissé la directive checkpoint mais augmenté les directives car a chaque ajout d'un utilisateur j'avais 10 Mo de log ! :
 
checkpoint 2048 60
 
Merki  

Faut qu'on se monte un wiki inter-Universités

why not
Ca n'existe pas déjà ?

Bon...
 
En fait je n'ai toujours pas résolu ce problème. Lors de la creation de plus de 3000 utilisateurs par mon script, les logs des transactions LDAP ont saturé le / ... plus de 20 G de logs : Plantage l'annuaire, plus de dhcp, dns, samba, etc
 
J'ai du ré-injecter un ldif à partir de notre annuaire de secours, db_recover ne marchant pas, et le / ne notre annuaire de secours étant également saturé....      
 
Bref, tout ca pour dire que je n'ai pas trouvé encore la solution pour la gestion des logs transactionnels de la base BDB.
 
D'autre part, je me suis apercu que si un fichier BDB_CONFIG est présent à la racine de la base, il écrase toutes les directives du fichiers slapd.conf.
 
J'ai bien essayé les parametres suivant dans le BDB_CONFIG, qui sont censés générer moins de log :
set_lg_regionmax 1048576
set_lg_max 10485760
set_lg_bsize 2097152
set_flags DB_LG_AUTOREMOVE
 
Le tout avec un checkpoint 1024 30 dans le slapd.conf... mais rien n'y fait... ! J'ai toujours 10 Mo de log pour la création de 2 utilisateurs !
 
Bref, à part déporter les logs sur un autre disque dédié ( set_lg_dir /mondisque/bdb-logs ) je ne vois pas...
 
Et vous ?

C'est DB_LOG_AUTOREMOVE
 
Sinon 10Mo de log pour 2 users, t'as un soucis ailleurs toi
Active donc les log (dans le sens log/journaux ) de slapd et regarde donc ce qu'il fait.
 
T'es en quelle version de slapd ? les dernière versions sont capables de prendre en charge les modifs du DB_CONFIG avec un simple reload/restart, par contre pour les plus anciennes il faut ré-initialiser la base BDB pour que ce soit pris en compte.

Ouais j'ai bien mis LOG je pense, je disais çà de tête
 
Ecoute, je fais un smbldap-useradd -A0 -B0 tout simple, et j'injecte un ldap modify par dessus. Je pense que c'est çà qui génère un log pas possible Je vais activer les logs slapd pour voir.
 
bdb 4.2 et slapd 2.3.30. Les modifs sont bien prises à la volée, je le vois avec le db_stat -l . Je monte un serveur lenny quasi-identique, je verrai si ca fait pareil

J'te dirai çà au JRES

Je confirme que c'est super bizarre ton histoire, je viens de regarder sur notre LDAP, y a eu 16385 modifs dans les 3 derniers jours, bah y a que 2 fichiers de log de 10 Mega
 
Au niveau du DB_CONFIG, je définie pas le set_lg_regionmax, je ne sais pas trop à quoi ca correspond, donc peut-être que c'est ca qui joue ?

le programme est
 
vous y allez tous les 2 ?

Oui \o/  
Pour moi ce sera mon dépuçelage de JRES, après plus de 4 ans dans l'ESR

(petit squat de topic)
c'est ouvert au privé à priori, mais y'a pas le prix de l'inscription

https://2009.jres.org/inscription/tarifs_d_inscription

Vous verrez ca dépote. J'ai pris la totale pour l'inscription  
Bon ben on se fera un rencart HFR

 
  C'est dingue ca !
Je balancerai mes parametres lundi. Mais j'ai ce comportement depuis le début !

faut déjà que je convainque ma boite de m'y envoyer

T'as qu'à leur dire que j'y serai  

Hello,
 

D'après les infos que j'ai pu glâner et les réponses que j'ai eu sur la liste openldap-technical, ce paramètre n'est pas fonctionnel avec BDB 4.2
En tout cas, chez moi, il ne fait rien, sur aucun de mes serveurs
Par contre, il semble que la directive checkpoint dans le slapd.conf influe sur le comportement mais je n'ai pas encore d'information plus précise sur cette relation, sauf que je suppute qu'en le réglant aux petits oignons ça permet d'éviter que le nombre de fichiers log.xxx n'explose    
Avec des versions plus récentes de BDB que celles packagées avec openldap sur les distribs Debian et Redhat c'est la directive txn_checkpoint du DB_CONFIG qui est prise en compte préférentiellement sur la directive checkpoint de slapd.conf mais je n'ai pas encore testé...
En tout cas, pour éviter l'explosion des fichiers log.xxx, j'y suis allé comme un bourin   , j'ai mis un slapd_db_archive -h /var/lib/ldap/ -d dans la crontab...    
 

Chez moi le nombre de fichiers de log est, grosso-modo, proportionnel au nombre d'entrées et sorties. Un slapadd de 41000 entrées génère 955 ( ) fichiers log.xxx de 1Mo alors qu'avec une base de 1800 entrées j'en ai 35.
 

set_lg_regionmax définit la taille de l'espace réservé pour stocker les noms de fichiers gérés par BDB. Normalement, ça ne devrait pas avoir beaucoup d'influence. En tout cas je n'ai jamais remarqué de différence...
 

+1
 
a+

 
edupdcvar/lib/ldap# cat DB_CONFIG
set_cachesize 0 10485760 0
set_lk_max_objects 1500
set_lk_max_locks 1500
set_lk_max_lockers 1500
set_lg_regionmax 1048576
set_lg_max 10485760
set_lg_bsize 2097152
set_flags DB_LOG_AUTOREMOVE
 
slapd.conf
backend         bdb
checkpoint 1024 30
 
A part réduire set_lg_max... Autoremove ne marche pas, je confirme... Bon ben je crois que ma seule solution reste de déporter les logs sur une autre partition ou un autre disque. Mettre un checkpoint genre 50000 120 n'etant pas vraiment judicieux je pense.

edupdcvar/lib/ldap# db4.2_stat -l
40988   Log magic number.
8       Log version number.
2MB     Log record cache size.
0600    Log file mode.
10Mb    Current log file size.
804MB 971KB 143B        Log bytes written.
804MB 965KB 563B        Log bytes written since last checkpoint.
1017    Total log file writes.
322     Total log file write due to overflow.
695     Total log file flushes.
3077    Current log file number.
2910726 Current log file offset.
3077    On-disk log file number.
2910726 On-disk log file offset.
1       Max commits in a log flush.
0       Min commits in a log flush.
3MB     Log region size.
0       The number of region locks granted after waiting.
12M     The number of region locks granted without waiting.
 
Etrange çà, on dirait que la directive checkpoint ne marche pas !?!! Elle figure dans le slapd.conf .
 
Je viens de faire un db_archive : rien
Or un db_checkpoint -1, suivi d'un db_archive marche correctement !!
 
Il y a vraiment un souci avec les logs/checkpoint sur cette version !!

Ton checkpoint il est bien déclarer dans la perspective de ton backend ?

Tu peux aussi déclarer le checkpoint dans le DB_CONFIG :
txn_checkpoint 128 15 0
# replaces checkpoint in slap.conf
# writes checkpoint if 128K written or every 15 mins
# 0 = no writes - no update

Je crois que je vais faire ca (dans le backend directement).
 
Le serveur (physique) est en prod, je vais attendre un soir C'est pas comme s'il gérait DNS DHCP SAMBA IMPRIMANTES de 30 salles Si je peux eviter de passer sur le serveur syncrepl

unrecognized name-value pair: txn_checkpoint
 
Supair

 
C'est quoi ton serveur ? (version du LDAP/OS)

Debian Etch 2.6.18-6-686-bigmem #1 SMP Sat Dec 27 10:38:36 UTC 2008 i686 GNU/Linux
 
slapd 2.3.30-5+etch2 OpenLDAP server (slapd)
 
Bon, ben j'ai déporté mes logs sur une autre partition...  set_lg_dir /home/bdb-logs . C pas génial... mais je trouve pas mieux.