Solucionando problemas de um Redis Stall

Question

Temos várias instâncias de redis em execução em um servidor. Também há vários servidores de camada da web que se conectam a essas instâncias que experimentam uma paralisação ao mesmo tempo.

Tivemos capturas de pacotes na época, que identificaram que há uma paralisação nos tráfegos TX e RX, conforme os seguintes gráficos de IO wireshark:

Houveumpicocorrelativonaschamadasderedis,massuspeitoqueissotenhasidoumefeitoenãoumacausadevidoaointervalodetempo:

Comumintervalodeamostragemde15/s(issoécoletadocomoumcontador),houveumamédiade136barracasdealocaçãodememória:

TambémpareciahaverumnúmeroforadocomumdepáginasNUMAmigradasaomesmotempo:

Emboraoacimapareçanormal,houvedoispontosdedadosconsecutivosparaisso,oqueotornaanormalcomparadoaoutrosacimade300pontosvistosnográfico.

Houvetambémumaumentocorrelacionadonasfalhasdecompactaçãodememóriaenasparadasdecompactação:

Emboraeutenhamuitasinformaçõesdememóriaaqui,meuconhecimentodememóriadoLinuxnãoéprofundoosuficienteparacriarahipótesedeumaboahistóriaquereúnatodasessasinformaçõesparaexplicarabarraca.AlguémcomconhecimentoprofundodememóriadoLinux(etalvezconhecimentodememóriadevermelhoprofundo)podeuniralgumasdessasinformações?

Coletamostodasasestatísticasde/proc/vmstatemintervalosde15segundos,portanto,sehouveralgumdadoquevocêpossaadicionaraisso,solicite-o.Acabeideescolherascoisasquepareciamteratividadeinteressante,emparticularaalocaçãodealocação,amigraçãonumaeasparadas/falhasdecompactação.Ostotaisseguemecobrem20diasdeatividade:

[kbrandt@ny-redis01:~]uptime21:11:49up20days,20:05,8users,loadaverage:1.05,0.74,0.69[kbrandt@ny-redis01:~]cat/proc/vmstatnr_free_pages105382nr_alloc_batch5632nr_inactive_anon983455nr_active_anon15870487nr_inactive_file12904618nr_active_file2266184nr_unevictable0nr_mlock0nr_anon_pages16361259nr_mapped26329nr_file_pages15667318nr_dirty48588nr_writeback0nr_slab_reclaimable473720nr_slab_unreclaimable37147nr_page_table_pages38701nr_kernel_stack987nr_unstable0nr_bounce0nr_vmscan_write356302nr_vmscan_immediate_reclaim174305nr_writeback_temp0nr_isolated_anon0nr_isolated_file32nr_shmem423906nr_dirtied3071978326nr_written3069010459numa_hit1825289996numa_miss3360625955numa_foreign3360626253numa_interleave64798numa_local1856473774numa_other3329442177workingset_refault297175workingset_activate24923workingset_nodereclaim0nr_anon_transparent_hugepages41nr_free_cma0nr_dirty_threshold3030688nr_dirty_background_threshold1515344pgpgin25709012pgpgout12284206511pswpin143954pswpout341570pgalloc_dma430pgalloc_dma32498407404pgalloc_normal8131576449pgalloc_movable0pgfree8639210186pgactivate12022290pgdeactivate14512106pgfault61444049878pgmajfault23740pgrefill_dma0pgrefill_dma321084722pgrefill_normal13419119pgrefill_movable0pgsteal_kswapd_dma0pgsteal_kswapd_dma3211991303pgsteal_kswapd_normal1051781383pgsteal_kswapd_movable0pgsteal_direct_dma0pgsteal_direct_dma3258737pgsteal_direct_normal36277968pgsteal_direct_movable0pgscan_kswapd_dma0pgscan_kswapd_dma3213416911pgscan_kswapd_normal1053143529pgscan_kswapd_movable0pgscan_direct_dma0pgscan_direct_dma3258926pgscan_direct_normal36291030pgscan_direct_movable0pgscan_direct_throttle0zone_reclaim_failed0pginodesteal0slabs_scanned1812992kswapd_inodesteal5096998kswapd_low_wmark_hit_quickly8600243kswapd_high_wmark_hit_quickly5068337pageoutrun14095945allocstall567491pgrotated971171drop_pagecache8drop_slab0numa_pte_updates58218081649numa_huge_pte_updates416664numa_hint_faults57988385456numa_hint_faults_local57286615202numa_pages_migrated39923112pgmigrate_success48662606pgmigrate_fail2670596compact_migrate_scanned29140124compact_free_scanned28320190101compact_isolated21473591compact_stall57784compact_fail37819compact_success19965htlb_buddy_alloc_success0htlb_buddy_alloc_fail0unevictable_pgs_culled5528unevictable_pgs_scanned0unevictable_pgs_rescued18567unevictable_pgs_mlocked20909unevictable_pgs_munlocked20909unevictable_pgs_cleared0unevictable_pgs_stranded0thp_fault_alloc11613thp_fault_fallback53thp_collapse_alloc3thp_collapse_alloc_failed0thp_split9804thp_zero_page_alloc1thp_zero_page_alloc_failed0

Tambémtodasasconfiguraçõesde/proc/sys/vm/*,seissoajudar:

***/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***25625632***/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

Atualização:

Existeumthp_splitqueestápróximonotempo:

    

Answer 1

Qual é a sua configuração para / proc / sys / vm / zone_reclaim? Tente defini-lo como 0. Há muita coisa na net se você procurar por "zone_reclaim", então não tentarei refazê-lo aqui.

    

Answer 2

Quando Redis forks to checkpoint, o kernel do Linux precisa duplicar as tabelas de mapeamento para copy em write. Se você tem muita memória RAM, isso pode levar muito tempo. Temos uma instância Redis de 200 GB, que leva 8 segundos para ser utilizada, e a máquina é surda para o mundo enquanto isso acontece.

Soluções alternativas (de fácil a difícil):

• ponto de verificação com menos frequência, aumentando o tempo e a contagem de chaves antes do ponto de verificação
• compartilhe seus dados em várias instâncias de processo, cada uma delas usando menos RAM
• experimente aof em vez de um ponto de verificação, embora isso ocorra ocasionalmente de qualquer maneira
• experimente páginas enormes, embora seja necessário dobrar sua RAM física, porque aproximadamente tudo ficará sujo ao se verificar
• aperte e vá com o Postgres