OVH Community, your new community space.

RAID Soft très lent ?


hugobros
10/03/2014, 18h15
Mouais, en gros si la smart du disque ne dit pas "Je suis mort et j'ai emporté les données avec moi, changez-moi maintenant", je vais devoir garder un dédé foireux qui corromp des données ? Où juste amener la preuve que le disque foire des enregistrements suffira ?

BBR
10/03/2014, 13h20
le changement de disque est gratuit mais faut prouver qu'il est défectueux
20 euros ? si tu parles du diagnostic payant ça n'existe pas sur ks

hugobros
10/03/2014, 13h08
Bon là ça devient intolérable, même sur un seul disque le raid fait n'importe quoi, il fait sauter des tables mysql, je dois les réparer tous les jours, ça plante le forum, les services, etc , j'exige d'avoir un serveur conforme à ce pour quoi j'ai payé. Même si les données smart prétendent le contraire, il y a très clairement un souci avec ces disques, et j'ai pas envie de payer 20 euros supplémentaires juste pour avoir droit à mon serveur qui fonctionne. Si je poste dans la section soucis techniques, ils vont changer ça gratuitement où pas ?

hugobros
07/03/2014, 15h19
Inutile, j'arrête tout court. ( Pour la petite histoire pour les intéressés : http://forum.xoliocraft.org/read.php...2301#msg-22301 )

Je vais me contenter d'auto-hébérger le site sur mon fidèle Fujitsu esprimo.

buddy
07/03/2014, 14h51
Salut

Regarde du cote de soyoustart.com en raid soft..

Si ton sp est en renew automatique n oubli pas de le decocher 10 ou 15 jours avant expiration..

hugobros
07/03/2014, 13h54
Bon ... ben je pense ne pas le garder longtemps ce ps, vu la qualitée merdique des disques qui ont l'air déjà à moitiée morts...
Je paie 20e de moins que pour le mSP, et j'ai à peine le tiers du service : un raid qui marche très mal, une bp foireuse, un manager minimal et si je veux faire investiguer le souci à OVH je dois payer presque un mois entier ... sans garantie que ça le règle. Bon, ben merci au revoir, le mois prochain j'irai voir ailleurs, j'ai pas envie de me casser les nerfs sur du matos foireux. Si seulement il y avait eu des réductions sur le mSP...

hugobros
07/03/2014, 12h35
Bon, j'ai dégagé ( --fail --remove ) sdb2 du raid, et je l'ai formatté en ext4. Je scp dessus : 10mbps, visiblement dessus je peux scp tranquillement... plus où moins.

hugobros
07/03/2014, 12h17
En dézippant les fichiers dans un screen, j'ai lancé un apt-get install iotop ( il prend 142kb sur le dd ) il y a 20 minutes ... j'attends toujours.

Est-ce qu'il y a moyen de virer le raid facilement "à chaud" ( sans devoir tout réinstaller ni perdre de données ) ? Ne serait-ce que sur un disque, histoire de pouvoir bricoler une solution temporaire et copier les données de l'ancien dédié sans foutre les services en l'air. Et si ça foire, on peut le remmetre aussi "facimement" ?

buddy
07/03/2014, 12h01
L'écart n'est pas énorme... puis on ne sait pas quand ni comment le cache des disque est utilisé (cache de 32 mo sur le disque ??). Pour que ca soit vraiment representatif faudrait faire le test sur 10 ou 20 go par exemple.. et faire plusieurs fois pour valider ses faibles écarts.

hugobros
07/03/2014, 11h10
Truc étrange :

root@ns38709:/home/root# hdparm -t /dev/md2

/dev/md2:
Timing buffered disk reads: 360 MB in 3.01 seconds = 119.77 MB/sec
root@ns38709:/home/root# hdparm -t /dev/sda2

/dev/sda2:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.64 MB/sec
root@ns38709:/home/root# hdparm -t /dev/sdb2

/dev/sdb2:
Timing buffered disk reads: 324 MB in 3.01 seconds = 107.72 MB/sec
Le raid prétend copier plus vite que les disques ne vont réellement ... ça pourrait être à l'origine des soucis ?

Les données SMART des disques : http://pastebin.aquilenet.fr/?89c9aa...biYnWX5HHi9kY=

hugobros
07/03/2014, 10h40
Même tous services coupés le scp accapare toutes les ressources disques ... truc de fou, il mange 11mbps et un nano sur 20 caractères prend 2s.
Lors de la copie - je la fait en mode bourrin, en coupant tout avant - j'ai en moyenne 50-60% d'iowait dans top...

J'ai testé sur l'ancien serveur, un gros dd de bourrin des familles à 220mbps : 25% d'io wait de moyenne dans top et système toujours réactif. Certes le cpu et les disques sont plus rapides, mais pas d'un facteur 40 non plus ... Je vais attendre de finir la copie de 11Go de backups et je ferais des tests de vitesse.

buddy
07/03/2014, 10h22
Meme si tu coupes tous les services ??
Parce que ecrire un gros fichier + des centaines de petits en meme temps...

Il faudrait aussi tester les debits disque 1 par 1 si possible..

Si le soucis vient juste de la, tu peux utiliser rsync qui peut limiter le debit avec l option bwlimit ..

hugobros
07/03/2014, 09h07
Citation Envoyé par hugobros
Edit : Je précise que lors de la copie sous scp, atop -c -d 5 me file 100% d'iowait pour scp.
Up : un "dd if=/dev/zero of=/media/test.dat bs=1M count=80000" met le serveur dans les choux après 3go, c'est bien un souci au niveau du système de fichiers. Le rm dudit fichier est aussi excessivement long ( presque une minute ), et les services reviennent après.

hugobros
06/03/2014, 23h53
Après investigation rapide :

Les serveurs minecraft consomment en permanance entre une centaine et une dizaine de ko/s ( auto-sauvegardes, profils des joueurs, logs, etc ), ainsi que MySQL.
Là j'ai tout laissé tourner environ 2 heures, pas de soucis, ça marchait nickel et les lags étaient très réduits.

Je lance un scp sur un fichier de 11go. Après 800mo, bim, tous les serveurs sont en connection reset et les io semblent bloqués ( écrire une poignée de ko sous nano prend 10s ). Même APRES avoir ctrl->c la copie. WTF ?

Le serveur s'en remmet environ 5 minutes après, retour à la normalle, les serveurs repingent, les pages réapparaissent et mumble redevient fonctionnel.
Ca sent la grosse merdouille coté raid. En fait ça m'arrangerait un dédé foireux, parce que coup le souci aurait une solution simple.

Edit : Je précise que lors de la copie sous scp, atop -c -d 5 me file 100% d'iowait pour scp.

buddy
06/03/2014, 23h12
Salut,

tu n'aurais pas des iowait ??

Personnellement, je préfère rsync pour la copie de données. ( mais scp devrait fonctionner quand même )

phil_
06/03/2014, 23h10
Oui clairement, il n'est pas impossible que ton kimsufi tourne à 100% du CPU avec le transfert. Fais un htop pour voir.

hugobros
06/03/2014, 21h18
Choix purement financier, sortir 50e/mois ça fait mal à la longue quand on a pas de taf. La différence de puissance n'explique pas du tout que une simple copie puisse mettre à genoux un i5 avec 16go de ram. Est-ce que c'est l'encryption SSH qui ferait aussi mal ?

BBR
06/03/2014, 20h43
migrer un mSP32G sur un ps-16g
sur le mSP tu as une BP garantie, pas sur le KS, le mSP est bien plus puissant que le ks, tu perds aussi les avantages du support, drôle de choix mais bon c'est le tien, s'il n'y a pas de problème matériel, la réponse est dans le début de ma phrase.

hugobros
06/03/2014, 20h29
Je suis en train de migrer un mSP32G sur un ps-16g ( i5 750, 2x500go raid-1 ), et je constate des freezes irréguliers de apache, mumble et de en gros tout ce qui tourne sur le serveur ( Des serveurs Minecraft surtout ). Le serveur est configuré en raid-1 ( la seule possibilité offerte par le manager ... ) et tourne sous debian 7.4 x64.

Les symptomes : Dès que je scp un gros tas de données ( quelques go ) sur le serveur, tout devient extrèmement lent, les serveurs se mettent à lagger de façon sévère, mumble perd la connection, un simple nano index.htm prend 20 secondes à s'éxécuter et de façon généralle le système de fichiers est lent.
Très lent.

Si bien que le serveur est tout bonnement inutilisable alors que je dois finir de tout migrer d'ici dimanche et que tous les services sont indisponibles depuis ce matin.

A quoi est-ce dû ? Est-ce que c'est un disque défectueux ( J'ai regardé vite fait en mode rescue, visiblement non ) ? Est-ce le raid-soft qui est buggé où qui consomme autant ? Il me semble que sur le mSP c'est du soft aussi, et même si son xeon est deux fois plus performant, on ne ressent absolument aucun souci du genre. Est-ce qu'il éxiste une façon pour dégager le raid soft tout court ? ( Le manager ne permet visiblement pas de mettre le / en non-raid )

Merci pour votre aide.