Changement de disque : debian 8 ou 9 lenteurs bizarres en ssh et apache
... / Changement de disque : de...
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

Changement de disque : debian 8 ou 9 lenteurs bizarres en ssh et apache

Par
SebPerk
Créé le 2019-02-11 15:00:33 (edited on 2024-09-04 11:25:44) dans Serveurs dédiés

Bonjour,

Suite à un changement de disque sur notre kimsufi, nous constatons des lenteurs sur les 2 OS stretch (installé par défaut) et jessie (encore php5 !).

Symptômes :
- ssh : top, dmesg, ls d'un répertoire assez grand
- apache : lenteurs sur les gros images

Et ce depuis pas mal de servers/laptops SAUF sur un autre server OVH !

Avant nous avions debian squeeze (oui... vieux !) et tout était ok.

top, iotop, free, ethtool, iperf ne donnent aucun incide, et le support OVH tarde à répondre...

Cependant on dirait que le réseau effectif tourne a 10MB... (test wget)

Je ne pense pas que le disque dur soit à l'origine, ni le hardware ... je soupconne le kernel...

Actuellement je viens de apt-get update/upgrade vers
Linux xxxxx 4.9.155-xxxx-std-ipv6-64

Et toujours les mêmes symptomes.

Merci d'avance pour ton conseil !

Sébastien


17 réponses ( Latest reply on 2019-02-16 10:54:37 Par
Sich
)

Juste pour tester le disque, que disent ces commandes ? :
/bin/dd if=/dev/zero of=speedtest bs=1M count=300 conv=fdatasync

fio --name=rand-write --ioengine=libaio --iodepth=32 --rw=randwrite --invalidate=1 --bsrange=4k:4k,4k:4k --size=512m --runtime=120 --time_based --do_verify=1 --direct=1 --group_reporting --numjobs=1

alors
# /bin/dd if=/dev/zero of=speedtest bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 3.27968 s, 95.9 MB/s

et

# fio --name=rand-write --ioengine=libaio --iodepth=32 --rw=randwrite --invalidate=1 --bsrange=4k:4k,4k:4k --size=512m --runtime=120 --time_based --do_verify=1 --direct=1 --group_reporting --numjobs=1
rand-write: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.1.11
Starting 1 process
rand-write: Laying out IO file(s) (1 file(s) / 512MB)
Jobs: 1 (f=1): [w(1)] [52.8% done] [0KB/2797KB/0KB /s] [0/699/0 iops] [eta 01m:48s]
rand-write: (groupid=0, jobs=1): err= 0: pid=15113: Mon Feb 11 22:58:39 2019
write: io=276072KB, bw=2298.1KB/s, iops=574, runt=120088msec
slat (usec): min=10, max=18925, avg=42.48, stdev=72.50
clat (usec): min=939, max=852204, avg=55618.31, stdev=53476.49
lat (usec): min=978, max=852254, avg=55661.99, stdev=53476.85
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 6], 10.00th=[ 10], 20.00th=[ 19],
| 30.00th=[ 28], 40.00th=[ 36], 50.00th=[ 45], 60.00th=[ 55],
| 70.00th=[ 65], 80.00th=[ 78], 90.00th=[ 103], 95.00th=[ 151],
| 99.00th=[ 273], 99.50th=[ 322], 99.90th=[ 461], 99.95th=[ 603],
| 99.99th=[ 832]
bw (KB /s): min= 20, max= 5664, per=100.00%, avg=2307.28, stdev=609.55
lat (usec) : 1000=0.01%
lat (msec) : 2=0.66%, 4=2.15%, 10=7.28%, 20=11.78%, 50=33.60%
lat (msec) : 100=33.77%, 250=9.41%, 500=1.28%, 750=0.03%, 1000=0.04%
cpu : usr=1.59%, sys=2.91%, ctx=68945, majf=0, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=69018/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
WRITE: io=276072KB, aggrb=2298KB/s, minb=2298KB/s, maxb=2298KB/s, mint=120088msec, maxt=120088msec

Disk stats (read/write):
sda: ios=12/69566, merge=0/184, ticks=280/3932440, in_queue=3933660, util=100.00%

Résultats assez conforme à un disque sata...
Boudiou je tourne sur des disques nvme c'est vraiment pas le même monde :)

Le 2° test les résultats ne sont pas terribles, mais bon, si ma mémoire est bonne ça correspond bien à des résultats sur disque sata.

merci bien de l'info,

Pur le dd effectivement ca me parait correct (heurseuement car ovh vient de le remplacer :) ) pour fio.. je ne connaissais pas !

chose curieuse : je faisais un tcpdump juste pour voir le ssh depuis l'IP... the dmesg marche de tonnerre ! pareil si je fais un loop de type "while true ; do date ; done"
des que j'arrete ces 2 tests... les choses lentes redeviennent lentes... si j'en lance un pendant le dmesg... tout accelere !

encore plus curieux, si le tcpdump est sur un autre IP (donc calm) ou que le boucle while est dans un screen... re lenteur !!!

arf, vraiment problème à la c.n quoi :(
Il y'a eu une réinstall complète je présume au moment du changement de disque.
A part si il y'avait 2 disques, je crois que certains kimsufi ont deux disques parfois.

non 1 seul disque... le kimsufi date de 2011. C'est un 2G, 1 cpu et 2GB de RAM. L'install est debian stretch puis jessie depuis le gui OVH, j'ai juste changé un peu les partitions lors d'une 3eme install.

j'ai testé le kernel ovh 4.9 installé par défaut (actuellement patché en 4.9.155) et le netboot (4.9.120-xxxx-std-ipv6-64)... même probleme.

Je vais être un peu violent, mais à la limite pourquoi ne pas commander un nouveau serveur, parce que 2011 ça commence à date :)

Oui je sais c'est bourrin comme solution :)

c'est pas exclu :D je voulais comprendre avant d'agir.

Il est tjrs intéressant de comprendre oui, mais là j'avoue que c'est vraiment un "problème à la c.n".... Une économie d'énergie mal gérée ? J'avoue ne pas voir d'où ça pourrait venir...

Pis j'ai proposé le changement de serveur à cause de l'âge du KS...

> Une économie d'énergie mal gérée

c'est pas bourrin ça ;)

a tout hasard j'ai stoppé acpi... pas mieux...

ce que je ne comprends pas est que j'ai 0 soucis si je connecte en ssh depuis un autre server ovh...

ce serait donc qqpart entre le eth0 et le kernel
j'ai meme testé le MTU = 1500 pas de soucis...

est encore possible d'utiliser un kernel classique de jessie ex la 3.16.59-1 ? si oui, est-ce juste un apt-get install en local ? (je peux toujours faire un netboot au cas ou)

debian snapshot?
https://snapshot.debian.org/
https://wiki.debian-fr.xyz/Le_d%C3%A9p%C3%B4t_snapshot

merci je vais regarder ca.
a part faire un diag en rescue mode, j'avoue que j'ai pas d'idees...

ah si :D

Est-ce que quelqu'un a testé les kernels ovh sur disque pour desactiver les patchs spectre meltdown et pti ?

d'apres ce que je vois le kernel a besoin de qques options sur le grub + update-grub.

merci !

Ha pas impossible que ça joue ces patchs... J'ai eu des baisses de perfs sur mes vm suite à ces patchs... Une + grande latence disque notamment...