O que devo considerar ao decidir quantos processos executar em um host de aplicativo? [fechadas]

Question

Trabalho nas operações e, como tal, sou o principal tomador de decisões para algumas implantações de nossos serviços. Eu trabalho com um aplicativo distribuído que envolve vários tipos de "serviços", alguns mais exigentes do que outros. Eu digo "serviços" porque eu não quero ser confuso - estas são múltiplas instanciações do mesmo executável C ++, apenas com parâmetros diferentes para dizer ao exe qual tipo de serviço iniciar como.

Então, tradicionalmente, a forma como implantamos nossos serviços no passado é uma proporção 1:1 de service-counts:cores - cores , especificamente isso. Não hyper-threaded cores .

Exemplo!

• Anfitrião com CPUs 4 físicas, cada uma com 4 núcleos.
• Em /proc/cpuinfo esse host aparece com 32 processors - não é isso que quero dizer quando digo cores daqui para frente. O que quero dizer é o 4cpus x 4cores == 16 cores total.

Nosso sistema não é multiencadeado no sentido de que os serviços funcionam em paralelo no mesmo cenário e ao mesmo tempo. Ele é distribuído, mas não encadeado . Nossos serviços não compartilham muita memória uns com os outros através de threads (principalmente informações do banco de dados, eu acho). Essa é provavelmente uma informação importante para saber.

A minha pergunta é, considerando que o nosso software não é tecnicamente segmentado por não tentar aproveitar a computação encadeada (é principalmente distribuída para lidar com a carga), devo me preocupar com service:core taxas? Eu sinto que isso está desperdiçando um monte de ciclos não utilizados que poderiam ser utilizados por outros serviços.

Exemplo!

• Host com 16 núcleos, executando 16 processos: Load average: 2.94 2.96 3.01
• A carga de serviço está em torno de 40% , cada uma (16 do mesmo tipo de serviço nesta caixa)

Embora a média de carga seja comparativamente baixa, ainda seguimos uma política de 1:1 . Eu não sou super educado sobre os meandros da contenção de barramento de memória (isto é, encadeamentos no mesmo núcleo terão acesso ao mesmo barramento de memória), mas parece que deveríamos ser capazes de hospedar vários outros processos neste host, considerando o Load average não está nem perto de 16 , o número de núcleos no sistema.

A questão!

O que devo considerar aqui ao sugerir uma nova política de ignorar principalmente as proporções de service:core e, em vez disso, concentrar-se principalmente na carga de serviço e na carga de caixa como KPI? Há mais detalhes granulares que devo considerar para esse tipo de aplicação?

    

Answer 1

Outros fatores além da média de carga incluem uso de memória, alternância de contexto e E / S de disco ou rede (ou pressão de porta efêmera, dependendo de quão gratuitos são os serviços em usar portas), especialmente à medida que mais serviços são agrupados em um único host. Além disso, um sistema 100% carregado pode cair em desastre quando os trabalhos cron diários ou semanais ou mensais são acionados (fato interessante: o assassino da OOM costumava matar sshd , geralmente às 04:00, devido aos diários do cron) então deixar alguma capacidade extra pode ser útil.

Que tipo de monitoramento de serviço você tem? Se você tiver métricas de latência e taxa de transferência para o (s) serviço (s), poderá testar configurações diferentes e comparar esses resultados com o caso de linha de base atual. (Se as coisas piorarem, você pode procurar o gargalo ...)

Além disso, se houver mais problemas em sistemas únicos, qual será a recuperação se essa caixa pegar fogo, em comparação com sua configuração atual?