Ralentissements aléatoires Java sur Mac OS

Question

J'ai un programme Java pour effectuer un ensemble de calculs scientifiques sur plusieurs processeurs en le décomposant et en exécutant chaque élément dans un thread différent. Le problème est trivialement partitionnable, il n'y a donc pas de conflit ou de communication entre les threads. Les seules données communes auxquelles ils accèdent sont des caches statiques partagés pour lesquels il n'est pas nécessaire de synchroniser leurs accès, ainsi que des fichiers de données sur le disque dur. Les threads écrivent aussi en permanence sur le disque, mais séparent les fichiers.

Mon problème est que, parfois, lorsque je lance le programme, ma vitesse est très bonne, et que parfois, quand je lance exactement la même chose, il tourne très lentement. Si je le vois courir lentement et que ctrl-C et le redémarre, il recommencera généralement à courir vite. Il semble se mettre en mode lent ou en mode rapide au début de la course et ne bascule jamais entre les modes.

Je l'ai relié à jconsole et cela ne semble pas être un problème de mémoire. Lorsque je l’ai surpris à ralentir, j’ai essayé de lui connecter un profileur, mais ce dernier ne se connecte pas. J'ai essayé de courir avec -Xprof mais les dumps entre une course lente et une course rapide ne semblent pas être très différents. J’ai également essayé d’utiliser différents collecteurs de déchets et différentes tailles des différentes parties de l’espace mémoire.

Ma machine est un Mac Pro avec une partition RAID en bandes. L’utilisation du processeur ne diminue jamais, que ce soit lentement ou rapidement, ce qui serait normal si les threads passaient trop de temps à bloquer les lectures du disque. Je ne pense donc pas que ce soit un problème de lecture du disque.

Ma question est la suivante: quels types de problèmes avec mon code pourraient être la cause? Ou cela pourrait-il être un problème de système d'exploitation? Je n'ai pas été en mesure de le dupliquer sur une machine Windows, mais je n'ai pas de machine Windows avec une configuration RAID similaire.

Answer 1

Vous avez peut-être un fil qui est entré dans une boucle sans fin.

Essayez de vous connecter avec VisualVM et utilisez le moniteur de thread.

https://visualvm.dev.java.net

Vous devrez peut-être vous connecter avant que le problème ne se produise.

Answer 2

Je suis d'accord avec le fait que vous devriez le faire avec un profileur examinant la vue des fils de discussion - combien de fils de discussion, dans quels états sont-ils, etc. Cela pourrait être une condition de course étrange qui se produit de temps en temps. Il se peut également que l’instrumentation des classes avec des hooks de profileur (ce qui provoque un ralentissement) sorte la condition de concurrence critique et que vous ne constatiez aucun ralentissement lorsque le profileur est connecté: /

Veuillez consulter le ce message , ou plutôt la réponse, lorsqu'un problème de conflit de cache est mentionné.

Créez-vous le même nombre de threads à chaque fois? Ce nombre est-il inférieur ou égal au nombre de threads disponibles sur votre plate-forme? Ce nombre pourrait être vérifié ou invité avec une exactitude correcte.

S'il vous plaît, postez les résultats!

Answer 3

Avez-vous un outil pour mesurer la température du processeur? Le système d'exploitation peut limiter le processeur pour résoudre les problèmes de température.

Answer 4

Est-il possible que votre programme soit paginé sur le disque parfois? Dans ce cas, vous devrez examiner l'utilisation de la mémoire du système d'exploitation dans son ensemble, plutôt que simplement celle de votre programme. Je sais par expérience qu’il existe une énorme différence de performances d’exécution lorsque la mémoire est continuellement paginée sur le disque et inversement.

Je ne connais pas grand-chose à propos d'OSX, mais sous Linux, le "gratuit" Cette commande est utile à cette fin.

Les fichiers journaux sont un autre problème susceptible de provoquer ce ralentissement. Je connais au moins un code de journalisation qui a ralenti le système progressivement au fur et à mesure de la croissance des fichiers journaux. Il est possible que vos threads se synchronisent sur un fichier journal dont la taille augmente, puis lorsque vous redémarrez votre programme, un autre fichier journal est utilisé.