Memcached lento: média de 10 ms memcached 'get'

Question

Memcached lento: média de 10 ms memcached 'get'

#1 resposta do (3 votos)
#2 resposta do (1 votos)
#3 resposta do (1 votos)
#4 resposta do (0 votos)
#5 resposta do (0 votos)
#6 resposta do (0 votos)

6

Estamos usando o Newrelic para medir o desempenho do aplicativo Python / Django. A Newrelic está relatando que, em todo o nosso sistema, o "Memcached" está tirando uma média de 12ms para responder aos comandos.

Analisando as dez ou mais visualizações da Web (por # de solicitações), vejo que alguns Memcache get ocupam 30ms ; Não consigo encontrar um único uso de Memcache get que retorne em menos de 10ms .

Mais detalhes sobre a arquitetura do sistema:

Atualmente, temos quatro servidores de aplicativos, cada um deles com um membro memcached. Todos os quatro membros do memcached participam de um cluster de memcache.
Estamos trabalhando em um provedor de hospedagem na nuvem e todo o tráfego está sendo executado na rede "interna" (por meio de IPs "internos")
Quando faço ping de um servidor de aplicativos para outro, as respostas estão em ~0.5ms

O tempo de resposta não é 10ms a lento para o Memcached?

Tanto quanto eu entendo se você acha que "Memcache está muito lento" então "você está fazendo errado" . Então estou fazendo errado?

Aqui está a saída do comando memcache-top :

memcache-top v0.7   (default port: 11211, color: on, refresh: 3 seconds)

INSTANCE        USAGE   HIT %   CONN    TIME    EVICT/s GETS/s  SETS/s  READ/s  WRITE/s 
cache1:11211    37.1%   62.7%   10      5.3ms   0.0     73      9       3958    84.6K   
cache2:11211    42.4%   60.8%   11      4.4ms   0.0     46      12      3848    62.2K   
cache3:11211    37.5%   66.5%   12      4.2ms   0.0     75      17      6056    170.4K  

AVERAGE:        39.0%   63.3%   11      4.6ms   0.0     64      13      4620    105.7K  

TOTAL:      0.1GB/  0.4GB       33      13.9ms  0.0     193     38      13.5K   317.2K  
(ctrl-c to quit.)

** Aqui está a saída do comando top em uma máquina: ** (Aproximadamente o mesmo em todas as máquinas do cluster. Como você pode ver, há muito pouca utilização da CPU, porque essas máquinas só executam o memcache.)

top - 21:48:56 up 1 day,  4:56,  1 user,  load average: 0.01, 0.06, 0.05
Tasks:  70 total,   1 running,  69 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Mem:    501392k total,   424940k used,    76452k free,    66416k buffers
Swap:   499996k total,    13064k used,   486932k free,   181168k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                               
 6519 nobody    20   0  384m  74m  880 S  1.0 15.3  18:22.97 memcached                                                                                              
    3 root      20   0     0    0    0 S  0.3  0.0   0:38.03 ksoftirqd/0                                                                                            
    1 root      20   0 24332 1552  776 S  0.0  0.3   0:00.56 init                                                                                                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                                                               
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0                                                                                            
    5 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kworker/u:0                                                                                            
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0                                                                                            
    7 root      RT   0     0    0    0 S  0.0  0.0   0:00.62 watchdog/0                                                                                             
    8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                                                                                                 
    9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper                                                                                                
...output truncated...

python cache memory memcached

por Chris W. 01.04.2013 / 21:47

6 respostas

Tags python cache memory memcached

nginx com real_ip - registra tanto o cliente remote_addr quanto o endereço de proxies desempenho de postfix com listas no main.cf

score 3 · Answer 1

Descobri que a gravação é rápida, as leituras únicas são lentas, mas as leituras em buffer são muito rápidas. Você precisa fazer uma leitura em buffer com get_many, passando uma matriz das chaves que deseja recuperar. Aqui está o meu teste:

ESCREVA 100000 escrita (uma a uma, mas provavelmente armazenada nos bastidores) em 0.42605304718 segundos, 234712 por segundo
LER 100000 com tamanho de baldes = 10000 leia (muitos) em 0.651949167252 segundos, 153386 por segundo
LEIA 100000 um de cada vez leia (um) em 86.2907109261 segundos, 1158 por segundo

No meu caso eu estou usando python com pymemcache.

score 1 · Answer 2

Até agora, minha pesquisa indica que 10ms é "lento". Com isso, quero dizer que os documentos do memcache se referem a sub- 1ms times como sendo 'esperado'. Então, os tempos de resposta que estamos vendo são uma ordem de magnitude mais lenta.

O que esperar do desempenho: link

Os "prováveis culpados" para respostas lentas de memcached parecem ser (em ordem aproximada de probabilidade):

design de aplicativo inadequado (ou um bug)
congestionamento de rede
trocando
alta carga de CPU de aplicativos de co-inquilino
atingindo algum tipo de conexão max
firewalls de estado
configurações TCP inválidas

Eu já falei sobre quase todos os itens a seguir:

De acordo com memcached-top ( link ), obtemos aproximadamente os mesmos tempos de conexão de nosso aplicativo. ao executar brutis ( link ) desses mesmos servidores de aplicativos.
O tempo de resposta permanece consistente ao longo do dia, apesar de nosso sistema ter um tempo de carregamento de pico claro; os tempos de resposta nunca são "espinhosos", como se poderia esperar se fosse um problema de congestionamento. (Além disso, nosso provedor de hospedagem afirma fornecer muito mais Mbps para essas instâncias do que os relatórios atop que estamos utilizando)
Observou que há bastante memória livre (e nenhum iowait) nos sistemas
Baixo uso da CPU no cache inteiro
Apenas atendendo 10-20 conexões simultâneas por servidor
Estávamos usando o firewall stateful (via iptables), mas quando removemos todas as entradas com estado, não houve alteração no desempenho.

Defina cegamente essas opções de configuração e espere que elas melhorem as coisas:

/sbin/sysctl -w net.ipv4.tcp_tw_recycle=1
/sbin/sysctl -w net.ipv4.tcp_tw_reuse=1 
/sbin/sysctl -w net.ipv4.tcp_fin_timeout=10

Resultados sem alterações.

Estamos basicamente perdidos para diagnosticar esse problema. Estamos nos aproximando do ponto de "instalar o Redis" e esperamos que funcione melhor.

score 1 · Answer 3

A primeira coisa que vem à mente é: você está usando um FQDN / DNS para iniciar uma conexão com seu servidor memcache ou está usando um endereço IP ou um soquete local?

Se você estiver usando um nome de host, talvez esteja perdendo algum tempo na resolução de nomes.

Tente colocar o FQDN nos clientes e servidores '/ etc / hosts e reinicie para que nada seja armazenado em cache ou altere a referência para ser baseada em endereço IP e veja se você não vê uma melhoria.

score 0 · Answer 4

Eu notei duas coisas. A taxa de acerto é muito baixa, deve ser o mais próximo possível de 100%. Você tem mais de 200 MB de memória livre, que você pode usar para o memcached.

score 0 · Answer 5

Acabei de fazer um flush memcached, então pensei em postar uma saída de exemplo de algo que acho que está funcionando. A nova relíquia está relatando 10.4ms gastos no memcached, então acho que está contando várias chamadas. Você está correndo em metal puro ou virtual, se você se importa com velocidade, então virtual não é o caminho a seguir ( link )

memcache-top v0.6   (default port: 11211, color: on, refresh: 3 seconds)

    INSTANCE        USAGE   HIT %   CONN    TIME    EVICT/s READ/s  WRITE/s 
    app01:11211     0.5%    49.8%   2994    0.7ms   0.0 75.2K   378.5K  
    app02:11211     0.5%    51.7%   2992    0.7ms   0.0 76.5K   143.9K  
    app03:11211     1.0%    69.6%   1469    0.7ms   0.0 42.0K   161.3K  
    app04:11211     2.0%    52.6%   801 0.5ms   0.0 66.0K   415.9K  
    app05:11211     2.2%    52.5%   801 0.4ms   0.0 71.9K   171.2K  
    app06:11211     2.0%    66.4%   800 0.5ms   0.0 135.9K  180.4K  
    app07:11211     1.9%    52.0%   800 0.6ms   0.0 65.5K   482.4K  
    app08:11211     1.1%    87.1%   1469    0.7ms   0.0 59.3K   365.3K  
    db01:11211      1.0%    82.4%   1469    0.5ms   0.0 64.6K   155.4K  
    elastic01:11211     1.7%    69.9%   737 0.5ms   0.0 44.2K   128.8K  
    elastic02:11211     1.7%    65.0%   737 0.5ms   0.0 48.2K   155.8K  
    elastic03:11211     1.8%    68.3%   737 0.6ms   0.0 24.5K   115.7K  
    elastic04:11211     1.8%    69.5%   737 0.7ms   0.0 95.3K   158.0K  

    AVERAGE:        1.5%    64.4%   1272    0.6ms   0.0 66.9K   231.7K  

    TOTAL:      12.1GB/ 1.0TB       16.2K   7.6ms   0.0 869.1K  2.9M    
    (ctrl-c to quit.)

score 0 · Answer 6

O problema com o django e o memcached é que ele faz uma conexão a cada requisição. Então, parte desse tempo é o tempo de configuração da conexão.

Depende de qual ligação do memcache você está usando. Mas você poderia colocar algo assim em seu wsgi.py

# Fix django closing connection to memcached after every request (#11331)
from django.core.cache.backends.memcached import BaseMemcachedCache
BaseMemcachedCache.close = lambda self, **kwargs: None

Basicamente, ele conserta o manipulador próximo para não fechar.

Se isso não funcionar, substitua por sua classe memcached.