O tempo de fork do meu redis é lento e afeta um pouco o desempenho da consulta. O que devo fazer para verificar?

Question

Eu usei apenas redis com a opção RDB. Usou 2 GB de memória. Quando forjado, usou cerca de 10 segundos para salvar completamente o arquivo. Quando eu check-up com o site redis.io, encontrei este stat de latência:

- Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
- Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
- Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 millisecodns (9 milliseconds per GB).
- Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
- Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
- Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).

Eu usei servidores Xeon E3-1240 dedicados. Compare com esses resultados acima, ele usou muito mais tempo para salvar. É porque todas as minhas chaves são hash? O que devo fazer para reduzir a latência e reduzir o impacto no processo principal do Redis para consultar?

    

Answer 1

da saída Redis INFO , as métricas relevantes para o tempo de garfos e para o disco são:

rdb_last_bgsave_time_sec:0
latest_fork_usec:545

As notas redis.io falam sobre o tempo do garfo , não o tempo gasto para persistir totalmente o arquivo no disco.

O tempo necessário para persistir totalmente no disco depende da velocidade da CPU e do armazenamento (disco ou discos) propriamente dito. Você precisaria examinar a saída vmstat ou iostat (supondo que você esteja no Linux). No caso do autor é 2GB para armazenar no disco depois de tudo ... Se as chaves são Hash ou não não entram em jogo. O hash é geralmente uma boa escolha para caber mais na memória, no entanto.

O tempo de salvamento em disco pode ter pouca relevância ou muita relevância ... depende de quão afetado é o processo do Redis durante o processo de salvar no disco.

Mas novamente; note que o tempo do garfo geralmente é o problema real, mesmo que seja milissegundos, quando a latência geralmente acontece, pois está bloqueando durante a cópia da memória (breve) . O salvamento real em disco, como eu disse, pode ou não ser algo com o qual você precisa se preocupar. É realizado em um thread de fundo.