Risoluzione dei problemi di una stalla Redis


8

Abbiamo diverse istanze redis in esecuzione su un server. Esistono anche più server di livello Web che si connettono a quelle istanze che si trovano contemporaneamente in stallo.

Avevamo acquisizioni di pacchetti in corso in quel momento, che identificavano la presenza di una stalla nel traffico TX e RX, secondo i seguenti grafici IO wirehark:

inserisci qui la descrizione dell'immagine

inserisci qui la descrizione dell'immagine

C'è stato un picco correlato nelle chiamate redis, ma sospetto che fosse un effetto e non una causa a causa del ritardo:

inserisci qui la descrizione dell'immagine

Con un intervallo di campionamento di 15 / s (che viene raccolto come contatore) si è verificata una media di 136 bancarelle di allocazione della memoria:

inserisci qui la descrizione dell'immagine

Sembrava che ci fosse anche un numero fuori dal comune di NUMA pagine migrate nello stesso momento:

inserisci qui la descrizione dell'immagine

Sebbene quanto sopra appaia normale, c'erano due punti dati consecutivi per questo che lo rendono anormale rispetto ad altri picchi sopra i 300 visti nel grafico.

C'era anche un picco correlato negli errori di compattazione della memoria e nelle stalle di compattazione:

inserisci qui la descrizione dell'immagine

inserisci qui la descrizione dell'immagine

Anche se qui ho una grande quantità di informazioni sulla memoria, la mia conoscenza della memoria di Linux non è abbastanza profonda per ipotizzare davvero una buona storia che riunisce tutte queste informazioni per spiegare la situazione. Qualcuno con una profonda conoscenza della memoria Linux (e forse una profonda conoscenza della memoria redis) può unire alcune di queste informazioni?

Raccogliamo tutte le statistiche da / proc / vmstat a intervalli di 15 secondi, quindi se ci sono dei dati che ritieni possano essere aggiunti a questo, ti preghiamo di richiederlo. Ho appena scelto le cose che sembravano avere attività interessanti, in particolare lo stallo di allocazione, la migrazione numa e lo stallo / i guasti della compattazione. I totali seguono e coprono 20 giorni di uptime:

[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 

Anche tutte le impostazioni / proc / sys / vm / * se questo aiuta:

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

Aggiornare:

C'è un thp_split che è vicino nel tempo:

inserisci qui la descrizione dell'immagine

Risposte:


4

Qual è la tua impostazione per / proc / sys / vm / zone_reclaim? Prova a impostarlo su 0. Se cerchi "zone_reclaim", ci sono molte cose in rete, quindi non proverò a ripassarle qui.


Sembra già zero sembra[kbrandt@ny-redis01: ~] cat /proc/sys/vm/zone_reclaim_mode 0
Kyle Brandt,

1
OK. Prossima fermata: hugepages trasparenti. Sembra che siano in uso: 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 Per Redis probabilmente vuoi THP disabilitato. antirez.com/news/84 TL; DR: echo never> / sys / kernel / mm / transparent_hugepage / enabled
Tobert

C'è un thp_split che è una stretta correlazione. Alcuni ritardi nella registrazione, ma anche i tempi dell'agente di monitoraggio potrebbero essere stati influenzati. Aggiornata la domanda con il grafico!
Kyle Brandt,

Ti dispiace illuminarci di ciò che sta accadendo durante una divisione thp?
Kyle Brandt,

Lo abbiamo messo in burattino, ma come un dirigente. Non lo vedo in rc.local, quindi la mia attuale ipotesi è una condizione di gara - redis inizia prima che venga impostato l'interruttore del kernel
Kyle Brandt,

2

Quando Redis richiede il checkpoint, il kernel Linux deve duplicare le tabelle di mapping per la copia in scrittura. Se hai molta RAM, questo può richiedere molto tempo. Abbiamo un'istanza Redis da 200 GB che impiega 8 secondi per fork, e la macchina è sorda al mondo mentre questo accade.

Soluzioni alternative (da facile a difficile):

  • checkpoint meno spesso, aumentando il tempo e il conteggio delle chiavi prima del checkpoint
  • suddividere i dati in più istanze di processo, ognuna delle quali utilizza meno RAM
  • prova aof anziché checkpoint, anche se questo occasionalmente biforcerà comunque
  • provare pagine enormi, anche se potrebbe essere necessario raddoppiare la RAM fisica perché quasi tutto verrà sporcato durante il checkpoint
  • fanculo e vai con Postgres
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.