不同的linux页面caching行为为服务器做同样的工作

我有两组服务器（128位内存），它们在configuration时会有区别，在运行完全相同的守护进程（elasticsearch）时performance得非常不同。 我正在使用elasticsearch进行全文search，而不是日志存储，所以这个基本上只需要很less的写操作（小于1MB / s）的读操作。 这个守护进程mmap将大约350GB的完整数据集放入其虚拟内存中，然后访问它的某些部分来处理请求。 这些服务器没有configuration交换空间。

问题是一组服务器运行良好，每秒发出大约50个重大故障，平均需要10MB / s的磁盘IO来满足这个需求。 性能不佳的服务器每秒可以看到500个重大故障，平均需要200MB / s的磁盘来满足这个要求。 磁盘IO的增加导致较差的p95响应延迟和偶然的过载，因为它达到约550MB / s的磁盘限制。

他们都坐在同一个负载平衡器后面，并且是同一个集群的一部分。 我可以看到，如果一台服务器的性能不好，可能是负载的差异，但是与16台服务器的性能差别很大，20台服务器的性能不错，在不同的时间内，它们被淘汰+供应，内核/configuration级别必须引起问题。

为了解决这个问题，我该如何让这些performance不佳的服务器像那些performance良好的服务器一样行事？ debugging工作应该集中在哪里？

• 在服务器2008 SP2上慢速读取SSD
• 实时IIS监控
• 使用apache日志测量和可视化Web应用程序的性能？
• 新鲜的NGINX安装非常低的请求/秒
• 命令行速度testing

下面是我收集的一些数据，用来查看系统在三种状态中的每种状态下的sar和page-types工具的function。

软件： – debian jessie – linux 4.9.25 – elasticsearch 5.3.2 – openjdk 1.8.0_141

首先从一个performance良好的服务器（来自sar -B ）的一些页面错误数据：

 07:55:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff 08:05:01 PM 3105.89 811.60 2084.40 48.16 3385.30 0.00 0.00 810.35 0.00 08:15:01 PM 4317.65 665.28 910.29 57.03 3160.14 0.00 0.00 1047.14 0.00 08:25:01 PM 3132.84 648.48 868.41 50.00 2899.14 0.00 0.00 801.27 0.00 08:35:01 PM 2940.02 1026.47 2031.69 45.26 3418.65 0.00 0.00 764.05 0.00 08:45:01 PM 2985.72 1011.27 744.34 45.78 2796.54 0.00 0.00 817.23 0.00 08:55:01 PM 2970.14 588.34 858.08 47.65 2852.33 0.00 0.00 749.17 0.00 09:05:01 PM 3489.23 2364.78 2121.48 47.13 3945.93 0.00 0.00 1145.02 0.00 09:15:01 PM 2695.48 594.57 858.56 44.57 2616.84 0.00 0.00 624.13 0.00 

这是一个performance不佳的服务器：

 07:55:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff 08:05:01 PM 268547.64 1223.73 5266.73 503.12 71836.18 0.00 0.00 67170.50 0.00 08:15:01 PM 279865.31 944.04 3995.52 520.17 74231.90 0.00 0.00 70000.23 0.00 08:25:01 PM 265806.75 966.55 3747.43 499.45 70443.49 0.00 0.00 66407.62 0.00 08:35:01 PM 251820.93 1831.04 4689.62 475.43 67445.29 0.00 0.00 63056.35 0.00 08:45:01 PM 236055.04 1022.32 3498.37 449.37 62955.37 0.00 0.00 59042.16 0.00 08:55:01 PM 239478.40 971.98 3523.61 451.76 63856.04 0.00 0.00 59953.38 0.00 09:05:01 PM 232213.81 1058.04 4436.75 437.09 62194.61 0.00 0.00 58100.47 0.00 09:15:01 PM 216433.72 911.94 3192.28 413.23 57737.62 0.00 0.00 54126.78 0.00 

我怀疑这是由于页面回收的LRU部分performance不佳。 如果我while true; do echo 1 > /proc/sys/vm/drop_caches; sleep 30; done跑了 while true; do echo 1 > /proc/sys/vm/drop_caches; sleep 30; done while true; do echo 1 > /proc/sys/vm/drop_caches; sleep 30; done ，所有非mmaped页面，将有一个磁盘io的初始尖峰，但约30分钟后，它会安顿下来。 我在所有的服务器上运行了大约48个小时，以validation它在日常负载高峰和低点下都会显示同样的IO减less。 它做了。 Sar现在报告如下：

 12:55:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff 01:05:01 PM 121327.14 1482.09 2277.40 140.25 32781.26 0.00 0.00 1764.61 0.00 01:15:01 PM 109911.39 1334.51 1057.51 130.53 31095.68 0.00 0.00 1121.39 0.00 01:25:01 PM 126500.69 1652.51 1216.76 143.07 35830.38 0.00 0.00 2801.84 0.00 01:35:01 PM 132669.45 1857.62 2309.86 148.47 36735.79 0.00 0.00 3181.19 0.00 01:45:01 PM 126872.04 1451.94 1062.94 145.68 34678.26 0.00 0.00 992.60 0.00 01:55:01 PM 121002.21 1818.32 1142.16 139.40 34168.53 0.00 0.00 1640.18 0.00 02:05:01 PM 121824.18 1260.22 2319.56 142.80 33254.67 0.00 0.00 1738.25 0.00 02:15:02 PM 120768.12 1100.87 1143.36 140.20 34195.15 0.00 0.00 1702.83 0.00 

主要的页面错误已经被削减到先前值的1/3。 从磁盘带入的页面减less了一半。 这将磁盘IO从〜200MB / s降低到〜100MB / s，但性能良好的服务器仍然只有50个主要故障，而且只需要做〜10MB / s的磁盘IO。

为了看看LRUalgorithm的工作原理，我使用了内核中的页面types工具。 这是一个performance良好的服务器（从page-types | awk '$3 > 1000 { print $0 }' | sort -nk3 ）：

  flags page-count MB symbolic-flags long-symbolic-flags 0x0000000000000828 257715 1006 ___U_l_____M______________________________ uptodate,lru,mmap 0x0000000000000080 259789 1014 _______S__________________________________ slab 0x000000000000006c 279344 1091 __RU_lA___________________________________ referenced,uptodate,lru,active 0x0000000000000268 305744 1194 ___U_lA__I________________________________ uptodate,lru,active,reclaim 0x0000000000100000 524288 2048 ____________________n_____________________ nopage 0x000000000000082c 632704 2471 __RU_l_____M______________________________ referenced,uptodate,lru,mmap 0x0000000000000000 763312 2981 __________________________________________ 0x0000000000000068 2108618 8236 ___U_lA___________________________________ uptodate,lru,active 0x000000000000086c 6987343 27294 __RU_lA____M______________________________ referenced,uptodate,lru,active,mmap 0x0000000000005868 8589411 33552 ___U_lA____Ma_b___________________________ uptodate,lru,active,mmap,anonymous,swapbacked 0x0000000000000868 12513737 48881 ___U_lA____M______________________________ uptodate,lru,active,mmap total 34078720 133120 

这是一个性能不佳的服务器：

  flags page-count MB symbolic-flags long-symbolic-flags 0x0000000000100000 262144 1024 ____________________n_____________________ nopage 0x0000000000000828 340276 1329 ___U_l_____M______________________________ uptodate,lru,mmap 0x000000000000086c 515691 2014 __RU_lA____M______________________________ referenced,uptodate,lru,active,mmap 0x0000000000000028 687263 2684 ___U_l____________________________________ uptodate,lru 0x0000000000000000 785662 3068 __________________________________________ 0x0000000000000868 7946840 31042 ___U_lA____M______________________________ uptodate,lru,active,mmap 0x0000000000005868 8588629 33549 ___U_lA____Ma_b___________________________ uptodate,lru,active,mmap,anonymous,swapbacked 0x0000000000000068 14133541 55209 ___U_lA___________________________________ uptodate,lru,active total 33816576 132096 

下面是循环drop_caches命令时的样子：

  flags page-count MB symbolic-flags long-symbolic-flags 0x0000000000100000 262144 1024 ____________________n_____________________ nopage 0x0000000000000400 394790 1542 __________B_______________________________ buddy 0x0000000000000000 761557 2974 __________________________________________ 0x0000000000000868 1451890 5671 ___U_lA____M______________________________ uptodate,lru,active,mmap 0x000000000000082c 3123142 12199 __RU_l_____M______________________________ referenced,uptodate,lru,mmap 0x0000000000000828 5278755 20620 ___U_l_____M______________________________ uptodate,lru,mmap 0x0000000000005868 8622864 33683 ___U_lA____Ma_b___________________________ uptodate,lru,active,mmap,anonymous,swapbacked 0x000000000000086c 13630124 53242 __RU_lA____M______________________________ referenced,uptodate,lru,active,mmap total 33816576 132096 

事情尝试：

• 增加/ proc / sys / vm / vfs_cache_pressure到150到10000之间的各种值。这不会影响IO或page-types报告的数据，这是合理的，因为这平衡了内核结构vs用户页面，我的问题是不同的用户页面
• 增加/ proc / sys / vm / swappiness。 没想到这个事情做了什么，也没有，但没有伤到检查。
• 禁用mmap（而不是使用基于epoll的java的nio）。 这就立即使服务器的IO使用看起来就像在IO使用方面performance良好。 这里的缺点是系统CPU与系统IO有关，10MB / s占用1.5％，偶尔负载高达100MB / s，IO系统CPU占用5％到10％。 在一个32位的核心服务器上，1.5到3个cpu完全用来处理epoll。 nio的延迟也比较差（与性能良好的mmap服务器相比）。 这是一个合理的解决scheme，但它是一个阴谋，不知道究竟是哪里出了问题。
• 无数个小时的时间，使用perf工具在堆栈轨迹上徘徊，火焰图，并寻找内核行为的差异。 如果有任何见解获得的话
• 检查磁盘预读设置在不同的服务器上是相同的。 raid0在性能​​不佳的服务器上默认为2048块，性能良好的服务器raid0默认为256块。 使用blockdev --setra差的服务器更新到256， blockdev --setra不会影响IO行为。
• 用numactl --interleave=all启动jvm，以确保问题与两个numa节点之间的平衡无关。 没有区别。
• 使用vmtouch进行validation， vmtouch基本上使用mincore(2)来询问内核是否caching文件，99％以上的缓冲内存正在用于文件系统elasticsearch存储数据。 从上面的三个案例都是如此。
• 通过fuser -m进行validation，elasticsearch是使用文件系统elasticsearch存储数据的唯一过程。

要很快testing：

• 我将在下周重新configuration一台运行exception的服务器，但我并不乐观，这将会产生很大的影响。 在这个configuration期间，我还更新了将LVM放在它前面的raidarrays。 不期待任何不同于LVM的东西，但删除一个variables似乎是值得的。