Lorsque je regardais Cloudwatch, la charge du processeur était élevée au démarrage de l'instance, on m'a donc demandé de la vérifier.
Si vous le recherchez, vous pouvez savoir comment le faire, mais pour votre propre mémorandum.
Red Hat Enterprise Linux Server release 7.5 (Sur AWS EC2)
Le processeur est-il vraiment surchargé? N'est-ce pas un bogue CloudWatch? Vérifiez donc avec la commande sar. Si l'environnement n'inclut pas la commande sar, installez-la.
$ sudo yum install sysstat
À propos, cette fois, cela s'est produit dans l'environnement de production, mais dans l'environnement de production, il est rare que vous puissiez vous connecter directement, vous pouvez donc également récupérer le journal de production et voir le fichier sa.
$sar -f <Chemin du fichier>
09:10:02 CPU%user %nice %system %iowait %steal %idle
09:20:01 tous les 3.97 0.00 0.35 0.00 0.01 95.67
09:30:01 tous les 4.01 0.00 0.36 0.00 0.01 95.62
09:40:02 tous les 3.87 0.00 0.42 0.00 0.01 95.69
09:50:01 tous les 4.05 0.00 0.35 0.00 0.01 95.59
10:00:01 tous les 4.04 0.00 0.37 0.00 0.01 95.58
10:10:01 tous les 3.95 0.00 0.35 0.00 0.01 95.69
10:20:02 tous les 3.98 0.00 0.36 0.00 0.01 95.65
10:30:01 tous les 4.04 0.00 0.36 0.00 0.01 95.59
10:40:01 tous les 3.81 0.00 0.41 0.00 0.01 95.76
10:50:02 tous les 3.96 0.00 0.36 0.00 0.01 95.67
11:00:01 tous les 4.14 0.00 0.35 0.00 0.01 95.49
11:10:01 tous les 3.94 0.00 0.35 0.00 0.01 95.71
Vous pouvez voir le résultat comme ceci. Quand je le regarde, je ne vois pas que la charge est particulièrement élevée.
Lorsque vous regardez le cloudwatch, le même phénomène peut être observé dans l'environnement de mise en scène, alors reproduisez-le dans l'environnement de mise en scène. De plus, 10 minutes est trop large, alors essayons 1 minute.
$ vi /etc/cron.d/sysstat
Remplacez \ * / 10 par \ * / 1
# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# 0 * * * * root /usr/lib64/sa/sa1 600 6 &
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A
Redémarrez le système d'exploitation et vérifiez
19:53:01 Processeur%user %nice %system %iowait %steal %idle
19:54:01 tous 68.91 0.00 3.04 0.05 0.01 28.00
19:55:01 tous 2.93 0.01 0.41 0.01 0.02 96.63
19:56:01 tous les 8.20 0.00 0.86 0.02 0.01 90.91
19:57:01 tous les 4.65 0.00 0.34 0.01 0.01 94.99
19:58:01 tous 0.26 0.00 0.07 0.00 0.01 99.67
19:59:01 tous les 4.97 0.01 0.36 0.00 0.02 94.65
20:00:01 tous les 4.93 0.00 0.39 0.00 0.01 94.67
20:01:01 tous les 3.11 0.00 0.54 0.00 0.01 96.34
20:02:01 tous les 4.97 0.00 0.38 0.00 0.01 94.64
20:03:01 tous les 4.87 0.00 0.34 0.00 0.01 94.78
Oui. Le processeur est soumis à une forte charge.
Tout d'abord, identifiez les processus avec une charge CPU élevée
$ ps -aux
Vous pouvez voir le taux de consommation CPU en regardant la colonne% CPU. Cette fois, Tomcat avait 140 ans ou quelque chose comme ça. (Il existe également un moyen de vérifier avec la commande top, mais j'ai utilisé la commande ps car c'était difficile à voir cette fois)
Vérifiez ensuite quel thread est sous charge.
$ ps -L aux
Lorsque cette commande est saisie, la sortie suivante est sortie (prise lorsque la charge du processeur s'est stabilisée).
USER PID LWP %CPU NLWP %MEM VSZ RSS TTY STAT START TIME COMMAND
test 1007 1016 0.4 56 16.8 6749028 1299196 ? Sl 16:52 0:01 /usr/bin/java -Djava.util.logging.config.file=/opt/test/tomcat/conf/logging.properties -Djava
test 1007 1029 2.2 56 16.8 6749028 1299196 ? Sl 16:52 0:05 /usr/bin/java -Djava.util.logging.config.file=/opt/test/tomcat/conf/logging.properties -Djava
test 1007 1032 1.6 56 16.8 6749028 1299196 ? Sl 16:52 0:04 /usr/bin/java -Djava.util.logging.config.file=/opt/test/tomcat/conf/logging.properties -Djava
test 1007 1053 1.9 56 16.8 6749028 1299196 ? Sl 16:52 0:04 /usr/bin/java -Djava.util.logging.config.file=/opt/test/tomcat/conf/logging.properties -Djava
test 1007 1057 0.0 56 16.8 6749028 1299196 ? Sl 16:52 0:00 /usr/bin/java -Djava.util.logging.config.file=/opt/test/tomcat/conf/logging.properties -Djava
Notez ici le PID et le LWP fortement chargés.
Je le savais, mais le processus à forte charge est Jaba! est. Alors vérifions le thread dump: avion:
sudo -u test jstack -l <PID haute charge> > /tmp/jstack
C'est ainsi que vous obtenez le vidage des threads. Si vous le prenez une fois toutes les quelques minutes, vous pouvez voir le changement.
En regardant dans / tmp / jstack, la sortie est la suivante
"localhost-startStop-1" #17 daemon prio=5 os_prio=0 tid=0x00007f6fe0001db0 nid=0x5ee runnable [0x00007f700c062000]
java.lang.Thread.State: RUNNABLE
at org.springframework.asm.Type.getReturnType(Type.java:386)
at org.springframework.core.type.classreading.AnnotationMetadataReadingVisitor.visitMethod(AnnotationMetadataReadingVisitor.java:81)
at org.springframework.asm.ClassReader.readMethod(ClassReader.java:1061)
at org.springframework.asm.ClassReader.accept(ClassReader.java:729)
at org.springframework.asm.ClassReader.accept(ClassReader.java:527)
at org.springframework.core.type.classreading.SimpleMetadataReader.<init>(SimpleMetadataReader.java:64)
at org.springframework.core.type.classreading.SimpleMetadataReaderFactory.getMetadataReader(SimpleMetadataReaderFactory.java:102)
at org.springframework.core.type.classreading.CachingMetadataReaderFactory.getMetadataReader(CachingMetadataReaderFactory.java:102)
- locked <0x00000006f3a459d8> (a org.springframework.core.type.classreading.CachingMetadataReaderFactory$1)
at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:287)
at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:272)
at org.springframework.context.annotation.ComponentScanAnnotationParser.parse(ComponentScanAnnotationParser.java:135)
at org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:289)
at org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:247)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:200)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:169)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:308)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:228)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:272)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:92)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:687)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:525)
- locked <0x0000000708be6ac8> (a java.lang.Object)
(Omis ci-dessous)
Le nombre après 0x où ce nid = 0x5ee est écrit est lavaleur obtenue en convertissant le LID vu avecps -L aux plus tôt en un nombre hexadécimal.
Recherchez celui qui correspond au LID parmi les nombreux vidages de threads écrits.
Reportez-vous au site suivant pour savoir comment lire le vidage des threads https://yohei-a.hatenablog.jp/entry/20150101/1420112104
En regardant dans le vidage des threads, je n'ai pas trouvé de threads étranges. En premier lieu, il consomme une certaine quantité de CPU lors du démarrage de tomcat, et comme deux tomcats sont démarrés dans cet environnement, il faut du temps pour que la charge du processeur se stabilise. Je suis content que ce ne soit pas anormal, mais j'ai beaucoup appris sur la façon de lire le thread dump, donc j'ai beaucoup appris: détendu:
Recommended Posts