Discussion :

[oodini]

Hello,

Je travaille sur une grosse appli, qui traite des données en multithreads. Quand elle est en prod, parfois (ça peut venir au bout de plusieurs semaines), la consommation CPU explose sur 1 ou 2 cœurs. Impossible à reproduire pour une session de debug.

Quelel serait votre méthode pour traquer ce problème (à part instrumenter les boucles comme un bourrin) ?
Je suis sous Visual Studio 2010 Pro.

Merci.

[djuju]

Salut,

J'ai déjà eu ce type de problème par le passé.
Dans mon cas, c'était soit des problèmes de changement de timming des threads en mode release (à cause de l'instrumentalisation du code ou des optimisations). Soit des problèmes d'optimisation en mode release. Des fois, le compilo de VC++ prend certaines libertés qu'il ne devrait pas. Généralement sur des concepts architecturaux discutables mis en place dans ton code (comme des variables globales p.ex.). Bref, on doit tous vivre avec les casseroles de l'histo du notre code...
J’imagine qu'il y a des chances pour que tu rencontre un problème du genre.

Loin de moi la prétention de dire que j'ai la meilleure méthode, mais voici mon approche. Je compile en release avec les debug info. Comme ça j'ai pas d’instrumentalisation du code (comme les new et delete p.ex.) et je garde mes optimisations. Par la suite je fais rouler le code jusqu'à rencontrer le pb. Éventuellement en remote debugger. Lorsque je rencontre le probleme, j'utilise le debugger de VS. Comme le code est optimisé, c'est parfois un peu freestyle de suivre les traces dans le débugger, mais ça m'a toujours permis d'au moins me rapprocher du problème en isolant un bout de code. Si je n'ai toujours résolu comme ça, je trace mon bout de code en disassembly ou j'ajoute un peu d'instrumentalisation localisée avec des debug breaks dynamiques (DebugBreak()).

Bref, cette solution n'est pas magique magique, mais je doute qu'il en existe une.

[Klaim]

Question: est-tu sur que c'est le CPU qui se mets a consommer trop, ou le disque dur qui embarque le CPU avec lui?


Si c'est le disque dur, alors c'est certainement un probleme de memoire cache.

[oodini]

@Klaim : pas d'entrées/sorties supplémentaires sur les disques

Loin de moi la prétention de dire que j'ai la meilleure méthode, mais voici mon approche. Je compile en release avec les debug info. Comme ça j'ai pas d’instrumentalisation du code (comme les new et delete p.ex.) et je garde mes optimisations.

J'ai du mal à comprendre ce que tu entends par instrumentalisation du code.

[Médinoc]

Le terme exact est "instrumentation" il me semble; c'est une chose qui consiste à insérer du code spécial pour recueillir plus d'informations de débogage (par exemple, enregistrer chaque appel à malloc/new avec leur fichier et n° de ligne)

[Klaim]

En anglait, profiling.

[djuju]

Effectivement, instrumentation... Désolé.
Médinoc a raison. En mode debug, le compilo de VS va ajouter plein d'info pour suivre le debug et faire des vérifications à la volée. Il y a bien sur les alloc/désalloc de mémoire, mais aussi p.ex. les array out of bounds et les variables non initialisées. Le problème, c'est que ça ralenti beaucoup le code. Donc si tu es dans des parties du code qui sont time critical, ça peut poser un problème. De la même façon, si tu cherches à reproduire un bug dans une appli multi-thread, il est possible que tu n'arrives plus à reproduire le bug parce que les changements de temps d'exec de chaque thread t’empêchent de reproduire ta course critique.

[oodini]

Le problème, je pense, est surtout que ça n'arrive en prod qu'au bout de quelques jours/semaines.

Le soft traite des données. je peux lui injecter le même jeu de données, mais si je dois attendre 2 semaines devant mon PC...

Je vais ajouter une précision au message original concernant les threads...

[white_tentacle]

Le problème, je pense, est surtout que ça n'arrive en prod qu'au bout de quelques jours/semaines.

Le soft traite des données. je peux lui injecter le même jeu de données, mais si je dois attendre 2 semaines devant mon PC...

Je vais ajouter une précision au message original concernant les threads...

Première chose : générer les symboles même en mode release.

Ensuite, quand le problème survient, identifier précisément le ou les threads qui bouffent la CPU (process explorer est ton ami, de mémoire il permet ça). Enfin, s’attacher au processus et déterminer où sont ces threads, dans quel bout de code. Normalement, avec les symboles, tu devrais retrouver tes petits.

À noter que pour débugger du code optimisé, j’ai tendance à préférer windbg (qui en plus peut facilement être installé sur un serveur de prod sans nécessiter de licence supplémentaire) que visual studio. Mais les choses ont peut être changé depuis quelques années.