Serveur lent à la détente

[dlalleme]

Bonjour à tous,

Je suis confronté à un problème sur un serveur chez un client. Il est lent et à priori il n'est pas planté.

C'est un serveur en P4 1Go de Ram et deux disques de 120 Go montés en RAID1

Le symptome est une lenteur importante pour tout accès (messagerie, internet) sauf pour l'applicatif PHP maison comprenant un base mysql.

Je n'arrive pas à diagnostiquer le problème.

Soit c'est la liaision ADSL qui rame. (il faut que je fasse un test).
Soit ce sont les disques montés en RAID (j'ai tendance à éliminer cette hypothèse) et là; comment diagnostiquer un problème de RAID ?

Lorsque je fait une commande TOP :

2:29pm up 4:59, 1 user, load average: 0,00, 0,04, 0,02
166 processes: 164 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0,4% user, 0,4% system, 0,0% nice, 99,2% idle
Mem: 1031208K av, 858508K used, 172700K free, 0K shrd, 48636K buff
Swap: 264952K av, 10892K used, 254060K free 640696K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
6701 root 9 0 1632 1632 1328 R 0,0 0,1 0:00 sshd
6818 root 9 0 1072 1072 792 R 0,0 0,1 0:00 top

On peut pas dire qu'il travaille beaucoup


Des idées ???

Merci d'avance

Cordialement

Denis

[sibsib]

Hello,

Mauvaise configuration de la carte réseau externe ?

A priori, vu d'avion, ton applicatif php est utilisé en local, j'imagine, et le reste (mail, internet...) repose sur la partie externe ?).

Que donne une bonne grosse copie de fichier en LAN sur Samba ?

A+,
Pascal

[dlalleme]

Bonsoir Pascal,

Au vu de mes tests de cet après-midi, je pense que la bande passante du fournisseur d'accès a fait le "yoyo" entre presque rien et l'optimal.

Hello,

Mauvaise configuration de la carte réseau externe ?

A priori, vu d'avion, ton applicatif php est utilisé en local, j'imagine, et le reste (mail, internet...) repose sur la partie externe ?).

Exact

Que donne une bonne grosse copie de fichier en LAN sur Samba ?

Ca marche bien.

Donc je suppose que le problème vient de la bande passante du fournisseur. En fait, j'ai été troublé par ce phénomène de "yoyo". Mais je suis l'affaire .....

Cordialement

Denis

[androme]

Pour être sur que ca vient de ton FAI tu devrais de l'exterieur te connecter en VPN sur ton serveur et copier un fichier de ton ibay pour voir l'effet yoyo

[dlalleme]

Bonsoir,

J'ai pu éliminer (j'espère) une piste ....

Mon serveur 6.0.01 est connecté directement sur un modem que j'ai configuré en modem simple.

Donc c'est mon serveur qui fait le routeur.....

J'ai fait un test simple; j'ai reconfiguré mon modem en routeur puis j'ai connecté un portable directement et fait des tests (ping, transferts ftp, ...) et les connexions sont "nickels". Un ping sur un site type www.nerim.net me donne une moyenne de 62 ms et le taux de transfert d'un fichier est de 60ko/s (liaison ADSL 512). Donc je peux mettre hors de cause mon FAI (nerim).

Lorsque je reviens dans la configuration initiale avec le serveur, puis je fais un ping -> 6200 ms

Je reboote le serveur; et en ce moment, depuis environ 15 minutes, j'ai une moyenne de 69 ms. Je suis certain que cela va se dégradé, mais je ne sais pas quand .....


Pouvez-vous me donner une piste ou une idée vers où diriger mes investigations, car là je ne comprend vraiment rien ?

Cordialement

Denis

[Muzo]

As-tu testé avec un autre modem/ routeur ?
Peut-être que le modem en mode routeur est défectueux. (j'en sais rien, c'est une idée)

[dlalleme]

Bonsoir,

As-tu testé avec un autre modem/ routeur ?
Peut-être que le modem en mode routeur est défectueux. (j'en sais rien, c'est une idée)

Non, dans mon cas, il serait plutôt défectueux en modem simple, ce qui est fort improbable....

Cordialement

Denis

PS : Je vous envoie un p'tit bout du fichier /var/log/messages (C'était cette nuit) serait-ce lié ?
Je ne mets pas tout; il y 'en a des kilomètres

Code: Tout sélectionner

May 29 04:24:26 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:27 roseau root[11678]: Attempt to free unreferenced scalar during global destruction.
May 29 04:24:27 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:27 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:27 roseau root[11678]: Attempt to free unreferenced scalar during global destruction.
May 29 04:24:28 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:29 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:29 roseau root[11678]: Attempt to free unreferenced scalar during global destruction.
May 29 04:24:31 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:33 roseau root[11678]: Attempt to free non-existent shared string during global destruction.
May 29 04:24:33 roseau root[11678]: Attempt to free unreferenced scalar during global destruction.
May 29 04:24:41 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.111 DST=213.41.138.247 LEN=504 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=32911 DPT=1026 LEN=484
May 29 04:26:11 roseau kernel: Out of Memory: Killed process 11525 (httpd).
May 29 04:27:17 roseau kernel: Out of Memory: Killed process 11526 (httpd).
May 29 04:27:23 roseau kernel: Out of Memory: Killed process 11527 (httpd).
May 29 04:27:30 roseau kernel: Out of Memory: Killed process 11528 (httpd).
May 29 04:27:38 roseau kernel: Out of Memory: Killed process 11529 (httpd).
May 29 04:27:45 roseau kernel: Out of Memory: Killed process 11530 (httpd).
May 29 04:27:51 roseau kernel: Out of Memory: Killed process 11531 (httpd).
May 29 04:28:06 roseau kernel: Out of Memory: Killed process 11532 (httpd).
May 29 04:28:21 roseau kernel: Out of Memory: Killed process 11533 (httpd).
May 29 04:28:37 roseau kernel: Out of Memory: Killed process 11534 (httpd).
May 29 04:28:51 roseau kernel: Out of Memory: Killed process 10131 (clamd).
May 29 04:28:51 roseau kernel: Out of Memory: Killed process 10495 (clamd).
May 29 04:39:02 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.119 DST=213.41.138.247 LEN=309 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=57361 DPT=1026 LEN=289
May 29 04:39:02 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.119 DST=213.41.138.247 LEN=309 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=57361 DPT=1027 LEN=289
May 29 04:39:02 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.119 DST=213.41.138.247 LEN=309 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=57361 DPT=1027 LEN=289

[androme]

j'allais dire un probleme de mtu entre ton wan et ton modem mais à la vue des logs je crois que ton souci est ailleur

[sibsib]

Hello,

Out of memory, en général, çà ralentit la machine

Ceci dit, ce n'est pas forcément lié, mais comme c'est anormal, c'est à traiter (et en urgence à mon avis...)

As tu une idée de ton process 'memory monger' ?
Si tu peux arriver à prendre la main sur la machine à ce genre de moments (J'ai fait çà une fois, 2 minutes de temps de réaction par lettre enfoncée...) Alors, top, puis M (m majuscule) pour trier dans le sens décroissant des plus gros consommateurs de RAM.

Ceci dit : Moi c'était le scan de l'anti-virus. C'est souvent gourmand, ces choses...

A+,
Pascal

[dlalleme]

Bonjour,

Je suis le ping vers la même adresse depuis hier soir et j'attend les premiers employés qui vont se connecter pour surveiller l'évolution.

@sibsib :

Voilà, j'ai fait un top ce matin et on constate qu'effectivement clamav prend du processus et de la mémoire, mais ceci n'a pas d'impact sur la connexion. De même, je n'ai eu aucun mal à me connecter ce matin (à distance) sur le serveur. Cette opération est impossible lorsque le serveur est lent.

Je suis donc dans l'expectative de nouveaux évènements qui pourraient m'aider dans mes recherches....

Code: Tout sélectionner

  8:08am  up 14:10,  2 users,  load average: 1,00, 1,02, 1,00
147 processes: 144 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  0,0% user,  1,2% system, 94,2% nice,  4,6% idle
Mem:  1031208K av,  439688K used,  591520K free,       0K shrd,   55860K buff
Swap:  264952K av,   55288K used,  209664K free                  318284K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
5494 root      20  10 12456  12M   448 R N  95,0  1,2 454:34 clamscan
2786 qmailq     9   0 17368 7780   624 S     0,0  0,7   0:02 clamd
3039 qmailq     8   0 17368 7780   624 S     0,0  0,7   0:00 clamd
2103 ntp        9   0  1812 1812  1616 S     0,0  0,1   0:00 ntpd
2708 squid      9   0  5080 1524   364 S     0,0  0,1   0:01 squid
4258 dnscache   9   0  1544  900   284 S     0,0  0,0   0:00 dnscache
15996 root       9   0   736  684   472 R     0,0  0,0   0:00 top
15948 root       9   0   616  616   340 R     0,0  0,0   0:00 sshd
15879 root       9   0   612  612   340 S     0,0  0,0   0:00 sshd
1867 root       9   0   664  580   516 S     0,0  0,0   0:00 pppd


Merci à tous

Cordialement

Denis

[dlalleme]

Bonjour, c'est encore moi

Après une journée calme, hier, passée à surveiller les temps de réponse avec "ping" d'un côté et les connexions des utilisateurs d'un autre; je n'ai pas pu faire une conclusion et surtout détecter le problème. J'ai détecter trois périodes de ralentissement importantes de la bande passante.

Ce matin en me connectant à 6 heures; c'est la galère. Les temps sont totalement dégradés avec des "ping's" de 12000ms

Je vais essayer quelques "manip's"

Changer la carte réseau
Continuer à surveiller les connexions, j'ai installé SARG. Cela va peut être m'aider.

Dans le log message, j'ai ça ... environ toutes les cinq minutes. Cela peut-il être la cause ? Si oui, que puis-je faire ?

May 31 07:05:54 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.37.243.189 DST=213.41.138.247 LEN=543 TOS=0x00 PREC=0x00 TTL=56 ID=26131 PROTO=UDP SPT=45604 DPT=1025 LEN=523
May 31 07:05:54 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.37.243.189 DST=213.41.138.247 LEN=543 TOS=0x00 PREC=0x00 TTL=56 ID=26133 PROTO=UDP SPT=45604 DPT=1027 LEN=523
May 31 07:05:54 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.37.243.189 DST=213.41.138.247 LEN=543 TOS=0x00 PREC=0x00 TTL=56 ID=26132 PROTO=UDP SPT=45604 DPT=1026 LEN=523
May 31 07:05:54 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.37.243.189 DST=213.41.138.247 LEN=543 TOS=0x00 PREC=0x00 TTL=56 ID=26134 PROTO=UDP SPT=45604 DPT=1028 LEN=523
May 31 07:05:54 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.37.243.189 DST=213.41.138.247 LEN=543 TOS=0x00 PREC=0x00 TTL=56 ID=26135 PROTO=UDP SPT=45604 DPT=1029 LEN=523
May 31 07:10:14 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=213.188.198.134 DST=213.41.138.247 LEN=908 TOS=0x00 PREC=0x00 TTL=120 ID=341 PROTO=UDP SPT=6274 DPT=1026 LEN=888
May 31 07:10:41 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.105 DST=213.41.138.247 LEN=449 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP SPT=43244 DPT=1026 LEN=429
May 31 07:10:41 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=204.16.208.105 DST=213.41.138.247 LEN=449 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP SPT=43244 DPT=1027 LEN=429
May 31 07:15:22 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=213.41.174.82 DST=213.41.138.247 LEN=48 TOS=0x00 PREC=0x00 TTL=124 ID=5691 DF PROTO=TCP SPT=2599 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
May 31 07:15:25 roseau kernel: denylog:IN=ppp0 OUT= MAC= SRC=213.41.174.82 DST=213.41.138.247 LEN=48 TOS=0x00 PREC=0x00 TTL=124 ID=6285 DF PROTO=TCP SPT=2599 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0

Merci
Cordialement

Denis

[jdh]

Je ne comprends pas les pistes suivies !

- test de ping : cela sert à vérifier le temps de traitement de paquet, bref la pile tcp/ip.
- log parlant de pb de process : pas de piste suivie
- qté mémoire utilisée : aucune réflexion

Avec un P4 et 1 Go de mémoire dont il apparait qu'elle est utilisée à 885M ou 459M, il me parait clair qu'il s'agit d'un problème de process nécessitant trop de mémoire. Or cette mémoire est très importante.

Il me semble que tu as vraisemblablement joué sur des paramêtres qui enclenchent beaucoup de process. Par exemple, on peut préciser le nombre de serveur client pour apache, le nombre de client pour spamassassin (peut-être utilisé).

Il est important de situer l'utilisation mémoire avec "ps fvax" ou autre paramêtres. Je ne trouve pas normal d'utiliser du swap avec 1 Go de mémoire (d'ailleurs 256Mo de swap ne me parait pas adapté à 1 Go).

Un ping à 12000ms peut largement venir de cette "sur-utilisation" mémoire. C'est même pour moi la simple conséquence et non pas la cause.

Quand on voit un clamscan qui utilise 95% du process (parce qu'il a un nice à 20, ce qui est totalement stupide !!), il est clair que cela ne peut pas alller. Pour info le nice est un coefficient de priorité qui va de -20 à +20 : de moins prioritaire à plus prioritaire. La ligne de commande, comme la plupart des pgms, étant à 0 (priorité moyenne). Il n'est absolument pas normal que des process tournant en arrière plan comme clamscan, http, ... ait un nice supérieur à 0. Cette info a forcément pour conséquence que des process standard comme la pile tcp/ip ayant des nice standard soit "écrasé". Ne pas oublier de regarder toutes les colonnes de "top" : le nice, le % cpu et le temps qui compte les secondes utilisées par ce process depuis le lancement de la machine. Ici clamscan utilise 95% de cpu avec 485 sec et dispose d'un nice à 20, cela signifie qu'il y a une grosse utilisation processeur (et avec souvent de la mémoire).

[dlalleme]

Merci jdh pour ta réponse,

Le seul problème est que tu utilises un vocabulaire auquel je ne suis pas habitué, même si je suis informaticien de métier.

J'ai rebooté le serveur et le process clamscan n'apparait plus et j'ai toujours la même problème.

Je t'envoie le resultat de la commande ps -fvax dans ta boîte mail IXUS.

Merci

Cordialement

Denis

[jdh]

Les process les plus gourmands sont généralement

- Spamassassin,
- Clamav (clamd),
- Squid (directement lié à la taille du cache),
- Apache (beaucoup de serveurs clients).

Mais avec 512M de mémoire, on a ce qu'il faut pour faire un peu tout dans de bonnes conditions ... pour autant qu'on ait des réglages économes mais correct et non laxistes et trop larges. En général le swap n'est quasi jamais utilisé avec cette quantité de mémoire.

Une sur-utilisation de la mémoire écrase des process standard : par exemple la pile tcp/ip. Un ping trop long pour un matériel immédiatement accessible (dans le même réseau) est un symptome ou un indice.

[dlalleme]

Merci pour cette explication. J'ai maintenant bien compris quel était le problème. Maintenant, le but est de trouvé le ou les coupables.

Un vmstat pour la route

[root@roseau root]# vmstat 5 10
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 0 579124 29372 313212 0 0 48 33 334 291 1 1 98
0 0 0 0 578604 29380 313368 0 0 32 6 314 592 15 3 83
0 0 0 0 578604 29392 313496 0 0 26 68 147 169 0 0 99
0 0 0 0 578296 29392 313496 0 0 0 18 320 887 18 6 76
0 0 0 0 578296 29404 313624 0 0 26 42 134 154 0 0 100
0 0 0 0 578296 29428 313624 0 0 0 64 278 286 0 0 99
1 0 0 0 578296 29432 313752 0 0 26 4 132 155 0 0 100
0 0 0 0 578296 29448 313880 0 0 27 12 220 216 0 0 99
0 0 0 0 578296 29456 313880 0 0 0 27 130 152 0 0 100
0 0 0 0 578296 29472 313880 0 0 0 42 222 223 0 0 100

Cordialement

Denis