Workers keep getting killed #16
Assignees
Labels
bug
Something isn't working
enhancement
New feature or request
help wanted
Extra attention is needed
Comments
|
Bonjour,
version: '3.8'
services:
yggratio-flaresolverr:
image: ghcr.io/flaresolverr/flaresolverr:latest
container_name: yggratio-flaresolverr
networks:
- yggratio-network
environment:
LOG_LEVEL: ${LOG_LEVEL:-info}
LOG_HTML: ${LOG_HTML:-false}
CAPTCHA_SOLVER: ${CAPTCHA_SOLVER:-none}
TZ: Europe/Paris
restart: always
yggratio-yggproxy:
image: ghcr.io/limedrive/ygg-rss-proxy:develop
container_name: yggratio-yggproxy
expose:
- 5000
volumes:
- ./config:/app/config
environment:
TZ: Europe/Paris
YGG_USER: ${YGG_USER}
YGG_PASS: ${YGG_PASS}
RSS_HOST: yggratio-yggproxy
RSS_PORT: 5000
FLARESOLVERR_HOST: yggratio-flaresolverr
GUNICORN_PORT: 5000
LOG_LEVEL: DEBUG
networks:
- yggratio-network
restart: always
depends_on:
- yggratio-flaresolverrl'image devrait être déployée d'ici quelques minutes |
|
Même problème qu'avant. J'ai update ma conf avec ce que tu m'as donné. Merci d'avoir mis un peu d'ordre dans les logs |
|
Je n'arrive pas à reproduire, même en bastonnant les workers sur les même requêtes en simultané. Ça a l'air d'être assez lié au système quand même. Peux-tu me donner les détails de ton système sur lequel est le container ? que je vois dans les prochains jours à monter une machine avec les mêmes specs. Par ailleurs, on peut aussi essayer de réduire de moitié le nombre de workers. en ajoutant la variables d'environnement : j'ai poussé ce matin un update de l'image |
|
C'est un dédié: Intel X3440 4c/8t 2.53GHz, 8 Go ram, 8To HDD. Je vais essayer de monter le timeout on va voir si ça tient mieux. |
LimeDrive
added a commit
that referenced
this issue
Jun 15, 2024
|
Le time out est déjà sur 2 minutes. Donc c'est qu'il y a soit une fonction qui bloque quelque part, soit un problème au niveau du système. |
|
Pour information, j'ai 4 flux RSS différents pour YGG. |
|
Ha c'est peut être de l'IO's sur HDD pour la db. Du coup normalement c'est pas bien grave, sa vas levé une exception c'est tout. Tu n'a pas de worker kill par contre ici.
oui j'ai fait les test avec 8 Flux appelé en même temps en reprenant tes subcat, et je ne rencontre pas le souci, mais sur ARM et une machine récente et puissante, donc pas comparable. Je reprendrai les test dans quelque jours. |
|
Non parce que j'ai fais le test rapidement, mais je pense qu'au bout de quelques minutes le worker ayant eu le problème de co à la DB se kill et se redémarre. C'est quand même un peu pénible, ça veut dire que de temps en temps les refresh vont pas fonctionner et faudra attendre la prochaine tentative. Sur un délais de 5 minutes ça va, mais sur 1h ça fait long la tentative. Pas possible d'implémenter un petit jitter qui rajoute 3 secondes de wait entre chaque request ? L'utilisateur final s'en rendra pas compte et ça permet aux systèmes plus lents de suivre. |
LimeDrive
added a commit
that referenced
this issue
Jun 15, 2024
Fix Workers keep getting killed #16
|
Ok, je vois. Mettre un jitter sur les requêtes n'est pas forcément pertinent étant donné qu'elles seront décalées tout en même temps à part à faire du random. Sachant maintenant d'où vient le problème des workers qui se kill. J'ai mis un rétry sur les fonctions et une exclusion de l'erreur. Donc normalement, sa aura le même effet. Alors j'ai pu tester personnellement en ddos mon instance. Pour avoir une remonté d'erreur. Ça a l'air concluant. Comme d'habitude, le fix et poussé sur la « :develop ». Je te laisse tester et me confirmer si le problème est résolu. Ensuite je ferai un update de l'image de base. |
|
J'ai pas l'impression que tu aies push la dernière version sur develop, pas d'update selon github depuis 2h et j'ai toujours les mêmes erreurs. |
|
C'est bien push en auto par le ci quand j'ai commit sur la branche dev. Donc c'est que cela n' a pas fonctionné pour toi. |
LimeDrive
added
enhancement
LimeDrive
added a commit
that referenced
this issue
Jun 15, 2024
LimeDrive
added a commit
that referenced
this issue
Jun 15, 2024
Fix: Workers keep getting killed #16
|
Bon je pousse une dernière tentative pour se soir afin de réglé ton souci. Voici une vidéo du forcing sans résolution pour éviter de me faire taper sur les doigts car je ne suis pas certain que le site d'YGG apprécie mdr. Tu vois que de mon côté, ça tient quand même très bien. Monosnap.screencast.2024-06-15.23-33-04.mp4 |
LimeDrive
added a commit
that referenced
this issue
Jun 15, 2024
Fix Logs session offuscation in exception #16
|
J'ai refais des tests et ça a l'air de tenir, merci pour les updates ! Je réouvrirai une issue si jamais le problème revient. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Salut !
Super projet, j'avais fais un script de mon côté mais le tien est carrément plus complet !
Néanmoins j'ai un problème récurrent, soit mes workers se font timeout, soit SIGKILL. J'ai check j'ai largement assez de CPU et de RAM pour le faire fonctionner.
Au delà de ça, j'ai pas mal d'erreurs similaires à #4 alors que j'ai bien tout configuré.
Ma conf:
Exemples de logs:
Bref, une fois sur deux les requêtes ne passent pas. Merci pour le coup de main !
The text was updated successfully, but these errors were encountered: