Seu verdadeiro problema aqui parece ser sua lentidão no desempenho. E roubar-tempo provavelmente não faz sentido em um servidor Solaris 10 T1000 / T2000.
Para descobrir se você está executando em uma zona, use o comando /usr/bin/zonename (o local pode ser diferente em versões diferentes do Solaris - verifique também /bin , /sbin/ e /usr/sbin ).zonename retorna algo diferente de global , você está executando em uma zona.
Se, por algum motivo, você não tiver acesso ao comando zonename , existem vários comandos ps que podem ser usados para ver se você está em uma zona. Primeiro, procure por init :
ps -ef | grep init
Se isso não localizar um processo init com um PID de 1 , você estará em uma zona. Você também pode procurar por zsched (IIRC):
ps -ef | grep zsched
Se isso retornar um processo que é seu próprio pai (tanto o PID quanto o PPID são iguais e maiores que 1 ), então você está executando em uma zona.
Se você estiver em uma zona, poderá estar encontrando limitações de recursos que diminuem sua velocidade. Não é provável que seja esse o caso.
O que else está sendo executado no servidor? Incluindo outras zonas. Tenho visto problemas de desempenho realmente desagradáveis nos servidores da série T semelhantes ao que você está descrevendo, causados por interações entre o ARC do ZFS e aplicativos que usam páginas de memória enormes - como um banco de dados Oracle.
O ZFS ARC usa 4k páginas de memória, por isso fragmenta a memória - e fragmentará ALL a memória em seu servidor. Se o seu servidor entrar nesse estado e um processo exigir uma quantidade significativa de grandes páginas de memória, o kernel terá que aglutinar um monte de páginas pequenas em grandes, o que envolve a movimentação de muita memória. E tudo é feito com um único thread. E qualquer encadeamento único em um servidor T-series antigo é LENTO porque os servidores foram projetados para lidar com um grande número de encadeamentos com grandes latências - como um servidor da Web ou de banco de dados que manipula muitas conexões através de uma rede.
Assim, o kernel entra em longos períodos em que tudo o que faz é juntar 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 é feito com elas e elas ficam fragmentadas.
Eu suspeito que você esteja tendo exatamente o mesmo problema.
Para descobrir, corra
echo ::memstat | mdb -k
como root, na região global, se você estiver executando zonas. Se a sua memória livre é muito baixa, você pode estar com este problema.
Para descobrir, execute o script dTrace a seguir, novamente como raiz da região 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, diga hot.d , configure-o como executável ( chmod 755 hot.d ) e execute-o como raiz na região global:
./hot.d
Execute-o quando estiver com lentidão. Deixe-o funcionar por uns bons 10 a 20 segundos, se não mais, depois que ele emite matched 1 probe e, em seguida, divida-o com CTRL-C . Em seguida, ele emitirá um lote de saída, a maioria dos quais você não se importa. O último punhado de saída de rastreios de pilha, no entanto, serão os mais comuns amostrados, o que lhe dirá onde o kernel está gastando todo o tempo.
Isso lhe dirá definitivamente onde está 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 rastreios de pilha com idle ou wait , você tem um problema de espaço do usuário. Você pode identificar isso substituindo stack() no script dTrace acima por ustack() para obter a pilha de usuários.
E se você estiver vendo muitos rastreios de pilha com coalesce nos nomes das funções, o kernel está gastando todo o tempo criando grandes páginas de memória. A solução para isso é liberar memória, provavelmente limitando o tamanho do ARC do ZFS, talvez até severamente. Eu tive que kneecap o ARC do ZFS em alguns servidores, abaixo de 1 GB, para parar de matar o desempenho.