Quantos comutadores de contexto são "normais" (em função dos núcleos da CPU (ou outros))?

34

Olá Overlords do Linux / UNIX,

Algum de vocês tem uma regra prática sobre quantas alternâncias de contexto (por núcleo do processador) são normais em um servidor Linux?

Minha faculdade aqui trouxe isso, e ele está vendo 16K em uma x86_64máquina de 8 núcleos .

Aqui estão algumas estatísticas do sarface nos últimos dias ...

texto alternativo http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

E para ver as estatísticas de criação do processo, aqui está uma visão logarítmica do mesmo gráfico ...

texto alternativo http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

E os 8 núcleos estão entediados até a morte ...

texto alternativo http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS vs IOwait (escala x10000)

texto alternativo http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Mais informações inúteis no caso de alguém perguntar ..

O armazenamento em que o servidor trabalha é uma SAN de 0,5 TB via FC
Há 8 GB de RAM, principalmente cache - sem troca.

linux performance context-switch

— Xerxes
fonte

11

Em algum período em particular?

— dmckee

Você pode ser mais específico sobre a carga de trabalho?

— Dmo 29/05/2009

11

Como você criou esse gráfico? Parece muito bom!

— Antoine Benkemoun

Oi Antoine - Os gráficos são feitos a partir de sarface ( projects.autonomy.net.au/sarface )

— Xerxes

os links do gráfico estão mortos a partir de agora. @Xerxes você pode chegar lá de algum lugar?

— törzsmókus 15/1118

25

Isso depende muito do tipo de aplicativo que você executa. Se você possui aplicativos que são syscalls WRT muito acionados, pode esperar ver grandes quantidades de alternância de contexto. Se a maioria de seus aplicativos ficar inativa e acordar apenas quando houver coisas acontecendo em um soquete, você poderá esperar taxas baixas de troca de contexto.

Chamadas do sistema

As chamadas do sistema causam alternâncias de contexto por sua própria natureza. Quando um processo faz uma chamada de sistema, basicamente diz ao kernel para assumir o seu ponto atual no tempo e na memória para fazer coisas que o processo não tem o privilégio de fazer e retornar ao mesmo local quando terminar.

Quando analisamos a definição do syscall write (2) do Linux, isso fica muito claro:

NOME
       write - grava em um descritor de arquivo

SINOPSE
       #incluir 

       ssize_t write (int fd, const void * buf, size_t count);

DESCRIÇÃO
       write () escreve até contar bytes do buffer apontado para o arquivo
       referido pelo descritor de arquivo fd. [..]

VALOR DE RETORNO
       Em caso de sucesso, o número de bytes gravados é retornado (zero indica
       nada foi escrito). Em caso de erro, -1 é retornado e errno é definido
       adequadamente.
       [..]

Isso basicamente diz ao kernel para assumir a operação do processo, mover para countbytes, começando pelo endereço de memória apontado por *bufpara o descritor fdde arquivo do processo atual e, em seguida, retorne ao processo e diga a ele como foi.

Um bom exemplo para mostrar isso é o servidor de jogos dedicado para jogos baseados em Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 mostra um segundo de syscalls feitos por uma única instância de um servidor de jogo que não tinha jogadores. Esse processo leva cerca de 3% do tempo de CPU em um Xeon X3220 (2.4Ghz), apenas para lhe dar uma idéia de quão caro isso é.

Multitarefa

Outra fonte de alternância de contexto pode ser processos que não fazem syscalls, mas precisam ser movidos de uma determinada CPU para abrir espaço para outros processos.

Uma boa maneira de visualizar isso é cpuburn . O cpuburn não realiza nenhum syscalls, apenas itera sobre a própria memória, portanto não deve causar nenhuma alternância de contexto.

Pegue uma máquina inativa, inicie o vmstat e execute um burnMMX (ou qualquer teste diferente do pacote cpuburn) para cada núcleo de CPU que o sistema possui. Você deve ter uma utilização completa do sistema até então, mas quase nenhuma alternância de contexto aumentada. Em seguida, tente iniciar mais alguns processos. Você verá que a taxa de alternância de contexto aumenta à medida que os processos começam a competir pelos núcleos da CPU. A quantidade de alternância depende da relação processos / núcleo e da resolução multitarefa do seu kernel.

Leitura adicional

O linfo.org tem uma boa descrição sobre o que são comutadores de contexto e chamadas de sistema . A Wikipedia possui informações genéricas e uma boa coleção de links nas chamadas do sistema.

— Michael Renner
fonte

11

Isso tem sido útil - você me deu uma ótima ideia! =)

— Xerxes

11

Sua afirmação System calls cause context switches by their very own natureparece errada. Sistema chama causa interruptor do modo como foi afirmado pela linfo.org/context_switch.html

— Nicolas Labrot

6

meu servidor da Web moderadamente carregado fica em torno de 100-150 switches por segundo na maioria das vezes, com picos de milhares.

Altas taxas de troca de contexto não são um problema, mas podem apontar o caminho para um problema mais significativo.

editar: opções de contexto são um sintoma, não uma causa. O que você está tentando executar no servidor? Se você possui uma máquina com multiprocessador, tente configurar a afinidade da CPU para os processos principais do servidor.

Como alternativa, se você estiver executando o X, tente entrar no modo de console.

edite novamente: a 16k cs por segundo, cada CPU tem em média dois comutadores por milissegundo - ou seja, metade a um sexto da fatia de tempo normal. Ele poderia estar executando muitos encadeamentos vinculados de E / S?

editar novamente postar gráficos: Certamente parece vinculado ao IO. o sistema está passando a maior parte do tempo no SYS quando as alternâncias de contexto são altas?

edite mais uma vez: iowait e sistema elevados no último gráfico - eclipsando completamente o espaço do usuário. Você tem problemas de IO.
Qual cartão FC você está usando?

editar: hmmm. Alguma chance de obter alguns benchmarks no acesso à SAN com bonnie ++ ou dbench durante o tempo morto? Eu estaria interessado em ver se eles têm resultados semelhantes.

editar: Estive pensando sobre isso no fim de semana e vi padrões de uso semelhantes quando Bonnie está fazendo o passe "escrever um byte de cada vez". Isso pode explicar a grande quantidade de comutações em andamento, pois cada gravação exigiria uma chamada de sistema separada.

— jay_dubya
fonte

Ainda não estou convencido de que uma alta taxa de troca de contexto não seja um problema, estou falando de alta como em 4K a 16K, não em 100-150.

— Xerxes

Nenhum de nossos servidores executa X. Concordo com você no problema de espera de E / S e na relação entre isso e o CS. A placa HBA não é suspeita, porque usamos a mesma placa em outras centenas de servidores ... Conclusão: eu culpo as péssimas SAN EVA SAN das equipes da SAN que elas tentam desesperadamente defender o tempo todo. Observe que uma alta espera de E / S nem sempre é motivo para se alarmar; se a maioria dos processos em uma máquina estiver vinculada a E / S, é esperado que o servidor não tenha nada melhor para executar rotações ociosas.

— Xerxes

No segundo, porém - o quarto gráfico em anexo mostra que não é tão próximo quanto eu pensava no começo. Não é exatamente um eclipse, por qualquer meio. Eu ainda culpo a SAN. =)

— Xerxes

1

Estou mais inclinado a me preocupar com a taxa de ocupação da CPU do estado do sistema. Se estiver perto de 10% ou mais, isso significa que seu sistema operacional está gastando muito tempo fazendo as alternâncias de contexto. Embora mover alguns processos para outra máquina seja muito mais lento, merece fazê-lo.

1

É por isso que você deve tentar manter as linhas de base de desempenho para seus servidores. Dessa forma, você pode comparar as coisas que percebe de repente com as que gravou no passado.

Dito isto, tenho servidores em execução (principalmente servidores Oracle não muito ocupados), que são constantes em torno de 2k com alguns picos de 4k. Para meus servidores, isso é normal, para servidores de outras pessoas que podem estar muito baixos ou muito altos.

Até onde você pode voltar nos seus dados?

Que tipo de informação da CPU você pode nos fornecer?

— wzzrd
fonte

Definitivamente, concordo em manter uma linha de base, e temos dados nagios que remontam a longos períodos - o problema com este servidor é que é sangue novo - só existe há pouco tempo. Além disso, ele está executando o software corporativo (leia-se: porcaria) - Teamsite - apenas para adicionar à lista de variáveis indefinidas. Eu ainda prefiro sar (preferência pessoal), por isso vou configurá-lo para manter mais do que o padrão (2 semanas) e ver como vai.

— Xerxes

Usar o sar em combinação com o rrdtool (do qual parecem os seus gráficos) pode ser um meio fácil de manter seus dados (ou pelo menos resumos deles) por um longo tempo.

— wzzrd

0

Não há regra de ouro. Uma alternância de contexto é apenas a CPU que passa do processamento de um encadeamento para outro. Se você executar muitos processos (ou alguns altamente encadeados), verá mais opções. Felizmente, você não precisa se preocupar com quantas alternâncias de contexto existem - o custo é pequeno e mais ou menos inevitável.

— Alex J
fonte

6

Na verdade, o custo de uma alternância de contexto é caro . Isso é ainda pior em máquinas virtuais - fizemos alguns testes alguns meses atrás, que mostraram que uma das maiores causas do desempenho da VM era a alternância de contexto.

— Xerxes

De fato, em qualquer sistema operacional moderno (multitarefa), a minimização da alternância de contexto é uma tarefa de otimização muito significativa. Você tem alguma fonte para fazer backup de sua alegação de que o custo é pequeno?

— Xerxes

Você está falando em minimizar as alternâncias de contexto da perspectiva do desenvolvimento do sistema operacional? Não tendo nada a ver com esse desenvolvimento, não tenho opinião sobre os benefícios de projetar um sistema para minimizar o CS :) Se você está falando em minimizar as alternâncias de contexto em um servidor, o problema é mitigar as alternâncias de contexto que introduzem latência em outros lugares. Por exemplo, reduzir o número de processos em uma máquina significa que você deve mover esses processos para outra máquina, o que significa que a comunicação ocorre através de uma rede, que é muito mais lenta!

— 287 Alex J

Acredito que sua definição de alternância de contexto é falha; elas também acontecem quando uma chamada do sistema é executada, mesmo que ela retorne ao mesmo encadeamento. Os aplicativos otimizam isso fazendo vários truques. Por exemplo, o Apache precisa obter tempo do sistema com muita frequência; para esse propósito, um thread chama a hora local repetidamente e armazena o resultado na memória compartilhada. Os outros threads precisam apenas ler da RAM e não sofrem uma troca de processo ao fazê-lo.

— NiXar 29/05/2009