• Serveurs

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

Ok effectivement ! La réponse exacte était : "Il semblerait qu'un BUG au niveau du BIOS de ces serveurs génère une mauvaise prise en compte de la norme SATA (il devrait être en SATA III et n'est qu'en SATA II) et donc des lenteurs sur le disque."
Tu pourrais lui demander si l'offre est bien en SATA II ou III en lui disant que sur la page des offres y'a marquer SATA II stp ?
bmth wrote:Tu pourrais lui demander si l'offre est bien en SATA II ou III en lui disant que sur la page des offres y'a marquer SATA II stp ?
Ben lis un peu, on vient dire que c'était en SATA II...
Ah autant pour moi ^^
De rien Dende83 et un grand merci Angristan, j'aurais eu du mal; mes souvenirs sont trop lointain et perdu...
Ainsi, je l'ai installé et voici un petit complément : 
smartctl -a /dev/sda | grep "^SATA"
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Donc, je dispose bien de la bonne version. Je crois, la fiche d'un prestataire ne fournit pas forcément cette information. Par moment, il m'est arrivé de lire juste la mention du SATA (sans la version).

Et a priori, ce serait le bios en cause. Je suis assez surpris car Online construit également les machines ? Avec un bios d'origine (s'il existe ? Asus, Clevo etc), est-ce que cela pourrait résoudre le problème ?
La norme est définit depuis plusieurs années alors j'imagine, il existe peut-être un correctif. Je présume, ce problème n'existe (ou il est très rare) parmi les autres constructeurs (de CM).
J'espère que Online le résoudra vite.
Oui il semblerait que leur matos, en tous cas sur cette gamme perso 2016, soit assez "custom", en ce qui concerne les cartes mères surement.
Voilà ce que j'obtiens avec le commande "dmidecode | more" : 
#  dmidecode | more
BIOS Information
        Vendor: Online Labs
        Version: 00.00.00.0011
        Release Date: 03/29/2016
...
        BIOS Revision: 0.0

System Information
        Manufacturer: Online Labs
        Product Name: SR
        Version: (^_^)
...
        SKU Number: (^_^)
        Family: Avoton

Base Board Information
        Manufacturer: Online Labs
        Product Name: SR
...
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: <BAD INDEX>
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0
Vu qu'on m'a parlé de gamme Perso 2016, il est possible que ça concerne aussi les XC SATA 2016 (on m'a clairement conseillé un XC 2015, ou les versions SSD des gammes Perso 2016 pour ne plus avoir de problème). Des retours de possesseurs de XC SATA 2016 seraient intéressants.

En tous cas si vous avez des problèmes de lenteurs avec ces serveurs testez d'abord la vitesse du disque avec : 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
Et si le résultat n'est pas normal je pense qu'il est assez important d'au moins signaler au sav que vous vous êtes aperçu du problème.
Salut,

Je confirme que cela concerne également les XC 2016: 
root@ns1:# 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, 48.2054 s, 21.8 MB/s
J'ai contacté le support et ils m'ont remplacé la machine. Mais en refaisant le test c'est pire qu'avant: 
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, 170.629 s, 6.1 MB/s
Du coup le support me propose le remboursement du serveur.
Aïe, c'est bien ce que je pensais... C'est franchement scandaleux qu'une si grosse boite commercialise des trucs pareils. Faut vraiment qu'ils trouvent une solution...

Edit : Ncity, la partie "rm test.data" de la commande sert à effacer le fichier créé lors du test je suppose ? Pas mal ça.
As-tu une idée du répertoire où ces fichiers se créent par défaut? J'en ai tellement effectués...
Re-edit : mes partitions ne semblent pas plus encombrées qu'avant, je suppose que ce fichier doit s'effacer de lui même.
Dense83, en effet "rm test.data" efface le fichier créé lors du test. J'ai remarqué le fichier de test est stocké dans le repertoire ou tu lance la commande.
un mois plus tard
Bonjour

Je viens de commander une Dedibox XC SATA 2016.

Meme probleme. 6MB/s max. L'horreur quand un torrent tourne. Je voulais passer de OVH a Online, mais la c'est pas gagné.

J'ai contacté le support suite à ce post, car effectivement meme si c'est pas trop cher, 6MB/s c'est inacceptable.

A quoi sert 2,5GBS de bande passante si le disque est completement à la rue.

D'apres les premieres info du ticket, il semble que le probleme serait plutot sur cette gamme à Amsterdam ...

Est ce que vous etes sur ce DC ? est ce qu'il y en a sur Paris avec le meme probleme ?

Merci
Bon test effectué par le technicien en rescue :

1,3GB/s !!! tout à l'air ok. Sauf que c'est impossible même si c'était un SSD ultra performant.

Je check. Le disque dur est même pas monté en rescue ... Donc test sur le système qui est monté en RAM ... Je suis très inquiet.

Je recheck moi même, en montant le disque dur et testant dessus cette fois, 10MB/s ...

Bon ben j'attends de voir la réponse.
    Bon j'appel, et c'est le technicien qui avait fait le test au téléphone...

    Il monte le disque et lance la commande toujours pas sur le disque ! Donc il ne sait pas comment marche "dd" du coup. of=CHEMIN_DU_FICHIER_A_ECRIRE...

    Mais ils sont complètement incompétent c'est incroyable ... et mauvaise fois en plus. du coup j'suis bon pour attendre mon serveur en rescue toute la journée...

    Bon, j'vais voir comme ça va tourner mais là, j'suis pas fan sur service en ligne.
    Les hotliners de 1er niveau n'ont pas besoin d'avoir des compétences spécifiques en informatique. Ils ont leur process à dérouler. Faut pas oublier qu'il doivent se taper de nombreux appels de noobs paumés parce qu'impossible de se connecter en root sur Debian 8, parce que leur seedbox est tombée en panne et j'en passe...

    Concernant ton souci hélas les petits modèles sont en effet sources de problèmes. Après vu le prix...
    Je te souhaite que ça s'arrange
    Ce n'est pas que sur la gamme à Amsterdam car j'avais le même soucis avec la XC 2016 hébergé en France.
    du coup comment tu as resolus ton probleme ?

    j'ai recu une autre machine, j'ai refait le test, 20MB/s ... donc on passe de 6 a 20 c'est mieux mais pas terrible.

    j'ai donc demandé encore une autre machine. En cours d'installation. Ca prend 1h a chaque essai, j'espere que ca sera la bonne.

    En fait OVH propose des prix sur les kimsufis similaire. J'ai pas besoin d'un trop gros serveur en fait. Juste un qui marche bien.

    L'avantage de Online, c'est la bande passante. OVH Kimsufi = 100MB/s, Online - 1GB/s voir 2,5GB/s !

    Il faut juste que le disque fonctionne et c'est parfais.

    Bon on va voir combien d'essais avant de tomber par chance sur un serveur qui marche.

    Je trouve ca incroyable qu'il les propose en fait, vu le bug, il devrait les retirer et les corriger. Proposer un model plus ancien qui marche. Ou corriger de toute urgence le probleme.

    Si tout le monde renvoie son serveur, on a pas fini.
    3e serveurs. 86MB/s. Je vais effectuer plein de test et voir si ca tient la route.
    celogeek wrote:du coup comment tu as resolus ton probleme ?
    Je suis allé chez SoYouStart
    Ah ok. Je suis chez SoYouStart, et je vais chez Online

    Mes raisons :

    * moins chers
    * plus besoin d'un si gros serveur
    * plus de bande passante

    La je suis autour de 90MB/s sur le disque. C'est correct sans être extraordinaire. Pour le prix ça va.

    Je check si rtorrent fonctionne bien et je reste la pour l'instant.
    Je voulais prendre un serveur plus puissant chez Online mais ce qui m'a freiné ce sont les frais d'install, trop coûteux
    Du coup j'ai étais obligé d'aller chez SYS.
    un mois plus tard
    Idem avec un XC Sata 2016 au datacenter DC2:

    dd if=/dev/zero of=test bs=1M count=1000 conv=fdatasync 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 276.19 s, 3.8 MB/s

    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, 214.502 s, 5.0 MB/s

    J'ai fait un ticket, ça remonte.