OVH Community, votre nouvel espace communautaire.

Load average élevé


karclop
09/04/2015, 15h27
Citation Envoyé par janus57
Bonjour,

très certainement le nœud de votre VPS qui est surchargé ou son filer et paf sa "explose".

Cordialement, janus57
Ce qui est dommage c'est que l'on a aucune info quand ce phénomène existe du coup un "top" ou un "htop" ne sert pas a grand chose car les infos données ne sont pas bonnes ( pas de wa ; du idl de processeur ; de la ram libre MAIS un load average élevé ). Forcément y a une de ces valeurs qui est erronée...
A noter que ça va bc mieux depuis 2-3 jours

janus57
07/04/2015, 13h54
Bonjour,

très certainement le nœud de votre VPS qui est surchargé ou son filer et paf sa "explose".

Cordialement, janus57

karclop
07/04/2015, 11h37
Bonjour,

Je ne sais pas d'ou ça peut venir, vous avez le même phénomène ? Pas de wa ( Wait I/O dc pas de pb de disque ) ; Le CPU qui idle à plus de 90% ; pas de swap et la bc de ram free MAIS un load average élevé parfois ?

Merci pr vos retours.

Seb

karclop
06/04/2015, 19h44
Bonsoir,

Gros ralentissement ce soir a partir de 19h20, site très très lent d'un seul coup, le cpu est au vert, la ram aussi et le load average passe de 1,21 a 65,61. Pas de copie possible de htop m'enfin c'est pas normal j'ai les même chiffre avec htop...

Help please...

Mon VPS : vps58994.ovh.net VPS 2014 Classic 3

Sebastien
Code:
Nb de connecte : 22
Temps de lecture de ping.php : 4ms.
Mon, 06 Apr 2015 19:21:01 +0200top - 19:21:01 up 58 min, 0 users, load average: 1,21, 0,87, 0,96
Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,8 us, 1,4 sy, 0,0 ni, 92,5 id, 1,3 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 4194304 total, 1010764 used, 3183540 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 308936 cached

Nb de connecte : 24
Temps de lecture de ping.php : 255ms.
Mon, 06 Apr 2015 19:31:23 +0200top - 19:31:23 up 1:08, 0 users, load average: 65,61, 55,59, 28,90
Tasks: 186 total, 5 running, 181 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,4 us, 1,3 sy, 0,0 ni, 93,2 id, 1,1 wa, 0,0 hi, 0,0 si, 0,0 st

janus57
05/04/2015, 18h01
Bonjour,

c'est claire que même si les VPS bêta ont des "coups de mou" depuis quelques jours ils sont quand même au minimum aussi rapide que les VPS actuelle (j'ai des "coups de mou" à 120MB/s au niveau de l'accès disque et des pointe à 770MB/s).

Je ne sais pas si OVH va généraliser la technologie utilisé sur les VPS Bêta et/ou si ils auront un tarifs plus élevé que les classic actuelle et/ou si ils vont changer le hardware lors du passage en production, mais à l'heure actuelle mais visiblement ce sont des"monstres" les VPS bêta si je compare au VPS classic 'si je compare avec vos infos, j'ai pas de VPS classic, mais j'ai un VPS bêta et ils sont juste "horrible" dans le sens oui les perfs sont monstrueuses comparé à d'autres fournisseurs).

Sinon il me semble que @oles avait dit sur twitter que les premier "runabove" à 2.5$ (Cf : https://www.runabove.com/instances/sandbox.xml) pouvait faire mieux que le classic 1, après ils sont la même "philosophie" les RA sandboxet les VPS classic c'est pour des tests et non de la prod critique.

Donc ceux qui ont envie de lâcher leur VPS classic 1 y a une alternative qui visiblement est viable (NO SLA par contre).
Sinon y a les VPS Bêta mais c'est 1mois sans renouvellement et avec les garanties bêta (0 donc).

Cordialement, janus57

helas
05/04/2015, 14h59
J'an en eu marre des coupures de mon vps classic ayant le VPS beta j'ai décidé de transfert sur celui-ci ...

Comparaison :
http://puu.sh/h2hIu/3394821443.png

karclop
05/04/2015, 10h51
Citation Envoyé par janus57
comme dit plus tôt, laisse tomber top et passe sur HTOP.
J'ai créé une tache pr la commande top pr surveiller le serveur, avec htop ce n'est pas possible...

janus57
04/04/2015, 18h17
Bonjour,

comme dit plus tôt, laisse tomber top et passe sur HTOP.

Une fois HTOP réglé il est beaucoup plus claire et peu donner plus de détails que top (sa se config).

Cordialement, janus57

karclop
04/04/2015, 17h59
Bonjour,

Comme j'aime bien comprendre, j'aimerai avoir une explication sur ce "top" svp :

Code:
Sat, 04 Apr 2015 15:15:07 +0200
top - 15:15:07 up 1 day, 5:11, 1 user, load average: 3,99, 1,92, 1,48
Tasks: 158 total, 27 running, 131 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,8 us, 1,6 sy, 0,0 ni, 93,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 4194304 total, 1267972 used, 2926332 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 527892 cached
Ce que je ne comprends pas c'est le load average élevé. Celui-ci tourne très souvent en dessous de 1 mais subitement il monte avec "27 task running". Voici la suite du top et visiblement ça vient d'apache, ce que je ne comprends pas c'est que je monitore tous mes scripts ( temps d'execution ) et rien de spécial à cette heure la. De plus le CPU ide 93,6% du temps, la RAM aucun pb, pas de waiting I/O ( wa ).... Vous auriez une explication svp ?

Bon weekend de pâques.

Sebastien

Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16444 www-data 20 0 182m 12m 3812 R 12,8 0,3 0:34.80 apache2
16424 www-data 20 0 181m 12m 3976 R 12,0 0,3 0:24.06 apache2
16415 www-data 20 0 182m 13m 4032 R 11,1 0,3 0:40.47 apache2
16400 www-data 20 0 182m 12m 3960 R 10,2 0,3 0:30.11 apache2
20268 www-data 20 0 180m 11m 3844 R 8,5 0,3 0:05.50 apache2
19457 www-data 20 0 182m 12m 3800 R 6,0 0,3 0:10.37 apache2
12111 mysql 20 0 552m 106m 8052 S 5,1 2,6 24:44.19 mysqld
16467 www-data 20 0 181m 12m 3876 S 5,1 0,3 0:33.82 apache2
16410 www-data 20 0 180m 12m 4000 R 4,3 0,3 0:28.56 apache2
16469 www-data 20 0 181m 11m 3992 S 4,3 0,3 0:28.37 apache2
18840 www-data 20 0 181m 12m 3872 R 3,4 0,3 0:12.06 apache2
20795 root 20 0 23612 1484 1084 R 3,4 0,0 0:00.05 top
16464 www-data 20 0 180m 11m 3956 R 2,6 0,3 0:27.90 apache2
19449 www-data 20 0 180m 11m 3708 S 2,6 0,3 0:09.85 apache2
16375 www-data 20 0 181m 12m 3980 R 1,7 0,3 0:32.67 apache2
16396 www-data 20 0 180m 12m 3924 R 1,7 0,3 0:28.80 apache2
17452 root 20 0 23740 1700 1188 R 1,7 0,0 1:01.36 top
20785 root 20 0 70124 3444 2668 R 1,7 0,1 0:00.11 sshd
16345 www-data 20 0 182m 13m 3952 R 0,9 0,3 0:32.25 apache2
16352 www-data 20 0 181m 12m 4068 S 0,9 0,3 0:33.27 apache2
16376 www-data 20 0 181m 12m 3956 S 0,9 0,3 0:32.22 apache2
16421 www-data 20 0 181m 12m 3988 R 0,9 0,3 0:33.56 apache2
16427 www-data 20 0 181m 12m 3876 R 0,9 0,3 0:27.94 apache2
16440 www-data 20 0 179m 10m 3952 R 0,9 0,3 0:25.82 apache2
16442 www-data 20 0 182m 13m 3872 S 0,9 0,3 0:27.09 apache2
16445 www-data 20 0 181m 12m 3960 R 0,9 0,3 0:23.77 apache2
16463 www-data 20 0 182m 12m 3964 S 0,9 0,3 0:30.23 apache2
18836 www-data 20 0 181m 12m 3864 R 0,9 0,3 0:18.18 apache2
18837 www-data 20 0 182m 13m 3956 S 0,9 0,3 0:16.48 apache2
19458 www-data 20 0 182m 12m 3748 R 0,9 0,3 0:09.97 apache2
1 root 20 0 10604 796 656 S 0,0 0,0 0:15.82 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd/58994
3 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khelper/58994
4 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/0
5 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/1
6 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/2
7 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/3
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/4
9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/5
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/6
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/58994/7
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 nfsiod/58994
1429 root 20 0 30764 452 212 S 0,0 0,0 0:00.00 syslog-ng
1430 root 20 0 88472 3180 2076 S 0,0 0,1 0:29.86 syslog-ng
1524 bind 20 0 202m 24m 2256 S 0,0 0,6 0:46.74 named
1534 root 20 0 49888 1232 628 S 0,0 0,0 0:00.68 sshd
1680 root 20 0 72552 2660 928 S 0,0 0,1 0:31.60 sendmail-mta
2094 root 20 0 20852 1064 816 S 0,0 0,0 0:08.68 cron
2119 root 20 0 25516 660 284 S 0,0 0,0 0:00.96 pure-ftpd
2130 root 20 0 14532 824 672 S 0,0 0,0 0:00.00 getty
2131 root 20 0 14532 828 672 S 0,0 0,0 0:00.00 getty
2132 root 20 0 14532 832 672 S 0,0 0,0 0:00.00 getty
2133 root 20 0 14532 832 672 S 0,0 0,0 0:00.00 getty
2134 root 20 0 14532 816 672 S 0,0 0,0 0:00.00 getty
2135 root 20 0 14532 820 672 S 0,0 0,0 0:00.00 getty
11212 root 20 0 71248 3684 2828 S 0,0 0,1 0:11.58 sshd
11214 root 20 0 20040 2244 1688 S 0,0 0,1 0:00.09 bash
11783 root 20 0 4136 732 584 S 0,0 0,0 0:00.11 mysqld_safe
16327 root 20 0 176m 9,9m 4564 S 0,0 0,2 0:05.47 apache2
16346 www-data 20 0 180m 11m 3936 S 0,0 0,3 0:27.13 apache2
16354 www-data 20 0 180m 11m 3952 S 0,0 0,3 0:35.63 apache2
16356 www-data 20 0 181m 12m 3980 S 0,0 0,3 0:27.63 apache2
16357 www-data 20 0 179m 10m 3860 R 0,0 0,3 0:33.72 apache2
16358 www-data 20 0 181m 12m 3932 S 0,0 0,3 0:32.27 apache2
16364 www-data 20 0 182m 12m 3872 S 0,0 0,3 0:28.02 apache2
16367 www-data 20 0 181m 12m 3992 S 0,0 0,3 0:28.23 apache2
16368 www-data 20 0 180m 11m 3976 S 0,0 0,3 0:27.42 apache2
16370 www-data 20 0 182m 13m 3916 S 0,0 0,3 0:31.26 apache2
16371 www-data 20 0 181m 12m 4004 S 0,0 0,3 0:28.42 apache2
16372 www-data 20 0 182m 13m 3944 S 0,0 0,3 0:30.30 apache2
16377 www-data 20 0 179m 10m 3988 S 0,0 0,3 0:29.45 apache2
16378 www-data 20 0 182m 12m 3968 S 0,0 0,3 0:32.32 apache2
16379 www-data 20 0 179m 10m 3980 S 0,0 0,3 0:26.95 apache2
16381 www-data 20 0 182m 13m 3980 S 0,0 0,3 0:30.41 apache2
16382 www-data 20 0 181m 12m 3980 R 0,0 0,3 0:30.94 apache2
16383 www-data 20 0 182m 13m 3888 S 0,0 0,3 0:26.24 apache2
16384 www-data 20 0 179m 10m 3940 S 0,0 0,3 0:23.63 apache2
16385 www-data 20 0 181m 12m 3976 S 0,0 0,3 0:28.18 apache2
16387 www-data 20 0 182m 13m 3988 S 0,0 0,3 0:29.51 apache2
16388 www-data 20 0 180m 11m 3932 S 0,0 0,3 0:29.50 apache2
16391 www-data 20 0 181m 12m 3916 S 0,0 0,3 0:28.00 apache2
16392 www-data 20 0 181m 13m 4024 S 0,0 0,3 0:25.91 apache2
16395 www-data 20 0 181m 12m 3912 S 0,0 0,3 0:21.01 apache2
16397 www-data 20 0 181m 12m 4024 S 0,0 0,3 0:23.56 apache2
16398 www-data 20 0 182m 13m 4012 S 0,0 0,3 0:37.13 apache2
16399 www-data 20 0 180m 12m 3900 S 0,0 0,3 0:30.32 apache2
16401 www-data 20 0 180m 11m 3908 S 0,0 0,3 0:34.58 apache2
16402 www-data 20 0 181m 12m 4048 S 0,0 0,3 0:32.69 apache2
16403 www-data 20 0 181m 12m 3960 S 0,0 0,3 0:34.17 apache2
16406 www-data 20 0 182m 12m 3948 S 0,0 0,3 0:30.39 apache2
16407 www-data 20 0 182m 13m 3872 S 0,0 0,3 0:28.58 apache2
16408 www-data 20 0 181m 12m 3984 S 0,0 0,3 0:32.28 apache2
16411 www-data 20 0 179m 10m 3968 S 0,0 0,3 0:27.51 apache2
16412 www-data 20 0 182m 13m 3936 S 0,0 0,3 0:29.60 apache2
16413 www-data 20 0 181m 12m 4032 S 0,0 0,3 0:27.71 apache2
16416 www-data 20 0 181m 12m 3908 S 0,0 0,3 0:31.53 apache2
16417 www-data 20 0 180m 12m 3992 S 0,0 0,3 0:29.68 apache2
16419 www-data 20 0 181m 12m 3916 S 0,0 0,3 0:25.95 apache2
16422 www-data 20 0 181m 12m 3868 S 0,0 0,3 0:30.59 apache2
16425 www-data 20 0 182m 13m 3936 S 0,0 0,3 0:28.40 apache2
16426 www-data 20 0 180m 11m 3908 S 0,0 0,3 0:25.60 apache2
16428 www-data 20 0 182m 13m 3976 S 0,0 0,3 0:37.03 apache2
16430 www-data 20 0 181m 13m 4004 S 0,0 0,3 0:29.30 apache2
16431 www-data 20 0 181m 12m 3948 S 0,0 0,3 0:28.56 apache2
16433 www-data 20 0 180m 12m 3956 S 0,0 0,3 0:26.10 apache2
16434 www-data 20 0 180m 11m 3840 S 0,0 0,3 0:29.74 apache2
16435 www-data 20 0 181m 12m 3992 S 0,0 0,3 0:31.26 apache2
16436 www-data 20 0 180m 11m 3880 S 0,0 0,3 0:25.32 apache2
16437 www-data 20 0 181m 12m 3968 S 0,0 0,3 0:29.64 apache2
16438 www-data 20 0 179m 10m 3948 S 0,0 0,3 0:33.40 apache2
16441 www-data 20 0 181m 12m 3984 S 0,0 0,3 0:31.01 apache2
16443 www-data 20 0 181m 12m 3920 S 0,0 0,3 0:27.83 apache2
16446 www-data 20 0 182m 13m 3888 S 0,0 0,3 0:31.80 apache2
16447 www-data 20 0 182m 13m 3988 S 0,0 0,3 0:27.72 apache2
16449 www-data 20 0 181m 12m 3980 S 0,0 0,3 0:28.87 apache2
16452 www-data 20 0 181m 12m 3908 S 0,0 0,3 0:24.66 apache2
16455 www-data 20 0 182m 12m 3912 R 0,0 0,3 0:29.19 apache2
16456 www-data 20 0 181m 12m 4032 S 0,0 0,3 0:22.31 apache2
16457 www-data 20 0 179m 10m 4004 S 0,0 0,3 0:36.23 apache2
16458 www-data 20 0 182m 13m 4000 S 0,0 0,3 0:31.83 apache2
16459 www-data 20 0 182m 13m 3984 R 0,0 0,3 0:28.98 apache2
16461 www-data 20 0 180m 11m 3876 S 0,0 0,3 0:28.71 apache2
16462 www-data 20 0 181m 12m 3976 S 0,0 0,3 0:33.68 apache2
16465 www-data 20 0 181m 13m 4004 S 0,0 0,3 0:31.26 apache2
16466 www-data 20 0 181m 12m 3848 S 0,0 0,3 0:27.03 apache2
16468 www-data 20 0 182m 12m 3852 S 0,0 0,3 0:35.53 apache2
16471 www-data 20 0 181m 12m 3904 S 0,0 0,3 0:34.50 apache2
16473 www-data 20 0 182m 13m 3992 S 0,0 0,3 0:41.68 apache2
16474 www-data 20 0 180m 11m 3924 S 0,0 0,3 0:35.55 apache2
16475 www-data 20 0 180m 11m 4048 S 0,0 0,3 0:24.49 apache2
16476 www-data 20 0 182m 13m 3864 S 0,0 0,3 0:27.78 apache2
16477 www-data 20 0 181m 11m 3876 S 0,0 0,3 0:27.67 apache2
16478 www-data 20 0 182m 12m 3820 S 0,0 0,3 0:26.11 apache2
16479 www-data 20 0 182m 13m 3992 S 0,0 0,3 0:30.01 apache2
16823 www-data 20 0 181m 12m 3980 R 0,0 0,3 0:25.51 apache2
16842 www-data 20 0 182m 13m 3908 S 0,0 0,3 0:25.43 apache2
17528 www-data 20 0 182m 12m 3920 S 0,0 0,3 0:23.70 apache2
18613 root 20 0 71248 3664 2812 S 0,0 0,1 0:00.14 sshd
18615 root 20 0 12640 1012 756 S 0,0 0,0 0:00.11 sftp-server
18838 www-data 20 0 181m 12m 3936 S 0,0 0,3 0:11.73 apache2
18839 www-data 20 0 181m 12m 3936 S 0,0 0,3 0:12.56 apache2
18841 www-data 20 0 179m 11m 3932 S 0,0 0,3 0:15.89 apache2
18842 www-data 20 0 179m 11m 3148 S 0,0 0,3 0:11.96 apache2
19001 www-data 20 0 181m 11m 3836 S 0,0 0,3 0:13.44 apache2
19443 www-data 20 0 180m 11m 3704 R 0,0 0,3 0:07.14 apache2
19450 www-data 20 0 181m 12m 3936 S 0,0 0,3 0:07.54 apache2
19456 www-data 20 0 182m 12m 3940 S 0,0 0,3 0:08.30 apache2
19459 www-data 20 0 181m 12m 3896 S 0,0 0,3 0:09.87 apache2
19610 www-data 20 0 181m 11m 3684 S 0,0 0,3 0:07.65 apache2
19717 www-data 20 0 180m 11m 3820 S 0,0 0,3 0:06.27 apache2
20262 www-data 20 0 180m 11m 3680 S 0,0 0,3 0:03.22 apache2
20786 sshd 20 0 51232 1556 860 S 0,0 0,0 0:00.00 sshd
20787 root 20 0 33516 1160 840 S 0,0 0,0 0:00.00 cron
20789 root 20 0 4136 636 540 S 0,0 0,0 0:00.00 sh
20790 root 20 0 136m 9792 6076 S 0,0 0,2 0:00.05 php
20794 root 20 0 4136 620 532 S 0,0 0,0 0:00.00 sh
31131 root 20 0 73128 7828 1916 S 0,0 0,2 1:39.69 fail2ban-server
31134 root 20 0 22124 1300 1016 S 0,0 0,0 0:28.79 gam_server

adrien62
03/04/2015, 17h00
Bonjour Damien et merci pour l’intérêt que tu portes sur mon / notre problème.

J'ai eu 2 petites coupures (le temps de la migration probablement), et je peux voir une nette amélioration du ping passant de 50ms à 24ms.voir 30ms max.

Je te tiens au courant.

Merci !

damien.rannou
03/04/2015, 14h12
Bonjour adrien62,

Je viens de lancer une migration de ton VPS, il va changer de vhost dans les minutes qui suivent, n'hésite pas a revenir vers moi si ca ne s'améliore pas.

- - - Mise à jour - - -

Bonjour adrien62,

Je viens de lancer une migration de ton VPS, il va changer de vhost dans les minutes qui suivent, n'hésite pas a revenir vers moi si ca ne s'améliore pas.

adrien62
02/04/2015, 23h10
top - 23:09:41 up 16:09, 1 user, load average: 11,06, 7,66, 3,41
Tasks: 54 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,3 us, 1,0 sy, 0,0 ni, 97,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 1048576 total, 574360 used, 474216 free, 0 buffers
KiB Swap: 131072 total, 69620 used, 61452 free, 85152 cached

Déconnexion à nouveau.

adrien62
02/04/2015, 10h18
Pour le moment je touche du bois, le ping est redevenu comme à son origine, pas eu de déconnexions hier soir.

Si quelqu'un est intervenu, je l'en remercie !

Edit : coupure à 12h18 jusque 12h22, la journée démarrait bien pourtant ^^

karclop
01/04/2015, 20h32
Citation Envoyé par Rizz
ET ca :

# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 2
J'ai lu que cette variable n'avait aucune influence... Je passe à 0 pr voir...

La flemme de tout déménager sur un cloud de plus il me reste 1 an de payé sur le VPS , je viens de passe au classic 3 pr voir et augmenté le MaxClients à 70.

Au passage il est normal qu' un thread apache utilise 180M ?

Rizz
01/04/2015, 19h15
Citation Envoyé par janus57
Bonjour,

Ce genre de script peu faire économiser pas mal de RAM utilisé pour rien et peu surtout prévenir si on a pas un peu trop poussé la config MySQL, car il suffit de pousser une ou 2 options trop haut et hop on se retrouve avec un MySQL qui mange 120% de la RAM.

Cordialement, janus57
Oui si tu suis pas la doc myqsl ca peut arriver XD

janus57
01/04/2015, 18h45
Bonjour,

Pas besoin de laisser tourner un soft 48h pour poser une valeur de table minimal a mettre en cache plutôt que sur le disque etc etc...
bah c'est MySQL qui doit tourner minimum 48H pour que le script évalue le mieux possible les meilleurs options MySQL pour correspondre au besoin de son site tout en ayant un fonctionnement optimal.

Ce genre de script peu faire économiser pas mal de RAM utilisé pour rien et peu surtout prévenir si on a pas un peu trop poussé la config MySQL, car il suffit de pousser une ou 2 options trop haut et hop on se retrouve avec un MySQL qui mange 120% de la RAM.

C'est pas du tout "gadget" vu que mysqltunner est de mémoire intégré dans les packages des distribution (en tout cas pour debian, https://packages.debian.org/wheezy/mysqltuner).
Idem pour les conseils de phpMyAdmin faut pas les prendre au pied de la lettre lui aussi parfois donne des indications pas spécialement bonne.

Après comme dit plus haut faut utiliser les 2scripts après avoir laissé MySQL manger les requêtes SQL du site pendant 48H minimum.

Cordialement, janus57

Rizz
01/04/2015, 18h20
Oui ca peut bien fonctionner ... Mais rien ne t’empêche d'estimer toi même ta config et ce en connaissance de cause de ton appli.
Pas besoin de laisser tourner un soft 48h pour poser une valeur de table minimal a mettre en cache plutôt que sur le disque etc etc...
Pour moi c'est plus de l'ordre du gadget inutile que du logiciel efficace et incontournable.

janus57
01/04/2015, 18h15
Citation Envoyé par Rizz
Mieux .... faut le dire vite. un truc pour ceux qui veulent rien comprendre et pas chercher d'accord.
Bonjour,

bah ils fonctionne très bien, mais faut utiliser les 2 et pas l'un ou l'autre car je trouve qu'ils sont complémentaires.

Sinon y avait déjà eu une discussion sur ce forum VPS VS mutualisé.

Si son but et d'avoir le moins cher et le plus performant un VPS c'est pas l'idéal, car d'après le support lui même faut être en VPS cloud (donc on commence avec le prix d'un mutualisé perfs chez OVH ou alors d'autres offres ailleurs qui sont souvent mieux qu'un VPS, pas toujours mais souvent).

Sinon si son but est de se faire la main sur un VPS bah là non plus c'est pas l'idéal, autant le faire en local avec du virtualbox.

Après c'est claire que si il veux rester en VPS pour une raison X ou Y ce sera +/- la même chose chez tous les fournisseur de VPS sous OpenVZ vu que cette technologie permet de bien surcharger un host VPS.

Cordialement, janus57

Rizz
01/04/2015, 18h14
ET ca :

# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 2


Je sais pas ou tu as trouvé ce truc..
Mais bon une simple recherche démontrerai que tu peux le mettre à 0 ( valeur par defaut ), donc de le retirer de ta config.
la tu le limite à 2 alors que ca valeur par défaut c'est " autant qu'il faudra et qu'on me laisse utiliser.".

Rizz
01/04/2015, 18h03
Citation Envoyé par janus57
Bonjour,

mieux que phpmyadmin pour faire le "tunning" du MySQL y a "mysqltunner" et "tuning-primer" mais avant faut laisser tourner le serveur 48H

Et aussi faut pas suivre à la lettre les indications du script car ce sont juste des conseils, faut avoir un peu de réflexions.


Mieux .... faut le dire vite. un truc pour ceux qui veulent rien comprendre et pas chercher d'accord.

sich
01/04/2015, 17h56
Perso à compter du VPS Cloud 3 je préconise de passer directement sur soyoustart....
Parce que pour le même prix y'a du dédié derrière...
Même si il y'a le risque de défaillance matérielle ça sera toujours mieux qu'un VPS.

janus57
01/04/2015, 17h49
Bonjour,

mieux que phpmyadmin pour faire le "tunning" du MySQL y a "mysqltunner" et "tuning-primer" mais avant faut laisser tourner le serveur 48H

Et aussi faut pas suivre à la lettre les indications du script car ce sont juste des conseils, faut avoir un peu de réflexions.

Pour la config apache c'est pareil (sauf que y a pas de script automatique à ma connaissance), faut le faire un peu au jugé et surtout savoir dans quel mode foncionne son apache, car sa sert à rien de toucher à la config "worker" si il fonctionne en "prefork".

Pour moi là clairement un mutualisé web à potentiellement (beaucoup ?) plus de puissance que un VPS classic 2 et VPS cloud 2 (qui sont eux aussi mutualisés).
Surtout que les mutualisé OVH intègre PHP-FPM couplé à de l'OPCache (donc potentiellement mieux que ton apache + mod_php5) donc le facteur qui fera toujours la différence c'est MySQL.

Cordialement, janus57

Rizz
01/04/2015, 17h35
Citation Envoyé par karclop
Non un 60 gp (mutu) à l'époque qui tournait très bien ( bon avec 80% de visiteurs en moins honnêtement ).
Passer vers un cloud peut être la solution ?
Ok je vois le raisonnement.
Ouais moi aussi j'avais un truc qui fonctionnait bien sur mutu avant2014. Mais pour tout te dire il tournerai pas plus sur un VPS....
Maintenant es tu sur que ce VPS Suffit ? Parce que bon un VPS 2 , a part un Vcore et 1G de RAM en plus que le VPS1 .... ca reste un VPS.


Si tu veux améliorer ta config SQL tu va sur phpmyadmin tu regarde ta base et les valeurs( cherche dans les onglet s), y'a des trucs en rouge c'est assez ludique ... Un peu de lecture quelque minute de recherche et tu trouvera à quoi tout ça est utile et si cela peut être responsable de tes problèmes. Maintenant personnellement je pense que c'est un peu compliqué d'assurer que ca ce passe bien niveau code et requête et pas savoir si on a des long query par exemple ou comment faire pour mettre tout ca en RAM . Perso sans avoir plus d'info j’hésiterai même pas a remettre en cause la modélisation de la base ou ton choix par rapport a ton besoin. Car il est vrai qu'on ne sait pas depuis quand tu est passé sur VPS ni même si cela à déja fonctionné avant.

Sinon je vois que le lien "Parties terminées récemment." ne fonctionne pas .. est ce que c'est pas ton crontab qui est sensé mettre ce fichier a dispo qui charge ta machine ? Sans doute non.. mais j'avoue ne pas etre le mieux placé pour savoir.

karclop
01/04/2015, 15h40
Merci,

Mysql :
# Here follows entries for some specific programs
skip-bdb
skip-innodb
# The MySQL server
[mysqld]
port = 3306
socket = /var/run/mysqld/mysqld.sock
skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 16M
table_open_cache = 64
table_definition_cache = 64
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 0
query_cache_size = 2M
query_cache_limit = 1M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 2


Apache :
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 150

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 2

##
## Server-Pool Size Regulation (MPM specific)
##

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 50
MaxRequestsPerChild 500


# worker MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadLimit: ThreadsPerChild can be changed to this maximum value during a
# graceful restart. ThreadLimit can only be changed by stopping
# and starting Apache.
# ThreadsPerChild: constant number of worker threads in each server process
# MaxClients: maximum number of simultaneous client connections
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxClients 150
MaxRequestsPerChild 100


# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxClients: maximum number of simultaneous client connections
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxClients 150
MaxRequestsPerChild 100

janus57
01/04/2015, 14h44
Bonjour,

un VPS cloud utilise une autre technologie de virtualisation qui n'autorise pas autant à "surcharger" les hosts, donc en théorie le fonctionnement devrait (en théorie hein) être plus fluide.

Sur un VPS cloud tout est virtualisé même le kernel (ce qui permet de mettre un OS tel que windows), mais après si apache et MySQL seront toujours mal config cela risque de ne rien changer.

De plus vu le prix d'un cloud, si cela fonctionné bien sur un mutualisé pourquoi ne pas être resté en mutualisé ?

Cordialement, janus57

karclop
01/04/2015, 14h32
Citation Envoyé par Rizz
En 2004 je suis pas sur qu'il y avait des VPS à 2€.
.
Non un 60 gp (mutu) à l'époque qui tournait très bien ( bon avec 80% de visiteurs en moins honnêtement ).
Passer vers un cloud peut être la solution ?

janus57
01/04/2015, 13h35
Citation Envoyé par helas
Encore une histoire avec Teamspeak .. et pourtant :

https://twitter.com/olesovhcom/statu...68546551197696
Bonjour,

ce message en veux strictement rien dire, c'est pas parce que TS ne "mange" rien qu'il va fonctionner tout le temps, suffit que le host physique du VPS soit trop solliciter ou qu'un (D)DoS touche votre TS pour le mettre à mal.

Ce message de @oles était surtout sur le prix de ventes des hébergements TS chez les fournisseurs qui facture TS à 0,25€ le SLOT alors que comme @oles l'a dit en soit TS ne consomme pas grand chose face à un apache/nginx/mysql/mariadb etc...

@karclop : il est pas trop possible de t'aider sans indications ou sans ta config actuelle.

Comment tu as fait le "tunning" de ton apache ? et celui de MySQL ?

Cordialement, janus57

Rizz
01/04/2015, 12h31
Tiens tu utilises 1G de RAM de plus que sur tes top de la première page...

En 2004 je suis pas sur qu'il y avait des VPS à 2€.

Sinon perso je trouve que ton apache et sql consomme trop ... Si tu as un crontab qui fait ramer SQL il te fera ramer tout le reste.

karclop
01/04/2015, 11h08
vps58994.ovh.net - VPS 2014 Classic 2.

Bonjour,

Voila deux top à 5 minutes d'intervalle.... Mes scripts php et mes requetes sql sont bonnes, j'ai le site echecsemail qui date d'avant facebook et n'a pas été changé... Ca marchait mieux en 2004...
Je bidouille la config de mysql et apache, je lis pas mal de docs a ce sujet mais bon si un pro pouvait me donner un coup de main...

Wed, 01 Apr 2015 10:51:01 +0200
top - 10:51:01 up 9:15, 0 users, load average: 0,26, 0,74, 0,63
Tasks: 56 total, 1 running, 55 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,1 us, 1,0 sy, 0,0 ni, 95,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1987176 used, 109976 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 1705792 cached

Wed, 01 Apr 2015 10:55:05 +0200
top - 10:55:05 up 9:19, 0 users, load average: 24,61, 7,56, 2,98
Tasks: 59 total, 1 running, 58 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,1 us, 1,0 sy, 0,0 ni, 95,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1992548 used, 104604 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 1709888 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17174 www-data 20 0 185m 10m 3112 S 24,6 0,5 0:01.40 apache2
5839 mysql 20 0 1016m 154m 4408 S 18,4 7,5 13:39.65 mysqld
15349 www-data 20 0 188m 11m 3712 S 12,3 0,5 0:02.62 apache2
15099 www-data 20 0 187m 10m 3820 S 6,1 0,5 0:04.05 apache2
19918 www-data 20 0 186m 10m 3064 S 6,1 0,5 0:00.60 apache2

adrien62
01/04/2015, 10h58
Bonjour Damien,

Merci pour l'info et de ton aide !
VPS 52940 pour le mien.

Si ça peut intéresser , je peux te donner les heures où les déconnexions interviendront, sachant qu'hier c'était moins critique qu'avant ("seulement 2 coupures") sur toute la journée, le ping quand à lui est resté loin des 31ms du début de location (entre 40 et 50 voir des montées jusqu'à 1700 lors des deconnexions (logique).

Si besoin d'autres infos ou rapport de commande, n'hésite pas !

retour du support :

- l'utilisation non optimisé par rapport à la plateforme (service en production sur une plateforme de test/pré-prod, développement)
=> https://twitter.com/olesovhcom/statu...71960752791552

Dans votre cas, vous avez plusieurs facteurs qui entre en compte :

- les attaques DDoS de Teamspeak à Teamspeak passant à travers notre système anti-DDos, pour l'instant car nous l'avons détecté et cette problématique sera corrigée suite à la propagation du nouveau système Anti-DDoS
=> Une bonne nouvelle ça =)

- le container de votre VPS, le principe de virtualisation sous OpenVz est de permettre à y stocker un certain nombre de machine virtuelle, ce qui veut dire que pendant tout ce temps, votre VPS était "tranquille" car peu de machines virtuelles ou peu d'utilisation ressource de ces machines et que depuis, plus de machines ont été configurées dans ce container donc plus d'utilisation ressource et moins pour votre propre VPS
=> Surpeuplement des hosts ?

Si votre service a bien fonctionné pendant un temps sur un VPS Classic, vous avez eu de la chance mais en tant que technicien, si vous souhaitez bénéficier d'une stabilité au niveau de votre serveur vocal, je vous invite à passer sur un Cloud.
"j'ai eu de la chance", je ne sais pas si je dois rire ou pleurer là ...

damien.rannou
01/04/2015, 10h20
On a rajouté pas mal de nouveaux indicateurs ces dernier jours, afin de monitorer au mieux les vhosts. N'hésitez pas de joindre à vos messages les noms de vos VPS, ou un numéro de ticket, afin qu'on check vos machines.

helas
01/04/2015, 02h15
Encore une histoire avec Teamspeak .. et pourtant :

https://twitter.com/olesovhcom/statu...68546551197696

adrien62
31/03/2015, 16h44
Montée du load average autour de 16h31, plus de com' avec le serveur pendant 10 secs, aucuns services plantés.
Charge CPU / Ram "normale"

cysharp
31/03/2015, 16h38
J'ai répondu suite à votre message qui parle également de TS et de DDoS et je n'ai rien d'autre à dire (j'ai déjà posté mon problème, aucune solution n'a été trouvée pour le moment, ni par la communauté, ni par le support)

Maintenant, je suis d'accord que le sujet a complètement dévié et que c'est pas très sympa pour l'auteur original. Désolé.

janus57
31/03/2015, 16h34
Bonjour,

non comment on passe d'un topic ou une personne a un problème de Load a un topic ou tout le monde à le même problème mais qui touche que TS ?

C'est pas pour faire la morale, mais vous pourrissez légèrement le post de @karclop, qui lui a juste signaler un gros problème de load.

Donc je vous conseil de faire votre propre post avec le maximum d'informations/tests.

Cordialement, janus57

cysharp
31/03/2015, 16h19
Oui, j'y ai pensé et j'ai donc, sur conseil du support, utilisé tcpdump pour analyser les paquets qui transitaient.
Conclusion : rien de spécial qui pourrait indiqué une attaque ddos c'était relativement calme

Rizz
31/03/2015, 15h26
C'est pas si simple quand on récupère une IP qui a deja tournée des centaines ( millier? ) de fois ou quand on se fait nmap simplement mais pourquoi pas. Moi j'ai pas de vps j'aime pas ca fin si mais seulement si j'ai un oeil sur l'host;

cysharp
31/03/2015, 14h55
J'ai exactement les mêmes symptômes (déconnexions multiples chez de nombreux FAI) et je suis à 99% sûr que ça ne vient pas de l'extérieur (ddos).

Pourquoi? Pour la simple raison que j'ai eu les premières déconnexions 24h après avoir commandé mon VPS et que l'IP n'avait pas été diffusée (ni sur la liste des serveurs publics TS).

janus57
31/03/2015, 13h28
Citation Envoyé par adrien62
Certain , non.
Mais comme les personnes présentes sur le teamspeak sont chez de nombreux ISP (free, Orange, numericable , sfr ..), et que l'ont se fait tous deconnecter en meme temps, je suis septique à l'idée que tous les ISP ont un problème d'interco avec ovh ..
Bonjour,

non tu te prend tout simplement un DDoS qui vise spécifiquement les serveur TS3 et qui n'est pas mitigé sous les VPS actuelle (ou alors très mal) et seulement sur les nouveau VPS "Game" en bêta qui ont un anti-DDoS renforcé pour les services vocaux (TS + Mumble) ainsi que les jeux (et surtout une nouvelle plateforme de VPS qui visiblement est sous SSD en RAID10 avec un bon cache pour atteindre les 700MB/s en pic).

P.S. le DDoS spécifique au TS3 vise à surcharger le soft du serveur TS + le faire participer de "force" au DDoS en envoyant des petit paquets x n serveur TS, ce qui à la fin fait très mal.
Perso avec mumble 0 problème (pas un VPS OVH, mais un sous-traitant qui a des perfs encore plus pourrie que le classic1, mais mumble tiens super bien).

Cordialement, janus57

adrien62
31/03/2015, 13h22
Au niveau des logs rien de particulier (ts comme sys), au niveau panel pas de pointe de traffic.
Certain , non.

Mais comme les personnes présentes sur le teamspeak sont chez de nombreux ISP (free, Orange, numericable , sfr ..), et que l'ont se fait tous déconnecter en même temps, je suis septique à l'idée que tous les ISP ont un problème d'interco avec ovh ..

Après au niveau mitigation, je ne l 'ai activé que récemment (je pensais que c'était activé par défaut à l'époque)

Rizz
31/03/2015, 12h51
ha oui dont tu serai sous mitigation, le support te parle d'un ddos sur ton team speak mais toi tu n'a aucun log

Donc est tu certain que ton pb ne provient pas de l’extérieur ?

adrien62
31/03/2015, 12h41
Déjà fait - RAS
Jvais continuer à garder un oeil dessus, là le ping est redevenu normal (31ms) alors que depuis les soucis il était autour des 50ms voir + (300ms)

Rizz
31/03/2015, 12h29
Je te comprend mais tu regarde les TOP de la personne qui a ouvert le topic on voit clairement qu'il consomme énormément de CPU.
Msql est à 70% et le moindre process apache à 11.9%.
Deja que le cpu choisi est lent sur cette archi. ... Perso si mon nginx depasse 1% j'investigue ..alors à 12% d'apache et 70 de mysql ...

Autant dire qu'il faut pas chercher trop loin.
Et quand msql est à 70% et que la config est reglé n'importe comment c'est que de l'acces disque plutot que RAM .. et ca craint en VPS mutu.

Mais avoir un load average elevé et en deduire que c'est la faute d'ovh c'est deux chose differente. Commence par regarder tes log du 21/03.

adrien62
31/03/2015, 12h25
Bah écoute, ce vps m'heberge depuis un an, aucuns soucis.
Le 21 mars , c'est le drame, déconnexions en série, perte d'accès au serveur, même le panel a déconné !
Et depuis c'est du load average elevé par intermittence et des déconnexions de 10-15 secs jusqu'à 1 minute parfois, sans que le serveur ne redemarre, que le CPU travaille et que la ram soit saturée.

En bref c'était stable, c'était ..

Le nom du topic correspond ducoup à mon problème puisque tout ses incidents arrivent à cause du load average elevé.

Rizz
31/03/2015, 12h21
Mais en dehors d'avoir dit" moi aussi j'ai le meme soucis "... tu n'en a pas adrien.
Tu n'est absolument pas dans le même cas que la personne qui ouvre ce poste et tout ce que tu vois c'est la puissance d'un VPS 1 classic.
Ren d'autrE.

adrien62
31/03/2015, 12h16
Voilà mon top (le premier en début de topic n'est pas le mien)

top - 12:15:30 up 5:15, 1 user, load average: 0,26, 0,37, 0,42
Tasks: 51 total, 1 running, 50 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,7 us, 0,7 sy, 0,0 ni, 98,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 1048576 total, 633084 used, 415492 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 186020 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3655 teamspeak3 20 0 145m 18m 5988 S 2,0 1,8 0:13.49 ts3server_linux
1621 root 20 0 71196 7812 1880 S 0,3 0,7 0:10.58 fail2ban-server
2079 mysql 20 0 382m 58m 3964 S 0,3 5,7 0:50.40 mysqld
3364 root 20 0 79880 4012 3072 S 0,3 0,4 0:00.23 sshd
1 root 20 0 10604 752 616 S 0,0 0,1 0:02.74 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd/52940
3 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khelper/52940
4 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/0
5 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/1
6 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/2
7 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/3
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/4
9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/5
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/6
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rpciod/52940/7
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 nfsiod/52940
1502 root 20 0 30764 388 144 S 0,0 0,0 0:00.00 syslog-ng
1504 root 20 0 88344 2064 1056 S 0,0 0,2 0:00.45 syslog-ng
1550 root 0 -20 15852 3572 2720 S 0,0 0,3 0:00.79 atop
1567 bind 20 0 117m 20m 1856 S 0,0 2,0 0:01.11 named
1571 messageb 20 0 29760 1116 788 S 0,0 0,1 0:00.00 dbus-daemon
1623 root 20 0 22124 1124 840 S 0,0 0,1 0:00.46 gam_server
1665 root 20 0 281m 8388 1172 S 0,0 0,8 0:07.01 apache2
1699 www-data 20 0 315m 43m 4368 S 0,0 4,3 0:13.12 apache2
1700 www-data 20 0 314m 43m 4316 S 0,0 4,2 0:16.38 apache2
1701 www-data 20 0 319m 47m 4428 S 0,0 4,7 0:16.04 apache2
1702 www-data 20 0 317m 46m 4412 S 0,0 4,5 0:10.21 apache2
1703 www-data 20 0 302m 30m 4440 S 0,0 3,0 0:15.44 apache2
1714 root 20 0 20852 908 660 S 0,0 0,1 0:00.43 cron
1764 root 20 0 4136 632 492 S 0,0 0,1 0:00.02 mysqld_safe
2080 root 20 0 4044 656 552 S 0,0 0,1 0:00.00 logger
2206 nobody 20 0 30388 1084 440 S 0,0 0,1 0:01.29 openvpn
2306 root 20 0 72556 2028 432 S 0,0 0,2 0:03.79 sendmail-mta
2308 root 20 0 49888 1136 532 S 0,0 0,1 0:00.00 sshd
2462 root 20 0 14532 760 604 S 0,0 0,1 0:00.00 getty
2463 root 20 0 14532 760 604 S 0,0 0,1 0:00.00 getty
2464 root 20 0 14532 756 604 S 0,0 0,1 0:00.00 getty
2465 root 20 0 14532 748 604 S 0,0 0,1 0:00.00 getty
2466 root 20 0 14532 756 604 S 0,0 0,1 0:00.00 getty
2467 root 20 0 14532 760 604 S 0,0 0,1 0:00.00 getty
2758 www-data 20 0 324m 53m 4428 S 0,0 5,2 0:15.17 apache2
2763 www-data 20 0 302m 30m 4044 S 0,0 3,0 0:13.38 apache2
3059 www-data 20 0 319m 49m 5300 S 0,0 4,8 0:05.75 apache2

Rizz
31/03/2015, 12h13
Ton" Un VPS devrait tourner entre 70 et 90 de moyenne, " c'est quoi ? de la théorie ?
Parce que moi mon VPS sur SSD il fuse.. Mais c'est pas un RAID10 et est pas en OVER SOLD. Sur VPS Ovh j'ai jamais vu plus de 40M.

Et pour son TOp du message 5 il est à environ 140% d'utilisation CPU... Donc si c'est qu'un classic 1 .... oublie les perf ( deja utiliser apache ca craint .. et le % cpu sql montre que le site est dev les pieds ou spammer super fortement. )

sich
31/03/2015, 11h59
Et beh, si à 30 le fonctionnement est normal faudra m'expliquer....

adrien62
31/03/2015, 11h50
Retour du support concernant la vitesse du vps

Concernant les tests que vous avez effectués, ils sont corrects, peu d'utilisation mémoire, la vitesse d'accès disque est correcte pour un VPS Classic donc pour moi la problématique vient de l'utilisation de vous avez de votre VPS et les attaques DDoS spécifique au serveur Teamspeak que vous subissez sur votre VPS.
La mitigation est activée..

sich
30/03/2015, 20h06
Pour avoir vu passer l'info, et pour avoir eu le problème moi même, en dessous de 20 mb/s c'est qu'il y'a vraiment un soucis.
En l'occurrence moi à l'époque c'était un disque défaillant dans le filer d'après le support.
Un VPS devrait tourner entre 70 et 90 de moyenne, en dessous les perfs sont de toute façon trop mauvaises pour pouvoir tout simplement utiliser les services hébergés sur le vps.... Latence disque notamment....

Sich

adrien62
30/03/2015, 18h41
Le service c'est simplement mon teamspeak, rien de critique , juste le temps que je / qu'il règle le soucis ^^
Yep , j'ai vu ça c'est beaucoup plus fluide

Là je ne peux être plus clair

Je vais aller droit au but :

Est-il normal d'avoir une vitesse d’écriture aussi faible ?
J'ai effectué les diags que vous avez demandé, tout ça pour n'avoir aucun retour sur une possible défaillance.

Je ne cherche pas un commercial, voulant me vendre / proposer du cloud, pour un service qui était stable auparavant.
Je souhaite avoir un service de qualité, qui en ce moment, fait défaut depuis plus d'une semaine maintenant.

Cordialement,

janus57
30/03/2015, 18h27
Bonjour,

dans un ticket il n'est jamais bon de poser plusieurs questions qui n'ont aucun rapports entre eux genre parler du SWAP + latence HDD c'est pas bon.

OVH donne un certain nombre de MO SWAP en focntions de l'offre (j'avais demandé en 2013/2014 de mémoire), cette quantité de SWAP est fixe, apès si sa swap trop dure, comme d'hab faut passer a une offre au dessus.

Sinon là pour ton problème parle seulement et uniquement du débit en écriture qui est un peu merdique, ne parle ni de swap ni de vps bêta, ni de rien d'autre.

[HS]
Pas bon de mettre un service sur du VPS bêta, sa peu crasher à tout moment et c'est surtout que le VPS expire dans 1mois sans renouvellement possible.

Car contre les nouveau VPS semble dopé aux SSD alors que les anciens sont en SATA/SAS.
[/HS]

Cordialement, janus57

adrien62
30/03/2015, 16h37
Test sur un des serveurs "beta"

dd if=/dev/zero of=/var/swap.img bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 6.98748 s, 150 MB/s

contre

16384+0 enregistrements lus
16384+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 34,543 s, 31,1 MB/s

sur mon serveur actuel.
Ya réellement un soucis ..
Réponse du support :

30/03/2015 02:05
De : support
Bonjour,

Veuille nous excuser du délai de réponse.

Il est normal pour vous de ne pas avoir de permissions sur l'augmentation de la swap sur votre VPS car cela est une restriction qu'oppose OpenVZ sur le container.

Si vous souhaitez bénéficier d'une plus grande liberté sur le serveur (accès kernel, pas de restriction accès disque, meilleure stabilité de vos services, etc) un VPS Cloud répondra mieux à votre demande.

De plus, votre serveur vocal bénéficiera d'une meilleure stabilité.

Je reste à votre disposition pour toutes informations complémentaires.

Cordialement,

Maxime O.
Support OVH
@VPS
Sauf que je voulais simplement savoir si c'était anormal (pour confirmer ou pas mon idée), j'ai l'impression qu'ils font "exprés" de répondre à côté ..

PS : Pour l'histoire de la swap, j'avais effectivement posé la question à tout hasard auparavant, mais au vu de la quantité de logs & co, cette réponse me parait totalement dérisoire (surtout la partie où "je te place du cloud, on sait jamais"), mon service était stable depuis 1 an jusque à la semaine dernière, je ne vois pas l’intérêt de changer de machine / offre.

Moi qui suis le premier à vanter OVH, là c'est la désillusion totale. :/

sich
30/03/2015, 16h21
Vrai qu'un service VPS + fiable serait vraiment un bon +, même si ça doit être un chouillat + cher.
Faut avouer que pour ma part les VPS ne m'intéresse que pour les offres de bases, après vu les prix des + chers je préfère partir sur un soyoustart. A prix équivalent on a de bien meilleures perfs. Reste le soucis de la défaillance matérielle qui n'existe pas sur du vps. Mais bon, gérable.

adrien62
30/03/2015, 15h26
Oui jme suis laissé tenter par la béta, 150mb/s ça change de mon 29,7mb/s tout pourrave ^^, ducoup j'ai basculé certains service dessus (je sais pas bien c'est une béta)

J'attends le retour du support pour me dire si c'est anormal, et j'ouvre un ticket (ou pas) en conséquence.

janus57
30/03/2015, 15h21
Citation Envoyé par sich
C'est 20€ si c'est une ouverture de ticket abusive. Si le problème est réel tu n'es pas facturé.
Je n'ai jamais été facturé pour tous les tickets que j'ai ouvert. Après faut être sûr de son coup
Bonjour,

après si l'écriture sur HDD passe de 70 à 30MB/s et que le LoadAverage s’envole de 1 à 30 je pense que le soucis est bien réel.

Je ne connais pas la politique du service VPS sur le "minimum" en terme de perfs HDD, mais 30MB/s parait effectivement bien bas.
Sinon effectivement les 20€ c'est si le ticket a été ouvert "dans le vide" genre pour signaler un problème logiciel au niveau du VPS ou pour sigaler que son VPS est down alors que c'est un faux positif ou une erreur/problème de votre côté

[Gros HS]
Après vivement les nouveau VPS (genre comme les VPS anti-DDoS qui sont en bêta), car même sir le prix se vois un peu élveé les perfs sont au RDV sur la bêta zone (en même temps c'est des VPS prévu pour les jeux...).

Sinon pour faire "baver" ceux qui ont pas voulu participer à la bêta de 1mois
http://pastebin.com/raw.php?i=VZXkMnNm
[/Gros HS]

Cordialement, janus57

adrien62
30/03/2015, 15h17
Le vps est là pour se faire la main, mais étant encore novice au niveau diag,
- de 1 ça m’embêterait de déranger le support pour rien surtout que le bug est totalement aléatoire concernant les montées de charge et les déconnexions réseaux.
- et de 2 , 24€TTC c'est quasi le prix d'un an de location :/

Ducoup j'ai l'impression d'être "bloqué"

Précision : ticket support technique sur la nouvelle interface, c'est bien ça l'histoire du ticket ? ^^

sich
30/03/2015, 14h54
C'est 20€ si c'est une ouverture de ticket abusive. Si le problème est réel tu n'es pas facturé.
Je n'ai jamais été facturé pour tous les tickets que j'ai ouvert. Après faut être sûr de son coup

adrien62
30/03/2015, 14h48
Ticket support, au niveau du ticket incident le support m'a signalé que c'était un coût de 20€. Ducoup j'ai pas tenté

karclop
30/03/2015, 14h46
Bonjour,

J'ai aussi envoyé un ticket... Damien d'OVH tu te proposais de regarder mon vps58994.ovh.net ?

Merci.

Sebastien

janus57
30/03/2015, 14h27
Bonjour,

ticket incident ou support ?

Sachant que le plus rapide est le ticket incident.

Cordialement, janus57

adrien62
30/03/2015, 14h03
J'ai déjà un ticket en cours, depuis le 22/03, mais j'ai l'impression que rien n'avance.
J'ai un tempérament très patient, mais là je me retiens d'être désagréable !

Voilà le résultat exact

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 enregistrements lus
16384+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 36,1294 s, 29,7 MB/s

28/03/2015 - 19h

ioping . -c 20
request=1 time=3.7 ms
request=2 time=0.6 ms
request=3 time=101.1 ms
request=4 time=0.4 ms
request=5 time=0.8 ms
request=6 time=1.6 ms
request=7 time=1.7 ms
request=8 time=1.0 ms
request=9 time=69.6 ms
request=10 time=67.4 ms
request=11 time=85.4 ms
request=12 time=13.6 ms
request=13 time=1.1 ms
request=14 time=9.5 ms
request=15 time=20.8 ms
request=16 time=19.4 ms
request=17 time=0.7 ms
request=18 time=12.2 ms
request=19 time=11.0 ms
request=20 time=6.4 ms

20 requests completed in 19618.7 ms, 47 iops, 0.2 mb/s
min/avg/max/mdev = 0.4/21.4/101.1/30.9 ms

sich
30/03/2015, 13h51
30 c'est très faible, tu peux demander un ticket au support éventuellement.
Ou faire le même test en mode rescue par exemple pour exclure une anomalie sur ton système.

Perso je fais cette commande 2x / heure pour mrtg. (ou 1x / heure je sais plus bref), et j'ai une moyenne qui tourne entre 70 et 90. Avec de gros pics en mieux et parfois quelques baisses ponctuelles.

Sich

adrien62
30/03/2015, 13h48
top - 13:47:21 up 6:47, 1 user, load average: 22,93, 13,67, 5,63
Tasks: 52 total, 1 running, 51 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 1048576 total, 609384 used, 439192 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 117764 cached

Pour le test dd je suis à 31mb/s

karclop
30/03/2015, 12h57
J'ai lancé cette commande si ça peut aider...
root@vps58994:~# dd if=/dev/zero of=speetest bs=1M count=100 conv=fdatasync
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 1,64885 s, 63,6 MB/s

La commande htop donne la même chose que top...

adrien62
30/03/2015, 01h51
Même problème pour moi, j'ai ouvert un ticket, mais j'ai l'impression de tourner en rond avec le support.
J'ai une hausse du load average, puis une coupure totale d'accès au serveur, sans que les services plantent, alors que la charge cpu / ram est correcte.
Problème depuis vendredi dernier.

janus57
30/03/2015, 01h03
Bonjour,

regarde avec HTOP qui est beaucoup plus lisible que top de mon point de vue.

Sinon y a un truc bizarre exemple :
Code:
Sun, 29 Mar 2015 17:14:07 +0200
top - 17:14:07 up 1 day, 22:43, 0 users, load average: 29,96, 13,82, 5,93
Tasks: 185 total, 7 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6,9 us, 1,3 sy, 0,0 ni, 91,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1356108 used, 741044 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 358044 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1890 mysql 20 0 1371m 261m 4352 R 35,3 12,8 153:02.74 mysqld
17248 www-data 20 0 191m 12m 4816 R 23,5 0,6 0:54.93 apache2
17134 www-data 20 0 191m 14m 4020 R 17,6 0,7 0:49.30 apache2
17152 www-data 20 0 191m 12m 4812 S 11,8 0,6 0:11.46 apache2
20257 www-data 20 0 188m 9892 2992 S 11,8 0,5 0:00.11 apache2
17203 www-data 20 0 192m 13m 4800 S 8,8 0,7 0:20.03 apache2
17121 www-data 20 0 194m 13m 4116 R 5,9 0,7 0:14.51 apache2
17217 www-data 20 0 189m 12m 4052 S 5,9 0,6 0:12.42 apache2
17167 www-data 20 0 190m 12m 3244 S 2,9 0,6 0:26.32 apache2
17178 www-data 20 0 192m 13m 3308 R 2,9 0,7 0:28.95 apache2
17180 www-data 20 0 191m 12m 4644 S 2,9 0,6 0:09.37 apache2
17204 www-data 20 0 191m 12m 4676 S 2,9 0,6 0:20.37 apache2
17235 www-data 20 0 193m 13m 4044 S 2,9 0,7 0:27.77 apache2
17245 www-data 20 0 190m 11m 3340 S 2,9 0,6 0:10.43 apache2
20329 root 20 0 23612 1504 1084 R 2,9 0,1 0:00.05 top
35,2 + 23,5 + 17,6 + 5,9 + 2,9 + 2,9 ==> 88%

Donc que te donne un htop plutôt qu'un top ?
Est-ce que l'accès aux disques sont lent ou rapide (ce qui pourrait peut être expliqué que MySQL "mange" 35%, ou alors votre site consomme beaucoup de requêtes SQL).

Cordialement, janus57

karclop
29/03/2015, 17h30
Bonjour,

Voici quelques exemples de "top", ce que je ncomprends pas c'est que proc se repose pas mal ( 91,9% id ) le swap est jamais utilisé... et le load average s'embale parfois.
Merci pour votre aide, bonne fin de we.

Sebastien

Sun, 29 Mar 2015 17:13:04 +0200
top - 17:13:04 up 1 day, 22:42, 0 users, load average: 36,65, 12,45, 5,06
Tasks: 186 total, 9 running, 177 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6,9 us, 1,3 sy, 0,0 ni, 91,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1343460 used, 753692 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 356444 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20269 root 20 0 23612 1504 1084 R 34,7 0,1 0:00.22 top
1890 mysql 20 0 1371m 261m 4352 S 27,0 12,8 152:58.12 mysqld
17135 www-data 20 0 191m 12m 4656 R 19,3 0,6 0:34.88 apache2
17246 www-data 20 0 192m 12m 4812 R 19,3 0,6 0:16.89 apache2
17228 www-data 20 0 192m 12m 4064 R 13,5 0,6 0:09.33 apache2
17220 www-data 20 0 192m 12m 4132 R 11,6 0,6 0:24.48 apache2
17229 www-data 20 0 194m 14m 4748 R 9,6 0,7 0:20.36 apache2
20253 www-data 20 0 189m 10m 3128 S 9,6 0,5 0:00.43 apache2
20261 root 20 0 136m 9,9m 6340 R 9,6 0,5 0:00.20 php
17203 www-data 20 0 192m 13m 4800 R 5,8 0,7 0:19.94 apache2
17231 www-data 20 0 193m 14m 4816 S 5,8 0,7 0:26.11 apache2
17222 www-data 20 0 192m 13m 4644 S 3,9 0,7 0:30.32 apache2
17140 www-data 20 0 191m 12m 4820 S 1,9 0,6 0:17.28 apache2
17158 www-data 20 0 194m 14m 4000 S 1,9 0,7 0:17.68 apache2
17183 www-data 20 0 192m 13m 4728 S 1,9 0,7 0:22.55 apache2

Sun, 29 Mar 2015 17:14:07 +0200
top - 17:14:07 up 1 day, 22:43, 0 users, load average: 29,96, 13,82, 5,93
Tasks: 185 total, 7 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6,9 us, 1,3 sy, 0,0 ni, 91,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1356108 used, 741044 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 358044 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1890 mysql 20 0 1371m 261m 4352 R 35,3 12,8 153:02.74 mysqld
17248 www-data 20 0 191m 12m 4816 R 23,5 0,6 0:54.93 apache2
17134 www-data 20 0 191m 14m 4020 R 17,6 0,7 0:49.30 apache2
17152 www-data 20 0 191m 12m 4812 S 11,8 0,6 0:11.46 apache2
20257 www-data 20 0 188m 9892 2992 S 11,8 0,5 0:00.11 apache2
17203 www-data 20 0 192m 13m 4800 S 8,8 0,7 0:20.03 apache2
17121 www-data 20 0 194m 13m 4116 R 5,9 0,7 0:14.51 apache2
17217 www-data 20 0 189m 12m 4052 S 5,9 0,6 0:12.42 apache2
17167 www-data 20 0 190m 12m 3244 S 2,9 0,6 0:26.32 apache2
17178 www-data 20 0 192m 13m 3308 R 2,9 0,7 0:28.95 apache2
17180 www-data 20 0 191m 12m 4644 S 2,9 0,6 0:09.37 apache2
17204 www-data 20 0 191m 12m 4676 S 2,9 0,6 0:20.37 apache2
17235 www-data 20 0 193m 13m 4044 S 2,9 0,7 0:27.77 apache2
17245 www-data 20 0 190m 11m 3340 S 2,9 0,6 0:10.43 apache2
20329 root 20 0 23612 1504 1084 R 2,9 0,1 0:00.05 top

Sun, 29 Mar 2015 17:11:02 +0200
top - 17:11:02 up 1 day, 22:40, 0 users, load average: 1,25, 1,05, 1,09
Tasks: 168 total, 3 running, 165 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6,9 us, 1,3 sy, 0,0 ni, 91,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 1320540 used, 776612 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 355156 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1890 mysql 20 0 1371m 261m 4352 S 63,7 12,8 152:48.58 mysqld
20163 root 20 0 23612 1500 1084 R 27,9 0,1 0:00.08 top
17216 www-data 20 0 194m 14m 4744 R 15,9 0,7 0:34.68 apache2
17201 www-data 20 0 191m 13m 4764 R 11,9 0,6 0:16.93 apache2
17244 www-data 20 0 192m 13m 4688 S 11,9 0,6 0:19.55 apache2

karclop
27/03/2015, 17h41
vps58994.ovh.net - VPS 2014 Classic 2.

Je précise que je n'avais pas ce genre de pbs il y a quelques semaines et je n'ai pas changé mes scripts.

Merci !

damien.rannou
27/03/2015, 17h37
Bonjour,

Peux-tu m'envoyer le nom de ton vps ? Je vais regarder.

- - - Mise à jour - - -

Bonjour,

Peux-tu m'envoyer le nom de ton vps ? Je vais regarder.

karclop
27/03/2015, 16h49
Bonjour,

Voila j'ai parfois à certaines heures en pendant quelques minutes un load average élévé. Exemple :
Fri, 27 Mar 2015 13:00:06 +0100
top - 13:00:06 up 1 day, 15:46, 0 users, load average: 37,09, 11,64, 4,13
Tasks: 119 total, 6 running, 113 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,3 us, 0,9 sy, 0,0 ni, 95,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 921956 used, 1175196 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 324988 cached

Et parfois tt va bien :
Fri, 27 Mar 2015 16:20:02 +0100
top - 16:20:02 up 1 day, 19:06, 0 users, load average: 0,12, 0,41, 0,55
Tasks: 120 total, 2 running, 118 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,3 us, 0,9 sy, 0,0 ni, 95,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2097152 total, 945592 used, 1151560 free, 0 buffers
KiB Swap: 131072 total, 0 used, 131072 free, 396400 cached

En faisant un top je ne vois rien de spécial ( mysqld et apache2 sont au top des ressources CPU ). Ce que je ne comprends pas c'est que le processeur est loin d'être à 100% d'utilisation et la aucun pb de RAM ( le swap n'est jamais utilisé ).
*D'ou vient cette hausse soudaine ?
*Cela peut il venir du VPS ? avec un voisin qui prend bc de ressources ?
*Mauvais config de apache ou de mysql ?

Merci pour votre aide.

Sebastien