• Docker

  • rutorrent script @ex_rat vs rutorrent docker @xataz

Bonjour,

Je cherche à comprendre pourquoi l'image docker de @xataz génère une montée en charge des lors que filebot commence à renommer le fichier.

Mon test est le suivant:
j ai simplement installé l image xataz/rutorrent:filebot en utilisant la commande suivante:

Run container :

docker run -dt 
  -p 9080:8080 \
  -p 6881:6881 \
  -p 6881:6881/udp \
  -p 127.0.0.1:5000:5000 \
  -e WEBROOT=/rutorrent  \
  -e DHT_RTORRENT=on     \
  -e PORT_RTORRENT=6881  \
  -e FILEBOT_RENAME_METHOD=move \
  -e FILEBOT_RENAME_SERIES="{n}/Season {s}/{n} - {s00e00} - {t}" \
  -e UID=1001 \
  -e GID=1001 \
  -v rutorrent-data-volume:/data   \
  -v /docker/config:/config        \
  xataz/rtorrent-rutorrent:filebot

URI access : http://XX.XX.XX.XX:9080/rutorrent

comme expliquer sur le lien
https://github.com/xataz/docker-rtorrent-rutorrent#advanced-launch

j ai testé avec un fichier de 20go
au moment ou filebot a commencé à bosser le cpu rutorrent est monté en flèche et s est bloqué a 100%
le load average (htop) quand a lui est monté a 12.

Avec le script de @ex_rat ainsi que filebot installé manuellement, le cpu reste au max a 40% et le load average à 5.

Par ailleurs la charge uniquement pendant le download est également différente
cpu rutorrent 30% load 3 avec l image @xataz
cpu rutorrent 15% load 1 avec le script @ex_rat

Il va sans dire que la sur charge provoquée par filebot, au moment de l ecriture sur le disque avec l'image @xataz, génère une instabilité du système.

Ce problème récurrent n'est pas uniquement lié à filebot mais également sonarr/radarr au moment du postprocessing.

Je suis également tombé sur ce post d'ou ma question, est ce que le problème est solutionné?
https://github.com/xataz/dockerfiles/issues/49

Merci

Salut,

Perso je n'ai jamais remarqué de surcharge, avec 4 rtorrent qui tourne.
Pour pouvoir comprendre le pourquoi du comment, pourrais-tu fournir un petit docker info, et également quelques information sur ta machine.

Merci par avance,

Merci pour ton aide

root@dedi-par-75092:/home# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 18.09.3
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc version: 6635b4f0c6af3810594d2770f662f34ddc15b40d
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.0-8-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.26GiB
Name: dedi-par-75092
ID: KKHV:46W3:KLCE:MVK7:VRPB:YBEL:6D6K:YR6C:2NSZ:2PM4:72HL:QGE4
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

WARNING: No swap limit support

Je n'ai aucun container actif pour le moment vu que j'ai désinstallé, s'il faut relancer l'image pour ton besoin d infos je le ferais

Infos sur machine

CPU: 	Intel Xeon E3-1230 v3 - 3.3 GHz - 4 core(s)
RAM: 	32GB - DDR3
Disque(s) Dur(s): 	2x 1TB (HDD SATA)
Bande Passante: 	Unmetered @ 1Gbps

Je precise que le symptome apparait sur de gros fichiers, clairement sur du sd le cpu n a pas le temps de monter en charge. Pour être plus précis j ai utilisé ton image pour mon script seedbox docker rclone plexdrive. Au début je pensais que cela venait de problèmes de montage lié a unionfs mais ensuite en installant qu'uniquement ton image sans rien d autre, le symptôme restait bien présent.

J'ai un serveur similaire au tien (xeon 1240 et 32Go de ram), j'ai fais quelques test avec des fichiers de 15/20Go. J'ai trois montés en charge (100% sur un coeur), lors de l'ajout du torrent, lors de la vérification du hash, et lors du lancement de filebot. Mais le load 1 ne dépasse pas les 1,5.

Je testerai de créer une image sous debian, pour voir si cela ne viendrai simplement pas de musl (on sais jamais).

Mais je soupçonne encore une fois overlay2. Il montre déjà des signe de faiblesse lors de la modification de permission, et c'est la seul grosse différence que l'on a (j'utilise personnellement btrfs).

Répondre…