4 votes

Tuer -9 ne fonctionne pas

J'ai un serveur avec 3 instances oracle dessus, et le système de fichiers est nfs avec netapp. Après l'arrêt des bases de données, un processus pour chaque base de données ne se termine pas pendant longtemps. Chaque kill -i ne fonctionne pas. J'ai essayé de truss, pfile it, la commande a généré une erreur.

Et iostat montre qu'il y a beaucoup d'IO vers le serveur netapp. Donc quelqu'un a dit que le processus était occupé à écrire des données sur le serveur netapp distant, et avant que l'écriture ne soit terminée, il ne se terminera pas. Donc ce qu'il fallait faire était juste d'attendre que tout l'IO soit terminé.

Après avoir attendu plus longtemps (environ 1,5 heures), les processus se terminent.

Donc ma question est: comment un processus peut-il ignorer le signal de kill? Autant que je sache, si nous faisons un kill -9, il s'arrêtera immédiatement. Avez-vous déjà rencontré une telle situation où kill -i ne tue pas immédiatement le processus?

TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0
  oracle  1469 25053   0 22:36:53 pts/1       0:00 grep dbw0
  oracle 26795     1   0 21:55:23 ?           0:00 ora\_dbw0\_TEST7
  oracle  1051     1   0   Apr 08 ?        3958:51 ora\_dbw0\_TEST2
  oracle   471     1   0   Apr 08 ?        6391:43 ora\_dbw0\_TEST1
TEST7-stdby-phxdbnfs11$> kill -9 1051 
TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0
  oracle  1493 25053   0 22:37:07 pts/1       0:00 grep dbw0
  oracle 26795     1   0 21:55:23 ?           0:00 ora\_dbw0\_TEST7
  oracle  1051     1   0   Apr 08 ?        3958:51 ora\_dbw0\_TEST2
  oracle   471     1   0   Apr 08 ?        6391:43 ora\_dbw0\_TEST1
TEST7-stdby-phxdbnfs11$> kill -9 471
TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0
  oracle 26795     1   0 21:55:23 ?           0:00 ora\_dbw0\_TEST7
  oracle  1051     1   0   Apr 08 ?        3958:51 ora\_dbw0\_TEST2
  oracle   471     1   0   Apr 08 ?        6391:43 ora\_dbw0\_TEST1
  oracle  1495 25053   0 22:37:22 pts/1       0:00 grep dbw0
TEST7-stdby-phxdbnfs11$> ps -ef|grep smon
  oracle  1524 25053   0 22:38:02 pts/1       0:00 grep smon
TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0
  oracle  1526 25053   0 22:38:06 pts/1       0:00 grep dbw0
  oracle 26795     1   0 21:55:23 ?           0:00 ora\_dbw0\_TEST7
  oracle  1051     1   0   Apr 08 ?        3958:51 ora\_dbw0\_TEST2
  oracle   471     1   0   Apr 08 ?        6391:43 ora\_dbw0\_TEST1
TEST7-stdby-phxdbnfs11$> kill -9 1051 471 26795
TEST7-stdby-phxdbnfs11$>  ps -ef|grep dbw0
  oracle  1528 25053   0 22:38:19 pts/1       0:00 grep dbw0
  oracle 26795     1   0 21:55:23 ?           0:00 ora\_dbw0\_TEST7
  oracle  1051     1   0   Apr 08 ?        3958:51 ora\_dbw0\_TEST2
  oracle   471     1   0   Apr 08 ?        6391:43 ora\_dbw0\_TEST1

TEST7-stdby-phxdbnfs11$> truss -p 26795
truss: erreur système inattendue: 26795

TEST7-stdby-phxdbnfs11$> pfiles 26795
pfiles: erreur système inattendue: 26795

0 votes

Il serait utile si vous décriviez le système d'exploitation sur lequel le client NFS fonctionne ; c'est en réalité plus pertinent que de savoir que le serveur est un appareil NetApp.

0 votes

Bien qu'il soit évidemment possible, vous obtiendrez de meilleures performances et vous n'aurez probablement pas le problème que vous demandez si vous n'exécutez pas votre base de données RDBMS sur NFS. Pouvez-vous mettre les données sur un disque directement sur le serveur DB? Vous pouvez toujours utiliser le NetApp via iSCSI ou Fibre Channel si vous avez ce matériel.

3voto

Pasi Savolainen Points 156

Le processus recevra le signal KILL (tous les signaux se comportent de la même manière) uniquement et seulement lorsqu'il est en "userspace". S'il est en kernelspace (par exemple en attendant qu'un partage NFS fournisse des données lues à partir d'un fichier), il ne recevra pas le signal (le signal attendra que le processus revienne en userspace, il ne sera pas perdu).

La plupart des NFSD ont des options à ce sujet, il peut retourner d'une lecture avec un statut d'échec en cas de dépassement du délai. Cela entraînera une perte de données (comme l'autre option...) car tous les programmes ne vérifient pas tous les résultats de read().

Les processus ne peuvent pas ignorer/annuler le signal KILL, c'est juste une notification et cela donne une chance de sauvegarder les données nécessaires.

0voto

Charles Duffy Points 926

La question n'a pas spécifié la plate-forme client, donc je suppose Linux.


Voir la FAQ pertinente sur le site Linux NFS.

Les processus ne peuvent pas ignorer SIGKILL, mais les appels système peuvent bloquer le traitement des signaux.

Il existe deux drapeaux de montage pour les clients Linux qui peuvent être utilisés pour contourner ce problème : soft et intr.

soft fait que NFS finit par abandonner lorsqu'une requête échoue. Si votre application n'est pas bien écrite pour être robuste face aux échecs des appels système (et de nombreuses applications ne le sont pas), cela peut causer une corruption des données.

intr tente de rendre les appels système NFS interruptibles de manière plus sûre que soft. Cependant, il est encore possible de mettre un point de montage intr,hard dans un état impossible à tuer.

0 votes

Le serveur que nous utilisons est Solaris 10

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