3 votes

Le noyau Linux s'écrase mutex_lock_slowpath "bloqué pendant plus de 120 secondes". Que faire ?

J'ai un Debian Lenny prêt à l'emploi avec un noyau non personnalisé 2.6.26-2-amd64. Un tout nouveau serveur qui n'utilise que 5% de son potentiel en termes de CPU et de disque. Cela signifie qu'il ne plante probablement pas en raison d'une surcharge.

Presque tous les traces ont __mutex_lock_slowpath en tant que niveau supérieur.

Seuls certains ont une trace différente :

: [284847.737386] INFO: la tâche apache2:12472 est bloquée depuis plus de 120 secondes.
: [284847.777551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" désactive ce message.
: [284847.824881] apache2       D ffff8101bc6b7ab0     0 12472  14358
: [284847.824886]  ffff8101b9cc1c50 0000000000000086 ffffffffa0131e0a 0000000000000002
: [284847.824889]  ffff8102e7454300 ffff810324c6cad0 ffff8102e7454588 0000000000000000
: [284847.824893]  0000000000000001 0000000000000296 0000000000000003 ffff8101b9cc1c58
: [284847.824896] Trace d'appel :
: [284847.828403]  [] :ext3:__ext3_journal_dirty_metadata+0x1e/0x46
: [284847.828412]  [] __mutex_lock_slowpath+0x64/0x9b
: [284847.828418]  [] mutex_lock+0xa/0xb
: [284847.828421]  [] do_lookup+0x82/0x1c1
: [284847.828427]  [] __link_path_walk+0x87a/0xd19
: [284847.828428]  [] find_lock_page+0x1f/0x8a
: [284847.828428]  [] filemap_fault+0x1c2/0x33c
: [284847.828428]  [] path_walk+0x46/0x8b
: [284847.828428]  [] do_path_lookup+0x158/0x1cf
: [284847.828428]  [] getname+0x140/0x1a7
: [284847.828428]  [] __user_walk_fd+0x37/0x4c
: [284847.828428]  [] vfs_lstat_fd+0x18/0x47
: [284847.828428]  [] sys_newlstat+0x19/0x31
: [284847.828428]  [] system_call_after_swapgs+0x8a/0x8f

Après avoir recherché "mutex_lock_slowpath", je ne trouve que des discussions sur la liste de diffusion du noyau selon lesquelles ce problème a été introduit dans un certain commit. Sans référence à la version. Des discussions aussi récentes que le 25 janvier 2011. Le noyau que j'utilise est celui de Debian Lenny, datant d'il y a un an.

Que dois-je faire ? Ce bogue est-il même corrigé dans le noyau ? Si c'est un bogue si évident, pourquoi se produit-il si rarement ?

  • Devrais-je télécharger le dernier noyau sur kernel.org et le mettre à jour ?
  • Devrais-je utiliser les backports de Debian pour installer le nouveau noyau "Approuvé" ?

Est-ce que j'oublie quelque chose ? Que faire ?

3voto

Mackenzie Points 678

Utilisez-vous par hasard un disque SSD?

J'ai vu ces erreurs sur mon système Ubuntu 10.10. Ce qui se passait, c'est qu'il y avait une erreur SATA qui perturbait complètement le sous-système de disque. Les tentatives ultérieures d'E/S disque entraînaient des délais d'attente de 120 secondes similaires aux vôtres (la trace de la pile variait).

J'ai documenté le problème initial ici : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/707583

La (assez banale) question que j'ai posée sur les délais est ici : Mystery stack traces in /var/log/messages

Je utilisais une carte mère basée sur le P55 et des disques SSD Crucial. Cependant, j'ai vu cela rapporté avec d'autres chipsets, d'autres marques de disques SSD et d'autres noyaux Linux.

Autant que je sache, la seule chose en commun était l'utilisation de disques SSD.

0voto

Gabriel Points 173

J'ai rencontré ce problème sur un ou deux de mes serveurs il y a quelque temps (Ubuntu 8.0.4 LTS). Je vous recommande ce qui suit :

  • Vérifiez que vous n'avez pas de problème matériel (dans mon cas, il y avait des problèmes de disques et potentiellement de mémoire)
  • Vérifiez la charge (CPU, IO, mémoire, swap)
  • Envisagez de mettre à jour votre kernel Linux (2.6.26 est assez ancien)

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