查看某个进程的占用内存情况(以‘device_maintenance’为例)
1.查找进程号
ps -ef | grep 'device_maintenance' 或 ps -aux | grep 'device_maintenance'
2.查看服务器整体内存占用情况1
3.查看服务器整体内存占用情况2
free -h
total: 内存总数 used: 已经使用内存数 free: 完全空闲内存 shared: 多个进程共享的内存 buffers: 用于块设备数据缓冲，记录文件系统metadata（目录，权限，属性等) cached: 用于文件内容的缓冲 available：真正剩余的可被程序应用的内存数
查看进程动态列表
// An highlighted block top使用Shift + M 排序
查看占用率高的进程PID，强制关闭进程// An highlighted block sudo kill -9 PID
1，内存耗用过高现象
如下图所示，ECS 服务器，系统物理内存8G，实际使用7.7G，占用达到96%。
但实际进程占用的内存加起来远远达不到这么高的占用。
2，问题分析
https://blog.csdn.net/Witch_Soya/article/details/54980680
https://blog.csdn.net/duanxianling/article/details/8167356
以上文章反映的问题与本文所述问题非常相似。
该文认为极有可能是SQLServer数据库占用内存过多。
3，问题处理
把最大服务器内存改成1G，确定后内存就会被强制释放，然后把最大服务器内存改成合适的值3072。服务器内存占用降为83%，降至正常耗用范围。
转载于:https://www.cnblogs.com/jackkwok/p/11062915.html
记一次服务器内存占用过高导致的简单JVM调优
继安装GPE分布式监控系统对服务器进行监控之后，陆续发现服务器内存占用率很高。有时间就对服务器上的应用进行逐一排查。
1.查看服务器状态
使用top命令看了下系统的状态：
top -c看到系统的整体负载和cpu并不高，但是内存使用比较高（15.6/16），遂使用M进行内存占用排序
可以看到其中占用内存较大的应用均为java应用，而且应用数量有20+，每个java应用的启动参数设置的都比较大。导致服务器内存占用很高。
如何在保证应用正常使用的同时，减小应用占用内存，修改启动参数，成为了解决问题的关键。2.优化-Xms，-Xmx参数
我们首先选用内存占用比例最高的PID：32477的java应用来进行分析，我们看到在启动参数中该应用配置的启动参数为
-Xms2048m -Xmx2048m堆内存分配了2个G，那么怎么确定应用是否用到了这么大的堆内存呢?
第一步
我们jstat命令来查看一下JVM的GC情况，并通过GC信息来确定下一步优化的侧重点：
#即会每5秒一次显示进程号为32477的java进成的GC情况,一共显示5次 jstat -gc 32477 5000 5结果如下图：
YGC平均耗时： 0.353s/9=0.8msFGC平均耗时：基本为0
平均大约40ms才会产生一次YGC
看起来似乎不错，YGC触发的频率不高，FGC的耗时也不高，但这样的内存设置是不是有些太浪费呢？(后续可以使用jmap工具强制触发FullGC来观察FullGC之后的老年代存活对象大小，使用命名
jmap -dump:live,format=b,file=heap.bin <pid>)第二步
我们再使用jmap工具来查看堆内存使用情况
jmap -heap 32477结果如下图：
可以看到老年代的内存占用仅为50M左右。那么根据老年代内存占用我们应该怎么分配堆内存设置呢，依据的原则是根据Java Performance里面的推荐公式来进行设置。
具体来讲：
Java整个堆大小设置，Xmx 和 Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍
永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍。
年轻代Xmn的设置为老年代存活对象的1-1.5倍。
老年代的内存大小设置为老年代存活对象的2-3倍。
按照上述规则，按照整个堆大小是老年代（FullGC）之后的3-4倍计算的话，设置各代的内存应该情况如下：
Xmx=512m Xms=256m Xmn=64m PermSize=64m老年代的大小为 （256-64=192m）为老年代存活对象大小的3倍左右
3.优化-XX:MetaspaceSize，-XX:MaxMetaspaceSize参数
MetaspaceSize含义
MetaspaceSize容量触发FGC的阈值。比如-XX:MetaspaceSize=256m，当MetaspaceSize容量超过256M时触发FGC，超过设定阈值后MetaspaceSize每扩容一次触发一次FGC；
第一步
我们jstat命令来查看一下JVM的Meta区使用率，并通过来Meta区使用率确定参数配置是否合理：
jstat -gcutil 32477结果如下图：
第二步
然后，再通过
jstat -gc 32477 5000 5命令查看，结果如下图所示，计算MU/MC即Meta区的使用率确实达到了23.12%，但是MC，即Metaspace Capacity只有322304k，并不是参数MetaspaceSize指定的512m，结果如下图：
通过以上结果，我们可以发现MetaspaceSize容量设置的过大，导致Meta区使用率太低，浪费了比较多的堆内存。并取消了-XX:InitialBootClassLoaderMetaspaceSize参数的配置（或随着MetaspaceSize的内存分配减少而减少，普通项目配置为64M即可）。修改后的Meta参数配置为：
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256mInitialBootClassLoaderMetaspaceSize
64位下默认4M，32位下默认2200K，metasapce前面已经提到主要分了两大块，Klass Metaspace以及NoKlass Metaspace，而NoKlass Metaspace是由一块块内存组合起来的，这个参数决定了NoKlass Metaspace的第一个内存Block的大小，即2*InitialBootClassLoaderMetaspaceSize，同时为bootstrapClassLoader的第一块内存chunk分配了InitialBootClassLoaderMetaspaceSize的大小。
设置建议
MetaspaceSize和MaxMetaspaceSize设置一样大；
MetaspaceSize值建议设置为应用稳定运行后1.2-1.5倍,对于大部分项目256m即可.
4.输出GC日志，并使用GC工具查看应用GC情况
通过GC日志可视化分析工具，我们可以很方便的看到JVM各个分代的内存使用情况、垃圾回收次数、垃圾回收的原因、垃圾回收占用的时间、吞吐量等，这些指标在我们进行JVM调优的时候是很有用的，这里我们选用GCeasy。
GCeasy介绍
官网地址：https://gceasy.io/，GCeasy是一款在线的GC日志分析器，可以通过GC日志分析进行内存泄露检测、GC暂停原因分析、JVM配置建议优化等功能，而且是可以免费使用的（有一些服务是收费的）。第一步
设置GC日志输出参数，在应用启动时，加入对GC日志打印的语句。
GC参数
JVM的GC日志的主要参数包括如下几个：
-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2017-09-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:…/logs/gc.log 日志文件的输出路径
修改应用启动脚本,加入如下启动配置：
-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log启动应用，在jar包的同级目录获得gc日志文件gc.log
第二步
将上述获得的日志文件导入第三方GC日志分析器：
JVM的各个分代区域分配的内存及使用峰值的内存
关键性能指标：吞吐量及GC暂停平均时间、最大时间、各个时间段的比例。
内存泄漏及fullGC异常
GC发生的原因、次数、时间等
4.修改启动参数后，对结果进行验证
经过上述修改，可以看到GPE上内存占用有比较明显的下降。
总结：
在内存相对紧张的情况下，可以按照上述的方式来进行内存的调优， 找到一个在GC频率和GC耗时上都可接受的一个内存设置，可以用较小的内存满足当前的服务需要
但当内存相对宽裕的时候，可以相对给服务多增加一点内存，可以减少GC的频率，GC的耗时相应会增加一些。 一般要求低延时的可以考虑多设置一点内存， 对延时要求不高的，可以按照上述方式设置较小内存。
