Difference between revisions of "MultiCoreAccounting"
(→Etape 1) |
(→Questions ouvertes) |
||
Ligne 53: | Ligne 53: | ||
Q (Edith Knoops) - Si on met reparse = true dans /etc/apel/parser.config cela va pas tout reparser ? | Q (Edith Knoops) - Si on met reparse = true dans /etc/apel/parser.config cela va pas tout reparser ? | ||
− | + | Solution : pas la pein de mettre reparse =true | |
− | |||
− | |||
− | |||
− | |||
Latest revision as of 09:19, 17 décembre 2014
Sommaire
Multicore Deployment
Accounting: Publishing multicore accounting to APEL works. ARC CEs publish correctly. For CREAM CEs to make it work it has to be an EMI-3 CE and it has to be enabled in the configuration.
Edit /etc/apel/parser.cfg and set the attribute parallel=true.
If the site was running multicore already, before upgrading and/or applying this modification, they need to reparse and republish the corrected accounts.
Mise en place de la solution
Une fois l'attribut corrigé sur les CREAM_CE (parallel=true), il faut reparser et republier les accountings. La solution vient en deux étapes :
- 1- les sites doivent reparser leur accounting
- 2- F. Schaer doit forcer une nouvelle publication
Etape 1
(info de Frédéric Schaer)
Pour forcer un reparsing il faut modifier la database sur node56 directement, ce que peut faire chaque site pour ses machines.
Donc pour le CPPM comme exemple :
mysql> select * from ProcessedFiles where filename like '%20141111%' limit 5 ;
Si le CPPM voulait reparser /var/torque/server_priv/accounting/20141111 et ce *uniquement* pour marsched, alors il devrait faire un truc du genre :
mysql> explain delete from ProcessedFiles where HostName='marsched.in2p3.fr' and filename like '%20141111%';
Si le CPPM veut forcer le reparsing de l'ensemble du mois et pour toutes ses machines, alors :
mysql> explain delete from ProcessedFiles where filename like '%201411%';
- pas besoin de mettre "reparse = true" dans /etc/apel/parser.config
- il suffit de faire une "delete" des fichiers que l'on veut remplacer
- et de relancer le "apel-pbs-log-parser", ce que nous avons fait sur nos trois CREAM-CE et notre TORQUE (apres avoir mis "parallel=true")
- seuls les fichiers "deletés" (et le fichier du jour) sont alors reloadés dans la DB de node65.
Etape 2
Le reparsing n'est pas suffisant, il faut ensuite que que F. Schaer force une republication, et pour cela il faut lui dire quels mois republier (i.e : la publication va forcer le joint sur les fichiers reparsés)
A noter : Frédéric doit faire un fichier de config spécifique par site (ça n'utilise pas d'arguments CLLI), et lancer un process apel sur chacun de ces fichiers. Comme chaque site n'a pas les même dates, Frédéric doit faire cette manipulation à la main.
Questions ouvertes
Q (Edith Knoops) - Si on met reparse = true dans /etc/apel/parser.config cela va pas tout reparser ?
Solution : pas la pein de mettre reparse =true
Q (Edith Knoops) - il faut reparser uniquement le scheduler ou aussi les creams ? Dans mon cas les 2 creams ont du multicoeurs et utilise un scheduler unique.
R (Fred. Schaer) - à voir
Liens utiles
Le lien pour voir un accounting « local » (extrait directement de mysql) des sites se trouve ici : https://node56.datagrid.cea.fr:20001/
L’accès est restreint à la CA GRID2-FR
Status des sites affectés
Impact | Depuis le | Statut Reparsing | Statut Republication | |
---|---|---|---|---|
CPPM | - | 29 septembre | non | non |
IPHC | faible | - | non | non |
LAPP | grand | 15 juillet | non | non |
LPC | faible | - | non | non |
LPSC | moyen | 1 octobre | non | non |