Forum Linux.général Serveur qui répond mal...

Posté par Twidi (site web personnel) le 18 février 2005 à 02:08.

Étiquettes : aucune

fév.

2005

Salut

J'ai un serveur qui part en vrille depuis un petit moment...
La charge s'est mise à monter, sans que je sache trop pourquoi, et impossible de voir car quand je fait par exemple un top ou un ps, il ne se passe rien et je ne récupère pas la main (idem avec la majorité des commandes)

J'ai tout stoppé, apache, exim, courier, y a que mysql qui ne semble pas vouloir se stopper.

J'ai tenter de rebooter, mais la machine ne reboote pas.

Le load etait de 48 il y a 10 mn il est maintenant de 85.... dans pas longtemps je ne pourrais plus rien faire :(

J'ai egalement joué avec init, bref, je ne sais pas trop quoi faire....

c'est une machine sous debien testing

Si quelqu'un a une idée m'évitant 4h aller retour demain pour appuyer sur le bouton "reset"..... d'avance merci

# ps aux

Posté par Twidi (site web personnel) le 18 février 2005 à 02:15. Évalué à 2.

quand je fais un px aux, j'ai quelques lignes, mais pas la totalité et de plus je ne récupère pas la main

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 1496 524 ? S Feb09 0:16 init [6]
root 2 0.0 0.0 0 0 ? SW Feb09 0:00 [keventd]
root 3 0.0 0.0 0 0 ? SWN Feb09 1:14 [ksoftirqd_CPU0]
root 4 0.0 0.0 0 0 ? SW Feb09 1:26 [kswapd]
root 5 0.0 0.0 0 0 ? SW Feb09 0:00 [bdflush]
root 6 0.0 0.0 0 0 ? SW Feb09 0:36 [kupdated]
root 7 0.0 0.0 0 0 ? SW Feb09 0:00 [i2oevtd]
root 9 0.1 0.0 0 0 ? SW Feb09 24:01 [kjournald]
root 44 0.0 0.0 0 0 ? SW Feb09 0:00 [khubd]
root 65 0.1 0.0 0 0 ? SW Feb09 20:31 [kjournald]
daemon 97 0.0 0.0 1604 392 ? S Feb09 0:00 /sbin/portmap
root 171 0.0 0.0 1540 592 ? S Feb09 0:09 /sbin/syslogd
root 174 0.0 0.0 2208 512 ? S Feb09 0:00 /sbin/klogd
root 179 0.0 0.0 1656 540 ? S Feb09 0:00 /sbin/rpc.statd
root 237 0.0 0.0 1520 456 ? S Feb09 0:00 /usr/sbin/inetd
# reboot -f

Posté par Twidi (site web personnel) le 18 février 2005 à 03:11. Évalué à 2.

J'ai pu rebooter grace au paramètre -f (force) de la commande reboot

après avoir fouillé en detail /proc, j'avais des dizaines de process en mode "D" (disk sleep), et bloquait donc ceux qui les appelaient

quant à savoir pourquoi, c'est une autre question...
- [^] # Re: reboot -f
  
  Posté par Mikaël Cordon le 18 février 2005 à 09:57. Évalué à 2.
  
  Bonjour,
  
  À première vue, je dirais que ton disque dur s'est arrêté (il faudrait savoir pourquoi) et ne redémarre pas malgré la nécessité : tes processus sont en attente (Sleep Waiting) jusqu'à ce qu'ils puissent obtenir le droit d'écrire sur le disque...
  
  Personnellement, je vérifierais d'abord que les connexions IDE et l'alimentation de ton disque n'aient pas bougés (machine éteinte, déconnecter puis souffler éventuellement dans les connecteurs, et reconnecter).
  
  Peut-être que ton disque tombe en panne ? Dans ce cas, pas grand chose à faire, sinon tester le disque sur une autre machine, par exemple ou effectuer un diagnostique (avec UBCD, par exemple).
  
  Et puis comme tu es en "testing", tu dois "updater" régulièrement. Il se peut qu'un paquet soit bogué. Dans ce cas, soit tu essais de chercher dans des rapports de bogues le paquet incriminé et tu le "downgrades" si possible, soit tu attends patiemment que la bogue soit corrigée... s'il s'agit bien d'une bogue.
  - [^] # Re: reboot -f
    
    Posté par Twidi (site web personnel) le 18 février 2005 à 12:38. Évalué à 1.
    
    Merci pour ces informations, notamment pour le disque dur... sur les 6 machines que nous avons achetés, nous avons renvoyés déjà 5 disques en garantie.... :-/
    
    Pour le côté testing je v voir ça
- [^] # Re: reboot -f
  
  Posté par daggett le 18 février 2005 à 12:15. Évalué à 3.
  
  j'avais des dizaines de process en mode "D"
  C'est intéressant; en effet, le calcul de la charge, qui se fait sur le nombre moyen de processus en attente d'être schedulé, prend en compte ces process en état "D". Ce qui veut dire que ta charge élevée n'est pas forcément causée par des processus qui "bourrinent", mais aussi par des processus en attente dans un appel système noyau bloqué. Par exemple s'ils tentent de faire un accès NFS vers un serveur qui ne répond pas, ou un CD-ROM ou disque dur défectueux qui fait pleins de "retry".
  - [^] # Re: reboot -f
    
    Posté par Twidi (site web personnel) le 18 février 2005 à 12:39. Évalué à 1.
    
    C'est vrai que malgré la charge de 100 sur la fin, je ne la sentais pas du tout, il reagissais au doigt et à l'oeil...
# Mysql

Posté par hommelix le 22 février 2005 à 09:55. Évalué à 2.

J'ai deja vu un truc semblable (bon on montait qu'a 40) avec un MySQL pas optimise (pas d'index sur les tables, etc...) avec un smtp qui cherchait ses alias dans le MySQL.

Apres avoir reorganise nos requetes vers les tables (LEFT JOIN je crois) , et avoir ajouter les index, tout est rentre dans l'ordre.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.