内存占用情况查询
检查系统内存使用情况以 GiB 为单位进行显示
remotecmd "free -g"
1. total: 物理内存总量(GiB)。
2. used: 当前已使用的物理内存量(不包括缓冲区和缓存)(GiB)。
3. free: 可用的物理内存量(GiB)。
4. shared: 被多个进程共享的内存量(GiB)。
5. buff/cache: 作为文件系统缓存或内核缓冲区而保留的物理内存量(GiB)。
6. available: 在新应用程序启动时可以立即分配给用户的空闲内存量(GiB),这是由 free 和 buff/cache 的值计算得出的。
示例结果可能如下所示:
$ remotecmd "free -g" total used free shared buff/cache available Mem: 79 10 68 0 1 67 Swap: 0 0 0
上述示例数据含义介绍
共有 79GB 的物理内存
其中 10GB 正在使用中
还有 68GB 可用
没有任何共享内存 (shared)
大约 1GB 用于文件系统缓存和内核缓冲区 (buff/cache)
并且可供新的应用使用 67GB 左右的空闲内存 (available)
没有交换分区 (swap) 使用。
内存占用结果说明
linux系统上free命令看到的buff/cache到底是什么
-
buff/cache是buffers和cache之和
-
buff是内核缓冲区用到的内存,对应的是/proc/meminfo 中的 Buffers 值,是对原始磁盘块的临时存储,也就是用来缓存磁盘的数据,一般不会特别大(20MB 左右),它既可以用作“将要写入磁盘数据的缓存”,也可以用作“从磁盘读取数据的缓存”。
-
cache是内核页缓存和Slab用到的内存,对应的是/proc/meminfo中的Cached与SReclaimable之和,不过它既可以用作“从文件读取数据的页缓存”,也可以用作“写文件的页缓存”
-
buff是对磁盘数据的缓存,而 cache是文件数据的缓存,它们既会用在读请求中,也会用在写请求中。
-
SReclaimable 是 Slab 的一部分,是可以被回收的,例如缓存
-
linux内核使用 Slab 机制,管理文件系统的目录项和索引节点的缓存。Slab 包括两部分,其中的可回收部分,是指可以被回收的内核内存,包括目录项(dentry) 和索引节点( inode )的缓存等,用 SReclaimable 记录;而不可回收部分,用 SUnreclaim 记录。
总结
-
buff/cache表示的是文件缓存cache、块缓存buffer以及文件系统目录项和索引节点的缓存SReclaimable之和,强调的是可以被系统回收的内容
-
读写文件时,会把文件内容缓存到内存cache中,提高读写效率
-
读写磁盘时,会把内容缓存到内存buffer中,提高读写效率
-
当内存不够时,buff和cache是可以被系统回收的,当然我们也可以使用drop cache的命令手动回收,不过可能会导致脏页同步到磁盘带来的磁盘IO变高
清理系统缓存
清理指令:
sync
echo 1 >/proc/sys/vm/drop_caches
echo 2 >/proc/sys/vm/drop caches
echo 3 >/proc/sys/vm/drop_caches
上述 Linux 命令用于清理系统缓存:
1. echo 1 > /proc/sys/vm/drop_caches - 清除 page cache,这将释放已被应用程序使用的内存页并返回给操作系统。
2. echo 2 > /proc/sys/vm/drop_caches - 清除 dentries 和 inodes 的 cache,这有助于在不重启机器的情况下重新挂载文件系统或修复某些错误(如 "No space left on device")。
3. echo 3 > /proc/sys/vm/drop_caches - 执行前面两项命令中的全部操作,即完全清空所有可用的 cache。
注意:使用此类命令时要小心,因为它们会立即释放大量可用 RAM,并且可能对正在运行的应用和服务产生负面影响。因此,只有在必要且可以承担后果时才应该执行这些操作。
总结
总的来说针对内存占用问题,不能把清理缓存作为最优解,根除问题还是要从程序优化下手。
要多维度分析原因,对症下药,可能的根因如下:
1. 存在大量未处理的账单项:检查代码是否正确地从数据库查询、过滤和排序账单项,然后将它们存储在 acctItemList 中。如果账单项数量过多,则可能会占用太多的堆空间。
2. 没有及时清理垃圾:在某些情况下,应用程序没有正确释放不需要使用的对象的引用,造成了内存泄漏。通过使用 JVM 参数 -XX:+UseG1GC 或 -XX:+CMSClassUnloadingEnabled 来启用 Garbage Collection (GC) 和类卸载功能可以帮助检测和修复此问题。
3. 使用了超大的集合类型:例如 HashMap 或 HashSet,其初始大小设置得很小,而随着数据的增加,它们会迅速膨胀。可以通过调整集合类型的初始大小来避免此问题。
4. 创建了大型对象:如果创建了一个非常大的对象,并且该对象不能被 GC 立即回收,那么也会消耗掉大部分可用的堆空间。
要解决此问题,您可以尝试以下方法之一:
1. 优化代码逻辑:仔细检查您的代码,找出哪里正在生成大量的账单项或者其他大型对象。根据需求进行修改,使其更高效且不会对堆内存产生如此大的压力。
2. 增大堆内存:您可以使用 JVM 参数 -Xmx 指定最大堆大小,其中 是所需的值,单位通常为 GB。例如,-Xmx4g 表示将最大堆大小设置为 4GB。
3. 实施垃圾收集策略:启用适用于您的应用场景的 GC 算法,例如 G1GC (-XX:+UseG1GC) 或 CMS (-XX:+CMSClassUnloadingEnabled)。这些算法旨在更好地管理堆内存并减少碎片化。
4. 监控和分析:使用 Java Virtual Machine Monitoring Tools (JVisualVM, JConsole, etc.) 对您的应用进行性能分析和诊断。这将帮助您识别潜在的问题并找到最佳的解决方案。 请注意,以上只是一些常见的方法,您还应该根据您的特定情况进行调试和测试。