cpu load average 1, 1, 1 au minimum

[ignami]

Bonjour,

J'utilise depuis plusieurs années un NAS DS213 en version DSM 6.0.2-8451 Update 1. Il me sert uniquement de serveur de fichier, accessible uniquement sur le réseau local. Dans les paquets installés, il y a l'analyseur de stockage, antivirus essential et php 5.6.

Depuis environ deux semaines, l'appareil est devenu un peu bruyant (le ventilateur). Un htop en SSH ou le monitoring de performance de l'interface Web signalent tous les deux un load average relativement important puisqu'il ne descend jamais au-dessous de 1, alors qu'il n'y a pas de tâches visibles. La température, selon l'interface Web est normale, signe que le ventilateur fait son travail. Seulement, je ne vois pas quel(s) processus pourrai(en)t être la cause de cette charge CPU importante. Par exemple dans htop, en triant les processus selon le % de charge CPU, il n'y a pas de processus qui très actif ni longtemps actif (voir capture ci-jointe). Aussi je ne comprends pas cette charge.

Récemment, j'ai réorganisé l'arborescence de mes fichiers, ce qui fait que j'ai déplacé des dossiers importants en volume (600 Go, 200 Go) sur une taille disponible de 4 Go (redondant). J'ai aussi mis à jour mon Synology, ce que je n'avais pas fait depuis assez longtemps (de la version 5 à la 6).

Comment pourrais-je faire pour avoir un détail plus fin de ce qui cause cette charge CPU, afin de savoir que faire pour la réduire et retrouver un peu plus de calme dans mon petit appartement ?

Merci d'avance.

[Fenrir]

Le LOAD n'est pas nécessairement lié à de la charge CPU, le load indique (à peu de choses près) le nombre de processus en attente dans la file de traitement.

Il peut y avoir plusieurs causes, les plus fréquentes sont :

• utilisation cpu : ça n'a pas l'air d'être ton cas
• latence disque => un disque fatigué ou entrain de lâcher peut vite faire monter la charge
• utilisation mémoire : ce n'est pas lisible sur ta vue, mais comme tu ne swap pas ça doit être ok
• réseau : c'est rare qu'un process se bloque à cause de ça
• ... tout autre composant matériel/logiciel mal utilisé : presque aucune chance

ps : htop c'est sympa, mais ce n'est pas très pratique pour déboguer, il vaut mieux utiliser ps (par exemple avec ps -eo state,pid,cmd | grep "^D")

[ignami]

Merci Fenrir pour ta réponse.

Du coup ta commande ps me donne : D 517 [xhci_thread]. D signifie donc uninterruptable sleep, ce qui n'est pas très clair pour moi.

L'hypothèse du disque fatigué est intéressante. Je vais regarder ça.

[Fenrir]

uninterruptable => qui ne peut pas être interrompu

Sauf très rares exceptions, c'est un appel en ring0, parfois en ring1 (aucun rapport avec H. Nakata ... quoique ...).

C'est presque toujours lié à une actions qui attend un retour d'IO => la piste du disque se confirme.

Tu peux tenter de faire un sync (c'est une commande) au cas où le soucis serait lié à ton gros mouvement.

Regarde aussi du coté de /proc/mdstat

Mais surtout => vérifie tes sauvegardes

[ignami]

cat /proc/mdstat :

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid1 sda5[0] sdb5[1]
      3902283648 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda2[0] sdb2[1]
      2097088 blocks [2/2] [UU]
      
md0 : active raid1 sda1[0] sdb1[1]
      2490176 blocks [2/2] [UU]
      
unused devices: <none>

Le sync n'a en apparence rien donné.

Edit : je suis en train de vérifier mes sauvegardes.

Modifié le 28 septembre 2016 par ignami

[Fenrir]

Il y a 10 heures, ignami a dit :

Le sync n'a en apparence rien donné.

sync ne renvoi rien, c'est normal, il dit juste au système : "si tu as des écritures en attente, termine les" - un peu comme un commit/rollback sur un base