• Serveurs

  • Dedibox 2016, lenteur HDD, I/O wait très élevé

Salut,

J'avais un petit SC SATA 2016 500Go (AMS1) chez online que je viens de changer pour un SC SATA 2016 1To (DC2).
Je n'avais strictement aucun problème avant avec 2 users sur l'ancien, mais là c'est la cata : dès que j'ajoute un torrent, je dis bien un seul, le serveur sature complètement et devient inaccessible : même la navigation sur le manager/rutorrent devient quasi impossible, la connexion ssh ou les commandes via terminal sont ultra lentes, tant que le téléchargement n'est pas fini.

*Je précise que j'avais simplement installé le script auto, plex (qui n'était pas utilisé lors de ces montées en charge), et effectué le tuto de sécurisation (logwatch, rkhunter, portsentry, etc).

Après avoir regardé tous les logs que j'ai trouvé pour voir si je ne m'étais pas fait infecter ou autre, je n'ai rien remarqué de vraiment anormal (à part une erreur cron de munin).
Par contre un tour sur la commande top m'avait indiqué qu'à l'ajout d'un torrent le "wa" (I/O wait) montait à 90 voir 100%... Même au repos avec 0 torrent en liste la charge CPU indiquée via rutorrent était quasi tout le temps entre 10 et 35%...

Dans le doute j'ai tout reformaté via la console d'online, simplement installé le scipt d'ex_rat auto, et créé un seul user sur une partition LVM. Dès l'ajout du 1er torrent, patatra ça recommence (testé dans la minute après réinstallation) : le serveur surcharge, I/O wait très élevé.
Je suis entrain de reformater encore une fois, pour essayer de faire quelques tests sans rien sur le serveur. Même si je ne sais pas vraiment quoi tester


En attendant quelqu'un aurait une idée, une piste ? Est-ce que ça peut être matériel ? Y a t-il a des choses que je pourrai vérifier avant d'installer le script auto ?

J'ai d'abord pensé à un disque défectueux, mais après plusieurs tests courts et un test long via smartmontools (qui devait d'ailleurs durer 3 heures et qui a duré plus du double), aucune erreur détectée. Mais je ne sais pas si c'est suffisant pour écarter un problème disque.

Please... Help !


Edit : ok bon je crois que j'ai vraiment un problème de disque dur. Je viens d'essayer de faire des copies de fichiers d'1Go : vitesse moyenne d'écriture entre 3.6 et 6.2Mo/s... Normal que l'I/O wait soit si élevé.
J'ai ensuite trouvé la commande : 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

Résultat : 
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 342.244 s, 3.1 MB/s
Je viens d'ouvrir un ticket avec ces résultats qui ne me paraissent vraiment pas normaux
Je me permets un petit up, ils m'ont enfin fourni un nouveau serveur cette fois avec la commande dd citée précédemment :

1er test : 36.6MB/s
2ème : 52.6 MB/s
3ème : 65.2MB/s

C'est beaucoup mieux !

A partir de quelques lectures j'ai cru comprendre qu'avec cette commande, pour un disque SATA +50MB/s est acceptable, moins de 20MB/s est inquiétant.
Sur un SSD moins de 100MB/s n'est pas acceptable. Ca vous paraît à peu près correct ?

Si quelques personnes passent par là, n'hésitez pas à partager vos résultats en précisant le type de serveur et de disque à titre de comparaison. Merci.

A l'avenir je lancerai toujours cette commande à l’acquisition d'un serveur avant de faire quoi que ce soit d'autre ^^' ...
Moins de 100Mo/s que ce soit pour un HDD ou un SSD, je trouve ça inquiétant.

Essaye avec cette commande : 
dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
Hello,

Au vue des résultats de DD, je pense que le support va te proposer un changement de HDD, car les débits ne sont vraiment pas bon la !
J'ai exactement le même soucis depuis que je suis chez online.net à savoir 3 ans environ, j'ai changé 3 fois de serveur, et j'ai tout le temps ce même problème, lorsque j'ajoute un torrent et qu'il télécharge à environ 30Mo/s minimum, ça y est, mes sites commencent tous à freeze pareil pour ruTorrent jusqu'à ce que le téléchargement s'arrête. Même problème lorsque je crée une archive.
Je pense clairement que ça vient du disque dur le problème, soit il est pas assez "puissant", soit le fait qu'il soit en sata 2 ?
Bref, je ne connais pas assez choses là dedans pour le confirmer, je laisse aux experts.
J'ai ouvert un ticket au support et comme d'hab ils me demandent de passer en rescue, chose que je fais, ensuite ils font leur test et m'assurent qu'il n'y a aucun soucis.
J'ai toujours eu ce problème avec les dedibox SC/XC alors je ne sais pas si c'est pareil pour les serveurs haut dessus de cette gamme.

Bref, je suis tout de même content de ne pas être le seul dans cette situation.
Merci de vos retours, jusqu'ici je me sentais bien seul avec ce problème ^^' Etant débutant sous linux le pire c'est que j'ai mis pas mal de temps à comprendre le problème et surtout d'où il venait.

C'est sûr qu'avec 3.1Mo/s en vitesse HDD le serveur était joignable en ssh, mais fallait pas lui demander plus
Et ils m'ont fait le même coup que bmth sur mon précédent serveur : après leur avoir montré les résultats de la commande dd, ils sont passés en mode rescue pour me sortir ce résultat de test en me disant que tout allait super bien : 
 dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in 
16384+0 records out
1073741824 bytes (1,1 GB) copied, 1,16366 s, 923 MB/s
Nan mais je sais pas comment sont configurés leur serveurs... Mais pour passer de 923 MB/s en rescue, à 3~4MB/s avec juste debian tout fraichement installé... oO Je ne savais même pas qu'un HDD pouvait aller aussi vite (ni aussi lentement 😀)...
C'est n'importe quoi.


Bref vous pensez qu'à +50MB/s ça ne va toujours pas apparemment...
@Angristan : avec ta commande j'ai obtenu 29.3 MBs la 1ère fois, puis 40.8 MB/s la seconde sur mon serveur actuel.

Par contre j'aimerai pas en changer pour me retrouver avec encore pire vu le précédent, et ce que raconte bmth. Y'aurait pas une config bios/hardware qui pourrait expliquer ça par hasard ? Bizarre tout ça.

Vos résultats sur vos propres serveurs avec les commandes dd citées plus haut sont toujours les bienvenus, histoire de comparer. Ca pourrait me donner des arguments pour leur opposer que ces vitesses ne sont vraiment pas satisfaisantes (c'est qui me manque le plus, des arguments techniques).
Voila un test sur un Dedibox SC gen2 
dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 11.1549 s, 94.0 MB/s
Et sur un Dedibox ST8 SATA 2016 
dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 7.19408 s, 146 MB/s
Merci cocolabombe0 ! La Dedibox SC gen2 est en HDD du coup je suppose ?
Effectivement ça n'a rien à voir T.T
Un HDD normal en SATA 3 c'est 150mo/s ou +
Dende83 wrote:Bref vous pensez qu'à +50MB/s ça ne va toujours pas apparemment [...]
Ce n'est pas seulement une pensée. C'est censé être de l'ordre du double au minimal... Néanmoins, les détails (et si j'ai bien retenu ? Je crois...), il faudra demander à quelqu'un d'autre. Je ne pourrais guère en dire plus...

Voici mon résultat avec ces 2 commandes : 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 7.14313 s, 150 MB/s
dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 7.11473 s, 147 MB/s
J'ai effectué le test quelque fois et en dehors d'un instant (une très légère variation à 135 MB/s), le résultat est (sensiblement) le même.
Certes, il ne provient pas d'une machine de Online mais comme il est question de matériel. Alors, je suppose, il ne devrait y avoir de (réelle) différence. D'autant plus, qu'il s'agit d'un DD, Tandis qu'avec un SSD, c'est tout un autre monde.

Quelqu'un pourrait-il me rappeler la commande afin de connaître (ou m'assurer) la version du SATA ?
Merci Wagner pour ton retour.

Après avoir installé hdparm, j'ai constaté que le disque était un HGST Travelstar 7K1000 (review). Sur ce test ils constatent un "sequential transfer" autour de 123MB/s, et un "random transfer" entre 50 et 57 MB/s (le problème c'est que je ne sais pas à quoi ça correspond 😮D).

En tous cas j'ai ré-écris au sav en leur disant que ces perfs semblaient encore très faibles (et que je n'étais pas le seul à le penser), en leur demandant si ils pouvaient me fournir un serveur avec des perfs disque plus correctes. Je leur ai demandé si ils pouvaient s'en assurer sans passer par le rescue mode, avant le remplacement... Je n'ai vraiment plus envie de jouer à la loterie.
J'ai moyennement confiance, mais je verrai bien.
J'ai commandé un serveur chez OVH, le HOST32-L (2x2Tb en raid0) pour une semaine et je fais le test.
J'ai téléchargé un torrent (avec beaucoup de seeders) du coup c'est monté à environ 80Mo/s dans ruTorrent, et dans ce même temps j'ai crée une archive de 40Go et je n'ai vu aucun ralentissement, j'ai actualisé ruTorrent pour voir le temps de chargement, et c'était tout aussi fluide que lorsque le serveur est "au repos".
Je pense changer d'hébergeur pour prendre OVH, au moins mes users pourront télécharger autant qu'ils veulent sans ralentir mes sites ou les autres users.
Ou sinon je reste chez Online mais je prend une game supérieur, je sais pas je réfléchis encore, mais j'ai entendu qu'OVH offre une meilleur peering ?
Voila je viens de faire le test sur une vieille KIMSUFI (4ans) 
 dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 11.4717 s, 93.6 MB/s
Wagner wrote:
Dende83 wrote:Bref vous pensez qu'à +50MB/s ça ne va toujours pas apparemment [...]
Ce n'est pas seulement une pensée. C'est censé être de l'ordre du double au minimal... Néanmoins, les détails (et si j'ai bien retenu ? Je crois...), il faudra demander à quelqu'un d'autre. Je ne pourrais guère en dire plus...

Voici mon résultat avec ces 2 commandes : 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 7.14313 s, 150 MB/s
dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 7.11473 s, 147 MB/s
J'ai effectué le test quelque fois et en dehors d'un instant (une très légère variation à 135 MB/s), le résultat est (sensiblement) le même.
Certes, il ne provient pas d'une machine de Online mais comme il est question de matériel. Alors, je suppose, il ne devrait y avoir de (réelle) différence. D'autant plus, qu'il s'agit d'un DD, Tandis qu'avec un SSD, c'est tout un autre monde.

Quelqu'un pourrait-il me rappeler la commande afin de connaître (ou m'assurer) la version du SATA ?
Tout à fait d'accord.

Pour connaitre la version : https://doc.ubuntu-fr.org/smartmontools
Bon bah j'ai obtenu une réponse beaucoup plus claire : il y a apparemment un bug bios qui empêcherait les HDD d'être reconnus en SATA3 sur toute la gamme "Perso 2016", ce qui conduirait à des lenteurs disques sur toute la gamme... Bug toujours non résolu, et qui prendra probablement du temps à l'être.

Avec 50MB/s de moyenne je suis peut-être même presque "chanceux"... Donc à part passer sur du XC 2015, pas vraiment de solutions pour le moment... C'est vrai que cette gamme est récente, mais je suis quand même étonné que ça ne se sache pas vraiment encore, ça les inciterait peut-être à se bouger un peu plus pour résoudre ce problème.
Oui enfin meme le sata2 c'est +-220Mbs (550 pour le sata3)
Effectivement, ça n'explique donc pas ces vitesses, ils ont l'art de détourner les raisons du problème chez online.net
Apparemment ils développent leur propre bios. Effectivement j'avais été étonné de constater "onilne.net" dans la marque du fabriquant du bios avec je ne sais plus qu'elle commande, ainsi que "revision 0.0".
On ne m'a jamais dit que les HDD de ces gammes 2016 tournaient en SATA2, mais précisément qu'un bug de leur BIOS maison empêchait leurs bon fonctionnement en SATA3. Rien ne me le prouve mais je pense que je suis tombé sur un technicien sincère, aucun intérêt pour lui de me dire qu'un bug touchait toute cette gamme de produit. J'ai été presque étonné de cette franchise.

Après je peux me tromper, p-e être un bridage volontaire des disques pour limiter la bande passante indirectement, mais je suppose qu'il y aurait des moyens plus simples