Aller au contenu

Limite d' unRAID, de mes HDD ou du CPU ?

mrlafrite

Messages recommandés

mrlafrite Débutant

mrlafrite

Posté(e)
Posté(e)

Bonjour les ami.e.s inpactien.ne.s,

Je me suis monté un NAS avec du matériel de récupération, le tout tournant sous unRAID :
- OS : unRAID 6.7.0
- CPU : AND FX-8150 (4C/8T à 3,6Ghz)
- RAM : 4 x 4 Go DDR3
- HDD : 4 x 4 To IRONWOLF
- ETH : 1000 Mbps

Tout fonctionne parfaitement … sauf quand j’ai mon docker duplicati qui exécute une tâche de sauvegarde et qui rend impossible la lecture d’un flux vidéo sur mon kodi d’une box androidTV (avec adaptateur 1000 Mbps USB) ou même un flux audio sur le VLC de mon PC.

Je détaille :

  • Les 4 disques sont montés en un « array » logiciel crypté, avec un disque de parité. Une sorte de RAID5. La stratégie de répartition des partage est en « High-water » se qui fait que mes données se trouve réparties entre tous mes disques (mais de manière aléatoire). L’intégrité de mon array est bonne. Pas de disque avec erreur SMART non plus.array.jpg

  • La vidéo à lire sur kodi est un .mkv FHD avec un débit moyen de 8 Mbps.

  • La musique écouté sur kodi est un .flac avec un débit moyen d’environs 1 Mbps.

  • Un docker transmission tournait en même temps avec un téléchargement régulier bridé à 0.25 Mbps. Ce docker a 1 x thread dédié.

  • Mon docker duplicati v.2.0.4.5 a 4 x threads dédiés (2 core et 2 HT), avec l’option « aes-set-threadlevel » configuré sur « 4 ». La tâche en exécution est une sauvegarde cryptée de ~600 Go de photos et vidéos personnelles (pour de vrai ! :-D) sur un FTP (sur le réseau local) par paquet de 500 Mo.
    Le CPU est chargé à ~20% pendant la tâche.
    charge_CPU.png
    La RAM n’est pas impactée.
    charge_RAM.png
    Le réseau n’est pas vraiment impacté non plus car il ne dépasse pas les 30 Mbps lors de l’envois sur le FTP.
    charge_ETH.jpg
    Les HDD sont sollicités à hauteur de 15-20 Mo/s.
    charge_HDD.jpg
    => Sur les graphs, tout roule ! (hormis que ça soit lent ...)

Ce sont les seuls périphériques actifs sur le NAS et bien évidement le flux vidéo est lisible en temps normal (lorsque duplicati n’exécute pas de tâche). Pour preuve ; la mise en pause du docker duplicati a permis une lecture normale de la vidéo ou encore de la musique.

Mes questions sont les suivantes :

  • Est-ce que se sont bien les limites physiques d’accès disques de mes HDD qui créent ce phénomène ? Ou est que le goulot vient du CPU lors du cryptage/zippage des archives duplicati ?
  • Est-ce que changer la méthode de répartition de mes données sur les disques pourrait changer la donne ? (Passage en « Most Free »)
  • Est-ce que changer la configuration des disques arrangerais ? (actuellement GPT: 4K-aligned
  • Est-ce que l’ajout d’un SSD de cache à mon « array » supprimerai ça ?
  • Une autre idée pour mon problème ?

Merci d'avance

Lien vers le commentaire
Partager sur d’autres sites
MeowMeow Mentor

MeowMeow

Posté(e)
Posté(e)
Il y a 11 heures, mrlafrite a écrit :

Bonjour les ami.e.s inpactien.ne.s,

Coool. Je ne suis plus seule.

Les sauvegardes, tu ne peux pas les mettre en décaler, genre tard le soir?

Quand veeam me fait des sauvegardes à chaud, les serveurs sont inutilisables.

Lien vers le commentaire
Partager sur d’autres sites
mrlafrite Débutant

mrlafrite

Posté(e)
  • Auteur
Posté(e)
Il y a 27 minutes, trOmAtism a écrit :

Les sauvegardes, tu ne peux pas les mettre en décaler, genre tard le soir?

C'est déjà le cas. C'était la première sauvegarde.

Je rencontre cette même problématique si je lance 3 flux vidéos FHD/UHD de mes 3 kodi .... (ça met hors de cause mon CPU du coup).

Est-ce que le NFS serait plus adapté par rapport à SMB ?

Lien vers le commentaire
Partager sur d’autres sites
brice.wernet Vétéran

brice.wernet

Posté(e)
Posté(e)

Bonjour,

Je ne connaissais pas unraid, ça a l'air sympa!

Quand on parle de stockage, la bande passante est un indicateur, mais le nombre d'IO/s l'est tout autant. Par exemple, un disque dur qui lit des données séquentielles (piste à piste) aura des temps d'accès < 1ms, on peut donc compter sur un nombre d'opérations/s de l'ordre de 1000 à 3000. Par contre, un disque dur dont la tête doit se déplacer aléatoirement ou attendre un secteur particulier du disque aura des temps d'accès de l'ordre de quelques ms (mettons  8, c'est déjà un très bon disque), soit un maximum de 1/0,008 = 125 opérations par secondes.

Donc si ton système doit faire des accès très aléatoires, les perfs s'écroulent. Surtout sur des disques à 5900TPM.

 

Mixer deux types de charge, ou avoir des système de sauvegarde qui parallélisent trop et font chercher les données dans tous les sens en même temps est parfois un problème. C'est peut-être le cas.

J'aurais donc tendance à limiter les ressources de duplicati à 1CPU pour voir. Le job ne sera peut-être même pas plus long!

De plus, je ne suis pas familier de docker, je ne sais pas si on peut vraiment le limiter à 2C+2HT. Par ailleurs, est-ce que tu lis les fichiers MKV directement ou au travers d'un serveur media qui fait du transcodage? Je soupçonne un problème d'affectation de CPUs. Quand tu dis 2C+2HT dédiés, tu as désigné les processeurs? C'est une manoeuvre à éviter, en général les systèmes se débrouillent mieux tout seuls pour répartir les charges.

Surtout que tu utilise du cryptage, et je ne suis pas sûr que dans une archi bulldozer les instructions AES-NI par exemple soient dédoublées (il est possible que chaque Core ne puisse pas hyperthreader ces instructions)

 

Enfin:

* Le cache SSD c'est bien surtout si tu ne lis pas TOUT ton contenu régulièrement. Donc si ton duplicati fait de la deduplication pour éviter de resauvegarder tout, le cache SSD est génial. Si tous les jours tu lis 600G au travers du cache, il n'a pas de grand intérêt.

 

Bref:

* Vérifier que limiter duplicati à 1 coeur ne suffisent pas pour régler le problème

Lien vers le commentaire
Partager sur d’autres sites
brice.wernet Vétéran

brice.wernet

Posté(e)
Posté(e)
Il y a 1 heure, mrlafrite a écrit :

Je rencontre cette même problématique si je lance 3 flux vidéos FHD/UHD de mes 3 kodi .... (ça met hors de cause mon CPU du coup).

Pas encore. Si le cryptage est logiciel, ça peut jouer. Mais je penche pour des disques trop lents pour des accès aléatoires.

D'ailleurs sur le graphe des disques, je n'avais pas tilté en première lecture: comment se fait-il que tu écrives autant que tu lises??? Le FTP de sauvegarde est sur ton unraid?

J'aurais pensé que tu aurais une part d'écriture (jaune) quasi à 0 et un read énorme! D'ailleurs, le graphe c'est read+write cumulé ou read dessiné "derrière" write? Donc 18M/s (dont 15 d'écriture) ou 33M/s (18 de lecture + 15 d'écriture)?

Lien vers le commentaire
Partager sur d’autres sites
mrlafrite Débutant

mrlafrite

Posté(e)
  • Auteur
Posté(e)
Il y a 48 minutes, beankylla a écrit :

est ce que tu peux observer ce qui se passe sur ton PC au niveau du CPU / Réseau quand tu lances les 3 flux avec KODI?

Que veux-tu dire par observer ? les flux réseaux ?

Il y a 36 minutes, brice.wernet a écrit :

Quand on parle de stockage, la bande passante est un indicateur, mais le nombre d'IO/s l'est tout autant. Par exemple, un disque dur qui lit des données séquentielles (piste à piste) aura des temps d'accès < 1ms, on peut donc compter sur un nombre d'opérations/s de l'ordre de 1000 à 3000. Par contre, un disque dur dont la tête doit se déplacer aléatoirement ou attendre un secteur particulier du disque aura des temps d'accès de l'ordre de quelques ms (mettons  8, c'est déjà un très bon disque), soit un maximum de 1/0,008 = 125 opérations par secondes.

Donc si ton système doit faire des accès très aléatoires, les perfs s'écroulent. Surtout sur des disques à 5900TPM.

Merci pour les explications ! 🙂

Il y a 33 minutes, brice.wernet a écrit :

J'aurais donc tendance à limiter les ressources de duplicati à 1CPU pour voir. Le job ne sera peut-être même pas plus long!

Je vais voir ça. Merci.

Il y a 34 minutes, brice.wernet a écrit :

est-ce que tu lis les fichiers MKV directement ou au travers d'un serveur media qui fait du transcodage?

Non, aucun transcodage. Kodi lit directement en SMB sur le NAS.

Il y a 35 minutes, brice.wernet a écrit :

Quand tu dis 2C+2HT dédiés, tu as désigné les processeurs?

J'ai redéfini en automatique l'attribution des C/HT.

Lien vers le commentaire
Partager sur d’autres sites
mrlafrite Débutant

mrlafrite

Posté(e)
  • Auteur
Posté(e)
Il y a 1 heure, brice.wernet a écrit :

D'ailleurs sur le graphe des disques, je n'avais pas tilté en première lecture: comment se fait-il que tu écrives autant que tu lises??? Le FTP de sauvegarde est sur ton unraid?

J'aurais pensé que tu aurais une part d'écriture (jaune) quasi à 0 et un read énorme! D'ailleurs, le graphe c'est read+write cumulé ou read dessiné "derrière" write? Donc 18M/s (dont 15 d'écriture) ou 33M/s (18 de lecture + 15 d'écriture)?

Je pense que l'écriture est liée à la création de l'archive chiffrée qui serait stocké dans un dossier temporaire.
Je dirais que les graphes sont superposés.

Lien vers le commentaire
Partager sur d’autres sites
brice.wernet Vétéran

brice.wernet

Posté(e)
Posté(e)
il y a une heure, mrlafrite a écrit :

Je pense que l'écriture est liée à la création de l'archive chiffrée qui serait stocké dans un dossier temporaire.
Je dirais que les graphes sont superposés.

Le stockage temporaire est-il bien situé sur un autre disque hors array?

Ton système n'aime pas les écritures (toute écriture logique se solde par 2 écritures minimum: données + parité - pour info en RAID5 X disques + parité une écriture logique c'est X-1 lectures (disques voisins) + 1 écriture (donnée) + 1 écriture (parité) / des systèmes peuvent le faire en 2 lectures + 2 écritures mais cela signifie qu'on a confiance dans l'intégrité de la parité en tout temps - à mon sens c'est dénaturer le RAID5)

-> Il faut faire en sorte que l'archive temporaire soit créée en dehors de l'array

 

Par ailleurs, est-ce que ton système de fichier maintient un attribut type "last access time" qui indique quand on a lu un fichier pour la dernière fois? Si c'est le cas, il faut le désactiver ou le contourner.

Il y a 2 heures, mrlafrite a écrit :

J'ai redéfini en automatique l'attribution des C/HT.

Ca c'est la bonne pratique.

Il y a 45 minutes, Edtech a écrit :

Juste pour faire mon chieur : chiffré, pas crypté !  https://www.nextinpact.com/news/99777-chiffrement-notre-antiseche-pour-expliquer-a-vos-parents.htm

😫

ok, chyffré alors...

Lien vers le commentaire
Partager sur d’autres sites
mrlafrite Débutant

mrlafrite

Posté(e)
  • Auteur
Posté(e)
Il y a 34 minutes, brice.wernet a écrit :

Le stockage temporaire est-il bien situé sur un autre disque hors array?

Non. Ce n'est pas possible. unRAID ne te permet pas d'avoir plusieurs arrays... par contre il est possible de définir d'exclure/inclure des HDD des "partages", mais ça me parait compliqué de faire quelque chose de viable avec seulement 3 HDD de même capacité.

Par contre, on peut définir l'utilisation d'un disque de cache (idéalement un SSD). Ou alors, rajouter un SSD dans l'array et de définir le dossier temporaire uniquement sur ce SSD.
Je pense que la création d'un cache global pour l'array serait plus performant et polyvalent. Non?

Il y a 46 minutes, brice.wernet a écrit :

Par ailleurs, est-ce que ton système de fichier maintient un attribut type "last access time" qui indique quand on a lu un fichier pour la dernière fois? Si c'est le cas, il faut le désactiver ou le contourner.

Aucune idée. Je ne trouve rien qui pourrait ressembler à ça.

Lien vers le commentaire
Partager sur d’autres sites
brice.wernet Vétéran

brice.wernet

Posté(e)
Posté(e)
Il y a 25 minutes, mrlafrite a écrit :

Non. Ce n'est pas possible. unRAID ne te permet pas d'avoir plusieurs arrays... par contre il est possible de définir d'exclure/inclure des HDD des "partages", mais ça me parait compliqué de faire quelque chose de viable avec seulement 3 HDD de même capacité.

Par contre, on peut définir l'utilisation d'un disque de cache (idéalement un SSD). Ou alors, rajouter un SSD dans l'array et de définir le dossier temporaire uniquement sur ce SSD.
Je pense que la création d'un cache global pour l'array serait plus performant et polyvalent. Non?

Comme je le disais plus haut, le cache est utile surtout si tu ne lis pas tes données tout le temps. De plus, le cache sera certainement "synchronisé", donc tu devras toujours attendre tes écritures avant de faire une lecture. Ton activité de sauvegarde va réduire très nettement (voir annuler) l'intérêt du cache.

Dans la capture, on voit que l'activité est pour 5 disques. Tu dois avoir un disque système. Est-ce que l'espace temporaire de duplicati peut être sur ce disque système? Sur une clé USB (pour test - quitte à la brancher en interne à terme)? Carrément en RAM (avec 16Go de RAM, tu as largement de quoi faire)?

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

Aller sur la liste des sujets
×
×
  • Créer...