Estamos enfrentando períodos intermitentes de 100% de utilização da CPU.
Configuração do servidor:
HP DL580 G7 (4 processadores com 8 núcleos cada; memória de 128 GB.)
Sistema operacional: Atualização do Solaris 10_x86 9
Aplicação: Oracle 10 R2; ASM para gerenciamento de disco. Tamanho do DB 5TB; SGA 78GB
Subsistema de Armazenamento: Armazenamento conectado direto SAS do Controlador Duplo MSA2312sa SAS
Em um dia normal (20% de utilização da CPU), a saída vmstat é fornecida abaixo: kthr falhas de disco da página de memória cpu < br> rbw swap livre re mf pi po fr de sr s0 s1 s2 s3 em sy cs us sy id
0 27 26 128133040 6469184 362 4937 829 3 22 0 117 -0 4 0 97 85888 383138 19238 19 2 79 |
0 20 31 129089972 4009408 294 4341 28 0 0 0 0 0 2 0 96 144240 363898 27797 12 5 82 |
1 17 31 128869152 3731692 243 4437 0 0 0 0 0 0 6 0 88 142738 385237 26503 10 5 84
1 21 31 128803936 3665112 283 5545 111 0 0 0 0 0 3 0 102 157962 347356 26940 12 5 82 |
2 20 31 128556548 3515596 274 10806 0 0 0 0 0 0 6 0 99 253881 391554 34754 13 7 80
Resumo dos processos:
Executar processos de fila- 0 ~ 2
Processos Bloqueados - 17 ~ 27
Processos Trocados - 31
Resumo da Utilização da CPU:
Usuário: 10% a 20%
Sistema - 2% ~ 7%
Idle- 79% ~ 85%
Qual pode ser a causa de tal comportamento de CPU irrático?
Por que os Processos Bloqueados (b) e Trocados (w) são muito mais altos nos Processos em Execução (r)?
Estamos olhando para o gargalo da CPU ou gargalo de memória ou gargalo de E / S?
Nós executamos o backup do Oracle RMAN, mas o backup é concluído às 4 da manhã todos os dias.
Considerando que a utilização da CPU dispara em até 100% durante o horário comercial normal (das 10h às 18h), nenhum backup em segundo plano é executado durante esse período.
Quanto às grandes consultas, executamos consultas bastante longas e complexas. Essas consultas são executadas todos os dias e a utilização da CPU mal ultrapassa 40%, mas na última semana estamos passando por curtos períodos de 100% de utilização da CPU.
Você tem o mesmo número de processadores que o sistema host? Nesse caso, isso é uma coisa ruim e pode impedir que o agendador funcione corretamente. Ou seja, se você tem um sistema de 8 núcleos, nenhum sistema nessa caixa deve ter 8 núcleos atribuídos a ele. Você pode ter 20 VMs com 4 Núcleos atribuídos e isso não é um problema, mas 1 caixa com 8 núcleos atribuídos pode causar problemas sob carga.
Você está experimentando 100% de utilização em todos os 32 núcleos de CPU ou apenas alguns? Não consigo falar com as estatísticas que você postou, pois elas são bastante ilegíveis, mas tente dar algumas respostas gerais para as coisas que você está enfrentando:
Processos bloqueados / trocados Às vezes, os processos em um sistema operacional de servidor serão vinculados a um núcleo de CPU específico e APENAS usarão esse núcleo para o que for necessário, ignorando todos os outros núcleos. Isso geralmente é mais um problema para os softwares mais antigos que não foram projetados para serem executados em sistemas com vários núcleos. O resultado final é que, se você tiver alguns processos fazendo isso e eles decidirem usar o mesmo núcleo, eles constantemente bloquearão e trocarão um ao outro para fazer o que precisam fazer, enquanto você tem outros núcleos ociosos para não fazer nada. Às vezes, você pode configurar o software para escolher núcleos específicos e manualmente "balancear a carga" dos processos em suas CPUs (semelhante às configurações manuais de IRQ no passado), mas isso é obviamente indesejável, pois exige uma reconfiguração manual de sua parte e você pode acabar piorando as coisas. Descobrir quais processos estão bloqueando uns aos outros e focar neles. Eu duvido que você tenha um gargalo de CPU com 32 núcleos, mas eu também não posso dizer com certeza. Leia a documentação sobre os processos / software para ver o que o fornecedor recomenda e se você pode até mesmo configurar o processo para fazer isso.
Processos bloqueados / trocados superiores aos processos em execução Provavelmente o que está acontecendo é que seu contador de desempenho está apenas aumentando toda vez que um processo é bloqueado / trocado e não está mostrando os processos CURRENT bloqueados / trocados, então isso deve ser sempre maior do que seus processos em execução (que é exatamente o que diz número de processos atualmente em execução no seu sistema). Isso não deve ser uma preocupação.
À primeira vista, seu sistema sofreu uma grave falta de memória RAM no passado. A taxa média de varredura desde a última inicialização é de 117, enquanto deveria ser 0 ou próxima a ela em um sistema com RAM suficiente. Isso parece ser confirmado por sua coluna de 31 w, o que provavelmente significa que 31 daemons foram trocados durante o evento de falta de memória ram e nunca mais voltaram a ser usados.
Você tem algum processo de backup automatizado ou algo que esteja debatendo o (s) disco (s)? Soa vagamente como se você tivesse problemas de espera. Você consegue um instantâneo do mpstat enquanto o seu servidor está infeliz? Você provavelmente poderia descartar o problema de i / o do disco fazendo pequenas gravações de 5 GB em disco ou algo no modo DIRECT_IO (para contornar o fato de você poder armazenar em cache metade da terra em memória livre naquele servidor). Além disso, você já tentou (se é capaz) examinar suas consultas durante esse período? Talvez alguém esteja batendo em você com um monte de varreduras de índice completo ou algo assim?