如何监控服务器状态监控的jvm状态，内存使用状况

来源：蜘蛛抓取(WebSpider) 时间：2016-11-07 12:32 标签： 如何监控服务器状态
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&远程监控tomcat的JVM运行情况详解-服务器-电脑编程网远程监控tomcat的JVM运行情况详解作者：l　和相关&&
win：win7、jdk1.6.0
server：linux、jdk1.6.0_03、tomcat6
主要从下面三个方面描述JVM内存监控流程：
◆jmap(MemoryMap)JVM内存对象打印工具
◆jstatd配置
◆Tomcat配置JMX
1.使用Jmap简单查看tomcat内存占用情况：
显示java进程内存使用的相关信息
jmap pid #打印内存使用的摘要信息
jmap Cheap pid #java heap信息
jmap -histo:live pid #统计对象count ，live表示在使用
jmap -histo pid &mem.txt #打印比较简单的各个有多少个对象占了多少内存的信息，一般重定向的文件
jmap -dump:format=b,file=mem.hprof pid #将内存使用的详细情况输出到mem.hprof 文件，这个文件很大，我设置的内存是8G文件大约2G,应该跟内存差不多大。
2.使用jvisualvm.exe
该文件位置在jdk1.6.0_29\bin下，1.6以后才有。
1.可以用将上一步生成的mem.hprof&直接用这个软件打开
然后便可以看到相应的信息并进行分析。如下图:
要监控远程linux主机上的tomcat服务情况还要用到jstatd
3.使用jstatd
jstatd [options]
此命令是一个RMI Server应用程序，提供了对JVM的创建和结束监视，也为远程监视工具提供了一个可以attach的接口
-nr&当一个存在的RMI Registry没有找到时，不尝试创建一个内部的RMI Registry
-p port&端口号，默认为1099
-n rminame&默认为JStatRemoteHost；如果多个jstatd服务开始在同一台主机上，rminame唯一确定一个jstatd服务
-J&jvm选项
jstatd&会报如下错误：
Could not create remote object
access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write)
java.security.AccessControlException: access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write)
&&&&&&& at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
&&&&&&& at java.security.AccessController.checkPermission(AccessController.java:546)
&&&&&&& at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
&&&&&&& at java.lang.System.setProperty(System.java:727)
&&&&&&& at sun.tools.jstatd.Jstatd.main(Jstatd.java:122)
这是因为没有给jstatd指定安全策略
创建安全策略文件，并命名为jstatd.all.policy
grant codebase &file:${java.home}/../lib/tools.jar& {
permission java.security.AllP
};再次启动 : & &jstatd -J-Djava.security.policy=jstatd.all.policy
利用jps查看:&&jps -l 127.0.0.1
更多示例 ：
（1）使用内部RMI Registry
jstatd -J-Djava.security.policy=all.policy
(默认端口为1099)
（2）使用外部RMI Registry
a)使用默认值
rmiregistry&
jstatd -J-Djava.security.policy=all.policy
b)使用2020端口
rmiregistry 2020&
jstatd -J-Djava.security.policy=all.policy -p 2020
c)使用2020端口，使用rminame
rmiregistry 2020&
jstatd -J-Djava.security.policy=all.policy -p 2020 -n AlternateJstatdServerName
（3）RMI Registry已经启动，不创建内部RMI Registry
jstatd -J-Djava.security.policy=all.policy -nr
（4）RMI日志能力
jstatd -J-Djava.security.policy=all.policy -J-Djava.rmi.server.logCalls=true
打开了jstatd已经可以使用jvisualvm.exe查看堆信息，类信息和线程信息，但是看不到cpu信息
先在jvisualvm添加远程主机
他会列出进程，双击进程就可以看到：
我们还需要配置JMX。
4.tomcat中配置JMX
可以直接在catalina.sh中添加如下命令行：
CATALINA_OPTS=&-Dcom.sun.management.jmxremote.port=8901 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.8.7&这样配置可以不用密码验证。
重启tomcat后直接在jvisualvm中添加JMX的连接
之后便可以监控cpu信息。在jvisualvm双击JMX的进程如下图：
上图的IP和端口号实际的时候是统一的，由于图片来自于多篇文章和实际使用，所以不同，请注意。
以上文章参考网址：
.cn/s/blog_7e40efgf.html
/art/701.htm
http://blog.csdn.net/gtuu0123/article/details/6025484
http://bbs.chinaunix.net/thread--1.html
http://visualvm.java.net/zh_CN/gettingstarted.html
相关资料：｜｜｜｜｜｜｜远程监控tomcat的JVM运行情况详解来源网络，如有侵权请告知，即处理！编程Tags：　　　　　　　　　　　　　　　　&　　　　　　　　　　　　　　　　　　　　07JVM架构（018）_如何监控jvm的运行情况
1、如何监控jvm的运行情况
我们通常使用Jdk工具来监控jvm的运行情况，当然目前有很多第三方产品是通过jdk提供的api来组织数据进行监控的。具体来说有如下监控软件：
jdk自带，功能简单，但是可以在系统有一定负荷的情况下使用。对垃圾回收算法有很详细的跟踪。
JavaVisualVM
JDK自带，功能强大，与JProfiler类似。推荐使用，通过jdk/bin/jvisualvm即可启动。
商业软件，需要付费。功能强大。
2、监控软件都能监控什么
上面这些调优工具都提供了强大的功能，但是总的来说一般都类似，能够监控CPU、内存、线程等信息。
例如JavaVisualVM具有以下几类功能：CPU、堆、类、线程关键信息，手动进行垃圾回收GC，线程详细信息，CPU、内存抽样信息，生成堆Dump、线程Dump
CPU、堆、类、线程关键信息
图形化CPMU、堆、类、线程关键信息供我们查看，并且可以通过&执行垃圾回收&可以手动进行垃圾回收GC。如图：
线程详细信息
应用中每个线程的详细信息，包括运行时、休眠、等待、驻留、监视等状态的线程。如图：
CPU、内存抽样信息
通过收集一段时间的CPU、内存运行数据，展示内存和线程的详细信息。如图：
生成堆Dump、线程Dump
通过生成某个应用的堆、线程Dump来分析具体的Dump文件。
通过堆Dump可以监控：堆详细概要信息，堆内类对象分析，堆内对象实例详细信息，OQL堆信息自定义查询
通过线程Dump可以监控：线程状态变化，线程堆栈信息
堆详细概要信息
展示堆Dump的概要信息，包括堆基本信息、环境、系统属性、堆转储上的线程。如图：
堆内类对象分析
展示堆内使用到的所有类，以及它们的实例数和占用大小。默认按照实例数倒序。如图：
堆内对象实例详细信息
通过类可以进入指定类的实例详细信息，包括每一个实例的详细信息。如图：
OQL堆信息自定义查询
通过OQL语言查询我们想得到的结果。如图：
线程Dump信息
通过打印线程堆栈，展示线程状态变化，以及运行信息。如图：
我们能够根据我们监控的到信息，能够让我们发现代码的问题，优化的办法。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'JVM服务器虚拟机内存一直增长，重启后五六天就涨到接近100%，如何解决？
JVM服务器虚拟机内存一直增长，重启后五六天就涨到接近100%，使用阿里云服务器，8G物理内存，跑了9个项目，请问这是怎么回事？如何解决？
同 ，请profile一下。另外也请更详细描述问题的信息。“物理内存8G”是说买的阿里云服务是8GB的instance是么？那么给JVM的-Xmx配置到了多少呢？如果说的“接近100%”是说Java heap的使用量（used）接近-Xmx配置的maximum capacity，那其实还比较好办，用常用的Java工具能比较好的分析问题。首先可以用任意的JMX工具监控Java heap的使用情况，如果使用量确实是在不断上涨而且GC了都无法回收足够空间，那请试试下面两种的其中一种：每隔一段时间用JDK自带的 jmap -dump:live,format=b,file=&filename& 来获取一份HPROF格式的heap dump文件。收集几份之后，用Eclipse Memory Analyzer（MAT）来打开这些heap dump，并按时间顺序来比对它们的内容，看到底是哪些对象在不断增加，并且以此尝试分析程序里哪里有内存泄漏。使用支持allocation profiling的profiler连接到JVM上去收集allocation profile，这样可以动态的知道哪里在分配什么对象，哪些类型的对象占内存特别多。免费的和收费的Java profiler都有，免费的像Oracle JDK自带的VisualVM里带的profiler（NetBeans Profiler）就支持allocation profiling。这两种办法各有优缺点。jmap获取heap dump的办法，在比较大的-Xmx下可能会导致JVM较长时间的停顿（因为-dump:live的背后需要做以此full GC），在线系统可能无法忍受这点。但如果可以忍受的话，得到heap dump可以离线反复分析，而且可以精确到某个对象实例来分析，精度较高。不过这种办法无法获得allocation site的stack trace，所以最好是对要分析的源码有比较深的了解、能够猜测出哪里会创建什么类型的对象的情况下使用。MAT支持headless模式工作，不一定要在能跑GUI的地方运行。Heap dump很大的话，通常是扔在内存足够大的服务器上先分析好了，再在能跑GUI的地方打开那些分析好的文件。Java层面的allocation profiling通常会用bytecode instrumentation来实现，而这会带来一些运行时开销——程序会跑得比平时慢。具体慢多少要看具体程序的情况。但至少这不会因为分析而引致full GC，所以如果jmap法无法接受的话可以试试这边。Allocation profiling通常无法精确到对象实例，而只能精确到类型+分配对象时的stack trace。关于VisualVM的profiler是如何实现allocation profiling的，可以参考我的一个笔记：Oracle JDK7u40+和Oracle JDK8自带的Java Mission Control都支持由JVM直接支持的allocation profiling，近乎零额外开销，精度跟一般做bytecode instrumentation的allocation profiler差不多，非常便利。Azul Systems的Zing自带的ZVision同样支持零开销的allocation profiling，用起来也是非常方便。
profile一下，我觉得是你们的代码有问题，导致资源泄露
添加一个 JVM 发生 OOM 后就进行 Heap Dump 的参数，得到 hprof文件后，用 MAT 分析就可以马上知道了哪里存在泄露了。参数大概是： -XX:HeapDumpOnOutOfMemoryError ，凭印象打的，你搜一下。应该能很快定位问题。
我们的项目和你的类似，最近刚解决了一个JVM内存泄漏的问题，不过解决这种问题，需要好的监控工具，这里有篇文章，希望对你在思路上有帮助
附上jvm选项配置和gc log吧！
这种一般都是编码问题，重点检查文件、大数据循环操作等，再结合内存分析工具查找对象及相关类。
同前两位。使用工具基本就能查出问题。如果确定代码没问题，调整GC配置，若效果仍不明显，加配置。
已有帐号？
无法登录？
社交帐号登录

我要回帖

更多关于 如何监控服务器状态 的文章

 

随机推荐