SMPFR

Ayo !

Est-ce que quelqu'un connaitrait une/des commandes/outils Linux pour connaitre la charge par core sur un V8. Aussi les threads tournant sur chaque core si possible.
Pcq là en fait l'entreprise dans laquelle je passe l'été en stage a un serveur Web dédié à un client qui est un mono-CPU Xeon quad core (le second socket sera ptet peuplé plus tard).
Le prob : bah je met ici les Load de la bête : 44.73 55.81 65.73
Ca fait peur hein !! Et encore c'était à 70 vers 11h ce matin.
Pourtant bizarrement la console via SSH est à peu près utilisable quoiqu'un peu lente, le site Web est naviguable aussi (un peu lent of course) etc.... alors que perso jusque là j'ai toujours considéré que déjà vers 10-20 la machine allait finir par dire "Fuck off" et freezer !

En fait ce qui suçe c'est une appli du site Web qui prend la forme d'un script CGI (qui manipule des photos hautes résolutions à la volée, spour ça c'est lourd). Mais j'ai beaucoup d'instance du CGI en permanence, qui squatte un peu la bécane. Et y'a toujours un certain nombre de process zombies...
Dja première question : les CGI c'est lancé comment : Apache2 qui fait un chtit fork puis exec CGI ??
Après je soupconne ces CGI de squatter un seul core, ca expliquerai que la bécane reste utilisable (car apache2 et sshd savent se servir des 4).

Donc bon j'aimerai avoir un peu plus d'info sur ce qu'il se passe précisément, histoire peut-être de voir après avec les dev de l'appli Web (pas nous) ce qu'il faut améliorer.

tu peux monitorer avec top ou htop (en ncurse)

Les CGI sont répartis sur chaque core normalement. Ils ne forkent/threadent pas, mais chaque exécution CGI doit être rattachée à un process apache.

Tu es sur que ton load n'est simplement pas bouffé par les zombies, et que tu n'as rien qui tourne pour de vrai ?

Pour la marrade : le Load est en ce moment à + de 100

Ouais bah depuis ce matin on fait déjà du top en fait. Le truc c'est que ça me dit pas la charge par core.
Mais bon en éditant le fichier /proc/stat il semble que la charge soit équivalente sur tous les cores (temps passés en user/systeme/idle du même ordre de grandeur).

Sinon pour savoir comment était organisé l'appel des CGI, j'ai fait "ps -ejH" qui m'affiche les process sous forme d'arbre. Conclu : le apache2 principal lance autant de petit process que de client (à priori), et chacun d'eux a son petit "viewer.cgi" (l'appli en question).

Mais on vient de se rendre compte d'un truc grace à top quand même : on passe entre 25 et 85 % du tps CPU en "wait for I/O" et aussi un tps "normal" en idle. Donc c'est vraiment juste que un process squatte le core empechant les autres de bosser. Confirmer par "top" puis "i" pour enlever les process en Idle -> on ne voit presque plus que les CGI.
Je pense maintenant que la source du probs c'est les accès disques, pour les images qui sont lourdes.

ZEP> pas trop cherché pour les zombies encore (j'ai d'autres trucs sur les bras), par contre non je n'ai rien d'autre d'important qui tourne (un sshd, un snmpd et un syslogd c'est tout).

Comment on peut faire sous Linux pour associer un process à un ou plusieurs cores/CPU précis ?? L'idée pour limiter les emmerdes pour les autres services, ça serait de mettre apache2 et ses potes CGI sur 3 cores, et de garder le dernier core pour les autres. Faisable ?

Non, pas faisable, le scheduler est prévu pour répartir sur tous les cores par défaut. Pour faire de l'aggrégation, il te faudrait une autre architecture, comme les alpha.

Ton apache2 ne lance pas autant de process que de clients, il en lance un certain nombre (comme défini dans la conf), qui peuvent accepter un autre nombre de clients. En l'occurence là, tu dois avoir moins de clients que de forks, ce qui explique ton amalgame.

Il faudrait que tu puisses détecter le goulot d'étranglement dans le cgi, histoire de corriger ça.

Là encore, ton scheduler est prévu pour ne pas bloquer les autres process (sinon tu ne pourrais ni te connecter par ssh ni lancer top). Ton seul blocage vient des I/O qui coulent. Tu as quoi comme carte contrôleur disque ?

du vieux highpoint sur carte controleur qtek sur pci sur via kt133a [:dslam]

Euh c'est un PowerEdge 2950 avec 6 disques SATA 1To chacun, et les techs m'ont dit que le tout était en RAID hardware.
Donc je pense que le contrôleur c'est du PERC 5/i (256 Mo de cache à priori).
Bon tfaçon nous on ne fait qu'héberger, donc on va les laisser se débrouiller un peu avec leur bestiole les gars. Ils ont planifiés un reboot cette nuit on verra demain, ca changera rien.
L'appli Web ne vient pas de chez nous, donc on va pas y mettre le nez pour savoir d'où ça vient hein. ^^

donc en fait, c'est pas votre serveur, et c'est pas votre code.

vous faites quoi sur ce machin alors ?

Ils le branchent et ils jettent des croquettes

Ils le branchent et ils jettent des croquettes

des putaing de croquettes amperées ouaip

Bah nous on héberge et on gère le serveur Web (OS maintenance backup toussa... ).

Bon bah aujourd'hui on a pas dépassé 30.
Le nombre de process lancés par apache2 ("StartServers") a été augmenté, et le Timeout pour la fermeture des connex inactives a été réduit.

S'il y a un nombre conséquent de clients qui accèdent au serveur en simultané, désactives le keepalive dans la conf d'apache, ca évite de maintenir des sessions (et donc des process) pour les sessions en idle.
Ce n'est pas une solution miracle, mais cela a déjà sauvé quelques serveurs de la crise cardiaque.

moi je ne dirai qu'une chose : le CGI c'est maaaaaal