Issues to be aware of when configuring visualvm:
1, JDK selection problem:
Pay attention to install the development version of jdk
development: This version only has bin and jre
This version of running time is only jre (if you choose this version, some commands will not be found, such as jstatd)
(see the jdk chapter for details)
2. You can't open the firewall, otherwise the ground will move and you won't be able to access it. All closed means all allowed (or all ports to be opened are opened)
3. Create your own script
#!/bin/shexport must be on a separate line and cannot be combined with the content
#!/bin/shexport
JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx512m -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password -Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access"
4. Use the local visualvm to connect to the remote:
1. After running, install the plug-in in the tool ( not more than once )
The plug-in that is installed has this function tab. As for what jar package is needed for this interface, it can be configured in the tab separately, such as the use of jconsole.
After restarting jtop.jar, when looking at tomcat, it does not prompt for configuration but prompts that jmx cannot be used, change a user (controlRole (add jmx)), and then add jstatd to the tomcatjconson available
Different plugins can only log in with different identities and see different plugin functions
2. When jmx is connected, it also needs to install rich plug-ins
3. Restart after installation
4. After each restart (visual vm), jstatd needs to be restarted. The listening port will change, and it needs to be set in jstatd again.
again
cd $JAVA_HOME/bin
./jstatd -J-Djava.security.policy=all.policy &
netstat -anp | grep *jstatd
After adding jstatd monitoring, tomcat comes out automatically ( after the above command is executed, start visualvm to automatically join jstatd-tomcat )
5, tomcat settings enable oom to generate dump
When developing and using Unix programs, sometimes the program is inexplicably down, but there is no prompt (sometimes it prompts core dumped). At this time, you can check whether there is a file in the shape of core. Process ID is generated, this file is the operation The system throws out the memory content when the program is down, and it can be used as a reference for debugging the program.
Core dump is also called core dump. When an exception occurs during the running of the program and the program exits abnormally, the operating system stores the current memory status of the program in a core file, which is called core dump.
gdb -c core file path [path to application]
After entering, enter where and press Enter, you can display which line the program failed, and in which function.
Sometimes the program is down, but the core file is not generated. The generation of the core file is related to the environment settings of your current system. You can use the following statement to set it, and then run the program to generate the core file. The location where the core file is generated Generally the same path as the running program, the file name is generally core.process number