VPS Cloud performances et disques virtuels
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

VPS Cloud performances et disques virtuels

by
SebastienE
Created on 2019-01-07 17:31:07 (edited on 2024-09-04 13:47:21) in Serveurs Privés Virtuels (VPS)

Bonjour,
J'ai un VPS cloud 2 depuis quelques années qui fonctionne bien.
J'ai pris un VPS cloud 1 en plus, et je trouve les accès disque pas terrible. En fait j'ai de gros blocage (5s) lors d'accès à certains fichiers la première fois (après c'est en cache et rapide).
Je me retrouve avec de gros iowait sur ce second VPS, chose que je n'ai pas sur le premier.

Si je fait un fdisk -l sur le premier VPS j'ai deux disques de 50Go (/dev/vda et /dev/vdb)
Sur le deuxieme j'ai un disque de 25Go (/dev/sda)
Notez le Vda sur le premier et Sda sur le deuxieme.

Qu'est ce qui peut expliquer cette différence au niveau de la structure des disques et des perfs ?
Merci


20 Replies ( Latest reply on 2019-01-17 10:48:01 by
kyodev
)

Bonjour,
Est-ce que tu peux me donner les ID des vps stp?
Ils sont probablement sur deux différents clusters Ceph de stockage, je vais regarder.

Bonjour,
Le premier qui fonctionne bien est vps270375
Le deuxième plus récent est vps633696
Merci

Les deux VPS sont bien sur différents clusters Ceph, ce qui peut expliquer un ressenti différent.
A noter que le premier VPS, étant un VPS Cloud 2, bénéficie de plus d'IO/s autorisés.

Tu as toujours ressenti ce problème de performance sur le second vps?

Le second VPS je l'ai pris il y a seulement 3 jours et c'est en commençant à installer un site web dessus que je me suis rendu compte de ça.
Ce n'est pas tellement les IO/s qui me genent mais le délai d'attente bloquante (iowait) sur certaines opérations, alors que la charge disque est très faible pour l'instant, le site n'étant pas en production.

Tu arriverais a générer quelques logs ?
Comme un 'time cat tonfichier' (avant la mise en cache ;) )
Ou des exemples d'iowait importants.

De mon côté je ne vois rien qui sur ce cluster qui expliquerait ton problème.

Je suis curieux!

Je n'arrive pas à le reproduire sur un cat, par contre un simple apt install bloque régulièrement sur la lecture de la base de donnée apt. Du coup pour tester j'ai simulé une lecture des deux fichiers de cette BDD, le premier coup 5s et le deuxieme 0.06s :
> time md5sum /var/cache/apt/pkgcache.bin
> dfee4f443b0f689d1ac2a6c77c641ea4 /var/cache/apt/pkgcache.bin
> real 0m4.853s

> time md5sum /var/cache/apt/pkgcache.bin
> dfee4f443b0f689d1ac2a6c77c641ea4 /var/cache/apt/pkgcache.bin
> real 0m0.063s

Servir une page web bloque aussi, mais je ne sais pas sur quels fichiers.
iostat me donne 30% d'iowait c'est énorme.

iostat -x
Linux 4.9.0-8-amd64 (vps633696) 01/09/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.81 0.11 1.75 27.86 0.00 65.47
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 3.91 5.35 40.46 5.70 618.83 105.57 31.39 3.19 69.03 21.93 403.41 6.71 30.99

Merci,

Le premier est sur le serveur où tout est OK et le second qui pose problème?

Il y a beaucoup d'io en cours sur ce serveur?

Non, les deux tests sur le serveur qui pose problème, l'un a la suite de l'autre. Du coup le deuxieme test est en cache, et montre la différence avec et sans iowait.
Il n'y a aucun io sur ce sereur en dehors des tests que je fait car c'est un serveur qui n'est pas en production

Ok je comprends, Je vais essayer de reproduire le problème.

Bon j'ai refait des tests : Réinstallation de mon VPS cloud 1 avec une debian 9. Direct après un reboot, je suis a 30s d'iowait !

> time md5sum /var/cache/apt/pkgcache.bin && time md5sum /var/cache/apt/srcpkgcache.bin
> 906606a2b40301accc1bf719dadac008 /var/cache/apt/pkgcache.bin

> real 0m30.807s
> user 0m0.092s
> sys 0m0.016s
> 8346c68f2a135987157bd16e8d92eeb0 /var/cache/apt/srcpkgcache.bin

> real 0m27.145s
> user 0m0.096s
> sys 0m0.008s

Pour comparaison sur mon autre VPS cloud, direct après un reboot également :
> time md5sum /var/cache/apt/pkgcache.bin && time md5sum /var/cache/apt/srcpkgcache.bin
> 288c3134e9d27fe2e3b0cc0a88cc0c31 /var/cache/apt/pkgcache.bin

> real 0m0.191s
> user 0m0.072s
> sys 0m0.024s
> 3dceb90bbbb24d5c7529313e8e65f5af /var/cache/apt/srcpkgcache.bin

> real 0m0.146s
> user 0m0.032s
> sys 0m0.016s

Désolé pour le délais, j'étais malade et absent vendredi dernier.

J'ai créé un vps du même flavor/OS sur le même stockage et je remonte un résultat très différent :

root@vps636913:~# time md5sum /var/cache/apt/pkgcache.bin && time md5sum /var/cache/apt/srcpkgcache.bin
4f6e50547a2b656008a01e67a090dfbc /var/cache/apt/pkgcache.bin
real 0m2.055s
user 0m0.116s
sys 0m0.004s
49b1022904afb5e9b4c30e9ba0fbe41f /var/cache/apt/srcpkgcache.bin
real 0m4.366s
user 0m0.108s
sys 0m0.008s
root@vps636913:~# time md5sum /var/cache/apt/pkgcache.bin && time md5sum /var/cache/apt/srcpkgcache.bin
4f6e50547a2b656008a01e67a090dfbc /var/cache/apt/pkgcache.bin
real 0m0.061s
user 0m0.060s
sys 0m0.000s
49b1022904afb5e9b4c30e9ba0fbe41f /var/cache/apt/srcpkgcache.bin
real 0m0.053s
user 0m0.052s
sys 0m0.000s

Je te conseille de passer ton vps en rescue et de faire le test sur le même fichier, je pense que tu as des IO en cours sur ton VPS qui influences le résultat du test.

En mode rescue c'est ok. Apres un reboot c'est ok aussi pour l'instant. Pourtant j'ai fait une réinstallation à neuf d'une debian 9 via le manager samedi. Et j'avais des iowait de 30s malgrès ça. Je n'ai RIEN installé du tout.
Sur ton test tu as 4 secondes pour lire un fichier de 20M eniron, ça parait assez lent. Sur le VPS qui est sur l'autre cluster je suis à 0.1s sans cache.

Je vais tester demain sur une autre région.

J'ai refait des essais aujourd'hui, toujours sur un serveur remis à 0.
Après un vidage de cache (echo 3 > /proc/sys/vm/drop_caches), je suis à 3 et 5s
Mais ensuite, malgrès des vidages de caches ou des reboot, je suis resté en dessous de 1s.

Je suis assez perplexe du coup. Est ce que ce sont les aléas des VPS cloud ? Et du coup peut etre que sur mon autre serveur je ne m'en étais pas rendu compte car une fois que tout est lancé et en cache ça ne se voit pas (car je ne l'ai jamais constaté en écriture) ? Est ce que 5s d'attente sur certaines opérations de lecture font partis du fonctionnement normal ? (sans autre opération à coté)

Sur un VPS d'un autre région j'ai obtenu un résultat similaire.

Il faut garder en tête qu'un vps cloud1 ne peut faire que 1000 io par seconde, on peut rapidement se retrouver limité.

Ok mais là je teste sur une install neuve, il n'y a rien qui tourne de spécial.

Je ne trouve pas les performances du stockage mauvaises.
Si tu as besoin de meilleures performances sur ce point, je te conseille de regarder les instances public cloud avec du stockage ssd raid en local.

> les instances public cloud avec du stockage ssd raid en local.

je m'interroge, les VPS aussi ont un SSD?
le cloudWeb aussi?

```text
dd if=/dev/zero of=./outputTempo bs=10k count=100k
rm ./outputTempo
```

* Vps: 760 MB/s
* public cloud: 573 MB/s
* cloud web: 38.3 MB/s à 17.3 MB/s (très variables, sans site en production, hébergement vide)
* mon ssd entrée de gamme: 1,0 GB/s
* un nvme grand public: 1,8 GB/s

je m'interroge sur le terme SSD employé ici parfois :/

Ça dépend des VPS, c'est soit sur du SSD local, soit sur du Ceph.

Pour le cloudweb, je ne sais pas te dire ce qui est derrière, je ne travaille que sur la partie Ceph.

Mais on applique des limites en IO/seconde suivant les flavors (types d'instances).

* VPS SSD 1

https://i.imgur.com/UAOFhaO.png

> on applique des limites en IO/s

on peut les connaître?