Atraso de Memcached

6

Deixe-me começar por dizer que se trata de uma pergunta de acompanhamento para este tópico .

Isso foi "resolvido" ao mudar do Solaris (SmartOS) para o Ubuntu para o servidor memcached. Agora multiplicamos o carregamento em cerca de 5x e estamos com problemas novamente.

Estamos executando um site que está fazendo cerca de 1000 solicitações / minuto, cada solicitação acessa o Memcached com aproximadamente 3 leituras e 1 gravação. Portanto, o carregamento é de aproximadamente 65 solicitações por segundo. O total de dados no cache é de aproximadamente 37M e cada chave contém uma quantidade muito pequena de dados (uma matriz codificada por JSON de números inteiros que equivale a menos de 1K).

Nós configuramos um script de benchmarking nessas páginas e inserimos os dados no StatsD para registro. O problema é que existem picos onde o Memcached leva muito tempo para responder. Estes não parecem correlacionar com picos de tráfego.

O que poderia estar causando esses picos? Por que memcached levaria mais de um segundo para responder? Acabamos de inicializar um segundo servidor para colocar no pool e isso não fez nenhuma diferença perceptível na frequência ou gravidade dos picos.

Esta é a saída de getStats () nos servidores:

Array
(
    [-----------] => Array
        (
            [pid] => 1364
            [uptime] => 3715684
            [threads] => 4
            [time] => 1336596719
            [pointer_size] => 64
            [rusage_user_seconds] => 7924
            [rusage_user_microseconds] => 170000
            [rusage_system_seconds] => 187214
            [rusage_system_microseconds] => 190000
            [curr_items] => 12578
            [total_items] => 53516300
            [limit_maxbytes] => 943718400
            [curr_connections] => 14
            [total_connections] => 72550117
            [connection_structures] => 165
            [bytes] => 2616068
            [cmd_get] => 450388258
            [cmd_set] => 53493365
            [get_hits] => 450388258
            [get_misses] => 2244297
            [evictions] => 0
            [bytes_read] => 2138744916
            [bytes_written] => 745275216
            [version] => 1.4.2
        )

    [-----------:11211] => Array
        (
            [pid] => 8099
            [uptime] => 4687
            [threads] => 4
            [time] => 1336596719
            [pointer_size] => 64
            [rusage_user_seconds] => 7
            [rusage_user_microseconds] => 170000
            [rusage_system_seconds] => 290
            [rusage_system_microseconds] => 990000
            [curr_items] => 2384
            [total_items] => 225964
            [limit_maxbytes] => 943718400
            [curr_connections] => 7
            [total_connections] => 588097
            [connection_structures] => 91
            [bytes] => 562641
            [cmd_get] => 1012562
            [cmd_set] => 225778
            [get_hits] => 1012562
            [get_misses] => 125161
            [evictions] => 0
            [bytes_read] => 91270698
            [bytes_written] => 350071516
            [version] => 1.4.2
        )

)

Edit: Aqui está o resultado de um conjunto e recuperar de 10.000 valores.

Normal:

Stored 10000 values in 5.6118 seconds.
Average: 0.0006
High: 0.1958
Low: 0.0003

Fetched 10000 values in 5.1215 seconds.
Average: 0.0005
High: 0.0141
Low: 0.0003

Quando Spiking:

Stored 10000 values in 16.5074 seconds.
Average: 0.0017
High: 0.9288
Low: 0.0003

Fetched 10000 values in 19.8771 seconds.
Average: 0.0020
High: 0.9478
Low: 0.0003
    
por Brad Dwyer 09.05.2012 / 22:53

3 respostas

0

A questão era que a máquina de chamada estava consumindo toda a CPU disponível. Isso estava causando problemas estranhos e estava aparecendo que o memcached era o problema quando, na verdade, não era. Isso foi apenas um sintoma do maior problema.

O escalonamento da camada da web solucionou o problema horizontalmente.

Se você estiver no Joyent, o comando útil para ver quanto do seu limite de CPU você está usando é jinf -c

    
por 18.06.2012 / 02:13
0

Pode haver um problema com a pilha de rede. Eu tenho parecido com problema com memcached e causa estava ficando sem manipuladores linux conntrack. Você pode verificar a saída netstat -s -t antes e depois dos picos para verificar os erros e retransmissões do tcp. Você também pode tentar usar o wireshark para examinar o despejo de tráfego para obter mais informações sobre o problema.

    
por 16.05.2012 / 09:15
0

Além de examinar as estatísticas da sua rede, uma atualização para a versão 1.4.10 (ou superior), que possui melhorias de desempenho, é possível? De 1.4.10 notas da versão :

This release is focused on thread scalability and performance improvements. This release should be able to feed data back faster than any network card can support as of this writing.

Embora nossos servidores não recebam o tráfego, no nosso caso, uma atualização para o 1.4.10 ajudou, assim como a ativação da compactação (tínhamos valores maiores que 1 MB) e o protocolo binário. Veja minha resposta em Drupal SE para detalhes .

    
por 23.05.2012 / 15:39