本文探讨了Swap机制对实时响应敏感的应用造成的性能问题。通过一个具体的案例分析，揭示了当Swap空间几乎耗尽时，应用程序的垃圾回收过程显著延长，进而导致服务器负载异常升高的现象。文章还提供了解决方案，包括关闭Swap机制和配置特定的JVM参数来提高应用稳定性。
源：http://blog.hesey.net/2014/05/swap-impact-on-rt-sensitive-apps.html
评：
最近排查的一个线上应用load高的问题，和GC以及Swap有关系。
现象是机器load突然升高，查看占用CPU的线程发现是JVM自己的线程。
jstat发现一个奇怪的现象，Eden Gen到了100%之后会持续好几秒，但Old Gen没有明显增大，说明并不是Eden Gen不够用promote到Old Gen了，感觉似乎是Young GC出了问题。
进一步查看GC Log，发现一次Young GC要1秒多，正常情况下20~30ms都应该结束了。
然而仔细去看那条log会发现CPU消耗并不高：
[Times: user=0.23 sys=0.00, real=1.31 secs]
多出来的时间如果不在CPU上，那就是耗在了I/O上了，GC的I/O不会在网络上，只能是磁盘了。
free -m看了下，果然Swap的空间快被用满了都。
在排查到最终的内存原因前，先把Swap关掉：
sudo swapoff -a
对于Web应用等对响应时间(rt)非常敏感的系统来说，关闭Swap通常都是一个好的实践。
因为一般来说宁愿应用OOM挂掉也不愿意导致rt飙高，使得应用hang在那里的。
另外建议开启这两个参数：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=path
帮助你在发生OOM时dump heap，一般这时候的heap dump质量都比较高：）
Written by Hesey Wang in: Java,Linux,技术 |
一条评论 »
diwayou
swap绝对是隐患啊，线上一般都是关闭的
[回复]
评：
最近排查的一个线上应用load高的问题，和GC以及Swap有关系。
现象是机器load突然升高，查看占用CPU的线程发现是JVM自己的线程。
jstat发现一个奇怪的现象，Eden Gen到了100%之后会持续好几秒，但Old Gen没有明显增大，说明并不是Eden Gen不够用promote到Old Gen了，感觉似乎是Young GC出了问题。
进一步查看GC Log，发现一次Young GC要1秒多，正常情况下20~30ms都应该结束了。
然而仔细去看那条log会发现CPU消耗并不高：
[Times: user=0.23 sys=0.00, real=1.31 secs]
多出来的时间如果不在CPU上，那就是耗在了I/O上了，GC的I/O不会在网络上，只能是磁盘了。
free -m看了下，果然Swap的空间快被用满了都。
在排查到最终的内存原因前，先把Swap关掉：
sudo swapoff -a
对于Web应用等对响应时间(rt)非常敏感的系统来说，关闭Swap通常都是一个好的实践。
因为一般来说宁愿应用OOM挂掉也不愿意导致rt飙高，使得应用hang在那里的。
另外建议开启这两个参数：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=path
帮助你在发生OOM时dump heap，一般这时候的heap dump质量都比较高：）
Written by Hesey Wang in: Java,Linux,技术 |
一条评论 »
diwayou
swap绝对是隐患啊，线上一般都是关闭的
[回复]
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
