我有两套具有128G内存的服务器,区别在于它们的配置时,在运行完全相同的守护进程(elasticsearch)时表现非常不同.我正在使用elasticsearch进行全文搜索,而不是日志存储,所以这是一个读取繁重的操作,写入次数最少(小于1MB / s).该守护进程mmap将〜350GB的完整数据集放入其虚拟内存中,然后访问其中的某些部分以处理请求.这些服务器没有配置交换空间.

问题是一组服务器表现良好,每秒发出约50个主要故障,平均需要10MB / s的磁盘来满足该需求.性能不佳的服务器每秒看到500个主要故障,平均需要大约200MB / s的磁盘来满足这一要求.磁盘io的增加导致p95响应延迟差和偶然的过载,因为它达到了~550MB / s的磁盘限制.

它们都位于相同的负载均衡器后面,并且属于同一个集群.我可以看到一台服务器是否表现不佳它可能是负载上的差异,但要明显区分16台服务器表现不佳而且20台服务器表现良好,它们在不同时间进行了purhased配置,内核/配置等级必须导致问题.

为了解决这个问题,我怎样才能使这些表现不佳的服务器表现得像那些表现良好的服务器？调试工作应该集中在哪里？

下面是我收集的一些数据,用于查看系统在三种状态中的sar和页面类型工具中正在执行的操作.

软件：
– 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部分性能不佳所致.如果我跑的话是真的;做回声1>的/ proc / SYS / VM / drop_caches;睡30;完成后,会删除所有非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算法的工作原理,我使用了内核中的页面类型工具.这是一个表现良好的服务器(来自页面类型| 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,active
0x0000000000000268          305744     1194  ___U_lA__I________________________________ uptodate,active,reclaim
0x0000000000100000          524288     2048  ____________________n_____________________ nopage
0x000000000000082c          632704     2471  __RU_l_____M______________________________ referenced,mmap
0x0000000000000000          763312     2981  __________________________________________
0x0000000000000068         2108618     8236  ___U_lA___________________________________ uptodate,active
0x000000000000086c         6987343    27294  __RU_lA____M______________________________ referenced,mmap
0x0000000000005868         8589411    33552  ___U_lA____Ma_b___________________________ uptodate,mmap,anonymous,swapbacked
0x0000000000000868        12513737    48881  ___U_lA____M______________________________ uptodate,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,mmap
0x000000000000086c          515691     2014  __RU_lA____M______________________________ referenced,mmap
0x0000000000000028          687263     2684  ___U_l____________________________________ uptodate,lru
0x0000000000000000          785662     3068  __________________________________________
0x0000000000000868         7946840    31042  ___U_lA____M______________________________ uptodate,mmap
0x0000000000005868         8588629    33549  ___U_lA____Ma_b___________________________ uptodate,swapbacked
0x0000000000000068        14133541    55209  ___U_lA___________________________________ uptodate,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,mmap
0x000000000000082c         3123142    12199  __RU_l_____M______________________________ referenced,mmap
0x0000000000000828         5278755    20620  ___U_l_____M______________________________ uptodate,mmap
0x0000000000005868         8622864    33683  ___U_lA____Ma_b___________________________ uptodate,swapbacked
0x000000000000086c        13630124    53242  __RU_lA____M______________________________ referenced,mmap
             total        33816576   132096

事情尝试：

>将/ proc / sys / vm / vfs_cache_pressure增加到各种值之间
150和10000.这对IO或报告的数据没有影响
页面类型,这是有道理的,因为这可以平衡内核
结构与用户页面,我的问题是不同的用户页面
>增加/ proc / sys / vm / swappiness.没想到这会做任何事情,但事实并非如此,但检查并没有受到伤害.
>禁用mmap(而不是使用基于epoll的java的nio).这立即使服务器的IO使用看起来就像IO使用方面表现良好的那样.这里的缺点是系统cpu％与发生了多少IO有关,10MB / s需要大约1.5％,偶尔加载大约100MB / s的磁盘,系统cpu占5％到10％.在32核心服务器上,1.5至3 cpu用于完全处理epoll. nio(与表现良好的mmap服务器相比)的延迟也更差.这是一个看似合理的解决方案,但它是一个警察,而不了解实际上出了什么问题.
>使用perf工具在堆栈跟踪,火焰图和寻找内核行为差异时无数个小时.几乎没有任何洞察力.
>已检查的磁盘预读设置在服务器之间是相同的. raid0在性能​​不佳的服务器上默认为2048块,性能良好的服务器raid0默认为256块.使用blockdev –setra将性能较差的服务器更新为256,这对IO行为没有影响.
>使用numactl –interleave = all启动jvm以确保问题与两个numa节点之间的平衡无关.没有区别.
>使用vmtouch验证,它基本上使用mincore(2)询问内核是否缓存文件,99％的缓冲内存用于文件系统elasticsearch存储它的数据.在上述所有3个案例中都是如此.
>使用fuser -m验证弹性搜索是使用文件系统上的文件的唯一过程elasticsearch存储它的数据.

要尽快测试：

>我将在下周重新配置一个行为不端的服务器,但我并不乐观,这会产生很大的影响.在此配置期间,我还要更新raid阵列以将LVM置于其前面.不期望与LVM有任何不同,但删除变量似乎是值得的.