对Redis停顿进行故障排除

我们有几个Redis实例在服务器上运行。也有多个Web层服务器连接到那些同时经历停顿的实例。

当时，我们进行了数据包捕获，根据以下wireshark IO图，发现在TX和RX流量中都出现了停顿现象：

Redis调用中有一个相关的峰值，但是我怀疑这是时间的延迟，而不是原因：

以15 / s的采样间隔（作为计数器收集），平均有136个内存分配停顿：

在同一时间迁移的NUMA页似乎也不同寻常：

尽管以上内容看起来很正常，但与图表中其他300个以上的尖峰相比，有两个连续的数据点使其异常。

内存压缩失败和压缩停顿也存在相关峰值：

尽管我在这里拥有大量的内存信息，但是我对Linux的内存知识还不足以真正假设一个好的故事，该故事将所有这些信息结合在一起来解释停顿。具有Linux内存知识（也许还有Redis内存知识）的任何人都可以将其中一些信息结合在一起吗？

我们每隔15秒从/ proc / vmstat收集一次所有统计信息，因此，如果有任何您认为可能会增加的数据，请提出要求。我只是选择了似乎有趣的活动，特别是分配停顿，numa迁移和压缩停顿/失败。随后是总计，涵盖了20天的正常运行时间：

[kbrandt@ny-redis01: ~] uptime
 21:11:49 up 20 days, 20:05,  8 users,  load average: 1.05, 0.74, 0.69
[kbrandt@ny-redis01: ~] cat /proc/vmstat
nr_free_pages 105382
nr_alloc_batch 5632
nr_inactive_anon 983455
nr_active_anon 15870487
nr_inactive_file 12904618
nr_active_file 2266184
nr_unevictable 0
nr_mlock 0
nr_anon_pages 16361259
nr_mapped 26329
nr_file_pages 15667318
nr_dirty 48588
nr_writeback 0
nr_slab_reclaimable 473720
nr_slab_unreclaimable 37147
nr_page_table_pages 38701
nr_kernel_stack 987
nr_unstable 0
nr_bounce 0
nr_vmscan_write 356302
nr_vmscan_immediate_reclaim 174305
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 32
nr_shmem 423906
nr_dirtied 3071978326
nr_written 3069010459
numa_hit 1825289996
numa_miss 3360625955
numa_foreign 3360626253
numa_interleave 64798
numa_local 1856473774
numa_other 3329442177
workingset_refault 297175
workingset_activate 24923
workingset_nodereclaim 0
nr_anon_transparent_hugepages 41
nr_free_cma 0
nr_dirty_threshold 3030688
nr_dirty_background_threshold 1515344
pgpgin 25709012
pgpgout 12284206511
pswpin 143954
pswpout 341570
pgalloc_dma 430
pgalloc_dma32 498407404
pgalloc_normal 8131576449
pgalloc_movable 0
pgfree 8639210186
pgactivate 12022290
pgdeactivate 14512106
pgfault 61444049878
pgmajfault 23740
pgrefill_dma 0
pgrefill_dma32 1084722
pgrefill_normal 13419119
pgrefill_movable 0
pgsteal_kswapd_dma 0
pgsteal_kswapd_dma32 11991303
pgsteal_kswapd_normal 1051781383
pgsteal_kswapd_movable 0
pgsteal_direct_dma 0
pgsteal_direct_dma32 58737
pgsteal_direct_normal 36277968
pgsteal_direct_movable 0
pgscan_kswapd_dma 0
pgscan_kswapd_dma32 13416911
pgscan_kswapd_normal 1053143529
pgscan_kswapd_movable 0
pgscan_direct_dma 0
pgscan_direct_dma32 58926
pgscan_direct_normal 36291030
pgscan_direct_movable 0
pgscan_direct_throttle 0
zone_reclaim_failed 0
pginodesteal 0
slabs_scanned 1812992
kswapd_inodesteal 5096998
kswapd_low_wmark_hit_quickly 8600243
kswapd_high_wmark_hit_quickly 5068337
pageoutrun 14095945
allocstall 567491
pgrotated 971171
drop_pagecache 8
drop_slab 0
numa_pte_updates 58218081649
numa_huge_pte_updates 416664
numa_hint_faults 57988385456
numa_hint_faults_local 57286615202
numa_pages_migrated 39923112
pgmigrate_success 48662606
pgmigrate_fail 2670596
compact_migrate_scanned 29140124
compact_free_scanned 28320190101
compact_isolated 21473591
compact_stall 57784
compact_fail 37819
compact_success 19965
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0
unevictable_pgs_culled 5528
unevictable_pgs_scanned 0
unevictable_pgs_rescued 18567
unevictable_pgs_mlocked 20909
unevictable_pgs_munlocked 20909
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
thp_fault_alloc 11613
thp_fault_fallback 53
thp_collapse_alloc 3
thp_collapse_alloc_failed 0
thp_split 9804
thp_zero_page_alloc 1
thp_zero_page_alloc_failed 0

同样，所有/ proc / sys / vm / *设置（如果有帮助）：

***/proc/sys/vm/admin_reserve_kbytes***
8192
***/proc/sys/vm/block_dump***
0
***/proc/sys/vm/dirty_background_bytes***
0
***/proc/sys/vm/dirty_background_ratio***
10
***/proc/sys/vm/dirty_bytes***
0
***/proc/sys/vm/dirty_expire_centisecs***
3000
***/proc/sys/vm/dirty_ratio***
20
***/proc/sys/vm/dirty_writeback_centisecs***
500
***/proc/sys/vm/drop_caches***
1
***/proc/sys/vm/extfrag_threshold***
500
***/proc/sys/vm/hugepages_treat_as_movable***
0
***/proc/sys/vm/hugetlb_shm_group***
0
***/proc/sys/vm/laptop_mode***
0
***/proc/sys/vm/legacy_va_layout***
0
***/proc/sys/vm/lowmem_reserve_ratio***
256 256 32
***/proc/sys/vm/max_map_count***
65530
***/proc/sys/vm/memory_failure_early_kill***
0
***/proc/sys/vm/memory_failure_recovery***
1
***/proc/sys/vm/min_free_kbytes***
90112
***/proc/sys/vm/min_slab_ratio***
5
***/proc/sys/vm/min_unmapped_ratio***
1
***/proc/sys/vm/mmap_min_addr***
4096
***/proc/sys/vm/nr_hugepages***
0
***/proc/sys/vm/nr_hugepages_mempolicy***
0
***/proc/sys/vm/nr_overcommit_hugepages***
0
***/proc/sys/vm/nr_pdflush_threads***
0
***/proc/sys/vm/numa_zonelist_order***
default
***/proc/sys/vm/oom_dump_tasks***
1
***/proc/sys/vm/oom_kill_allocating_task***
0
***/proc/sys/vm/overcommit_kbytes***
0
***/proc/sys/vm/overcommit_memory***
1
***/proc/sys/vm/overcommit_ratio***
50
***/proc/sys/vm/page-cluster***
3
***/proc/sys/vm/panic_on_oom***
0
***/proc/sys/vm/percpu_pagelist_fraction***
0
***/proc/sys/vm/scan_unevictable_pages***
0
***/proc/sys/vm/stat_interval***
1
***/proc/sys/vm/swappiness***
60
***/proc/sys/vm/user_reserve_kbytes***
131072
***/proc/sys/vm/vfs_cache_pressure***
100
***/proc/sys/vm/zone_reclaim_mode***
0

更新：

有一个thp_split及时关闭：

linux memory redis

— 凯尔·勃兰特（Kyle Brandt）
source

您对/ proc / sys / vm / zone_reclaim的设置是什么？尝试将其设置为0。如果您搜索“ zone_reclaim”，那么网络上就会有很多东西，因此在这里我不会尝试对其进行哈希处理。

— 托伯特
source

似乎已经为零[kbrandt@ny-redis01: ~] cat /proc/sys/vm/zone_reclaim_mode 0

— 凯尔·布兰特

好。下一站：透明的大页面。看起来它们正在使用中：thp_fault_alloc 11613 thp_fault_fallback 53 thp_collapse_alloc 3 thp_collapse_alloc_failed 0 thp_split 9804 thp_zero_page_alloc 1 thp_zero_page_alloc_failed 0对于Redis，您可能希望禁用THP。 antirez.com/news/84 TL; DR：永不回显> / sys / kernel / mm / transparent_hugepage / enabled

— Tobert

有一个thp_split是紧密相关的。记录有些滞后，但是监视代理程序的时间也会受到影响。用图表更新了问题！

— 凯尔·布兰特

头脑使我们了解到thp分裂期间发生了什么？

— 凯尔·布兰特

我们将其设置为人偶，但作为执行者。我没有看到它在rc.local中，所以我现在的假设是一个竞争条件-设置内核切换之前的Redis开始

— 凯尔·勃兰特

当Redis派生到检查点时，Linux内核需要复制映射表以在写入时进行复制。如果您有大量RAM，则可能要花费很多时间。我们有一个200 GB的Redis实例，需要8秒钟的时间进行分叉，而在这种情况下，机器对世界充耳不闻。

解决方法（从简单到困难）：

减少检查点的频率，增加检查点之前的时间和密钥计数
将您的数据分成多个流程实例，每个实例使用更少的RAM
尝试使用aof而不是检查点，尽管有时还是会分叉
尝试大页面，尽管您可能需要将物理RAM加倍，因为在检查点时几乎所有东西都会被弄脏
拧紧并与Postgres一起使用

— 乔恩·瓦特
source