Acho que a versão do Solaris que estamos executando é muito antiga para relatar tempo de roubo no topo. Existe uma maneira de obter essas informações nesta versão mais antiga do Solaris. Aqui estão as informações básicas da versão:
-bash-3.2$ uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32
Eu não tenho nenhum conhecimento real sobre esses sistemas Sun VM, então posso estar entendendo mal as coisas e pode haver uma maneira melhor de fazer o que preciso nesta situação. Aplicando meu modelo mental da Intel, suspeito que estamos ficando sem CPU, mas como posso medir isso?
Atualizar
Perdoe a terminologia Intelish. Basicamente, estamos executando duas VMs em um único blade, onde uma é um servidor de aplicativos e a outra fornece suporte SSO do aplicativo. Temos momentos em que o servidor de aplicativos fica significativamente mais lento e também temos momentos em que o aplicativo SSO de terceiros vai para o mato.
Também há silos e políticas envolvidas, por isso não tenho visibilidade do host SSO ou da camada de hardware real.
Minha hipótese operacional atual é que quando o aplicativo SSO enlouquece, ele ocupa tanto a CPU que o servidor de aplicativos não consegue obter tempo real de computação suficiente para acompanhar a carga. Analisei os logs do GC do aplicativo e uma coisa que se destacou foram entradas como esta:
[Times: user=0.71 sys=1.36, real=1.47 secs]
Isso ocorre com 10 threads de trabalho GC paralelos, normalmente user >> real >> syse uma causa do padrão de tempo estranho é uma VM onde você não consegue obter CPU suficiente. (Não estamos trocando e os sistemas são todos baseados em SSD, portanto as esperas de E/S não são um problema.)
Neste ponto, preciso obter dados para ajudar a provar essa teoria e, na minha mente do Linux, eu apenas verificaria o st% no topo. Pesquisando no Google também diz que na versão moderna do Solaris eu poderia fazer a mesma coisa. Meu problema é que não estamos executando aquela versão moderna do Solaris.
Responder1
Seu verdadeiro problema aqui parece ser a lentidão no desempenho. E o tempo de roubo provavelmente não faz sentido em um servidor Solaris 10 T1000/T2000.
Para descobrir se você está executando em uma região, use o /usr/bin/zonenamecomando (a localização pode ser diferente em versões diferentes do Solaris - verifique também /bin, /sbin/e /usr/sbin.) Se zonenameretornar algo diferente de global, você está executando em uma região.
Se, por algum motivo, você não tiver acesso ao zonenamecomando, existem vários pscomandos que você pode usar para ver se está em uma zona. Primeiro, procure init:
ps -ef | grep init
Se isso não localizar um initprocesso com um PID de 1, você estará em uma zona. Você também pode procurar zsched(IIRC):
ps -ef | grep zsched
Se isso retornar um processo que é seu próprio pai (PID e PPID são iguais e maiores que 1), então você está executando em uma zona.
Se você estiver em uma zona, poderá enfrentar limitações de recursos que o atrasam. No entanto, não é provável que seja o caso.
O queoutroestá sendo executado no servidor? Incluindo outras zonas. Já vi problemas de desempenho realmente desagradáveis em servidores Sun série T semelhantes ao que você está descrevendo, causados por interações entre o ZFS ARC e aplicativos que usam páginas de memória enormes - como um banco de dados Oracle.
O ZFS ARC usa páginas de memória de 4k, por isso fragmenta a memória - e irá fragmentarTODOSa memória do seu servidor. Se o seu servidor entrar nesse estado e um processo exigir uma quantidade significativa de páginas grandes de memória, o kernel terá que unir um monte de páginas pequenas em páginas grandes, o que envolve movimentar muita memória. E tudo é feito em thread único. E qualquer thread único em um servidor da série T éLENTOjá que os servidores foram projetados para lidar com um grande número de threads com grandes latências - como um servidor web ou servidor de banco de dados que lida com muitas conexões em uma rede.
Portanto, o kernel passa por longos períodos em que praticamente tudo o que faz é unir pequenas páginas de memória em páginas grandes.
Em seguida, o ZFS ARC recupera as páginas depois que o processo de uso de páginas grandes é concluído com elas e elas ficam fragmentadas.
Eu suspeito que você pode estar tendo exatamente o mesmo problema.
Para descobrir, corra
echo ::memstat | mdb -k
como root, na zona global se você estiver executando zonas. Se sua memória livre estiver muito baixa, você pode estar tendo esse problema.
Para descobrir, execute o seguinte script dTrace, novamente como root da zona global para determinar onde o kernel está gastando todo o seu tempo:
#!/usr/sbin/dtrace -s
profile:::profile-1001hz
/arg0/
{
@[ stack() ] = count();
}
Copie isso para um arquivo, digamos hot.d, configure-o como executável ( chmod 755 hot.d) e execute-o como root na zona global:
./hot.d
Execute-o quando estiver enfrentando lentidão. Deixe-o funcionar por uns bons 10-20 segundos, se não mais depois de emitir matched 1 probe, e então interrompa-o com CTRL-C. Em seguida, emitirá ummuitode produção, a maior parte da qual você não se importa. O último punhado de resultados de rastreamentos de pilha, no entanto, serão os mais comuns amostrados, o que lhe dirá onde o kernel está gastando todo o seu tempo.
Isso lhe dirá definitivamente onde está o seu problema. Pode não ser preciso o suficiente para resolvê-lo completamente e você pode precisar fazer mais investigações, mas saberá onde procurar.
Se você vir muitos rastreamentos de pilha nele idleou waitdentro dele, você tem um problema de espaço do usuário. Você pode identificar isso substituindo stack()o script dTrace acima por ustack()para obter a pilha do usuário.
E se você estiver vendo muitos rastreamentos de pilha coalescenos nomes das funções, o kernel está gastando todo o seu tempo criando grandes páginas de memória. A solução para isso é liberar memória, provavelmente limitando o tamanho do ZFS ARC, talvez até severamente. eu tive querótulao ZFS ARC em alguns servidores, até menos de 1 GB, para impedir que ele prejudique o desempenho.