我有两组带有 128G 内存的服务器，根据配置时间进行区分，它们在运行完全相同的守护进程 (elasticsearch) 时表现非常不同。我使用 elasticsearch 进行全文搜索，而不是日志存储，因此这基本上是一个读取繁重的操作，写入很少（小于 1MB/s）。此守护进程将约 350GB 的完整数据集映射到其虚拟内存中，然后访问其中的某些部分以处理请求。这些服务器没有配置交换空间。
问题是一组服务器表现良好，每秒发生约 50 次重大故障，平均需要 10MB/s 的磁盘 io 才能满足这一需求。性能不佳的服务器每秒发生 500 次重大故障，平均需要约 200MB/s 的磁盘 io 才能满足这一需求。磁盘 io 的增加导致 p95 响应延迟不佳，并偶尔出现过载，因为它达到了约 550MB/s 的磁盘限制。
它们都位于同一个负载平衡器后面，并且是同一个集群的一部分。我可以看到，如果一台服务器表现不佳，可能是负载不同，但是 16 台服务器表现不佳，20 台服务器表现良好，而且是在不同时间购买和配置的，因此内核/配置级别一定存在问题。
回到问题，我怎样才能让这些行为不佳的服务器表现得像那些行为良好的服务器一样？调试工作应该集中在哪里？
下面是我收集的一些数据，用于查看系统在三个状态下通过sar和工具执行的操作。page-types
软件： - debian jessie - linux 4.9.25 - elasticsearch 5.3.2 - openjdk 1.8.0_141
首先是来自运行良好的服务器的一些页面错误数据（来自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
以下是其中一台性能不佳的服务器：
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 部分性能不佳造成的。如果我运行while true; do echo 1 > /proc/sys/vm/drop_caches; sleep 30; done删除所有非 mmaped 页面，磁盘 io 最初会激增，但大约 30 分钟后就会稳定下来。我在所有服务器上运行了大约 48 小时，以验证它在每日负载高峰和低点下是否显示相同的 IO 减少量。确实如此。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。从磁盘调入的页面减少了一半。这将磁盘 IO 从约 200MB/s 减少到约 100MB/s，但运行良好的服务器仍然表现优于其他所有服务器，重大错误/秒仅为 50 次，并且仅需要执行约 10MB/s 的磁盘 IO。
为了了解 LRU 算法的工作原理，我使用了内核中的页面类型工具。这是一个运行良好的服务器（来自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，这是有道理的，因为这平衡了内核结构与用户页面，而我的问题是不同的用户页面 - 增加 /proc/sys/vm/swappiness。没想到这会有什么作用，而且也没有，不过检查一下也没什么坏处。
- 禁用 mmap（改用基于 epoll 的 java nio）。这会立即使服务器的 IO 使用率看起来与 IO 使用率表现良好的服务器一样。缺点是系统 cpu % 与发生的 IO 量有关，10MB/s 占用约 1.5%，偶尔高达约 100MB/s 的磁盘 io 负载会导致系统 cpu % 为 5 到 10%。在 32 核服务器上，有 1.5 到 3 个 cpu 完全用于处理 epoll。nio 的延迟也更差（与表现良好的 mmap 服务器相比）。这是一个可行的解决方案，但它是一种逃避，没有理解到底出了什么问题。
- 花了无数个小时使用该
perf工具查看堆栈跟踪、火焰图并寻找内核行为的差异。但收获甚微。 - 已检查磁盘预读设置在各个服务器上是否相同。性能较差的服务器上的 raid0 默认为 2048 个块，性能良好的服务器上的 raid0 默认为 256 个块。将性能较差的服务器更新为 256 个块
blockdev --setra对 IO 行为没有影响。 - 启动 jvm 以
numactl --interleave=all确保问题与两个 numa 节点之间的平衡无关。没有区别。 - 使用 进行验证
vmtouch，它基本上用于mincore(2)询问内核是否缓存文件，99% 以上的缓冲内存正在用于 elasticsearch 存储其数据的文件系统。以上 3 种情况均是如此。 - 已验证
fuser -melasticsearch 是使用文件系统上文件并存储其数据的唯一进程。
即将测试：
- 下周我将重新配置其中一台出现问题的服务器，但我并不乐观，认为这不会产生太大影响。在此配置过程中，我还更新了 raid 阵列，将 LVM 放在其前面。与 LVM 没有任何不同，但删除一个变量似乎是值得的。
答案1
这最终导致磁盘预读过于激进。性能良好的服务器预读 128 kB。性能较差的服务器预读 2 mB。无法查明预读不同的确切原因，但最可能的原因是新机器在软件 raid 前面有 LVM，而旧机器直接与软件 raid 通信。
虽然我的问题表明我最初确实检查了预读，注意到了差异，并在其中一台服务器上对其进行了更新，但 mmap 和预读之间的交互并不是那么简单。具体来说，当文件被 mmap 时，Linux 内核会将预读设置从磁盘复制到有关该文件的结构中。更新预读设置不会更新该结构。因此，更新的预读直到保持文件打开的守护进程重新启动后才会生效。
减少预读并重新启动性能较差的服务器上的守护进程立即使磁盘读取与性能良好的服务器保持一致，并立即减少了我们的 IO 等待和尾部延迟。