Posté(e) le 6 mai 200916 a Bonjour à tous, J'ai un petit soucis, peut-être pourrez vous m'aider. J'ai un gros processus qui est une machine à gaz, un script en perl qui s'execute en plusieurs heures, et via la commande "top", je viens de m'appercevoir avec horreur de ceci : L'usage de mon processeur oscille entre 0.3% et 1.2%, et pourtant il devrait être utilisé à fond, c'est du traitement brut (conversion / stockage). Est-ce que, d'après vous, c'est ma commande "top" qui me renvoit une information eronnée, ou est-ce que mon processeur est réellement aussi peu sollicité ? De plus, son statut est à "sleep", mais mes fichiers de logs m'indiquent qu'il travaille toujours. =/ Merci d'avance, The Lootrophile
Posté(e) le 6 mai 200916 a Il est peut etre bloqué à cause des accès disque trop lent ? personnellement je n'utilise pas top, mais atop (bon y'a un demon qui s'intalle en tache de fond, mais il sert a rien faut l'enlever) avec lui tu as plus d'info sur les dd, le reseau, les processus, etc...
Posté(e) le 6 mai 200916 a Il est peut etre bloqué à cause des accès disque trop lent ?personnellement je n'utilise pas top, mais atop (bon y'a un demon qui s'intalle en tache de fond, mais il sert a rien faut l'enlever) avec lui tu as plus d'info sur les dd, le reseau, les processus, etc... Salut Si c'etait le disque dur, il y a des chances que la machine fasse du load. la ce n'est pas le cas. Ramene nous le résulat d'un vmstat 2 Tu peux aussi faire un strace -p pid_du_process a+
Posté(e) le 6 mai 200916 a Auteur Je n'ai pas d'accès SSH vers mes serveurs hors du boulot, je vous copierai les résultats demain. Merci pour votre aide
Posté(e) le 6 mai 200916 a Et si c'était cette bouse de perl ? ok, à part, c'est normal que tu aies 1Go de swap utilisé ? Est-ce que ton processus est multithreadé ? (genre coincé dans un gros deadlock à cause d'une ressource partagée ?) Il ne ferait pas des attentes bloquante sur un flux de données, par hasard ? (style un fichier qui est arrivé au bout, etc)
Posté(e) le 6 mai 200916 a Auteur Il y a peu de risque de deadlock, mon processus s'exécute en une seule instance à la fois (c'est controlé) et aucun autre processus n'accède à ces fichiers. En plus mon script continue d'itérer, mais visiblement beaucoup trop lentement.=/
Posté(e) le 6 mai 200916 a Salut Pour le Go de swap, c'est typique d'une machine qui il y a peu a utilisé beaucoup de RAM. Le swap ne se vide pas aussitot, mais quand ce sera nécessaire. Pour voir si ça bloque sur un fichier : strace -p a+
Posté(e) le 7 mai 200916 a il est sensé faire quoi au juste ce scripte ? et sur quel type de données ? tu peux le benchmarker sur un jeu réduit afin de déterminer les gouleaux d'étranglement ?
Posté(e) le 7 mai 200916 a Auteur Il prend des fichiers texte qui contiennent des statistiques sur des milliers de routeurs, et il les converti en bases de données RRD (des fichiers binaires) chaque fichier contient 16000 lignes (4mn de stats) et au gré de ses humeurs il met entre 3 et 15 minutes à les traiter, ça génère un backlog irréversible. J'ai tenté le benchmark hier, il n'y avait rien de bien notable, le script passe - comme prévu - tout son temps à itérer, aucune pause dans ses traitements, c'est pour ça que je ne m'explique pas le taux d'usage du CPU. Maintenant peut être qu'il fait des micro pauses en permanence, mais je ne vois pas bien sur quoi.. Feignant !
Posté(e) le 7 mai 200916 a Auteur Voici le vmstat J'ai lancé mon script sur une machine beaucoup plus puissante, son occupation CPU oscille entre 0.5 et 22% (plus souvent sous les 10% quand même) Voici le strace dessus (les parties en noir correspondent aux adresses IP de nos clients, je les ai supprimées) Il défile à fond sans avoir l'air de bloquer L'autre machine a beau être beaucoup plus puissante, elle ne va traite pas les fichiers plus vite..
Posté(e) le 7 mai 200916 a Ca veut tout simplement dire que ton programme ne fournit pas assez de données pour saturer ton proc. Il te reste à savoir où est le bottleneck. Essaie de mettre des flags de date (je connais pas la commande en shell) et fait des différences pour voir où le temps est occupé.
Posté(e) le 7 mai 200916 a Auteur Mon problème a l'air de venir d'une dépendance (RRDtool) qui met à jour mes bases de données.. Sans mon script se déroule en 3 secondes (en commentant une ligne sur les 3000 de mon script =]), avec en 8 minutes.. C'est un peu ce qui fait tout, mais mon proco reste bloqué sous les 5%. Les clients risquent de gueuler encore un peu. =/
Posté(e) le 7 mai 200916 a Salut Si ça vient d'un problème du programme tente de le lancer comme ça : perl -W monpg.pl a+
Posté(e) le 7 mai 200916 a Tu calcule des moyennes ou bien des min/max avec RDDTool ? Parce que dans ce cas, c'est un traitement qui est minimum en O(n) le nombre de lignes, et qui peut prendre un certain temps. En plus, ça expliquerait pourquoi tu ne vois pas ton scripte s'exécuter à 100%, car le plus gros du precessing est fait par rddtool.
Posté(e) le 8 mai 200916 a Auteur Cette partie du processus ne calcul rien (tout est fait en amont sur d'autres serveurs), lui ne fait "que" prendre les données dans le fichier texte, (des relevés tous les X secondes à propos de UDP, TCP, etc.) les stocker dans des variables, calculer dans quelle base de données il doit ranger les statistique en cours de traitement (on en a 30 Go), et faire un RRDs::update avec le timestamp, et tout ça x16 000 par fichier. Je ne suis pas expert en Unix, mais ce qui est clair c'est que c'est la partie où j'appelle RRDtool qui prend 99% du temps de processus, ça pourrait faire que je ne vois pas du tout l'utilisation CPU que ça génère avec les commandes du type "top" ? Je vais multi-threader mon script aujourd'hui, en donnant à chaque thread une partie des BDD pour éviter les deadlocks, pour voir comment il réagit. Merci encore pour votre intérêt
Posté(e) le 8 mai 200916 a Auteur Oui. Sinon, on a trouvé le vainqueur, c'était.. Il est peut etre bloqué à cause des accès disque trop lent ?personnellement je n'utilise pas top, mais atop (bon y'a un demon qui s'intalle en tache de fond, mais il sert a rien faut l'enlever) avec lui tu as plus d'info sur les dd, le reseau, les processus, etc... Le disque dur est complètement surchargé (nos admins système ont jeté un oeil sur le problème), peut-être parce qu'on fait des milliers de micro modifications à des emplacements différents sur le DD ? (il y a 30GO de statistiques, mais je ne suis pas certain qu'elles se trouvent dans une zone contigüe) peut-être y a-t'il un remède miracle, dans ces situations ? (à part s'en remettre au tout puissant ^^) Merci encore, The Lootrophile
Posté(e) le 8 mai 200916 a le dd, effectivement... SalutSi c'etait le disque dur, il y a des chances que la machine fasse du load. la ce n'est pas le cas. je quote le message de zoto, ca m'etonne aussi qu'il n'y ai pas de load alors que le dd soit a fond il devrait y avoir un max de WAIT sur les process, et donc du load
Posté(e) le 8 mai 200916 a Salut Le load average est un indicateur de la charge globale de la machine. Quand tu tape la commande : w 18:27:29 up 2:12, 2 users, load average: 0,24, 0,31, 0,28 Tu a trois chiffres : La charge globale a 5 ,10, 15 minutes. C'est en gros le nombre de processus en attente sur 5, 10, 15 mintes. C'est un indicateur qui n'est pas pour autant des plus fiables. Cela te dis juste que la machine a plus ou moins de mal à traiter les donnée. J'ai deja vu une machine qui load pas mal (600) et elle restait stable, et on l'on pouvait encore faire ce que l'on veut en ligne de commande. un bonne article la dessus : http://www.teamquest.com/resources/gunther/display/5/#cock a+
Posté(e) le 9 mai 200916 a Un truc à voir c'est que dans ton top le champ wa est à 72%, ce qui indique que ton cpu passe 72% de son temps à attendre des i/os.
Posté(e) le 14 mai 200916 a Bonne réponse de Paulez Ton système passe 72 % du temps à attendre des IO (iowait), 21% à ne rien faire (idle), 3% pour les interruptions soft (probablement lié aux io) et 3% pour le kernel.
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.