J'ai une application de serveur exécutant sous CENT OS. Le serveur répond de nombreuses demandes par seconde, mais elle se bloque à plusieurs reprises après chaque heure environ et crée un fichier de vidage de crash. La situation est vraiment mauvaise et j'ai besoin de découvrir la cause du crash dès que possible.
Je soupçonne que le problème est un problème de concurrence, mais je ne suis pas sûr. J'ai accès au code source et aux fichiers de décharge de crash, mais je ne sais pas comment utiliser les décharges de crash sur le point d'épingle du problème.
Toutes les suggestions sont très appréciées.
4 Réponses :
Votre application crée-t-elle un fichier de base? Si oui, j'utiliserais GDB pour déboguer ce problème.
Si le problème prend environ une heure de se manifester, il pourrait s'agir d'un problème de mémoire - peut-être épuisé, ou peut-être piétiné (en utilisant une mémoire déjà libérée, par exemple).
Vous dites que vous avez le crash Dump Files - c'est-à-dire un vidage de noyau? p>
supposant que vous avez un vidage de base, la première étape devrait probablement être d'imprimer la pile Backtrace: P>
gdb program core > where
Merci pour votre réponse détaillée. Le serveur a été compilé avec les informations de débogage et crée un dépotoir de base lorsqu'il se bloque. Le serveur initialise de nombreux threads. Chaque fois que les threads sont inférieurs à 200, le serveur reste de travailler pendant plus d'une heure, mais lorsque l'augmentation du nombre de demandes augmente le nombre de threads dans la piscine à environ 300 le serveur s'écrase beaucoup plus tôt. Puissiez-vous me dire comment utiliser une version de débogage de MALLOC peut aider? Merci
En ce qui concerne «débogage MALLOC»: si le problème est une abus de mémoire, le débogage du MALLOC vous aidera à enregistrer davantage d'informations sur l'espace alloué, généralement en allouant plus d'espace, alors lorsque ses fonctions sont invoquées, elles peuvent repérer diverses sortes d'abus de mémoire plus tôt. Dans le processus - limiter les dommages causés et permettant généralement de repérer le problème. Par exemple, si vous libérez une mémoire de mémoire déjà libérée, cela peut signaler cela - plutôt que de simplement prendre votre valeur libre à la valeur et travailler avec les informations qui ne sont pas vraiment là. Voir K & R pour une implémentation MALLOC () simple ().
Concernant 'sous 200 threads ok; plus de 300 crashs plus tôt '; Avez-vous examiné si le serveur attribue un pool de taille fixe de certaines ressources (peut-être 200, peut-être 256) et ne vérifie pas correctement l'épuisement de cette ressource. Il pourrait s'agir d'un ensemble de mautexes, de sémaphores, ou autre chose qui déclenche une abus de mémoire. Le code serveur est-il écrit? Devez-vous examiner la limitation du nombre de threads au travail?
Malheureusement, je n'ai pas écrit le code alors je ne sais vraiment pas ce qui se passe exactement sur le serveur. Je suis juste responsable de la stabilisation du serveur et je suis malheureusement la personne qui l'a écrit n'est pas disponible. L'idée d'épuisement des ressources est une bonne. Je vais essayer de trouver quelque chose de ressource pouvant causer ce problème. Je vais également essayer d'utiliser la solution malloc de débogage. J'espère que cela me montre la vraie cause des accidents. Merci beaucoup pour votre aide
valgrind --tool=memcheck --leak-check=full exename
La première chose à rechercher est le message d'erreur que vous obtenez lorsque le programme se bloque. Cela vous dira souvent quel type d'erreur est survenu. Par exemple, Si vous ne voyez pas le message d'erreur, exécutez le programme de la ligne de commande ou de pipeler sa sortie dans Un fichier. p> Pour qu'un fichier principal soit vraiment utile, vous devez compiler votre programme sans optimisation et avec des informations de débogage. GCC a besoin des options suivantes: une fois que vous avez le fichier principal, puis ouvrez-le dans GDB avec: P> -g -o0 code>. (Assurez-vous que votre construction n'a pas d'autre -o code> -o code>.) P> gdb YOUR-APP COREFILE