微软发布了新的终端程序，可多选项卡
|
体分为两个步骤： 1、释放内存：释放 PageCache 内存，保证新的空闲内存尽可能连续，具体的处理措施是 echo1 > /proc/sys/vm/drop_cache 2、保留一定空闲内存：目的是避免内存的不断申请和回收，导致内存碎片化再次变得严重，具体处理措施是限制 PageCache 的大小（这里依赖 tlinux 的实现），具体的命令是 echo36 > /proc/sys/vm/pagecache_limit_ratio 优化效果
经过上述的优化之后，系统的空闲内存分布如下： 化方案
明确了当前的问题后，那么接下来重点就是考虑将碎片化的内存变成连续内存。前文我们明确了当前 ES 节点的内存主要有两部分组成，分别是 JVM 内存和 PageCache 内存，并且在我们现网环境中，这两部分内存基本上是独立的（当前现网机器内存有两个 NODE，每个 NODE 占了一半的物理内存，其中 JVM 和 PageCache 分布在不同的 NODE 上），这就意味着我们可 优化效果采用 MMap+Nio 的方式后，通过测试验证：
采用 MMap+Nio 组合方式上线后，对应现网写成功率由 99.85%提升到 99.99%。 三、高阶内存优化问题分析
在系统运行一段时间后，现网的成功率逐渐降低，由 99.99%降低到 99.97%，对应接入层的超时失败也相应增多，有了之前的经验，我们相应查看了 ES 节点的负载情况，发现仍然有 CPU 抖动的现象（如下图）。考虑到之前已经优化了内存回收慢的问题，此时应是新的问题导致的 CPU 抖动，于是接下来优化点依旧是解决抖动。 采用 NIO 方式访问文件，PageCache 内存只被操作系统维护，则内核可以及时回收 PageCache 以保证足够的内存使用，这样就解决了内存不足问题，进而解决 CPU 抖动问题，从而提高读写成功率；
但是采用 NIO 访问文件也存在问题，即数据会多一次内存复制，会导致延迟方面比 MMap 方式的高，经过测试发现延迟会高 30%左右，这样的结果也不是我们想要的，于是我们考虑将两者结合起来，目的是加快内存回收的同时降低延迟，采取的策略是根据访问频率来确定文件的读写方式（即高频采用 MMap 方式，这样可以保证延迟低，低频采用 Nio 方式，这样可以加快内核回收 PageCache），具体不同文件类型读取方式如下表： （编辑：鹤壁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
