Récemment, nous avons commencé à tester le stress Notre application (un serveur de discussion basé sur XMPP) à l'aide de YJP 11.0.9. Pendant notre test, nous avons remarqué un comportement étrange.
J'ai fait plusieurs tests pour confirmer les résultats et chaque fois que j'ai reçu des résultats similaires. P>
Je suis incapable de comprendre pourquoi l'imprécis devrait prendre 60% de temps et pourquoi le traçage montre exactement les résultats opposés.
Quelqu'un peut-il m'aider à comprendre ces résultats. Est-ce que je manque quelque chose ici? P>
Environnement: P>
java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
3 Réponses :
avec certaines commandes de blocage de niveau bas telles que lecture / écriture / parc / verrouillage, le temps "CPU" est surévuateur tel qu'il suppose que cela consomme une CPU lorsque l'opération est en réalité bloquée. Les faits imprécis / parc sont à la fois élevés suggèrent que vous avez un problème, mais je soupçonne que vous devriez prendre le plus bas des deux pourcentages comme estimation.
Haute Temps de CPU de Combien de temps faut-il pour faire un changement de contexte?
L'option la plus simple de découvrir CS compter sur Linux est exécutée Une fois que élevé CS est confirmé (par exemple, plus de commutateurs 10k par noyau / par seconde), vous prenez le thread incriminé (vous pouvez trier les threads en YJP par leur heure de processeur) et exécuter Unfafe.unpark est un signe de commutation excessive Context . Voici un article pour obtenir l'idée de la façon dont on cherche un commutateur de contexte:
vmstat strace -p
J'ai appris la solution difficile à savoir que vous pouvez également avoir une utilisation élevée de CPU% sur Locksupport.parknanos () si vous appelez plusieurs fois la méthode et votre argument de sommeil se trouve dans l'ordre des nanosecondes:
while(true){
// code logic
LockSupport.parkNanos(100);
}
Cela pourrait supporter beaucoup si appeler
imparquement est à peu près la seule chose que le fil est jamais. Que voulez-vous dire que "Tracing montre exactement les résultats opposés"? Le traçage peut-il peut-être mesurer le temps passé dans une méthode?Park est une méthode de blocage, donc aucun temps d'émerveillement n'est dépensé en elle.@ Markotopolnik thread fait d'autres choses aussi. Fondamentalement, son produit producteur / consommateur. Produire des tâches produisent des tâches et soumettez-la dans la file d'attente et informer les consommateurs en attente. Le consommateur agit sur la tâche et si aucune tâche n'est disponible que de se garer elle-même.
Le fil qui appelle
imparquement n'est pas le fil étant imprégné. Ce fil, à son tour, ne peut vraiment faire que peu de travail en dehors de l'imprégnation des threads de consommation appropriés. Quant à l'heure du processeur dePark , il est difficile de mesurer en raison de la blocage et de B) sans pertinence car ce sera une fraction insignifiante du temps passé dans l'état garé.@Markotopolnik dans le test d'échantillonnage 60% de la CPU consacrée à faire des consommateurs imprécis. Lors du test de traçage 52% de la CPU consacré à faire du parc du fil de consommation.
@Markotopolnik Comme je l'ai dit producteur, l'activité du processeur comme XML analyse de XML qui devrait être nettement supérieure à celle de l'interruption.
Vous empilez le temps de stationnement effectué par un fil contre le temps d'imprégnarde effectué par un autre fil. Ces deux chiffres sont en principe sans signification à comparer, même en ignorant le fait probable que l'échantillonnage ne messe pas correctement le temps passé à bloquer, tout en «traçage».
@Markotopolnik Ma principale confusion est donnée Il y a beaucoup d'autres activités de la CPU, pourquoi l'imprécis peut-il se livrer à des points chauds pendant l'échantillonnage tout au long de la traçabilité de l'impuissance de l'impuissance, c'est que non dans la liste, mais se garent maintenant la liste des points chauds.
Je concentrerais mon attention sur
impréck seulement.Park ne peut pas être un problème. En outre, je ne sais pas ce que vous entendez exactement par "lors de l'échantillonnage" et "pendant le traçage". Jvisalvm, par exemple, a un profileur d'échantillonnage, il affiche des points chauds en courant. Ils sont en grande partie non pertinents. Les trucs vraiment pertinents sont montrés après avoir pris un instantané et analysant les piles d'appel de chaque thread.@Markotopolnik dans YJP Il y a deux façons pour le profilage de la CPU - échantillonnage et traçage. Plus de détails sont chez Yourkit.com/docs/80/help/cpu_intro.jsp < / a>
Le traçage serait le même que de «profiler» de Visualvm. Notez que "Traçage" compare simplement l'horodatage d'entrée de méthode avec la sortie de la méthode Timestamp. Il ne sait pas à quel point ce temps a été dépensé en réalité exécutant sur la CPU et combien venait de bloquer.