默认分类

默认分类

默认分类描述

nginx反向代理nodejs报错no live upstreams while connecting to upstream

默认分类sdil 发表了文章 • 0 个评论 • 392 次浏览 • 2016-08-22 14:16 • 来自相关话题

问题描述:
最近公司需要使用nginx做nodejs的反向代理,upstream 大致配置如下:upstream nodejs {
ip_hash;
server 192.168.12.10:1088;
server 192.168.12.11:1088;
}
最近监控发现nginx+nodejs做的webservice接口有些失败率,查看nginx错误日志发现了问题,有大量的no live upstreams while connecting to upstream的错误。 
个人理解,这个错误应该是upstream里的2台node都连不上。
后来经过查阅网上相关文档发现:
是因为nodejs的http server不支持url中有空格的(未编码),这种请求进来,对于nginx来说,就是后端的node不可用,
而上面的upstream没有配max_fails,一次就被标记为失败了,这个时候后面跟着的同一nginx进程上的请求就会no live upstreams,
从错误日志也可以看出,每次no live upstreams while connecting to upstream错误都是紧跟在2条upstream prematurely closed connection while reading response header from upstream错误后的,
而后者这个错误都是由于url里有未编码的空格引起的。
解决办法:
1.调大max_fails,调低fail_timeout,不过这个方法不彻底也不会推荐哦!
2.最好是别用http建server,用tcp反向代理或者websocket,虽然这个问题是因为url不规范,但是没法限制用户要这么传,而且即使不规范也不能造成问题。
下面将简单介绍一下websocket反向代理的配置http{
#Add to nginx.conf http section
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream nodejs {
ip_hash;
server 192.168.12.10:1088;
server 192.168.12.11:1088;
}
server {
listen 8888;
server_name www.icesr.com;
index index.html index.htm index.jsp index.php;
location / {
proxy_pass http://nodejs;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_redirect off;
#proxy_buffers 8 32k;
#proxy_buffer_size 64k;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
}
}

以上配置即可实现nginx websocket反向代理。
  查看全部
问题描述:
最近公司需要使用nginx做nodejs的反向代理,upstream 大致配置如下:
upstream nodejs { 
ip_hash;
server 192.168.12.10:1088;
server 192.168.12.11:1088;
}

最近监控发现nginx+nodejs做的webservice接口有些失败率,查看nginx错误日志发现了问题,有大量的no live upstreams while connecting to upstream的错误。 
个人理解,这个错误应该是upstream里的2台node都连不上。
后来经过查阅网上相关文档发现:
是因为nodejs的http server不支持url中有空格的(未编码),这种请求进来,对于nginx来说,就是后端的node不可用,
而上面的upstream没有配max_fails,一次就被标记为失败了,这个时候后面跟着的同一nginx进程上的请求就会no live upstreams,
从错误日志也可以看出,每次no live upstreams while connecting to upstream错误都是紧跟在2条upstream prematurely closed connection while reading response header from upstream错误后的,
而后者这个错误都是由于url里有未编码的空格引起的。
解决办法:
1.调大max_fails,调低fail_timeout,不过这个方法不彻底也不会推荐哦!
2.最好是别用http建server,用tcp反向代理或者websocket,虽然这个问题是因为url不规范,但是没法限制用户要这么传,而且即使不规范也不能造成问题。
下面将简单介绍一下websocket反向代理的配置
http{
#Add to nginx.conf http section
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream nodejs {
ip_hash;
server 192.168.12.10:1088;
server 192.168.12.11:1088;
}
server {
listen 8888;
server_name www.icesr.com;
index index.html index.htm index.jsp index.php;
location / {
proxy_pass http://nodejs;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_redirect off;
#proxy_buffers 8 32k;
#proxy_buffer_size 64k;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
}
}

以上配置即可实现nginx websocket反向代理。
 

tomcat日志报错“Connection reset”

回复

默认分类sdil 回复了问题 • 1 人关注 • 1 个回复 • 336 次浏览 • 2016-08-22 14:19 • 来自相关话题

JVM tomcat性能实践

默认分类sdil 发表了文章 • 0 个评论 • 203 次浏览 • 2016-08-09 11:27 • 来自相关话题

Tomcat的JVM参数可以配置在catalina.sh,如果是在window上可以配置.bat文件
配置1:






这里 我配置了一个gc日志路径为/home/log/gc.log ,打印gc的日志,初始堆和最大堆内存设置为50M,输出Dump文件在内存溢出的时候 ,使用串行垃圾收集器,永久代大小为50m。
将web应用放到对应的目录,配置好server.xml(这里不作配置介绍),sh start.sh启动tomcat.
 
使用压测工具(Jmeter)进行吞吐量的测试。没用过的同学可以上官网下载学习一下http://jmeter.apache.org/
建立用户组(10个线程,每个线程请求1000次),设置好Http请求的信息,生成一个聚合报告和一个gc日志
先来看一下gc日志吧:






满屏幕的Full GC啊,而且观察第一列时间戳变化结合用时可以发现,几乎上一次Full GC还没有结束,下一次又来了,真是一波还未平息,一波又来侵袭啊!
最后查看jmeter上给出的聚合报告:
 





吞吐量维持在122.7每秒。从这个案例中我们可以看到老年代34176k基本已经满了,经过FUll GC之后新生代会有一点剩余的空间。总的来说Full GC的停顿时间是最长的,而且发生的这么频繁,显然这样的配置是不合理的。
 
 
配置2:






这次配置主要是增大了最大堆内存。以便虚拟机自动扩容,得到稳定的堆内存大小。
 






只需要关注一点 最大堆内存为82924k 80M左右,也就是说虚拟机对堆内存自动扩容到80M,并且稳定下来。这个配置测试只是为了找到一个稳定的堆内存,以便接下来的测试。
 
配置三:






设置堆的初始内存128m。
由配置2的结果可知,堆内存最终稳定在80m左右,因此小于80m的堆内存,很有可能会引起大量的GC反应,所以这里我把堆内存设置为128M,可以减少GC次数。











可以看到吞吐量略微有所提升,GC次数大量减少,并且GC的时间间隔变得更长。
配置四:






当前使用ParallalGC回收器,这是一个多线程并行回收器。






使用多线程并行的GC回收器吞吐量有略微有提升。(在没有GC压力的情况下,ParallalGC与serialGC的差异对吞吐量影响并不大。)
 
配置五:













 
配置六:












 
根据配置三的结论在80M以下的堆内存会发生频繁的GC,再结合配置四中得到的结论在有一定GC压力的时候,ParallelGC和serialGC的差异会在吞吐量有一定的体现。配置五和配置六的堆内存为64M  (小于80M) ,所以会发生频繁的GC,在采用不同的GC回收器的时候,理论上会在在吞吐量上有较大的差异性,但是我的实验为什么差距不是很大,到底为什么呢?   诶, 家里穷,我用的是单核的CPU,在单核的情况下ParallelGC改变性能并不明显。在单核或者并行能力较弱的情况下还是推荐使用serialGC。有条件的同学可以用多核的服务器试一下哦!并告知结果,让本人体会一下糕富帅的生活。
 
配置七:






用ParNewGC试试,新生代使用ParNewGC回收,老年代依旧使用SerialGC回收。看看性能如何?






比全部使用串行回收器的性能好,但是比全部使用并行回收器的性能差些。
 
另外JDK版本的升级可能也会使得性能有一点的提升,这可以说是免费的午餐,但是JDK版本升级伴随着一定的风险,也许在新版本的JDK中引入某些未知的BUG,毕竟吃人家的嘴软,出来混的还是要还的!
 

 
 
最后我列出一些常用的JVM配置参数供参考:
1.与串行回收期相关的参数
    •-XX:+UseSerialGC:在新生代和老年代使用串行的收集器
    •-XX:SurvivorRatio:设置eden区的大小和survivor区的比例
    •-XX:PretenureSizeThreshold:设置大对象直接进入老年代的阀值。当对象的大小超过这个值,将直接在老年代分配
    •-XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次Minor GC后,对象年龄就加1.任何大于这个年龄的对象,一定会进入老年代。
2.与并行GC相关的参数
   •-XX:+UseParNewGC:在新生代使用并行收集器。
   •-XX:+UseParallelOldGC:在老年代使用并行收集器
   •-XX:+ParallelGCThreads:设置用于垃圾回收的线程数,通常可以设置成和CPU数相等。CPU数量较多的情况下,设置相对小的数值也可。
   •-XX:+MaxGCPauseMillis:设置最大垃圾收集停顿时间。它的值是一个大于0的整数。收集器在工作时,会调整java堆的大小或其他的一些参数,尽可能把停顿时间控制在MaxGCPauseMillis以内。
   •-XX:+UseAdaptiveSizePolicy:打开自适应GC策略,在这种模式下,新生代的大小和survivior的比例,晋升老年代的对象年龄等参数会被自动的调整,以达到堆大小,吞吐量和停顿之间的平衡点。
   •-XX:+GCTimeRatio:设置吞吐量大小。它的值是一个0到100之间的证书。假设GCTimeRatio的值为n,那么系统将花费不超过1/(1+n)的时间用于垃圾收集。
3.与CMS收集器相关的参数
   •-XX:+UseConcMarkSweepGC:新生代使用并行收集器,老年代使用CMS+串行收集器。
   •-XX:ParallelCMSThreads:设置CMS的线程数量。
   •-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发,默认68%
   •-XX:UseCMSCompactAtFullCollection:设置CMS在完成垃圾收集后是否要进行一次碎片整理
   •-XX:CMSFullGCBeforeCompaction:设定进行多少次CMS垃圾回收后,进行一次内存压缩。
   •-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收
   •-XX:CMSInitiatingPermOccupancyFraction:当永久代占有率达到这一百分比时,启动CMS回收(前提是-XX:+CMSClassUnloadingEnabled被激活了)
   •-XX:UseCMSInitiatingOccupancyOnly:表示只有在到达阀值的时候才进行CMS回收。
   •-XX:+CMSIncrementalMode:使用增量模式,比较适合单CPU.增量模式在中标记为废弃,jdk9中将彻底移除
4.与G1回收期相关的参数
   •-XX:+UseG1GC:使用G1回收器
   •-XX:+MaxGCPauseMillis:设置最大的垃圾收集停顿时间
   •-XX:+GcPauseIntervalMillis:设置停顿时间间隔。
5.TLAB相关
   •-XX:+UseTLAB:开启TLAB分配。
   •-XX:+PrintTLAB:打印TLAB相关分配信息
   •-XX:TLABSize:设置TLAB大小
   •-XX:+ResizeTLAB:自动调整TLAB大小
6.其他一些参数
   •-XX:+DisableExplicitGC:禁用显式GC
   •-XX:+ExplicitGCInvokesConcurrent:使用并发方式处理显式GC
本文转自:http://www.icesr.com/archives/2653 查看全部
Tomcat的JVM参数可以配置在catalina.sh,如果是在window上可以配置.bat文件
配置1:
2653-1.png



这里 我配置了一个gc日志路径为/home/log/gc.log ,打印gc的日志,初始堆和最大堆内存设置为50M,输出Dump文件在内存溢出的时候 ,使用串行垃圾收集器,永久代大小为50m。
将web应用放到对应的目录,配置好server.xml(这里不作配置介绍),sh start.sh启动tomcat.
 
使用压测工具(Jmeter)进行吞吐量的测试。没用过的同学可以上官网下载学习一下http://jmeter.apache.org/
建立用户组(10个线程,每个线程请求1000次),设置好Http请求的信息,生成一个聚合报告和一个gc日志
先来看一下gc日志吧:

2653-2.png


满屏幕的Full GC啊,而且观察第一列时间戳变化结合用时可以发现,几乎上一次Full GC还没有结束,下一次又来了,真是一波还未平息,一波又来侵袭啊!
最后查看jmeter上给出的聚合报告:
 
2653-3.png


吞吐量维持在122.7每秒。从这个案例中我们可以看到老年代34176k基本已经满了,经过FUll GC之后新生代会有一点剩余的空间。总的来说Full GC的停顿时间是最长的,而且发生的这么频繁,显然这样的配置是不合理的。
 
 
配置2:

2653-4.png


这次配置主要是增大了最大堆内存。以便虚拟机自动扩容,得到稳定的堆内存大小。
 

2653-5.png


只需要关注一点 最大堆内存为82924k 80M左右,也就是说虚拟机对堆内存自动扩容到80M,并且稳定下来。这个配置测试只是为了找到一个稳定的堆内存,以便接下来的测试。
 
配置三:

2653-6.png


设置堆的初始内存128m。
由配置2的结果可知,堆内存最终稳定在80m左右,因此小于80m的堆内存,很有可能会引起大量的GC反应,所以这里我把堆内存设置为128M,可以减少GC次数。

2653-7.png


2653-8.png


可以看到吞吐量略微有所提升,GC次数大量减少,并且GC的时间间隔变得更长。
配置四:

2653-9.png


当前使用ParallalGC回收器,这是一个多线程并行回收器。

2653-10.png


使用多线程并行的GC回收器吞吐量有略微有提升。(在没有GC压力的情况下,ParallalGC与serialGC的差异对吞吐量影响并不大。)
 
配置五:

11.png



2653-11.png



 
配置六:

2653-12.png


2653-13.png



 
根据配置三的结论在80M以下的堆内存会发生频繁的GC,再结合配置四中得到的结论在有一定GC压力的时候,ParallelGC和serialGC的差异会在吞吐量有一定的体现。配置五和配置六的堆内存为64M  (小于80M) ,所以会发生频繁的GC,在采用不同的GC回收器的时候,理论上会在在吞吐量上有较大的差异性,但是我的实验为什么差距不是很大,到底为什么呢?   诶, 家里穷,我用的是单核的CPU,在单核的情况下ParallelGC改变性能并不明显。在单核或者并行能力较弱的情况下还是推荐使用serialGC。有条件的同学可以用多核的服务器试一下哦!并告知结果,让本人体会一下糕富帅的生活。
 
配置七:

2653-14.png


用ParNewGC试试,新生代使用ParNewGC回收,老年代依旧使用SerialGC回收。看看性能如何?

2653-15.png


比全部使用串行回收器的性能好,但是比全部使用并行回收器的性能差些。
 
另外JDK版本的升级可能也会使得性能有一点的提升,这可以说是免费的午餐,但是JDK版本升级伴随着一定的风险,也许在新版本的JDK中引入某些未知的BUG,毕竟吃人家的嘴软,出来混的还是要还的!
 

 
 
最后我列出一些常用的JVM配置参数供参考:
1.与串行回收期相关的参数
    •-XX:+UseSerialGC:在新生代和老年代使用串行的收集器
    •-XX:SurvivorRatio:设置eden区的大小和survivor区的比例
    •-XX:PretenureSizeThreshold:设置大对象直接进入老年代的阀值。当对象的大小超过这个值,将直接在老年代分配
    •-XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次Minor GC后,对象年龄就加1.任何大于这个年龄的对象,一定会进入老年代。
2.与并行GC相关的参数
   •-XX:+UseParNewGC:在新生代使用并行收集器。
   •-XX:+UseParallelOldGC:在老年代使用并行收集器
   •-XX:+ParallelGCThreads:设置用于垃圾回收的线程数,通常可以设置成和CPU数相等。CPU数量较多的情况下,设置相对小的数值也可。
   •-XX:+MaxGCPauseMillis:设置最大垃圾收集停顿时间。它的值是一个大于0的整数。收集器在工作时,会调整java堆的大小或其他的一些参数,尽可能把停顿时间控制在MaxGCPauseMillis以内。
   •-XX:+UseAdaptiveSizePolicy:打开自适应GC策略,在这种模式下,新生代的大小和survivior的比例,晋升老年代的对象年龄等参数会被自动的调整,以达到堆大小,吞吐量和停顿之间的平衡点。
   •-XX:+GCTimeRatio:设置吞吐量大小。它的值是一个0到100之间的证书。假设GCTimeRatio的值为n,那么系统将花费不超过1/(1+n)的时间用于垃圾收集。
3.与CMS收集器相关的参数
   •-XX:+UseConcMarkSweepGC:新生代使用并行收集器,老年代使用CMS+串行收集器。
   •-XX:ParallelCMSThreads:设置CMS的线程数量。
   •-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发,默认68%
   •-XX:UseCMSCompactAtFullCollection:设置CMS在完成垃圾收集后是否要进行一次碎片整理
   •-XX:CMSFullGCBeforeCompaction:设定进行多少次CMS垃圾回收后,进行一次内存压缩。
   •-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收
   •-XX:CMSInitiatingPermOccupancyFraction:当永久代占有率达到这一百分比时,启动CMS回收(前提是-XX:+CMSClassUnloadingEnabled被激活了)
   •-XX:UseCMSInitiatingOccupancyOnly:表示只有在到达阀值的时候才进行CMS回收。
   •-XX:+CMSIncrementalMode:使用增量模式,比较适合单CPU.增量模式在中标记为废弃,jdk9中将彻底移除
4.与G1回收期相关的参数
   •-XX:+UseG1GC:使用G1回收器
   •-XX:+MaxGCPauseMillis:设置最大的垃圾收集停顿时间
   •-XX:+GcPauseIntervalMillis:设置停顿时间间隔。
5.TLAB相关
   •-XX:+UseTLAB:开启TLAB分配。
   •-XX:+PrintTLAB:打印TLAB相关分配信息
   •-XX:TLABSize:设置TLAB大小
   •-XX:+ResizeTLAB:自动调整TLAB大小
6.其他一些参数
   •-XX:+DisableExplicitGC:禁用显式GC
   •-XX:+ExplicitGCInvokesConcurrent:使用并发方式处理显式GC
本文转自:http://www.icesr.com/archives/2653

详解Java GC的工作原理+Minor GC、FullGC

默认分类sdil 发表了文章 • 0 个评论 • 191 次浏览 • 2016-08-07 20:25 • 来自相关话题

JVM内存管理和JVM垃圾回收
JVM内存组成结构

JVM内存结构由堆、栈、本地方法栈、方法区等部分组成,结构图如下所示:




 
1)堆

所有通过new创建的对象的内存都在堆中分配,其大小可以通过-Xmx和-Xms来控制。堆被划分为新生代和旧生代,新生代又被进一步划分为Eden和Survivor区,最后Survivor由FromSpace和ToSpace组成,结构图如下所示:





 
新生代。新建的对象都是用新生代分配内存,Eden空间不足的时候,会把存活的对象转移到Survivor中,新生代大小可以由-Xmn来控制,也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例。旧生代用于存放新生代中经过多次垃圾回收(也即Minor GC)仍然存活的对象

2)栈

每个线程执行每个方法的时候都会在栈中申请一个栈帧,每个栈帧包括局部变量区和操作数栈,用于存放此次方法调用过程中的临时变量、参数和中间结果

3)本地方法栈

用于支持native方法的执行,存储了每个native方法调用的状态

4)方法区

存放了要加载的类信息、静态变量、final类型的常量、属性和方法信息。JVM用持久代(PermanetGeneration)来存放方法区,可通过-XX:PermSize和-XX:MaxPermSize来指定最小值和最大值。介绍完了JVM内存组成结构,下面我们再来看一下JVM垃圾回收机制。

JVM垃圾回收机制

JVM分别对新生代和旧生代采用不同的垃圾回收机制

新生代的GC:

新生代通常存活时间较短,因此基于Copying算法来进行回收,所谓Copying算法就是扫描出存活的对象,并复制到一块新的完全未使用的空间中,对应于新生代,就是在Eden和FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发,指针保持最后一个分配的对象在新生代区间的位置,当有新的对象要分配内存时,用于检查空间是否足够,不够就触发GC。当连续分配对象时,对象会逐渐从eden到survivor,最后到旧生代,

用javavisualVM来查看,能明显观察到新生代满了后,会把对象转移到旧生代,然后清空继续装载,当旧生代也满了后,就会报outofmemory的异常,如下图所示:





 
在执行机制上JVM提供了串行GC(SerialGC)、并行回收GC(ParallelScavenge)和并行GC(ParNew)

1)串行GC

在整个扫描和复制过程采用单线程的方式来进行,适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上,是client级别默认的GC方式,可以通过-XX:+UseSerialGC来强制指定

2)并行回收GC

在整个扫描和复制过程采用多线程的方式来进行,适用于多CPU、对暂停时间要求较短的应用上,是server级别默认采用的GC方式,可用-XX:+UseParallelGC来强制指定,用-XX:ParallelGCThreads=4来指定线程数

3)并行GC

与旧生代的并发GC配合使用

旧生代的GC:

旧生代与新生代不同,对象存活的时间比较长,比较稳定,因此采用标记(Mark)算法来进行回收,所谓标记就是扫描出存活的对象,然后再进行回收未被标记的对象,回收后对用空出的空间要么进行合并,要么标记出来便于下次进行分配,总之就是要减少内存碎片带来的效率损耗。在执行机制上JVM提供了串行GC(SerialMSC)、并行GC(parallelMSC)和并发GC(CMS),具体算法细节还有待进一步深入研究。

以上各种GC机制是需要组合使用的,指定方式由下表所示:






    -  新生代 GC(Minor GC):指发生在新生代的垃圾收集动作,因为 Java 对象大多都具备朝生夕灭的特性,所以 Minor GC 非常频繁,一般回收速度也比较快。     -  老年代 GC(Major GC  / Full GC):指发生在老年代的 GC,出现了 Major GC,经常会伴随至少一次的 Minor GC(但非绝对的,在 ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程) 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然存活,并且能被 Survivor 容纳的话,将被移动到 Survivor 空间中,并将对象年龄设为 1。对象在 Survivor 区中每熬过一次 Minor GC,年龄就增加 1 岁,当它的年龄增加到一定程度(默认为 15 岁)时,就会被晋升到老年代中。对象晋升老年代的年龄阈值,可以通过参数 -XX:MaxTenuringThreshold 来设置。




总结:

堆的初始大小                                       -Xms2g

堆的最大大小                                       -Xmx2g

年轻代初始大小                                   -XX:NewSize=512m 

年轻代最大大小                        -XX:MaxNewSize=512m

控制Eden和Survivor的比例                 -XX:SurvivorRatio                


串行GC(SerialGC)                              -XX:+UseSerialGC                 

并行回收GC(ParallelScavenge)          -XX:+UseParallelGC来强制指定,用-XX:ParallelGCThreads=4来指定线程数

并行GC(ParNew)                                 查看全部
JVM内存管理和JVM垃圾回收
JVM内存组成结构

JVM内存结构由堆、栈、本地方法栈、方法区等部分组成,结构图如下所示:
1.gif

 
1)堆

所有通过new创建的对象的内存都在堆中分配,其大小可以通过-Xmx和-Xms来控制。堆被划分为新生代和旧生代,新生代又被进一步划分为Eden和Survivor区,最后Survivor由FromSpace和ToSpace组成,结构图如下所示:

2.gif

 
新生代。新建的对象都是用新生代分配内存,Eden空间不足的时候,会把存活的对象转移到Survivor中,新生代大小可以由-Xmn来控制,也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例。旧生代用于存放新生代中经过多次垃圾回收(也即Minor GC)仍然存活的对象

2)栈

每个线程执行每个方法的时候都会在栈中申请一个栈帧,每个栈帧包括局部变量区和操作数栈,用于存放此次方法调用过程中的临时变量、参数和中间结果

3)本地方法栈

用于支持native方法的执行,存储了每个native方法调用的状态

4)方法区

存放了要加载的类信息、静态变量、final类型的常量、属性和方法信息。JVM用持久代(PermanetGeneration)来存放方法区,可通过-XX:PermSize和-XX:MaxPermSize来指定最小值和最大值。介绍完了JVM内存组成结构,下面我们再来看一下JVM垃圾回收机制。

JVM垃圾回收机制

JVM分别对新生代和旧生代采用不同的垃圾回收机制

新生代的GC:

新生代通常存活时间较短,因此基于Copying算法来进行回收,所谓Copying算法就是扫描出存活的对象,并复制到一块新的完全未使用的空间中,对应于新生代,就是在Eden和FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发,指针保持最后一个分配的对象在新生代区间的位置,当有新的对象要分配内存时,用于检查空间是否足够,不够就触发GC。当连续分配对象时,对象会逐渐从eden到survivor,最后到旧生代,

用javavisualVM来查看,能明显观察到新生代满了后,会把对象转移到旧生代,然后清空继续装载,当旧生代也满了后,就会报outofmemory的异常,如下图所示:

3.gif

 
在执行机制上JVM提供了串行GC(SerialGC)、并行回收GC(ParallelScavenge)和并行GC(ParNew)

1)串行GC

在整个扫描和复制过程采用单线程的方式来进行,适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上,是client级别默认的GC方式,可以通过-XX:+UseSerialGC来强制指定

2)并行回收GC

在整个扫描和复制过程采用多线程的方式来进行,适用于多CPU、对暂停时间要求较短的应用上,是server级别默认采用的GC方式,可用-XX:+UseParallelGC来强制指定,用-XX:ParallelGCThreads=4来指定线程数

3)并行GC

与旧生代的并发GC配合使用

旧生代的GC:

旧生代与新生代不同,对象存活的时间比较长,比较稳定,因此采用标记(Mark)算法来进行回收,所谓标记就是扫描出存活的对象,然后再进行回收未被标记的对象,回收后对用空出的空间要么进行合并,要么标记出来便于下次进行分配,总之就是要减少内存碎片带来的效率损耗。在执行机制上JVM提供了串行GC(SerialMSC)、并行GC(parallelMSC)和并发GC(CMS),具体算法细节还有待进一步深入研究。

以上各种GC机制是需要组合使用的,指定方式由下表所示:

4.png


    -  新生代 GC(Minor GC):指发生在新生代的垃圾收集动作,因为 Java 对象大多都具备朝生夕灭的特性,所以 Minor GC 非常频繁,一般回收速度也比较快。     -  老年代 GC(Major GC  / Full GC):指发生在老年代的 GC,出现了 Major GC,经常会伴随至少一次的 Minor GC(但非绝对的,在 ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程) 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然存活,并且能被 Survivor 容纳的话,将被移动到 Survivor 空间中,并将对象年龄设为 1。对象在 Survivor 区中每熬过一次 Minor GC,年龄就增加 1 岁,当它的年龄增加到一定程度(默认为 15 岁)时,就会被晋升到老年代中。对象晋升老年代的年龄阈值,可以通过参数 -XX:MaxTenuringThreshold 来设置。




总结:

堆的初始大小                                       -Xms2g

堆的最大大小                                       -Xmx2g

年轻代初始大小                                   -XX:NewSize=512m 

年轻代最大大小                        -XX:MaxNewSize=512m

控制Eden和Survivor的比例                 -XX:SurvivorRatio                


串行GC(SerialGC)                              -XX:+UseSerialGC                 

并行回收GC(ParallelScavenge)          -XX:+UseParallelGC来强制指定,用-XX:ParallelGCThreads=4来指定线程数

并行GC(ParNew)                                

tomcat JVM参数调优

默认分类sdil 发表了文章 • 0 个评论 • 201 次浏览 • 2016-08-07 19:42 • 来自相关话题

一. 堆大小设置
JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;
系统的可用物理内存限制。32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制。我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m。
典型设置:
-Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m:设置JVM最大可用内存为3550M。
-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g:设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。
-Xss128k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

-Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

二. 回收器选择
JVM给了三种选择:串行收集器、并行收集器、并发收集器,但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和并发收集器。默认情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行判断。

1. 吞吐量优先的并行收集器
如上文所述,并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等。
典型配置:
-Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=4
-XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=4:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间,如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开。

2. 响应时间优先的并发收集器
如上文所述,并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC:设置年老代为并发收集。测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明。所以,此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction:由于并发收集器不对内存空间进行压缩、整理,所以运行一段时间以后会产生“碎片”,使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片

3. 辅助信息
JVM提供了大量命令行参数,打印信息,供调试使用。主要有以下一些:
        - -XX:+PrintGC
输出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
        - -XX:+PrintGCDetails
输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs][GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
        - -XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可与上面两个混合使用
输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
        - -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前,程序未中断的执行时间。可与上面混合使用
输出形式:Application time: 0.5291524 seconds
        - -XX:+PrintGCApplicationStoppedTime:打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式:Total time for which application threads were stopped: 0.0468229 seconds
        - -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式:
34.702: [GC {Heap before gc invocations=7:
 def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
 tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
 def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
 tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}, 0.0757599 secs]
        - -Xloggc:filename:与上面几个配合使用,把相关日志信息记录到文件以便分析。
    
三. 常见配置汇总
1. 堆设置
            - -Xms:初始堆大小
            - -Xmx:最大堆大小
            - -XX:NewSize=n:设置年轻代大小
            - -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4
            - -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5
            - -XX:MaxPermSize=n:设置持久代大小
2. 收集器设置
            - -XX:+UseSerialGC:设置串行收集器
            - -XX:+UseParallelGC:设置并行收集器
            - -XX:+UseParalledlOldGC:设置并行年老代收集器
            - -XX:+UseConcMarkSweepGC:设置并发收集器
3. 垃圾回收统计信息
            - -XX:+PrintGC
            - -XX:+PrintGCDetails
            - -XX:+PrintGCTimeStamps
            - -Xloggc:filename
4. 并行收集器设置
            - -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
            - -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
            - -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
5. 并发收集器设置
            - -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
            - -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数。
四、调优总结
 
1. 年轻代大小选择
                - 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择)。在此种情况下,年轻代收集发生的频率也是最小的。同时,减少到达年老代的对象。
                - 吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度。因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用。
2. 年老代大小选择
        - 响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了,可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间。最优化的方案,一般需要参考以下数据获得:
            - 并发垃圾收集信息
            - 持久代并发收集次数
            - 传统GC信息
                - 花在年轻代和年老代回收上的时间比例
                - 减少年轻代和年老代花费的时间,一般会提高应用的效率
                - 吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象。
3. 较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、清除方式进行回收。如果出现“碎片”,可能需要进行如下配置:
               - -XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩。
               - -XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
  查看全部

一. 堆大小设置
JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;
系统的可用物理内存限制。32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制。我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m。
典型设置:
-Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m:设置JVM最大可用内存为3550M。
-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g:设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。
-Xss128k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

-Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

二. 回收器选择
JVM给了三种选择:串行收集器、并行收集器、并发收集器,但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和并发收集器。默认情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行判断。

1. 吞吐量优先的并行收集器
如上文所述,并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等。
典型配置:
-Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=4
-XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=4:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间,如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开。

2. 响应时间优先的并发收集器
如上文所述,并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC:设置年老代为并发收集。测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明。所以,此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction:由于并发收集器不对内存空间进行压缩、整理,所以运行一段时间以后会产生“碎片”,使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片

3. 辅助信息
JVM提供了大量命令行参数,打印信息,供调试使用。主要有以下一些:
        - -XX:+PrintGC
输出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
        - -XX:+PrintGCDetails
输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs][GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
        - -XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可与上面两个混合使用
输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
        - -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前,程序未中断的执行时间。可与上面混合使用
输出形式:Application time: 0.5291524 seconds
        - -XX:+PrintGCApplicationStoppedTime:打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式:Total time for which application threads were stopped: 0.0468229 seconds
        - -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式:
34.702: [GC {Heap before gc invocations=7:
 def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
 tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
 def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
 tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
 compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
   the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
    ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
    rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}, 0.0757599 secs]
        - -Xloggc:filename:与上面几个配合使用,把相关日志信息记录到文件以便分析。
    
三. 常见配置汇总
1. 堆设置
            - -Xms:初始堆大小
            - -Xmx:最大堆大小
            - -XX:NewSize=n:设置年轻代大小
            - -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4
            - -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5
            - -XX:MaxPermSize=n:设置持久代大小
2. 收集器设置
            - -XX:+UseSerialGC:设置串行收集器
            - -XX:+UseParallelGC:设置并行收集器
            - -XX:+UseParalledlOldGC:设置并行年老代收集器
            - -XX:+UseConcMarkSweepGC:设置并发收集器
3. 垃圾回收统计信息
            - -XX:+PrintGC
            - -XX:+PrintGCDetails
            - -XX:+PrintGCTimeStamps
            - -Xloggc:filename
4. 并行收集器设置
            - -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
            - -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
            - -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
5. 并发收集器设置
            - -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
            - -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数。
四、调优总结
 
1. 年轻代大小选择
                - 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择)。在此种情况下,年轻代收集发生的频率也是最小的。同时,减少到达年老代的对象。
                - 吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度。因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用。
2. 年老代大小选择
        - 响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了,可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间。最优化的方案,一般需要参考以下数据获得:
            - 并发垃圾收集信息
            - 持久代并发收集次数
            - 传统GC信息
                - 花在年轻代和年老代回收上的时间比例
                - 减少年轻代和年老代花费的时间,一般会提高应用的效率
                - 吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象。
3. 较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、清除方式进行回收。如果出现“碎片”,可能需要进行如下配置:
               - -XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩。
               - -XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
 

mysql服务器性能优化

默认分类sdil 发表了文章 • 0 个评论 • 194 次浏览 • 2016-08-07 19:37 • 来自相关话题

在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分。

MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数。 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分:

一是服务器物理硬件的优化;

二是MySQL自身(my.cnf)的优化。




一、服务器硬件对MySQL性能的影响

①磁盘寻道能力(磁盘I/O),MySQL每秒钟都在进行大量、复杂的查询操作,对磁盘的读写量可想而知。所以,通常认为磁盘I/O是制约MySQL性能的最大因素之一,对于日均访问量在100万PV以上的web应用,由于磁盘I/O的制约,MySQL的性能会非常低下!解决这一制约因素可以考虑以下几种解决方案: 使用RAID-0+1磁盘阵列,注意不要尝试使用RAID-5,MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快;

②CPU 对于MySQL应用,推荐使用S.M.P.架构的多路对称CPU;

③物理内存对于一台使用MySQL的Database Server来说,服务器内存建议不要小于2GB,推荐使用4GB以上的物理内存。




二、MySQL自身因素当解决了上述服务器硬件制约因素后,让我们看看MySQL自身的优化是如何操作的。 对MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。 由于my.cnf文件的优化设置是与服务器硬件配置息息相关的, 因而我们指定一个假想的服务器硬件环境:CPU: 2颗Intel Xeon 2.4GHz 内存: 4GB DDR 硬盘: SCSI 73GB(很常见的2U server ) 。

下面,我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明:

[mysqld] 
port = 3306 
server id = 1 
socket = /tmp/mysql.sock 
skip-locking 
#避免MySQL的外部锁定,减少出错几率增强稳定性。

 
skip-name-resolve 
#禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项,则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求!


back_log = 384 
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。



key_buffer_size = 256M 
#key_buffer_size指定用于索引的缓冲区大小,增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意:该参数值设置的过大反而会是服务器整体效率降低!



max_allowed_packet = 4M 
thread_stack = 256K 
table_cache = 128K 



sort_buffer_size = 6M 
#查询排序时所能使用的缓冲区大小。注意:该参数对应的分配内存是每连接独占,如果有100个连接,那么实际分配的总共排序缓冲区大小为100 × 6 = 600MB。所以,对于内存在4GB左右的服务器推荐设置为6-8M。



read_buffer_size = 4M 
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。



join_buffer_size = 8M 
#联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。



myisam_sort_buffer_size = 64M 
table_cache = 512 
thread_cache_size = 64 



query_cache_size = 64M 
#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察,如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况;如果Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,如果该值较小反而会影响效率,那么可以考虑不用查询缓冲;Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多。
tmp_table_size = 256M 



max_connections = 768 
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示,则需要增大该参数值。



max_connect_errors = 10000000 
wait_timeout = 10 
#指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。 



thread_concurrency = 8 
#该参数取值为服务器逻辑CPU数量*2,在本例中,服务器有2颗物理CPU,而每颗物理CPU又支持H.T超线程,所以实际取值为4*2=8



skip-networking 
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式,如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项!否则将无法正常连接!



table_cache=1024 
#物理内存越大,设置就越大.默认为2402,调到512-1024最佳 



innodb_additional_mem_pool_size=4M 
#默认为2M 



innodb_flush_log_at_trx_commit=1 
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1 



innodb_log_buffer_size=2M 
#默认为1M 



innodb_thread_concurrency=8 
#你的服务器CPU有几个就设置为几,建议用默认一般为8 



key_buffer_size=256M 
#默认为218,调到128最佳 



tmp_table_size=64M 
#默认为16M,调到64-256最挂 



read_buffer_size=4M 
#默认为64K 
read_rnd_buffer_size=16M 



#默认为256K 
sort_buffer_size=32M 



#默认为256K 
thread_cache_size=120 



#默认为60 
query_cache_size=32M

提升性能的建议:



如果Key_reads太大,则应该把my.cnf中Key_buffer_size变大,可以用 Key_reads/Key_read_requests计算出cache失败率,保持Key_reads/Key_read_requests至少1/100以上,越小越好。




如果Qcache_lowmem_prunes很大,就要增加Query_cache_size的值。


如果opened_tables太大,应该把my.cnf中的table_cache变大。
如果Handler_read_rnd太大,则你写的SQL语句里很多查询都是要扫描整个表,而没有发挥索引的键的作用。
如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用 Threads_created/Connections计算cache命中率。
如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基于内存的临时表代替基 于磁盘的。


另外下面对几个重要的参数进行详细介绍:
key_buffer_size:表示索引缓存的大小。这个值越大,使用索引进行查询的速度就越快;
table_cache:表示同时打开的表的个数。这个值越大,能同时打开的表的个数就越多。这个值不是越大越好,因为同时打开的表过多会影响操作系统的性能;
query_cache_size:表示查询缓冲区的大小。使用查询缓存区可以提高查询的速度。这个方式只使用与修改操作少且经常执行相同的查询操作的情况;默认值是0;
Query_cache_type:表示查询缓存区的开启状态。0表示关闭,1表示开启;
Max_connections:表示数据库的最大连接数。这个连接数不是越大越好,因为连接会浪费内存的资源;
Sort_buffer_size:排序缓存区的大小,这个值越大,排序就越快;
Innodb_buffer_pool_size:表示InnoDB类型的表和索引的最大缓存。这个值越大,查询的速度就会越快。这个值太大了就会影响操作系统的性能;
  查看全部
在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分。

MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数。 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分:

一是服务器物理硬件的优化;

二是MySQL自身(my.cnf)的优化。




一、服务器硬件对MySQL性能的影响

①磁盘寻道能力(磁盘I/O),MySQL每秒钟都在进行大量、复杂的查询操作,对磁盘的读写量可想而知。所以,通常认为磁盘I/O是制约MySQL性能的最大因素之一,对于日均访问量在100万PV以上的web应用,由于磁盘I/O的制约,MySQL的性能会非常低下!解决这一制约因素可以考虑以下几种解决方案: 使用RAID-0+1磁盘阵列,注意不要尝试使用RAID-5,MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快;

②CPU 对于MySQL应用,推荐使用S.M.P.架构的多路对称CPU;

③物理内存对于一台使用MySQL的Database Server来说,服务器内存建议不要小于2GB,推荐使用4GB以上的物理内存。




二、MySQL自身因素当解决了上述服务器硬件制约因素后,让我们看看MySQL自身的优化是如何操作的。 对MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。 由于my.cnf文件的优化设置是与服务器硬件配置息息相关的, 因而我们指定一个假想的服务器硬件环境:CPU: 2颗Intel Xeon 2.4GHz 内存: 4GB DDR 硬盘: SCSI 73GB(很常见的2U server ) 。

下面,我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明:

[mysqld] 
port = 3306 
server id = 1 
socket = /tmp/mysql.sock 
skip-locking 
#避免MySQL的外部锁定,减少出错几率增强稳定性。

 
skip-name-resolve 
#禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项,则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求!


back_log = 384 
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。



key_buffer_size = 256M 
#key_buffer_size指定用于索引的缓冲区大小,增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意:该参数值设置的过大反而会是服务器整体效率降低!



max_allowed_packet = 4M 
thread_stack = 256K 
table_cache = 128K 



sort_buffer_size = 6M 
#查询排序时所能使用的缓冲区大小。注意:该参数对应的分配内存是每连接独占,如果有100个连接,那么实际分配的总共排序缓冲区大小为100 × 6 = 600MB。所以,对于内存在4GB左右的服务器推荐设置为6-8M。



read_buffer_size = 4M 
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。



join_buffer_size = 8M 
#联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。



myisam_sort_buffer_size = 64M 
table_cache = 512 
thread_cache_size = 64 



query_cache_size = 64M 
#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察,如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况;如果Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,如果该值较小反而会影响效率,那么可以考虑不用查询缓冲;Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多。
tmp_table_size = 256M 



max_connections = 768 
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示,则需要增大该参数值。



max_connect_errors = 10000000 
wait_timeout = 10 
#指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。 



thread_concurrency = 8 
#该参数取值为服务器逻辑CPU数量*2,在本例中,服务器有2颗物理CPU,而每颗物理CPU又支持H.T超线程,所以实际取值为4*2=8



skip-networking 
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式,如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项!否则将无法正常连接!



table_cache=1024 
#物理内存越大,设置就越大.默认为2402,调到512-1024最佳 



innodb_additional_mem_pool_size=4M 
#默认为2M 



innodb_flush_log_at_trx_commit=1 
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1 



innodb_log_buffer_size=2M 
#默认为1M 



innodb_thread_concurrency=8 
#你的服务器CPU有几个就设置为几,建议用默认一般为8 



key_buffer_size=256M 
#默认为218,调到128最佳 



tmp_table_size=64M 
#默认为16M,调到64-256最挂 



read_buffer_size=4M 
#默认为64K 
read_rnd_buffer_size=16M 



#默认为256K 
sort_buffer_size=32M 



#默认为256K 
thread_cache_size=120 



#默认为60 
query_cache_size=32M

提升性能的建议:



如果Key_reads太大,则应该把my.cnf中Key_buffer_size变大,可以用 Key_reads/Key_read_requests计算出cache失败率,保持Key_reads/Key_read_requests至少1/100以上,越小越好。




如果Qcache_lowmem_prunes很大,就要增加Query_cache_size的值。


如果opened_tables太大,应该把my.cnf中的table_cache变大。
如果Handler_read_rnd太大,则你写的SQL语句里很多查询都是要扫描整个表,而没有发挥索引的键的作用。
如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用 Threads_created/Connections计算cache命中率。
如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基于内存的临时表代替基 于磁盘的。


另外下面对几个重要的参数进行详细介绍:
key_buffer_size:表示索引缓存的大小。这个值越大,使用索引进行查询的速度就越快;
table_cache:表示同时打开的表的个数。这个值越大,能同时打开的表的个数就越多。这个值不是越大越好,因为同时打开的表过多会影响操作系统的性能;
query_cache_size:表示查询缓冲区的大小。使用查询缓存区可以提高查询的速度。这个方式只使用与修改操作少且经常执行相同的查询操作的情况;默认值是0;
Query_cache_type:表示查询缓存区的开启状态。0表示关闭,1表示开启;
Max_connections:表示数据库的最大连接数。这个连接数不是越大越好,因为连接会浪费内存的资源;
Sort_buffer_size:排序缓存区的大小,这个值越大,排序就越快;
Innodb_buffer_pool_size:表示InnoDB类型的表和索引的最大缓存。这个值越大,查询的速度就会越快。这个值太大了就会影响操作系统的性能;
 

memcached stats参数详解

默认分类sdil 发表了文章 • 0 个评论 • 209 次浏览 • 2016-08-07 00:34 • 来自相关话题

STAT pid 22362//memcache服务器的进程ID
STAT uptime 1469315//服务器已经运行的秒数
STAT time 1339671194//服务器当前的unix时间戳
STAT version 1.4.9//memcache版本
STAT libevent 1.4.9-stable    //libevent版本
STAT pointer_size 64//当前操作系统的指针大小(32位系统一般是32bit,64就是64位操作系统)
STAT rusage_user 3695.485200//进程的累计用户时间
STAT rusage_system 14751.273465//进程的累计系统时间
STAT curr_connections 69//服务器当前存储的items数量
STAT total_connections 855430//从服务器启动以后存储的items总数量
STAT connection_structures 74//服务器分配的连接构造数
STAT reserved_fds 20//
STAT cmd_get 328806688//get命令(获取)总请求次数
STAT cmd_set 75441133//set命令(保存)总请求次数 
STAT cmd_flush 34//flush命令请求次数
STAT cmd_touch 0//touch命令请求次数
STAT get_hits 253547177//总命中次数
STAT get_misses 75259511//总未命中次数
STAT delete_misses 4//delete命令未命中次数
STAT delete_hits 565730//delete命令命中次数
STAT incr_misses 0//incr命令未命中次数
STAT incr_hits 0//incr命令命中次数
STAT decr_misses 0//decr命令未命中次数
STAT decr_hits 0//decr命令命中次数
STAT cas_misses 0//cas命令未命中次数
STAT cas_hits 0//cas命令命中次数
STAT cas_badval 0//使用擦拭次数
STAT touch_hits 0//touch命令未命中次数
STAT touch_misses 0//touch命令命中次数
STAT auth_cmds 0//认证命令处理的次数
STAT auth_errors 0//认证失败数目
STAT bytes_read 545701515844//总读取字节数(请求字节数)
STAT bytes_written 1649639749866//总发送字节数(结果字节数)
STAT limit_maxbytes 2147483648//分配给memcache的内存大小(字节)
STAT accepting_conns 1//服务器是否达到过最大连接(0/1)
STAT listen_disabled_num 0//失效的监听数
STAT threads 4//当前线程数
STAT conn_yields 14//连接操作主动放弃数目
STAT hash_power_level 16//
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT expired_unfetched 30705763
STAT evicted_unfetched 0
STAT bytes 61380700//当前存储占用的字节数
STAT curr_items 28786//当前存储的数据总数
STAT total_items 75441133//启动以来存储的数据总数
STAT evictions 0//为获取空闲内存而删除的items数(分配给memcache的空间用满后需要删除旧的items来得到空间分配给新的items)
STAT reclaimed 39957976//已过期的数据条目来存储新数据的数目
END 查看全部

STAT pid 22362//memcache服务器的进程ID
STAT uptime 1469315//服务器已经运行的秒数
STAT time 1339671194//服务器当前的unix时间戳
STAT version 1.4.9//memcache版本
STAT libevent 1.4.9-stable    //libevent版本
STAT pointer_size 64//当前操作系统的指针大小(32位系统一般是32bit,64就是64位操作系统)
STAT rusage_user 3695.485200//进程的累计用户时间
STAT rusage_system 14751.273465//进程的累计系统时间
STAT curr_connections 69//服务器当前存储的items数量
STAT total_connections 855430//从服务器启动以后存储的items总数量
STAT connection_structures 74//服务器分配的连接构造数
STAT reserved_fds 20//
STAT cmd_get 328806688//get命令(获取)总请求次数
STAT cmd_set 75441133//set命令(保存)总请求次数 
STAT cmd_flush 34//flush命令请求次数
STAT cmd_touch 0//touch命令请求次数
STAT get_hits 253547177//总命中次数
STAT get_misses 75259511//总未命中次数
STAT delete_misses 4//delete命令未命中次数
STAT delete_hits 565730//delete命令命中次数
STAT incr_misses 0//incr命令未命中次数
STAT incr_hits 0//incr命令命中次数
STAT decr_misses 0//decr命令未命中次数
STAT decr_hits 0//decr命令命中次数
STAT cas_misses 0//cas命令未命中次数
STAT cas_hits 0//cas命令命中次数
STAT cas_badval 0//使用擦拭次数
STAT touch_hits 0//touch命令未命中次数
STAT touch_misses 0//touch命令命中次数
STAT auth_cmds 0//认证命令处理的次数
STAT auth_errors 0//认证失败数目
STAT bytes_read 545701515844//总读取字节数(请求字节数)
STAT bytes_written 1649639749866//总发送字节数(结果字节数)
STAT limit_maxbytes 2147483648//分配给memcache的内存大小(字节)
STAT accepting_conns 1//服务器是否达到过最大连接(0/1)
STAT listen_disabled_num 0//失效的监听数
STAT threads 4//当前线程数
STAT conn_yields 14//连接操作主动放弃数目
STAT hash_power_level 16//
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT expired_unfetched 30705763
STAT evicted_unfetched 0
STAT bytes 61380700//当前存储占用的字节数
STAT curr_items 28786//当前存储的数据总数
STAT total_items 75441133//启动以来存储的数据总数
STAT evictions 0//为获取空闲内存而删除的items数(分配给memcache的空间用满后需要删除旧的items来得到空间分配给新的items)
STAT reclaimed 39957976//已过期的数据条目来存储新数据的数目
END