[RESOLU] - Charge CPU du container rtorrent de Xataz

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[RESOLU] - Charge CPU du container rtorrent de Xataz

christophebe

Hello,

Suite à quelques tests, j'ai décidé d'utiliser l'image de xataz pour la partie rtorrent/rutorrent.
Je l'ai poussé sur un serveur de tests et lorsque je checke la conso CPU de mes différents containers je vois que cette dernière consomme presque 50% de CPU.
J'ai testé un autre container rtorrent (de diameter je crois) et là j'obtiens une conso CPU plus correcte (de l'ordre de 2%).
Avez vous déjà rencontré le problème? une idée d'où cela pourrait venir?

Ci dessous l'extract de la commande : docker stats

1ier extract avec container de xataz:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
546d466c4c82        muximux             0.00%               0B / 0B             0.00%               13.3MB / 57.8kB     4.1MB / 17.7MB      0
422e4f58779c        ombi                0.11%               0B / 0B             0.00%               4.39MB / 217B       4.71MB / 10.4MB     0
76cf69a2525b        medusa              0.22%               0B / 0B             0.00%               76.8MB / 656kB      3.2MB / 138MB       0
5671e152c68f        rtorrent            48.69%              0B / 0B             0.00%               101kB / 2.27kB      983kB / 15.8MB      0
c955d5430870        lidarr              0.08%               0B / 0B             0.00%               10.3MB / 1.66MB     0B / 143MB          0
0b5b2c95dfaf        sonarr              0.01%               0B / 0B             0.00%               11.4MB / 908kB      1.9MB / 280MB       0
a59dbc67417c        radarr              0.01%               0B / 0B             0.00%               10.7MB / 944kB      0B / 323MB          0
394c241bd5ee        headphones          0.13%               0B / 0B             0.00%               10.8MB / 1.07MB     0B / 18.9MB         0
e5def4bf7555        plexpy              0.13%               0B / 0B             0.00%               27.1MB / 29.4kB     0B / 1.41MB         0
c4d27739359c        jackett             0.00%               0B / 0B             0.00%               35.1MB / 53.1kB     508kB / 23.6MB      0
2dcb74417a28        plex                0.45%               0B / 0B             0.00%               24.5MB / 430MB      4.41MB / 153MB      0
7a280db74d08        watchtower          0.00%               0B / 0B             0.00%               27MB / 438B         0B / 0B             0
b1f455daa872        portainer           0.00%               0B / 0B             0.00%               27.1MB / 2.74MB     6.23MB / 147kB      0
47acf381a944        traefik             0.01%               0B / 0B             0.00%               36.7MB / 13.7MB     778kB / 0B          0

2ieme extract avec container de diameter (en 1iere ligne):

CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
efc0d1a9c9f8        1.06%               0B / 0B             0.00%               99.8GB / 216GB      345GB / 0B          0
f104514084f5        0.00%               0B / 0B             0.00%               2.35MB / 10.4kB     11.3MB / 65.5kB     0
db05bc9f05c7        0.16%               0B / 0B             0.00%               63.7MB / 7.25MB     94.3MB / 59.5MB     0
fbd0e719b755        0.07%               0B / 0B             0.00%               10.4MB / 2.68MB     42.2MB / 0B         0
6a606486d11e        0.00%               0B / 0B             0.00%               5.92MB / 567kB      32MB / 16.4kB       0
443b9fb29e6d        0.26%               0B / 0B             0.00%               5.88MB / 5.98kB     104MB / 11.4MB      0
b15b565e0af1        0.00%               0B / 0B             0.00%               9.91MB / 28.4kB     62.9MB / 8.19kB     0
808add8cfd33        0.11%               0B / 0B             0.00%               206MB / 7.08GB      710MB / 596MB       0
e4f34dc4ff22        0.00%               0B / 0B             0.00%               5.88MB / 0B         51.5MB / 0B         0
ad374edb3614        0.24%               0B / 0B             0.00%               5.88MB / 217B       75.7MB / 9.73MB     0

Merci

A+

Chris.

Banip

Utilises les balises

[ code ] [ /code ]

(sans espace) mon ami ce sera beaucoup plus lisible 🙂

xataz

J'avais pourtant corrigé ce problème.

Je regarde ce soir pour corriger ça.

christophebe

xataz super merci

christophebe

xataz J'en profite pour te poser une question.
Sur ton container, si je modifie la partie postprocessing en adaptant ton script, est ce que lors de la prochaine mise à jour du container mes modifications seront perdues puisque le fichier concerné ne fait pas parti des volumes partagés?
Merci

xataz

christophebe C'est en cours de rebuild, dans 30 min c'est good.

Pour répondre à ta question, oui malheureusement ce sera perdu.
Par contre, les scripts de postprocessing sont gérer par rtorrent, si tu monte bien le /config, dedans tu as la configuration de rtorrent qui est persistante.

Rien ne t'empêche donc de mettre tes scripts dans un volume que tu crée toi (ou dans /config par exemple), et de les appeler dans le .rtorrent.rc.

EDIT : Je me suis permis d'éditer ton message de base, pour ajouter des balises, c'est plus propres comme ça, non ?! ^^

christophebe

xataz Merci beaucoup
Suis pas doué pour ce qui est des balises, promis je ferai des efforts pour mon prochain post.

Merci

zer

C'est bizarre ce docker stats avec des charges mémoire à 0. C'est toi qui les as édité ou ça sort comme ça ?

Chez moi, ça donne plutôt quelque chose comme ça:

CONTAINER ID        NAME                      CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
73abd5fb6390        toolz-wallabag_db         0.03%               42.8MiB / 50MiB       85.60%              75.7kB / 452kB      53.5MB / 127MB      30
5851e8b70045        toolz-wallabag            0.00%               89.5MiB / 100MiB      89.50%              6.43MB / 1.03MB     90.8MB / 122MB      9
2d923187e440        toolz-wallabag_cache      0.04%               1.312MiB / 50MiB      2.62%               1.92kB / 0B         0B / 0B             4

xataz

zer ça vient surement du fait que le cgroup memory n'est pas activé cgroup_enable=memory swapaccount=1

christophebe

je confirme, une fois cgroup memory activé j'ai bien les stats mémoire.
Xataz, j'ai vu que sur docker-hub et ton git que tu avais corrigé le problème CPU.
Par contre lorsque je relance docker-compose il me dit que je suis up-to-date
Tu as poussé sur docker hub ton container intégrant filebot?
Désolé avec toutes ces questions de débutant.

Merci de ton aide

zer

christophebe Tu as bien fait un docker-compose pull avant le docker-compose up -d?

Merrick

C'est flagrant : 6 containers qui tournaient avec cette image, mise à jour ce matin :

A voir si ça évolue avec le temps (le top est passé de 3 à 0.5 par la même occasion)

christophebe

Parfait, tout marche nickel.
C'est mon watchtower qui n'a pas fait les maj, je pige pas pourquoi, je vais creuser ce point.
Merci à tous
Je passe en résolu