Número ideal de processos por unicórnio da CPU

Question

Estamos executando um aplicativo da Web Ruby on Rails no Unicorn. Nosso aplicativo não é estritamente ligado à CPU (temos um sistema dual Xeon E5645 com 12 núcleos e um valor médio de carga de pico é de aproximadamente 6). Começamos com 40 trabalhadores do Unicorn inicialmente, mas a pegada de memória do aplicativo aumentou com o tempo. Então, agora temos que diminuir o número de processos de trabalho. Eu achava que a fórmula padrão (número de núcleos de CPU + 1) se aplica ao Unicorn também, mas meu colega tentou me convencer de que deveríamos reservar mais instâncias de unicórnio por CPU e fornecer este link . No entanto, não sei exatamente por que precisamos gastar tanta memória em processos Unicorn ociosos.

Minha pergunta é: qual é o motivo de ter mais de uma instância Unicorn por núcleo da CPU? É devido a alguma peculiaridade arquitetônica do unicórnio? Estou ciente de que os processos ocupados do Unicorn não podem aceitar novas conexões (estamos usando sockets de domínio UNIX para se comunicar com instâncias Unicorn BTW), mas eu pensei que o backlog foi introduzido exatamente para resolver isso. É possível superar de 2 a 8 instâncias de Unicorn por regra de CPU?

    

Answer 1

Ok, finalmente encontrei a resposta. O número ideal de trabalhadores Unicorn não está diretamente conectado ao número de núcleos da CPU, isso depende da sua carga e da estrutura / capacidade de resposta do aplicativo interno. Basicamente, usamos amostrador de amostragem para determinar o estado dos trabalhadores, tentamos manter os trabalhadores 70% ociosos e 30% fazendo o trabalho real. Portanto, 70% das amostras devem estar "aguardando a chamada select () para obter uma solicitação do servidor frontend". Nossa pesquisa mostrou que existem apenas 3 estados efetivos de trabalhadores: 0-30% das amostras estão inativas, 30-50% das amostras estão inativas e 50-70% das amostras estão inativas (sim, podemos obter mais amostras ociosas, mas há não é um ponto real, porque a capacidade de resposta da aplicação não muda significativamente). Consideramos 0-30% situação uma "zona vermelha" e 30-50% situação uma "zona amarela".

    

Answer 2

Você está certo sobre N + 1 para trabalhos limitados à CPU.

Por outro lado, o unicórnio não usa encadeamentos, portanto, cada IO op. bloqueia o processo e outro processo pode chutar e analisar cabeçalhos HTTP, concatenar cadeias de caracteres e executar todas as tarefas de uso intensivo da CPU necessárias para atender o usuário (fazendo isso antes para reduzir a latência da solicitação).

E você pode querer ter mais threads / processos e núcleos. Imagine a seguinte situação: req. Um leva dez vezes mais que o req. B, você tem várias solicitações A simultâneas e a solicitação B rápida está apenas enfileirada aguardando a conclusão do A-req. Então, se você pode prever o número de pedidos pesados, você pode usar esse número como outra diretriz para ajustar o sistema.