Início / server / Perguntas / 1167527
Accepted
NicoAdrian
Asked: 2024-11-07 23:12:46 +0800 CST

Varnish número muito alto de arquivos abertos

  • 772

Aqui está minha configuração do Varnish:

/usr/sbin/varnishd \
      -a 127.0.0.1:6081 \
      -T 127.0.0.1:6082 \
      -f /varnish/default.vcl \
      -P %t/%N/varnishd.pid \
      -s malloc,4G \
      -p thread_pools=12 -p thread_pool_min=250 -p default_ttl=1 -p default_grace=0 -p timeout_idle=1800

Então 12 * 250 = 3000 threads. Com essa configuração, acabo com mais de 400k arquivos abertos.

Reduzir o número de threads ao mínimo realmente reduz muito o número de arquivos abertos.

A questão é: como isso é possível? É normal que cada thread do Varnish ocupe tantos arquivos abertos?

EDIT: Aqui está meu arquivo VCL:

vcl 4.1;

backend someBackend {
    .host = "someBackend.net";
    .connect_timeout = 2s;
    .first_byte_timeout = 5s;
    .between_bytes_timeout = 5s;
}

sub vcl_recv {
    # Remove Varnish from X-Forwarded-For (set by Nginx)
    set req.http.X-Forwarded-For = regsub(req.http.X-Forwarded-For, ",[^,]+$", "");
}

sub vcl_backend_fetch {
    # Hide Varnish token
    unset bereq.http.X-Varnish;
}

sub vcl_backend_response {
    unset beresp.http.Vary;
}

sub vcl_deliver {
    unset resp.http.Via;
    unset resp.http.X-Varnish;
}
varnish

1 respostas

  1. Best Answer

    Alguns dos parâmetros que você definiu podem ser responsáveis ​​por esse alto número de arquivos abertos.

    Tópicos

    Vamos começar com thread_pools=12. O valor padrão é 2 e não aconselhamos que você o altere. Enquanto thread_pool_minestiver definido como 250em seu caso de uso, o valor padrão para thread_pool_maxé 5000.

    A questão é: "você está vendo 400 mil arquivos abertos durante o pico de tráfego ou mesmo quando está bem abaixo de 1.000 tópicos ativos?"

    Para sua informação: o MAIN.threadscontador varnishstatpode ajudar você a descobrir quantos tópicos ativos existem.

    Digamos hipoteticamente que isso esteja acontecendo durante o pico absoluto de tráfego, quando você tem 5.000 threads por pool, mas os 12 pools de threads resultam em 60.000 threads ativos.

    Isso significaria que haveria cerca de 7 descritores de arquivo por thread, o que não é absurdo.

    O impacto detimeout_idle

    É claro que há o timeout_idleparâmetro que você aumentou de 5 para 1800. Isso significa que uma conexão fica ociosa por 1800 segundos antes de ser fechada se keepalive estiver definido.

    Isso é muito tempo.

    Os descritores de arquivo para conexões ociosas são movidos para longe dos threads e são gerenciados por um thread waiter . Isso significa que os descritores de arquivo são mantidos por perto, enquanto os threads podem assumir novas conexões e criar mais descritores de arquivo.

    Para sua informação: você pode executar varnishstat -f "WAITER.*.conns" -f "MAIN.sess_conn" -f "MAIN.backend_conn"para monitorar conexões que são manipuladas pelo thread de espera, conexões de entrada regulares e conexões de backend.

    Mais alguma depuração necessária

    Ao longo da minha resposta, presumi que os 400k arquivos abertos ocorrem durante o pico de tráfego. Se esse não for o caso, há mais depuração necessária para descobrir quais arquivos (ou descritores de arquivo) estão em uso.

    Uma maneira de fazer isso é executar o seguinte comando:

    lsof -p $(pgrep cache-main)

    Este comando listará os vários descritores de arquivo que estão em uso para esse processo.

    E, claro, executando o seguinte comando com parâmetros combinados para listar todos os threads e conexões:

    varnishstat -f "MAIN.threads" -f "WAITER.*.conns" -f "MAIN.sess_conn" -f "MAIN.backend_conn"

    Atualização após comentários

    Na seção de comentários desta pergunta, você notará algumas idas e vindas na tentativa de reunir mais informações e obter algum contexto.

    @NicoAdrian mencionou que estava vendo muitos descritores de arquivo apontando para var/lib/varnish/varnishd/_.vsm_child/_.Stat.*. Não consegui simular isso. Sempre que inicio, varnishdhá cerca de 45 descritores de arquivo associados a esse padrão.

    Quando aumento as configurações de threading para os parâmetros que foram compartilhados aqui, esse número aumenta para 80, mas não mais.

    No entanto, posso simular o alto número de descritores de arquivo ao aumentar as configurações de threading.

    Executei os seguintes comandos em um servidor Varnish em execução para imitar as configurações mencionadas nesta pergunta:

    varnishadm param.set thread_pools 12
varnishadm param.set thread_pool_min 250

    A saída de lsof | grep "varnish" | wc -lfoi 188918. Isso significa que 188918 descritores de arquivo estavam em uso.

    Enquanto isso, a saída de varnishstat -1 -f MAIN.threadsmostra que 3198os threads de trabalho estão ativos naquele momento. Isso é 12 x 250.

    250 threads de trabalho por pool de threads é o mínimo com essas configurações. Conforme o tráfego começa a aumentar, os threads por pool podem ir até 5000, porque o valor padrão de thread_pool_maxé 5000.

    Há em média 50-60 descritores de arquivo por thread de trabalho. Ao ter um alto número de threads ativas, esses descritores de arquivo aumentarão na mesma proporção. A maioria deles deve ser vinculada a /proc/*.

    Conforme mencionado, o número de pools de threads foi aumentado para 12 para diminuir a contenção de bloqueio. Dificilmente aumentamos o valor de thread_pools, mesmo para sistemas em escala. No caso de 12 pools de threads, pode fazer sentido diminuir o thread_pool_minvalor para reduzir a criação inicial de threads e reduzir os descritores de arquivo em uso.

    No tráfego de linha de base, faz sentido olhar para para MAIN.threadsver quantos threads estão realmente sendo criados. Se esse valor for maior que thread_pools x thread_pool_min, é uma indicação de que mais threads foram criados e que a thread_pool_minconfiguração estava muito baixa.

    Isso tem uma correlação direta com o número de descritores de arquivo em uso. Se houver suspeita de que o desempenho se torne um problema por causa disso, é possível montar a /var/lib/varnishpasta em tmpfs.

    • 1

relate perguntas