OVH Community, votre nouvel espace communautaire.

erreurs dmesg (jbd2/vda1-8:102 blocked for more than 120 seconds)


contremaitre
29/06/2016, 13h26
Je confirme, pendant 20mn de 12:45 a 13;05
Pas d'erreur dans dmesg sur les deux dernieres pannes, mais je le vois dans les stats

sich
29/06/2016, 13h04
Sérieusement, encore des soucis sur le cluster de stockage à SBG ??
root@vps291322:~# /bin/dd if=/dev/zero of=/etc/mrtg/speedtest bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 77.3371 s, 4.1 MB/s

root@vps291537:~# /bin/dd if=/dev/zero of=/etc/mrtg/speedtest bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 139.267 s, 2.3 MB/s

Un autre vps (vps242099) à nouveau dans les choux...

Cela devient très très très problématique maintenant !!!

sich
25/06/2016, 11h57
Encore des problèmes ce matin aux environs de 10H / 10H30....
Hormis 2 serveurs où le service amavis a planté les autres ont réussi à passer aux travers sans intervention de ma part...
Mais avec tout de même des soucis d'accès aux services...

Malgré le plantage de cette semaine nous n'avons eu encore aucun retour par OVH sur ce qui sera fait pour que ces problème s'arrêtent...
Assez flagrant le test d'accès disques non ?


sich
23/06/2016, 14h05
Non pas de test iowait. Et oui je sais bien qu'un serveur en activité va fausser les résultats.
Mais j'ai un VPS par projet /client. Par conséquent la plupart n'hébergent qu'un ou deux petit site et éventuellement un domaine de messagerie.
Pas de quoi saturer les accès disques.
Mon idée étant surtout de surveiller la disponibilité du stockage qui a posé pas mal de problème ces derniers temps.

Mais pourquoi pas, un test iowait pourrait être un + effectivement.

EtienneMenguy
23/06/2016, 13h11
Tu peux fixer une durée plutôt qu'une quantité. Tu seras certain de ne pas impacter le service plus de X secondes.
Tu monitor l'iowait?

Si tu fais ton bench pendant que ton serveur est utilisé, tu le fausses.

sich
23/06/2016, 12h52
ok ok je test ça.
Mais je ne veux pas non plus créer inutilement de la charge sur les disques, pour ça que 100 me semblait raisonnable.
Mais je test les 300 sur les 2 vps cloud ram que je viens de prendre pour voir si il y'a une différence notable.

EtienneMenguy
23/06/2016, 12h31
Augmente un peu la quantité de data, tu auras un bench plus constant/fiable.

root@xxx:~# /bin/dd if=/dev/zero of=toto bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 2.31252 s, 136 MB/s
root@xxx:~# /bin/dd if=/dev/zero of=toto bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 2.23577 s, 141 MB/s
root@xxx:~# /bin/dd if=/dev/zero of=toto bs=1M count=300 conv=fdatasync
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 2.22808 s, 141 MB/s


Je ne pense pas que les performances aient évolués depuis avant hier.

sich
23/06/2016, 12h08
Citation Envoyé par EtienneMenguy
Tes graphs remontent des benchs ou l'utilisation de tes disques?
C'est le résultat de cette commande 2x / heure :
/bin/dd if=/dev/zero of=/etc/mrtg/speedtest bs=1M count=100 conv=fdatasync

On voit d'ailleurs que ça remonte un peu, les travaux doivent progresser.

EtienneMenguy
23/06/2016, 10h58
Citation Envoyé par sich
Des travaux sont toujours en travaux sur SBG ?
Les perfs sur les disques sont vraiment mauvaises depuis les derniers incidents....
Rien qu'à voir les graphs de perfs sur un VPS Cloud que j'ai pris le week end dernier :
http://vps291537.ovh.net/speed.html

On voit bien la différence de vitesse des disques avant et après la panne....

Sommes nous condamner à avoir des perfs comme ça sur SBG ? (n'ayant pas de vps cloud sur GRA je ne peux pas comparer).
Tes graphs remontent des benchs ou l'utilisation de tes disques?

xttago
23/06/2016, 10h43
Citation Envoyé par yakki
C'est du n'importe quoi la SLA. Meme si ton VPS est en rade pendant 1 semaine avec une SLA de 99,99999999% , tu auras 20 € de compensation... Youpi ! Face a la crédibilité et au temps que tu as perdu, ca n'a que peu d'interet, non ?
Le probleme est que les clients d'OVH sont trop considérés comme des béta-testeurs, OVH innove mais les clients essuient les platres a chaque fois, c'est pénible...
exactement!

désolé pour le post je me suis relu et je me suis aperçu que ce n'était pas très limpide à lire!
Sinon le post #32 répond bien à ma question, on n'a pas tous les mêmes besoins en termes de performances bien sur, mais sur la régularité par contre on se retrouve tous sur ce point, personnellement ca peut ralentir ce n'est pas très grave mais que ca freeze sur plusieurs minutes c'est la cata pour mon service proposé qui doit donner réponse dans les 2 minutes max.

j'espere simplement que nous allons sur une pente ascendante, d'ailleurs pour remonter le % on est tranquille pour l'année, ...non?

sich
22/06/2016, 19h16
Des travaux sont toujours en travaux sur SBG ?
Les perfs sur les disques sont vraiment mauvaises depuis les derniers incidents....
Rien qu'à voir les graphs de perfs sur un VPS Cloud que j'ai pris le week end dernier :
http://vps291537.ovh.net/speed.html

On voit bien la différence de vitesse des disques avant et après la panne....

Sommes nous condamner à avoir des perfs comme ça sur SBG ? (n'ayant pas de vps cloud sur GRA je ne peux pas comparer).

yakki
22/06/2016, 09h58
Citation Envoyé par xttago
bon sinon faut attraper une formule avec SLA 99,999% ? par je suis pas sur que les 99,99% y soit encore sur la vps cloud.
C'est du n'importe quoi la SLA. Meme si ton VPS est en rade pendant 1 semaine avec une SLA de 99,99999999% , tu auras 20 € de compensation... Youpi ! Face a la crédibilité et au temps que tu as perdu, ca n'a que peu d'interet, non ?
Le probleme est que les clients d'OVH sont trop considérés comme des béta-testeurs, OVH innove mais les clients essuient les platres a chaque fois, c'est pénible...

xttago
21/06/2016, 18h49
Citation Envoyé par sich
Rassurons nous, ici http://travaux.ovh.com/?do=details&id=18746 on nous dit que ce n'est que 0,04% des données qui sont concernées...
2 serveurs concernés également l'un pas trop d'impact car usage faible en cette période, par contre l'autre en pleine recette client avec un blocage entre identifié par le client 10h00 et 10h30... bref...

bon sinon faut attraper une formule avec SLA 99,999% ? par je suis pas sur que les 99,99% y soit encore sur la vps cloud.

je ne sais pas trop quoi faire pour le coup, une offre ovh, ou concurrente qui serait plus fiable?
Peut-etre que ces problèmes sont des soucis de jeunesses ou de montées en charge sur le succès rencontré sur ces offres?

sich
21/06/2016, 12h30
Rassurons nous, ici http://travaux.ovh.com/?do=details&id=18746 on nous dit que ce n'est que 0,04% des données qui sont concernées...

contremaitre
21/06/2016, 12h25
Pareil, VPS cloud inaccessible toute la nuit, et accès aléatoires depuis ce matin.
Donc service fortement dégradé depuis hier 20h00 :/

sich
21/06/2016, 10h53
Oui pareil 2 serveurs à nouveau en rade...
Un des clients vient de m'appeler, dès que les choses se stabilisent départ de chez ovh.... 3 coupures déjà la semaine dernière pour les mêmes motif (problème de stockage).

[EDIT]
C'est reparti pour un tour, la plupart de mes vps cloud sur sbg sont entrain de tomber également....
Comment une telle panne peut elle se produire sur une infra vendue comme HA ?
[/EDIT]

Kactoo
21/06/2016, 10h41
De mon coté, j'ai un serveur qui n'arrête pas de tomber en panne depuis 21h41 hier, coupure sur coupure ...

sich
21/06/2016, 09h47
J'en ai eu 6 de down.... Sur tous mes vps cloud de SBG 1 seul n'a pas été coupé cette nuit.... Il est passé au travers des mailles....

buddy
21/06/2016, 09h39
Tu peux demander un remboursement.
Mais le SLA en lui même n'est qu'une indication ... C'est le remboursement après expiration du SLA qui montre le niveau de garantie.

Kactoo
21/06/2016, 09h37
Le serveur de mon client été down de 21h41 à 6h20 ! Vous ne tenez pas vos SLA.

sich
21/06/2016, 05h40
J'ai 5 serveurs down ce matin ! vps207848 vps218055 vps242099 vps291322 vps291537
Problème signalé depuis hier soir....
Tickets : 9047483599 et 2584799300

On m'a signé des travaux qui sont marqués résolus mais les serveurs sont tjrs HS....

A quoi ça sert de prendre des gammes cloud pour avoir des downtimes aussi important ?

identifiant client : sy4612

[EDIT]
D'après le support c'est lié à ceci : http://travaux.ovh.net/?do=details&id=18738
Retour à la normale ce matin vers 07H30.
Une explication un peu plus poussée ? Ce sont tous mes vps cloud sur SBG qui ont été impactés cette nuit tout de même... Avec des temps de coupures plus ou moins long selon les instances..
[/EDIT]

Kactoo
20/06/2016, 22h39
Et encore une panne, plus 1 mois que cela dure. Le serveur bloqué, impossible redémarrer depuis 1 heure en panne ...

sich
17/06/2016, 18h54
c'est lié à ça : http://travaux.ovh.com/?do=details&id=18702

EtienneMenguy
17/06/2016, 17h16
Bonjour,

Tu as des logs d'erreur? Coté stockage je ne trouve rien d'étrange.

Etienne

sich
17/06/2016, 15h15
Et encore un plantage de mon côté....
2° fois que le vps du client plante à cause de ça cette semaine c'est assez gênant...
On voit bien sur le graph qu'il y'a une bizarrerie sur les accès disques.
http://vps242099.siegler-informatique.fr/speed.html

Ces problèmes sont censés se reproduire souvent ? Car je vends un vps cloud au client pour m'assurer que le service soit dispo et au final c'est à cause du stockage que le vps n'est pas dispo....

Les problèmes ont commencé vers 14H50 sur le vps242099... à 15H10 c'était déjà terminé.

sich
13/06/2016, 10h53
http://travaux.ovh.com/?do=details&id=18581

Pour la récente panne... J'ai eu plusieurs vps en carafe aussi.
Assez pénible de devoir expliquer au client que le VPS Cloud qu'il a choisit qui est censé être HA se retrouve planté à cause de l'infra HA justement....

Ensuite concernant la concurrence ce n'est pas forcément évident de trouver un bon rapport qualité / prix ailleurs.
J'ai un VPS chez un autre presta qui est vraiment extrêmement stable, mais pas le même prix par contre.
Par exemple le VPS Cloud 1 se retrouve à pas loin de 24€ / mois contre 8 chez ovh...
Le VPS Cloud 2 est à 42€ / mois contre 16 chez ovh....

Après tout dépend du budget de chacun... Mais c'est dommage car jusqu'à fin décembre, courant janvier les vps cloud fonctionnaient parfaitement... Depuis les perfs se sont pas mal dégradées sans même parler des incidents comme ce matin encore...

EtienneMenguy
13/06/2016, 10h47
Ca fait suite à cet incident : http://travaux.ovh.com/?do=details&id=18581

Kactoo
13/06/2016, 10h33
Encore ce matin un blocaque de 10h10 à 10h20, je songe sérieusement a faire partir l'ensemble de mes services des VPS / Public cloud chez un concurrent, j'accumule de nombreuses pannes ses dernières semaines.
Vendredi, j'ai une panne aussi sur un VPS Cloud 2014 pendant près de 2h car l'host de stockage en panne. J'avais 6 serveurs VPS / Public Cloud chez OVH et je teste votre concurrent directe et bien ils sont bien plus sérieux et contractuellement tous est indiqué noir sur blanc sur les garanties tenu.

contremaitre
13/06/2016, 10h15
De nouveau le problème, en ce moment même depuis 5mn vps270375 :
[Mon Jun 13 10:07:52 2016] INFO: task jbd2/vda1-8:105 blocked for more than 120 seconds.
[Mon Jun 13 10:07:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 13 10:07:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 13 10:07:52 2016] jbd2/vda1-8 D ffff880133c287e8 0 105 2 0x00000000
[Mon Jun 13 10:07:52 2016] ffff880133c28390 0000000000000046 0000000000012f00 ffff8800b9083fd8
[Mon Jun 13 10:07:52 2016] 0000000000012f00 ffff880133c28390 ffff880139c137b0 ffff880139fc4170
[Mon Jun 13 10:07:52 2016] 0000000000000002 ffffffff811d7620 ffff8800b9083c80 ffff88007fd4a398
[Mon Jun 13 10:07:52 2016] Call Trace:
[Mon Jun 13 10:07:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:07:52 2016] [] ? io_schedule+0x99/0x120
[Mon Jun 13 10:07:52 2016] [] ? sleep_on_buffer+0xa/0x10
[Mon Jun 13 10:07:52 2016] [] ? __wait_on_bit+0x5c/0x90
[Mon Jun 13 10:07:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:07:52 2016] [] ? out_of_line_wait_on_bit+0x77/0x90
[Mon Jun 13 10:07:52 2016] [] ? autoremove_wake_function+0x30/0x30
[Mon Jun 13 10:07:52 2016] [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[Mon Jun 13 10:07:52 2016] [] ? pick_next_task_fair+0x3e3/0x820
[Mon Jun 13 10:07:52 2016] [] ? kjournald2+0xb2/0x240 [jbd2]
[Mon Jun 13 10:07:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 13 10:07:52 2016] [] ? commit_timeout+0x10/0x10 [jbd2]
[Mon Jun 13 10:07:52 2016] [] ? kthread+0xbd/0xe0
[Mon Jun 13 10:07:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:07:52 2016] [] ? ret_from_fork+0x58/0x90
[Mon Jun 13 10:07:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:09:52 2016] INFO: task jbd2/vda1-8:105 blocked for more than 120 seconds.
[Mon Jun 13 10:09:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 13 10:09:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 13 10:09:52 2016] jbd2/vda1-8 D ffff880133c287e8 0 105 2 0x00000000
[Mon Jun 13 10:09:52 2016] ffff880133c28390 0000000000000046 0000000000012f00 ffff8800b9083fd8
[Mon Jun 13 10:09:52 2016] 0000000000012f00 ffff880133c28390 ffff880139c137b0 ffff880139fc4170
[Mon Jun 13 10:09:52 2016] 0000000000000002 ffffffff811d7620 ffff8800b9083c80 ffff88007fd4a398
[Mon Jun 13 10:09:52 2016] Call Trace:
[Mon Jun 13 10:09:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:09:52 2016] [] ? io_schedule+0x99/0x120
[Mon Jun 13 10:09:52 2016] [] ? sleep_on_buffer+0xa/0x10
[Mon Jun 13 10:09:52 2016] [] ? __wait_on_bit+0x5c/0x90
[Mon Jun 13 10:09:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:09:52 2016] [] ? out_of_line_wait_on_bit+0x77/0x90
[Mon Jun 13 10:09:52 2016] [] ? autoremove_wake_function+0x30/0x30
[Mon Jun 13 10:09:52 2016] [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[Mon Jun 13 10:09:52 2016] [] ? pick_next_task_fair+0x3e3/0x820
[Mon Jun 13 10:09:52 2016] [] ? kjournald2+0xb2/0x240 [jbd2]
[Mon Jun 13 10:09:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 13 10:09:52 2016] [] ? commit_timeout+0x10/0x10 [jbd2]
[Mon Jun 13 10:09:52 2016] [] ? kthread+0xbd/0xe0
[Mon Jun 13 10:09:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:09:52 2016] [] ? ret_from_fork+0x58/0x90
[Mon Jun 13 10:09:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:11:52 2016] INFO: task jbd2/vda1-8:105 blocked for more than 120 seconds.
[Mon Jun 13 10:11:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 13 10:11:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 13 10:11:52 2016] jbd2/vda1-8 D ffff880133c287e8 0 105 2 0x00000000
[Mon Jun 13 10:11:52 2016] ffff880133c28390 0000000000000046 0000000000012f00 ffff8800b9083fd8
[Mon Jun 13 10:11:52 2016] 0000000000012f00 ffff880133c28390 ffff880139c137b0 ffff880139fc4170
[Mon Jun 13 10:11:52 2016] 0000000000000002 ffffffff811d7620 ffff8800b9083c80 ffff88007fd4a398
[Mon Jun 13 10:11:52 2016] Call Trace:
[Mon Jun 13 10:11:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:11:52 2016] [] ? io_schedule+0x99/0x120
[Mon Jun 13 10:11:52 2016] [] ? sleep_on_buffer+0xa/0x10
[Mon Jun 13 10:11:52 2016] [] ? __wait_on_bit+0x5c/0x90
[Mon Jun 13 10:11:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 13 10:11:52 2016] [] ? out_of_line_wait_on_bit+0x77/0x90
[Mon Jun 13 10:11:52 2016] [] ? autoremove_wake_function+0x30/0x30
[Mon Jun 13 10:11:52 2016] [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[Mon Jun 13 10:11:52 2016] [] ? pick_next_task_fair+0x3e3/0x820
[Mon Jun 13 10:11:52 2016] [] ? kjournald2+0xb2/0x240 [jbd2]
[Mon Jun 13 10:11:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 13 10:11:52 2016] [] ? commit_timeout+0x10/0x10 [jbd2]
[Mon Jun 13 10:11:52 2016] [] ? kthread+0xbd/0xe0
[Mon Jun 13 10:11:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:11:52 2016] [] ? ret_from_fork+0x58/0x90
[Mon Jun 13 10:11:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 13 10:11:52 2016] INFO: task repquota:4436 blocked for more than 120 seconds.
[Mon Jun 13 10:11:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 13 10:11:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 13 10:11:52 2016] repquota D ffff880134b946a8 0 4436 4435 0x00000000
[Mon Jun 13 10:11:52 2016] ffff880134b94250 0000000000000086 0000000000012f00 ffff880134af3fd8
[Mon Jun 13 10:11:52 2016] 0000000000012f00 ffff880134b94250 ffff88007fd4a000 000000000006243d
[Mon Jun 13 10:11:52 2016] ffff88007fd4a088 ffff88007fd4a024 ffff880134af3e48 ffff88007fd4a0a0
[Mon Jun 13 10:11:52 2016] Call Trace:
[Mon Jun 13 10:11:52 2016] [] ? jbd2_log_wait_commit+0x95/0x100 [jbd2]
[Mon Jun 13 10:11:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 13 10:11:52 2016] [] ? ext4_sync_fs+0x12d/0x140 [ext4]
[Mon Jun 13 10:11:52 2016] [] ? dquot_quota_sync+0x43/0x130
[Mon Jun 13 10:11:52 2016] [] ? SyS_quotactl+0x39f/0x710
[Mon Jun 13 10:11:52 2016] [] ? task_work_run+0x91/0xb0
[Mon Jun 13 10:11:52 2016] [] ? do_notify_resume+0x69/0xa0
[Mon Jun 13 10:11:52 2016] [] ? system_call_fast_compare_end+0x10/0x15

EtienneMenguy
07/06/2016, 11h13
Sich : rien d'anormal à cette heure là de notre côté

Justme : un serveur a eu énormément de load sur un serveur pendant quelques minutes, je creuse pour avoir une explication (aucun problème de disque)

contremaitre : un serveur est monté en load et a reboot de lui même, un disque était en fait KO. Lorsque l'on a les symptômes avant le système ne remonte les anomalies il est difficile de réagir. Heureusement ce sont des problèmes très rares.

contremaitre
06/06/2016, 21h51
Je viens d'avoir encore l'erreur, serveur bloqué 10 minutes :
Mon Jun 6 21:23:52 2016] INFO: task jbd2/vda1-8:105 blocked for more than 120 seconds.
[Mon Jun 6 21:23:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 6 21:23:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 6 21:23:52 2016] jbd2/vda1-8 D ffff880133c287e8 0 105 2 0x00000000
[Mon Jun 6 21:23:52 2016] ffff880133c28390 0000000000000046 0000000000012f00 ffff8800b9083fd8
[Mon Jun 6 21:23:52 2016] 0000000000012f00 ffff880133c28390 ffff880139d137b0 ffff880139fcd188
[Mon Jun 6 21:23:52 2016] 0000000000000002 ffffffff811d7620 ffff8800b9083c80 ffff88007fd4a398
[Mon Jun 6 21:23:52 2016] Call Trace:
[Mon Jun 6 21:23:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 6 21:23:52 2016] [] ? io_schedule+0x99/0x120
[Mon Jun 6 21:23:52 2016] [] ? sleep_on_buffer+0xa/0x10
[Mon Jun 6 21:23:52 2016] [] ? __wait_on_bit+0x5c/0x90
[Mon Jun 6 21:23:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 6 21:23:52 2016] [] ? out_of_line_wait_on_bit+0x77/0x90
[Mon Jun 6 21:23:52 2016] [] ? autoremove_wake_function+0x30/0x30
[Mon Jun 6 21:23:52 2016] [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[Mon Jun 6 21:23:52 2016] [] ? pick_next_task_fair+0x3e3/0x820
[Mon Jun 6 21:23:52 2016] [] ? kjournald2+0xb2/0x240 [jbd2]
[Mon Jun 6 21:23:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 6 21:23:52 2016] [] ? commit_timeout+0x10/0x10 [jbd2]
[Mon Jun 6 21:23:52 2016] [] ? kthread+0xbd/0xe0
[Mon Jun 6 21:23:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 6 21:23:52 2016] [] ? ret_from_fork+0x58/0x90
[Mon Jun 6 21:23:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 6 21:25:52 2016] INFO: task jbd2/vda1-8:105 blocked for more than 120 seconds.
[Mon Jun 6 21:25:52 2016] Not tainted 3.16.0-4-amd64 #1
[Mon Jun 6 21:25:52 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Jun 6 21:25:52 2016] jbd2/vda1-8 D ffff880133c287e8 0 105 2 0x00000000
[Mon Jun 6 21:25:52 2016] ffff880133c28390 0000000000000046 0000000000012f00 ffff8800b9083fd8
[Mon Jun 6 21:25:52 2016] 0000000000012f00 ffff880133c28390 ffff880139d137b0 ffff880139fcd188
[Mon Jun 6 21:25:52 2016] 0000000000000002 ffffffff811d7620 ffff8800b9083c80 ffff88007fd4a398
[Mon Jun 6 21:25:52 2016] Call Trace:
[Mon Jun 6 21:25:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 6 21:25:52 2016] [] ? io_schedule+0x99/0x120
[Mon Jun 6 21:25:52 2016] [] ? sleep_on_buffer+0xa/0x10
[Mon Jun 6 21:25:52 2016] [] ? __wait_on_bit+0x5c/0x90
[Mon Jun 6 21:25:52 2016] [] ? generic_block_bmap+0x50/0x50
[Mon Jun 6 21:25:52 2016] [] ? out_of_line_wait_on_bit+0x77/0x90
[Mon Jun 6 21:25:52 2016] [] ? autoremove_wake_function+0x30/0x30
[Mon Jun 6 21:25:52 2016] [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[Mon Jun 6 21:25:52 2016] [] ? pick_next_task_fair+0x3e3/0x820
[Mon Jun 6 21:25:52 2016] [] ? kjournald2+0xb2/0x240 [jbd2]
[Mon Jun 6 21:25:52 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Mon Jun 6 21:25:52 2016] [] ? commit_timeout+0x10/0x10 [jbd2]
[Mon Jun 6 21:25:52 2016] [] ? kthread+0xbd/0xe0
[Mon Jun 6 21:25:52 2016] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 6 21:25:52 2016] [] ? ret_from_fork+0x58/0x90
[Mon Jun 6 21:25:52 2016] [] ? kthread_create_on_node+0x180/0x180

justme
06/06/2016, 15h26
Jun 5 07:17:33 ums kernel: [1454880.392160] INFO: task jbd2/vda1-8:192 blocked for more than 120 seconds.
Jun 5 07:17:33 ums kernel: [1454880.402776] jbd2/vda1-8 D ffff880139d13180 0 192 2 0x00000000
Jun 5 07:17:33 ums kernel: [1454880.402969] [] jbd2_journal_commit_transaction+0x1943/0x1b90
Jun 5 07:19:33 ums kernel: [1455000.404118] INFO: task jbd2/vda1-8:192 blocked for more than 120 seconds.
Jun 5 07:19:33 ums kernel: [1455000.411932] jbd2/vda1-8 D ffff880139d13180 0 192 2 0x00000000
Jun 5 07:19:33 ums kernel: [1455000.412156] [] jbd2_journal_commit_transaction+0x1943/0x1b90

sich
06/06/2016, 13h41
Pour ma part un problème ce matin sur vps242099 à 11H55 sur SBG.(c'est un vps cloud 1) avec un mail de la part de cron comme quoi il n'a pas pu s'exécuter car un autre process était déjà en cours...
Après vérif il y'a bien eu un soucis côté disque http://vps242099.siegler-informatique.fr/speed.html

EtienneMenguy
06/06/2016, 13h19
Sans la date et heure il est difficile de donner une explication, mais ce n'est probablement pas en lien avec l'agrandissement du cluster.

justme
06/06/2016, 11h13
VPS 2016 cloud 2 GRA.
je vois qu'hier:
[1454880.392160] INFO: task jbd2/vda1-8:192 blocked for more than 120 seconds.
[1455000.404118] INFO: task jbd2/vda1-8:192 blocked for more than 120 seconds.
c'est un cadeau de l'extension du cluster de stockage en cours ?
en tout cas ça marche mieux ce matin:
min/avg/max/mdev = 3.4 ms / 33.3 ms / 971.2 ms / 120.4 ms

EtienneMenguy
06/06/2016, 09h14
Tu as fait le test à quelle heure et sur quel DC? Tu as un VPS 1 2 ou 3 ?

sich
03/06/2016, 15h44
Malheureusement les perfs côté disque restent assez instables...
Avec des passages où ça fonctionne super bien et d'autres où.... Ben on regrette de ne pas être sur un vrai dédié...
Mais bon, les outils du public cloud sont vraiment pratiques (snapshot, upgrade, etc).

justme
03/06/2016, 13h57
Suis-je tombé sur le cas en question ?
sur le papier ça dépote:
fio: write: io=650648KB, bw=5420.8KB/s, iops=1355, runt=120029msec
dd bs=128k count=4096 if=/dev/zero of=test conv=fdatasync
4096+0 records in
4096+0 records out
536870912 bytes (537 MB) copied, 8.12878 s, 66.0 MB/s

dans la vraie vie (ioping):
min/avg/max/mdev = 4.2 ms / 795.9 ms / 11.6 s / 2.0 s
oui oui, ce sont bien des SECONDES...
les problèmes de perf stockage datent du RPS et ne sont toujours pas réglés... Tout a changé, sauf le résultat

EtienneMenguy
03/06/2016, 10h59
Petit oubli, il y a une tâche travaux.
http://travaux.ovh.com/?do=details&id=18188

EtienneMenguy
03/06/2016, 10h00
lors du démontage de la partition, le process est tombé en D et le serveur a du être redémarré. Désolé pour la gêne.

Kactoo
03/06/2016, 01h03
Encore une panne, à 0h49 aujourd'hui.
Blocage du serveur pendant dix minutes ...

EtienneMenguy
31/05/2016, 13h18
On a mis en production ce matin le patch qui devrait résoudre le problème lors d'un changement de disque. On attend que le problème se produise pour pouvoir confirmer le bon fonctionnement.

Kactoo
26/05/2016, 17h51
J'ai eu une réponse du service commercial m'indiquant que sur les instances de type SP et HG avec stockage HA block storage, c'est du 250 IOPS min. Cela devrait être indiqué comme chez les autres services dans les détails de l'offre.

EtienneMenguy
24/05/2016, 08h28
Citation Envoyé par sich
Merci pour ce retour !
Je n'ai rien trouvé sur travaux.ovh.com. J'ai mal cherché ou peut être que l'incident n'a pas été répertorié.
Effectivement, la personne qui s'en est occupée ne parle pas français et n'a fait la tache travaux. Je vais voir avec l'équipe pour que ce soit créé, même en anglais.
J'ai créé la tache travaux avec les infos.

Citation Envoyé par justme
sich,
merci pour l'éclairage (qui devrait être dans la description du produit à mon avis). La question qui tue, comment teste-t-on les 200iops garantis décrits sur l'extension de stockage ? Si c'est comme ça on est mal barrés
ioping -R -D -W .

--- . (ext4 /dev/vda1) ioping statistics ---
82 requests completed in 3.2 s, 25 iops, 101.4 KiB/s
min/avg/max/mdev = 4.0 ms / 39.4 ms / 416.8 ms / 62.8 ms
Il existe une documentation pour ça
https://www.ovh.com/fr/g1956.tester_...se_des_disques

justme
23/05/2016, 16h25
sich,
merci pour l'éclairage (qui devrait être dans la description du produit à mon avis). La question qui tue, comment teste-t-on les 200iops garantis décrits sur l'extension de stockage ? Si c'est comme ça on est mal barrés
ioping -R -D -W .

--- . (ext4 /dev/vda1) ioping statistics ---
82 requests completed in 3.2 s, 25 iops, 101.4 KiB/s
min/avg/max/mdev = 4.0 ms / 39.4 ms / 416.8 ms / 62.8 ms

sich
23/05/2016, 14h31
@Contremaitre : j'ai simplement utilisé ça : http://www.phpservermonitor.org/
Après j'ai d'autres scripts sur les vps eux mêmes pour alimenter des graphs mrtg... Donc généralement quand une collecte d'info se passe mal je reçois un mail (comportement normal de cron ça).


@ justme : le VPS SSD a les disques en local sur l'host. Il y'a bien des disques raids (et encore pas sur les offres SP-SSD ou HG-SSD) mais si l'host tombe pour une panne quelconque (hard of soft) ton vps est down aussi. OVH. En cas de panne grave ton vps peut être down pendant un bon moment. Pour ma part j'ai plusieurs VPS SSD mais je n'ai eu qu'un seul gros problème pendant peut être 2H, je ne me souviens plus trop. Les offres SP et HG n'ayant pas de raid local si le disque tombe tu perds toutes tes données ...

Les offres cloud sont sur des disques réseaux. Donc si l'host tombe c'est un autre host qui va prendre le relais assez rapidement. Ce qui garantie une meilleure disponibilité de tes services. Sans oublier le raid 10 qui protège les données (sauf incident majeur).
Le prix à payer étant effectivement des perfs disques plus mauvaises. Mais là c'est un problème de surcharge des filers, car au lancement de l'offre les perfs étaient excellentes sur les offres cloud... Pour moi j'ai vue une nette dégradation à partir de la fin du mois de janvier de cette année. Puis un gros creux au mois d'avril et une légère amélioration depuis ce mois ci. Mais on est loin des perfs de fin 2015 encore.

Donc le VPS SSD c'est ok pour les services non critiques qui peuvent se permettre exceptionnellement une coupure de plusieurs heures.
Les offres cloud sont pour les offres qui demandent une disponibilité plus importante.
Quand aux offres SP-SSD et HG-SSD à mes yeux ça se limite aux besoins ponctuels, ou pour de la réplication. Dans mon cas je m'en sers pour augmenter mon infra en cas de charge sur un cluster web + mysql. Ce sont des instances temporaires qui ne durent que quelques heures, voir 1 ou 2 jours max. Mais la base du cluster (3 serveurs) sont sur des offres SP en HA.

Donc tout dépends de tes besoins et du risque que tu es prêts à prendre.

contremaitre
23/05/2016, 14h15
sich : est ce que tu partagerai tes scripts pour probe les vps et avoir un message d’alerte quand ils sont down ?

justme
23/05/2016, 13h47
Citation Envoyé par EtienneMenguy
Les VPS sont dans webs et les instances public cloud dans cloud.
Cependant il y a des instances public cloud nommées VPS.
C'est bien là qu'est l'os Typiquement, pourquoi un client ne prendrait-il pas un VPS SSD qui se trouve en plus être moins cher qu'un VPS Cloud (le bien nommé qui est dans la section Web par opposition au VPS SSD qui lui est dans la section Cloud ? ). D'un côté on a du moins cher pour -0.04% de SLA mais avec du SSD en plus. De l'autre on paie plus cher pour du disque plus lent mais c'est potentiellement pluS disponible. Bizarre comme positionnement non ? à part le stockage, quelle différence d'infra justifie de l'écart de prix/SLA ? Et qu'en est-il en réalité (degré d'indisponibilité réel constaté ) ? Merci.

sich
23/05/2016, 13h09
Merci pour ce retour !
Je n'ai rien trouvé sur travaux.ovh.com. J'ai mal cherché ou peut être que l'incident n'a pas été répertorié.

EtienneMenguy
23/05/2016, 12h00
Dans la nuit de dimanche à lundi, il y a eu deux disques dans différents racks d'impactés. On a donc été obligé de modifier la configuration du cluster pour résoudre le problème, ce qui explique la durée de l'incident.

Les VPS sont dans webs et les instances public cloud dans cloud.
Cependant il y a des instances public cloud nommées VPS. Ton ticket est en cours de traitement.

justme
23/05/2016, 10h46
Bonjour,
j'ai aussi un incident d'ouvert sur un vps tout neuf de la semaine dernière...
ioping -D -W .
4.0 KiB from . (ext4 /dev/vda1): request=1 time=39.1 ms
4.0 KiB from . (ext4 /dev/vda1): request=2 time=16.8 ms
4.0 KiB from . (ext4 /dev/vda1): request=3 time=22.3 ms
4.0 KiB from . (ext4 /dev/vda1): request=4 time=37.7 ms
4.0 KiB from . (ext4 /dev/vda1): request=5 time=35.7 ms
4.0 KiB from . (ext4 /dev/vda1): request=6 time=54.3 ms
4.0 KiB from . (ext4 /dev/vda1): request=7 time=359.6 ms
4.0 KiB from . (ext4 /dev/vda1): request=8 time=14.5 ms
4.0 KiB from . (ext4 /dev/vda1): request=9 time=9.0 ms
4.0 KiB from . (ext4 /dev/vda1): request=10 time=8.1 ms
4.0 KiB from . (ext4 /dev/vda1): request=11 time=4.2 ms
4.0 KiB from . (ext4 /dev/vda1): request=12 time=988.7 ms
4.0 KiB from . (ext4 /dev/vda1): request=13 time=4.2 ms
4.0 KiB from . (ext4 /dev/vda1): request=14 time=17.0 ms
^C
--- . (ext4 /dev/vda1) ioping statistics ---
14 requests completed in 15.2 s, 8 iops, 34.8 KiB/s
min/avg/max/mdev = 4.2 ms / 115.1 ms / 988.7 ms / 257.7 ms
je n'ai pas pris de SSD en pensant qu'ils n'étaient pas RAID mais en fait si... Bon le SLA est moindre, par contre ils sont visibles dans la console Cloud et pas dans Web -> c'est un peu le bordayle non tout ça ? Un peu de ménage s'impose

sich
23/05/2016, 10h31
J'ai eu plusieurs autres vps d'impactés, la plupart j'ai seulement reçu une alerte à cause de mrtg.
Il se lance toutes les 5min via cron et quand il y'a déjà un process en cours je reçois un mail d'alerte.
Donc mail à 23H45 sur vps218055, 217119, 218765 avec soit l'erreur mrtg, soit une erreur sur le script de test des accès disques.

Les graphiques mrtg sont très clairs il y'a eu un soucis sur les disques de 23H30 à 00H30 environ sur tous ces vps.

Bon après en pleine nuit sur ces serveurs ça ne me dérange pas trop. Surtout que ça n'a entrainé aucun problème une fois les disques revenus à la normale.

EtienneMenguy
23/05/2016, 09h04
Bonjour, je me renseigne sur ce qui est arrivé dans le weekend.

sich
23/05/2016, 08h22
Pour ma part j'ai encore eu de gros soucis sur mes vps207848 et vps242099..
Sur le207848 accès disques down hier soir de 23H à 0H30... Le monitoring de mon côté me dit un peu plus tard mais il ne se déclenche pas de suite..
Pour le 242099 exactement pareil avec en plus hier matin vers 11H/11H30 et ce matin autour de 7H30...
C'est vraiment problématique d'avoir des problèmes disques comme ça...
J'avais espéré plus de stabilité après les travaux sur SBG mais je vois qu'on a toujours de gros problème de stabilité à ce niveau...

EtienneMenguy
20/05/2016, 10h43
C'est le but oui.

Kactoo
19/05/2016, 20h33
D'accord donc nous auront plus le soucis ? Car cette après-midi, nous avons eu encore des pannes vers 16h48, 16h20, 16h10 pendant quelques minutes.

EtienneMenguy
19/05/2016, 15h40
Nous avons trouvé une solution définitive aux problèmes rencontrés lorsqu'un disque est défectueux, nous développons son automatisation.

sich
19/05/2016, 10h56
Citation Envoyé par Kactoo
Sur les VPS SSD, ils sont moins stable que les VPS Cloud. Les VPS SSD ont de meilleur performance disque en général avec de rare cas de ralentissement, mais j'ai eu plusieurs fois des hosts down pendant des heures. Je suis déçu des VPS en générale, je suis près a prendre un service plus chère mais avec des garanties, sur vos offre Public Cloud, il y'a indiqué des garanties mais sans indiquer le minimum, donc on ne sait pas.
C'est pour éviter ce genre de risques qu'une bonne partie de mes clients ont choisi des vps cloud.
Très sincèrement la plupart fonctionnent très bien, mais j'ai 2/3 cas avec des performances vraiment sous la moyenne.
Généralement c'est l'accès disque qui pose problème, et quand c'est lent ben forcément ça ralentit tout le serveur.
On a beau tenter d'utiliser un max les caches ou les ramdisk il faut tout de même pouvoir accéder au disque régulièrement.

Côté SSD je dois être chanceux car je n'ai pas eu trop de problèmes à ce jour. Mais votre expérience confirme le besoin de rester sur des gammes cloud en prod sur des services importants.

- - - Updated - - -

Citation Envoyé par EtienneMenguy
Je vous ai envoyé un mail pour avoir plus d'informations sur les différents problèmes.
Hum je ne vois rien dans les tickets ovh, rien dans ma boite mail, ni sur le forum...
Je le trouve où ce message ?
Mon compte ovh est sy4612 en cas de besoin.

EtienneMenguy
19/05/2016, 10h35
Citation Envoyé par sich
Mes alertes me remontent les problèmes suivant le 17/05 :
vps242099 ne répondant plus à partir de 15H18
vps207848 ne répondant plus à partir de 15H31.
Je vous ai envoyé un mail pour avoir plus d'informations sur les différents problèmes.

Kactoo
19/05/2016, 10h24
Sur les VPS SSD, ils sont moins stable que les VPS Cloud. Les VPS SSD ont de meilleur performance disque en général avec de rare cas de ralentissement, mais j'ai eu plusieurs fois des hosts down pendant des heures. Je suis déçu des VPS en générale, je suis près a prendre un service plus chère mais avec des garanties, sur vos offre Public Cloud, il y'a indiqué des garanties mais sans indiquer le minimum, donc on ne sait pas.

sich
19/05/2016, 09h56
Mes alertes me remontent les problèmes suivant le 17/05 :
vps242099 ne répondant plus à partir de 15H18
vps207848 ne répondant plus à partir de 15H31.

Je probe toutes les 5 min et j'envoie un mail d'alerte au bout de 3 erreurs.

Les 2 sont redevenus dispo vers 17H sans que je fasse quoi que ce soit.

Je n'ai pas trop creusé vu que je savais qu'il y'avait des travaux sur le stockage... Les serveurs n'ont même pas redémarré... Par contre certains services ont planté et il a fallu les redémarrer à la main.
Par contre mes graphs MRTG sont vides pour ces périodes, comme si le serveur avait été à l'arrêt complet, ou qu'il n'a rien pu écrire sur le disque.
Et j'ai eu des erreurs sur mes tests de vitesse sur les disques un peu avant les plantages. Donc pour moi c'est clairement le stockage qui a posé problème.
Avec des vitesses d'accès disques mesurés autour de 10/15 mb/s.....Quand j'arrivais à mesurer quelque chose...

L'un de ces vps d'ailleurs a tjrs des vitesses d'accès déplorables à l'heure actuelle pour cette gamme... Pire qu'un vieux vps 2014...
Mais bon, ce VPS n'a jamais eu de bonnes perfs depuis qu'il est lancé (moyenne à 90mb/s, ne dépasse quasiment jamais les 100... Mais peux descendre à 30mb/s)... Et le support me dit que c'est normal
Je vais probablement en louer un autre, tester les perfs et finir par basculer mon client dessus et fermer celui qui pose problème... Tant pis pour la réputation de l'IP..

Après le problème des VPS SSD c'est que l'host peux tomber et on a pas trop de garanties dessus.
Mais avec le recul je me rends compte que mes VPS SSD tournent mieux, et j'ai du avoir 1 coupure sur l'un d'entre eux pendant 1H max je crois... Donc moins de problème que les Cloud qui sont vendu comme HA...
C'est là dessus que je suis déçu... Car les VPS Cloud avaient d'excellente perfs au lancement de l'offre. Mais quand on regarde l'évolution on se rends bien compte que les filer ont été chargé au max et que les perfs s'en ressentent fortement et se dégradent progressivement dans le temps. Même si j'ai pu constater une amélioration à nouveau ces derniers temps je dois le reconnaitre. J'espère que les travaux en cours sur SBG vont continuer dans ce sens.

EtienneMenguy
19/05/2016, 09h32
Ce n'est pas normal que ton instance soit restée KO pendant 2 heures, si tu as des informations on peut regarder ce qu'il s'est passé.

Les différentes instances répondent à différents besoins, si on a des besoins spécifiques en stockage, les instances SSD peuvent être une solution.

sich
18/05/2016, 18h50
Oui les perfs disques sur les instances cloud sont assez aléatoires...
Il y'a encore eu de la maintenance sur SBG et les perfs se sont fortement dégradées... J'ai même eu 2 serveurs dans les choux pendant 2H....

Les VPS SSD sont bien plus stable, et avec le retour d'expérience je vais finir par passer tous mes clients sur du VPS SSD... Au pire en cas de panne grave je réinjecte les backups de la nuit sur une nouvelle instance... Au final j'ai vraiment l'impression que les VPS Cloud sont vraiment border line en prod si le serveur est un peu sollicité...

Kactoo
18/05/2016, 17h33
D'accord donc pour une machine Public cloud HG-7 ... cela veut dire qu'on a la garantie d'avoir des performances stable. Par contre je trouve qu'il y'a un problème, vous garantissez un maximum mais pas un minimum en terme IOPS (c'est bizarre).

EtienneMenguy
18/05/2016, 17h22
On vient de réavoir le soucis, le workaround appliqué a permis de réduire l'impact à une minutes, cependant c'est loins d'être parfait. On continue à travailler sur le problème. Le but étant de ne plus être impacté lors d'un problème sur un disque.

Côté public cloud, les instances VPS-SSD 1/2/3 proposent un raid ssd local, les instances SP/EG SSD elles n'ont pas de RAID sur le ssd local.
Ces instances ne tournant pas sur un stockage mutualisé, vous ne serez pas impactés par des interventions de maintenance, amélioration de performances qui peuvent engender une diminution temporaire des performances.

Etienne

Kactoo
18/05/2016, 16h57
J'ai eu mon coté aussi le :

2 Mai à 11h10
2 Mai à 11h56
2 Mai à 12h05
... de nombreuse autres panne assez courte mais qui ont augmenté en durée. Et cela a eu la conséquence de bloquer le serveur MySQL.

Ce que j'aimerais savoir si vous avez des VPS avec ressource garantie au niveau disque, es-ce que les Public Cloud sont garantie et exempte de ce type de problème.
Car sur les VPS Cloud, j'ai régulièrement des baisses de performance au niveau disque et c'est très problématique pour des applications en production. Car j'ai des ralentissement passage sur plusieurs de mes applications et donc des visiteurs.
J'aimerai que OVH nous garantisse au moins un minimum de fonctionnement.

contremaitre
18/05/2016, 12h47
Pour moi c'est : vps270375
Et les heures :
[Mon May 2 11:10:13 2016]
[Mon May 2 12:20:13 2016]
[Mon May 2 12:26:13 2016]

EtienneMenguy
18/05/2016, 12h02
On a réfléchi à un workaround au prochain soucis sur un disque avant d'obtenir une solution définitive.

Je reviens poster dès que l'on aura eu le cas.

EtienneMenguy
18/05/2016, 10h34
Je retrouve bien l'anomalie à cette même heure, cependant cela n'aurait pas du durer aussi longtemps.
Je creuse.

Merci pour les informations.

Kactoo
18/05/2016, 09h45
Bonjour,
Nous avons fait évolué le VPS vers une offre supérieur. Nous avons eux une amélioration, l'ID du serveur est 226953.

Merci

- - - Mise à jour - - -

Nous avons eux des problème hier, a 12h48 pendant plus de 30 min et vers 15h. La semaine dernières plusieurs fois, vendredi 11 mais à 19h 55 ... et encore d'autres ...

EtienneMenguy
18/05/2016, 09h16
Bonjour,

Pouvez-vous m'indiquer vos ID de VPS et la date et heure où est arrivé le problème?

Lorsqu'un disque du cluster ne fonctionne plus, il est possible que certaines requêtes se retrouvent bloquées et que vous ayez ce genre de logs.

Etienne

contremaitre
17/05/2016, 21h45
Je n'ai plus eu cette erreur depuis 15 jours

Kactoo
13/05/2016, 16h20
J'ai reçu une réponse bateau du support en me disant que nous surchargeons le serveur ... Ce n'est pas le cas, mais bon. C'est sans doute un voisin sur l'host qui plante les performances disque.

Kactoo
11/05/2016, 12h40
Je pense que c'est un défaut du stockage, une lenteur ou un blocage. Sur mon serveur, cela bloque le processus de Mysql.

contremaitre
11/05/2016, 12h26
ok je veux bien connaître leur réponse.
Merci

Kactoo
11/05/2016, 11h59
Citation Envoyé par contremaitre
Bonjour,
J'ai ce type d'erreurs sur les deux derniers jours sur mon VPS cloud :
Inquiétant ?
Code:
[1460160.124244] INFO: task jbd2/vda1-8:102 blocked for more than 120 seconds.
[1460160.126152]       Not tainted 3.16.0-4-amd64 #1
[1460160.127427] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[1460160.129722] jbd2/vda1-8     D ffff880133c2adf8     0   102      2 0x00000000
[1460160.129746]  ffff880133c2a9a0 0000000000000046 0000000000012f00 ffff8800b905bfd8
[1460160.129753]  0000000000012f00 ffff880133c2a9a0 ffff880139d137b0 ffff880139fd1a18
[1460160.129757]  0000000000000002 ffffffff811d7180 ffff8800b905bc80 ffff880133c9a398
[1460160.129762] Call Trace:
[1460160.129820]  [] ? generic_block_bmap+0x50/0x50
[1460160.129850]  [] ? io_schedule+0x99/0x120
[1460160.129854]  [] ? sleep_on_buffer+0xa/0x10
[1460160.129858]  [] ? __wait_on_bit+0x5c/0x90
[1460160.129861]  [] ? generic_block_bmap+0x50/0x50
[1460160.129865]  [] ? out_of_line_wait_on_bit+0x77/0x90
[1460160.129885]  [] ? autoremove_wake_function+0x30/0x30
[1460160.130054]  [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[1460160.130068]  [] ? pick_next_task_fair+0x3e3/0x820
[1460160.130077]  [] ? kjournald2+0xb2/0x240 [jbd2]
[1460160.130081]  [] ? prepare_to_wait_event+0xf0/0xf0
[1460160.130089]  [] ? commit_timeout+0x10/0x10 [jbd2]
[1460160.130109]  [] ? kthread+0xbd/0xe0
[1460160.130114]  [] ? kthread_create_on_node+0x180/0x180
[1460160.130119]  [] ? ret_from_fork+0x58/0x90
[1460160.130123]  [] ? kthread_create_on_node+0x180/0x180
Bonjour, de mon coté aussi.
J'ai lancé un ticket.

contremaitre
04/05/2016, 15h00
Bonjour,
J'ai ce type d'erreurs sur les deux derniers jours sur mon VPS cloud :
Inquiétant ?
Code:
[1460160.124244] INFO: task jbd2/vda1-8:102 blocked for more than 120 seconds.
[1460160.126152]       Not tainted 3.16.0-4-amd64 #1
[1460160.127427] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[1460160.129722] jbd2/vda1-8     D ffff880133c2adf8     0   102      2 0x00000000
[1460160.129746]  ffff880133c2a9a0 0000000000000046 0000000000012f00 ffff8800b905bfd8
[1460160.129753]  0000000000012f00 ffff880133c2a9a0 ffff880139d137b0 ffff880139fd1a18
[1460160.129757]  0000000000000002 ffffffff811d7180 ffff8800b905bc80 ffff880133c9a398
[1460160.129762] Call Trace:
[1460160.129820]  [] ? generic_block_bmap+0x50/0x50
[1460160.129850]  [] ? io_schedule+0x99/0x120
[1460160.129854]  [] ? sleep_on_buffer+0xa/0x10
[1460160.129858]  [] ? __wait_on_bit+0x5c/0x90
[1460160.129861]  [] ? generic_block_bmap+0x50/0x50
[1460160.129865]  [] ? out_of_line_wait_on_bit+0x77/0x90
[1460160.129885]  [] ? autoremove_wake_function+0x30/0x30
[1460160.130054]  [] ? jbd2_journal_commit_transaction+0x175e/0x1950 [jbd2]
[1460160.130068]  [] ? pick_next_task_fair+0x3e3/0x820
[1460160.130077]  [] ? kjournald2+0xb2/0x240 [jbd2]
[1460160.130081]  [] ? prepare_to_wait_event+0xf0/0xf0
[1460160.130089]  [] ? commit_timeout+0x10/0x10 [jbd2]
[1460160.130109]  [] ? kthread+0xbd/0xe0
[1460160.130114]  [] ? kthread_create_on_node+0x180/0x180
[1460160.130119]  [] ? ret_from_fork+0x58/0x90
[1460160.130123]  [] ? kthread_create_on_node+0x180/0x180