2 votes

Un VPS basé sur KVM tombe en panne tous les 3 à 7 jours. Est-ce un problème du côté du VPS ou du nœud ?

Je me demande s'il est possible qu'un VPS soit à l'origine des crashs qui se produisent tous les 3-7 jours dans la nuit de 03:00 à 04:00 heure (bug du noyau, ou autre chose), ou est-ce un nœud sur lequel le serveur virtuel est hébergé (un problème avec le backend).

Détails : VPS basé sur KVM avec CentOS 7, xfs hébergé chez le fournisseur de VPS, qui dispose d'une infrastructure de back-end et de stockage.

Habituellement, cela se passe de la façon suivante, en une seule fois la course kthreadd le processus se transforme en D -status (c'est-à-dire un sommeil ininterrompu), et ensuite nous recevons des messages comme : blocked for more than 120 seconds. et LA élevé :

May 21 03:08:01 vps root: root 2 0.0 0.0 0 0 ? S May18 0:00 [kthreadd] May 21 03:10:01 vps root: root 2 0.0 0.0 0 0 ? S May18 0:00 [kthreadd] May 21 03:12:01 vps root: root 2 0.0 0.0 0 0 ? S May18 0:00 [kthreadd] May 21 03:14:01 vps root: root 2 0.0 0.0 0 0 ? D May18 0:00 [kthreadd] May 21 03:15:16 vps kernel: INFO: task kthreadd:2 blocked for more than 120 seconds. May 21 03:15:16 vps kernel: kthreadd D ffffffffffffffff 0 2 0 0x00000000 May 21 03:15:16 vps kernel: [<ffffffff810a65f2>] kthreadd+0x2b2/0x2f0 May 21 03:16:01 vps root: root 2 0.0 0.0 0 0 ? D May18 0:00 [kthreadd] May 21 03:18:01 vps root: root 2 0.0 0.0 0 0 ? D May18 0:00 [kthreadd] May 21 03:20:02 vps root: root 2 0.0 0.0 0 0 ? D May18 0:00 [kthreadd]

ici nous avons une trace d'appel :

May 18 04:14:37 vps kernel: INFO: task kthreadd:2 blocked for more than 120 seconds. May 18 04:14:37 vps kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 18 04:14:37 vps kernel: kthreadd D ffffffffffffffff 0 2 0 0x00000000 May 18 04:14:37 vps kernel: ffff88023413b4e0 0000000000000046 ffff880234120b80 ffff88023413bfd8 May 18 04:14:37 vps kernel: ffff88023413bfd8 ffff88023413bfd8 ffff880234120b80 ffff88023413b628 May 18 04:14:37 vps kernel: ffff88023413b630 7fffffffffffffff ffff880234120b80 ffffffffffffffff May 18 04:14:37 vps kernel: Call Trace: May 18 04:14:37 vps kernel: [<ffffffff8163ae49>] schedule+0x29/0x70 May 18 04:14:37 vps kernel: [<ffffffff81638b39>] schedule_timeout+0x209/0x2d0 May 18 04:14:37 vps kernel: [<ffffffff8104fac3>] ? x2apic_send_IPI_mask+0x13/0x20 May 18 04:14:37 vps kernel: [<ffffffff810b8a86>] ? try_to_wake_up+0x1b6/0x300 May 18 04:14:37 vps kernel: [<ffffffff8163b216>] wait_for_completion+0x116/0x170 May 18 04:14:37 vps kernel: [<ffffffff810b8c30>] ? wake_up_state+0x20/0x20 May 18 04:14:37 vps kernel: [<ffffffff8109e7ac>] flush_work+0xfc/0x1c0 May 18 04:14:37 vps kernel: [<ffffffff8109a7e0>] ? move_linked_works+0x90/0x90 May 18 04:14:37 vps kernel: [<ffffffffa021143a>] xlog_cil_force_lsn+0x8a/0x210 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa020fa7e>] _xfs_log_force_lsn+0x6e/0x2f0 [xfs] May 18 04:14:37 vps kernel: [<ffffffff81632005>] ? __slab_free+0x10e/0x277 May 18 04:14:37 vps kernel: [<ffffffffa020fd2e>] xfs_log_force_lsn+0x2e/0x90 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa0201fc9>] ? xfs_iunpin_wait+0x19/0x20 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa01fe4b7>] __xfs_iunpin_wait+0xa7/0x150 [xfs] May 18 04:14:37 vps kernel: [<ffffffff810a6b60>] ? wake_atomic_t_function+0x40/0x40 May 18 04:14:37 vps kernel: [<ffffffffa0201fc9>] xfs_iunpin_wait+0x19/0x20 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa01f684c>] xfs_reclaim_inode+0x8c/0x350 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa01f6d77>] xfs_reclaim_inodes_ag+0x267/0x390 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa01f7923>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs] May 18 04:14:37 vps kernel: [<ffffffffa0206895>] xfs_fs_free_cached_objects+0x15/0x20 [xfs] May 18 04:14:37 vps kernel: [<ffffffff811e0cd8>] prune_super+0xe8/0x170 May 18 04:14:37 vps kernel: [<ffffffff8117c5c5>] shrink_slab+0x165/0x300 May 18 04:14:37 vps kernel: [<ffffffff811d5f01>] ? vmpressure+0x21/0x90 May 18 04:14:37 vps kernel: [<ffffffff8117f742>] do_try_to_free_pages+0x3c2/0x4e0 May 18 04:14:37 vps kernel: [<ffffffff8117f95c>] try_to_free_pages+0xfc/0x180 May 18 04:14:37 vps kernel: [<ffffffff8117365d>] __alloc_pages_nodemask+0x7fd/0xb90 May 18 04:14:37 vps kernel: [<ffffffff81078d73>] copy_process.part.25+0x163/0x1610 May 18 04:14:37 vps kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140 May 18 04:14:37 vps kernel: [<ffffffff8107a401>] do_fork+0xe1/0x320 May 18 04:14:37 vps kernel: [<ffffffff8107a666>] kernel_thread+0x26/0x30 May 18 04:14:37 vps kernel: [<ffffffff810a65f2>] kthreadd+0x2b2/0x2f0 May 18 04:14:37 vps kernel: [<ffffffff810a6340>] ? kthread_create_on_cpu+0x60/0x60 May 18 04:14:37 vps kernel: [<ffffffff81645e18>] ret_from_fork+0x58/0x90 May 18 04:14:37 vps kernel: [<ffffffff810a6340>] ? kthread_create_on_cpu+0x60/0x60

Un tour avec des pages sales n'a pas aidé.

Seul le hard reset permet de remettre le serveur en état de fonctionnement.

Pourriez-vous nous aider à comprendre s'il s'agit d'un problème causé du côté du VPS ou du nœud ?

Regards, Alex.

0 votes

Je soupçonne l'hôte d'avoir un problème avec son stockage. Vous devriez les contacter.

0 votes

Je soupçonnais la même chose, et je les ai contactés plusieurs fois. Ils m'ont dit qu'ils n'avaient pas ce problème avec d'autres serveurs virtuels de plus de 3 000 personnes et que nous devions vérifier le serveur de notre côté.

5voto

ewwhite Points 193555

Il s'agit probablement d'un processus de sauvegarde ou de quelque chose ayant un impact sur le stockage qui se passe à l'endroit où se trouve l'ordinateur. hôte niveau. Ceci est hors de votre contrôle et vous devez pousser le fournisseur de VPS à trouver une solution.

S'ils n'y parviennent pas, envisagez d'aller ailleurs.

0 votes

Je suis presque sûr que les choses sont exactement comme vous les décrivez (merci pour cela). J'aimerais en trouver les preuves, afin que le propriétaire du serveur (ce n'est pas moi en fait) puisse les croire. Y a-t-il une chance de déboguer les incidents et de recueillir des preuves à 100% que le cas est causé au niveau de l'hôte. De sorte que même l'hébergeur ne puisse pas les nier.

-2voto

crashedagain Points 1

C'est parce que vous utilisez Redhat/CentOS 7.2 et xfs. Le noyau n'est pas stable comme il l'était avec 7.1. La solution actuelle est de migrer vers ext4 si vous voulez utiliser CentOS 7.2.

0 votes

Je peux difficilement être d'accord avec cela. Qu'est-ce qui pourrait être spécial avec ce serveur spécifique si je n'ai pas de problèmes avec CentOS 7.2 sur d'autres serveurs ? J'ai au moins 2 autres serveurs avec XFS et je n'ai jamais eu de problème avec eux. Et chacun de ces 2 serveurs est hébergé par des sociétés VPS différentes. Kernel 3.10.0-327.36.3.el7.x86_64 y /dev/vda1 on / type xfs (rw,relatime,attr2,inode64,noquota) .

0 votes

De plus, nous avons plusieurs serveurs chez le fournisseur de VPS (exactement le fournisseur de VPS avec lequel nous avons un problème), et ces autres serveurs avec CentOS 7.2 ne produisent pas les mêmes incidents. Comment l'expliquer ?

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X