Observé
Sur un VPS 2 vCPU, deux passes lancées via python -m pipeline run --retry-exhausted --no-lint --no-doctor --ref … (0.4.0) ne se sont jamais terminées :
| processus |
durée écoulée |
CPU cumulé |
état |
mémoire résidente |
--ref despret_2019_habiter |
2 j 21 h |
53 h 48 |
R (actif) |
700 Ko |
--ref kopenawa_2010_chute_2,… (13 refs) |
23 h 34 |
8 h 56 |
R (actif) |
704 Ko |
Chacun avait encore son playwright/driver/node run-driver vivant, inactif.
État R continu + mémoire résidente minuscule = boucle active, pas une attente réseau. Aucune sortie n'était produite.
Conséquence : un cœur saturé en continu pendant 3 jours, puis bridage de la machine entière par l'hébergeur (90 % de temps volé), tous les autres services du serveur à l'arrêt.
Environnement
- paper-trail 0.4.0,
RESEARCH_ENABLE_SHADOW_LIBS=1
- lancé sous
xvfb-run, profil navigateur persistant
RESEARCH_ANNAS_HEADFUL_BUDGET_S non fixé pour la première passe (donc 600 s), fixé à 180 pour la seconde — les deux ont largement dépassé leur budget
Attendu
BUDGET_S + _wall_clock_guard sont censés borner la route Anna's headful, et la passe entière devrait rendre la main. Aucune des deux bornes n'a joué.
Pistes
_wall_clock_guard ne s'arme que dans le fil principal (threading.current_thread() is main_thread()) et rend la main en silence sinon : si une route s'exécute hors fil principal, il n'y a plus aucune borne dure.- Le ré-armement de
SIGALRM toutes les 15 s peut relancer _BudgetExpired à l'intérieur du finally de fermeture du navigateur.
- Aucune borne globale sur la passe
run elle-même, seulement par route.
Suggestions
- Une borne dure au niveau de
run (échéance globale, pas seulement par route), qui rende la main même si une route ne coopère pas.
- Faire échouer bruyamment
_wall_clock_guard quand il ne peut pas s'armer, plutôt que de rendre la main en silence sans protection.
- À défaut, documenter que
run doit être lancé dans son propre groupe de processus et tué par groupe : tuer le processus direct laisse les descendants en vie.
Observé
Sur un VPS 2 vCPU, deux passes lancées via
python -m pipeline run --retry-exhausted --no-lint --no-doctor --ref …(0.4.0) ne se sont jamais terminées :--ref despret_2019_habiterR(actif)--ref kopenawa_2010_chute_2,…(13 refs)R(actif)Chacun avait encore son
playwright/driver/node run-drivervivant, inactif.État
Rcontinu + mémoire résidente minuscule = boucle active, pas une attente réseau. Aucune sortie n'était produite.Conséquence : un cœur saturé en continu pendant 3 jours, puis bridage de la machine entière par l'hébergeur (90 % de temps volé), tous les autres services du serveur à l'arrêt.
Environnement
RESEARCH_ENABLE_SHADOW_LIBS=1xvfb-run, profil navigateur persistantRESEARCH_ANNAS_HEADFUL_BUDGET_Snon fixé pour la première passe (donc 600 s), fixé à 180 pour la seconde — les deux ont largement dépassé leur budgetAttendu
BUDGET_S+_wall_clock_guardsont censés borner la route Anna's headful, et la passe entière devrait rendre la main. Aucune des deux bornes n'a joué.Pistes
_wall_clock_guardne s'arme que dans le fil principal (threading.current_thread() is main_thread()) et rend la main en silence sinon : si une route s'exécute hors fil principal, il n'y a plus aucune borne dure.SIGALRMtoutes les 15 s peut relancer_BudgetExpiredà l'intérieur dufinallyde fermeture du navigateur.runelle-même, seulement par route.Suggestions
run(échéance globale, pas seulement par route), qui rende la main même si une route ne coopère pas._wall_clock_guardquand il ne peut pas s'armer, plutôt que de rendre la main en silence sans protection.rundoit être lancé dans son propre groupe de processus et tué par groupe : tuer le processus direct laisse les descendants en vie.