问题是一组服务器表现良好,每秒发出约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有任何不同,但删除变量似乎是值得的.
解决方法
虽然我的问题表明我最初检查了预读,但注意到差异,并在其中一台服务器上更新,mmap和预读之间的交互不是那么直接.特别是当文件是mmap时,linux内核会将预读设置从磁盘复制到关于该mmap’d文件的结构.更新预读设置不会更新该结构.因此,更新的预读直到重新启动保持文件打开的守护程序之后才会生效.
在性能较差的服务器上减少预读并重新启动守护程序会立即使磁盘读取内容与执行良好的磁盘一致,并立即减少IO等待和尾部延迟.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。