Lentidão nas saídas no Solaris 8

Question

Não sou especialista em Solaris, estou acostumado com o sistema operacional Windows. De qualquer forma, estou tendo dificuldades em descobrir um problema que está ocorrendo, mas não consigo encontrar uma resposta.

Temos um servidor físico com o Solaris 11, que possui 3 LDOMs w / Solaris 10. Cada LDOM tem uma zona (além da global, a zona global não tem nenhuma configuração). Essa Zona é um Solaris 8 (isso se deve aos aplicativos executados sob ela que não suportam uma versão do Solaris superior a 8)

Agora, temos problemas com o Zone, o DB está em um disco, enquanto o software e outras coisas estão em discos diferentes. Os usuários estão reclamando que o servidor se sente lento.

Quando eu verifico o status com top e iostat, as coisas parecem com isso

load averages:  1.82,  1.74,  2.71                                                                             09:45:06
1047 processes:1040 sleeping, 2 zombie, 2 stopped, 3 on cpu
CPU states: 85.0% idle, 11.5% user,  3.5% kernel,  0.0% iowait,  0.0% swap
Memory: 56G real, 12G free, 25G swap in use, 8798M swap free

[imagem]

O maior valor para carga foi

5.xx 6.xx 
CPU States: 40% idle,
Memory: 4G free

Enquanto os resultados do iostat mostram

root # iostat -xtc
                  extended device statistics                      tty         cpu
device       r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b  tin tout  us sy wt id
vdc0         0.3    1.0    4.4   14.2  0.0  0.0   33.1   0   0    2  112  141 172  0 162
vdc1        40.9    3.6  667.9   78.7  0.0  0.2    3.4   0   8
vdc2         2.0    1.0  127.1    5.1  0.0  0.0    2.7   0   0
vdc3         0.0    3.8    0.0   90.9  0.0  0.0    3.8   0   1
vdc4        62.6   31.5 17615.7 1232.5  0.0  7.4   78.9   1  82
vdc5        12.5    7.9  281.2  421.3  0.0  0.1    7.2   0   4
vdc6         0.0    0.0    0.0    0.0  0.0  0.0    2.8   0   0
vdc7         0.0    7.3    0.0  451.0  0.0  0.0    2.1   0   1
vdc8        40.6    3.6  667.9   78.8  0.0  0.1    3.3   0   8

[imagem]

O disco 4 (vdc4), onde o DB está localizado, tem uma porcentagem alta de% b o tempo todo e sempre tem pelo menos um processo em espera (% w), não tenho certeza se parece ruim, mas considerando que de 150 usuários acessá-lo, considero OK. Me corrija se eu estiver errado

Agora, sempre que o usuário X está listando ou pressionando enter no CMD, o servidor demora muito para mostrar a nova entrada, não tem problemas com o login, eles realmente fazem o login rapidamente através do ssh. O estranho é que o usuário root está funcionando bem quando está reclamando. Não importa se o servidor está baixo ou alto em recursos, o mesmo problema sempre acontece.

Verificando o que está executando o usuário, este é seu único processo.

# ps -fu user
     UID   PID  PPID   C    STIME TTY         TIME CMD
user       6027  6024   0 08:13:14 pts/15      0:00 -ksh
user       186   181   0 09:40:48 pts/4       0:00 -ksh
user       555 15455   0 09:42:52 ?           0:00 in.ftpd
user       14114 14104   0 08:42:06 pts/7       0:00 -ksh
user       24325 14114   0 09:15:28 pts/7       0:00 tail -f XXXXXXXX
user       26 15119   0   May 30 ?           0:35 ./oplinkse_SGCR6
user       8412 15119   0 01:59:24 ?           0:01 XXXXXXXXXXXXXXXXXXXX
user       27    26   0   May 30 ?           7:00 ./oplinkse_SGCR6
user       1504  6027   0 09:46:24 pts/15      0:00 tail -f XXXXXXXX
user       5818  5815   0 08:12:39 pts/14      0:00 -ksh

[image]

Eles só estão visualizando alguns arquivos e estão conectados ao DB através de 2 sessões openlink. Mesmo quando eles não estão rodando nada e só querem ls -l um diretório que tem 3 arquivos demora (até 1min algumas vezes)

O que poderia ser verificado para descobrir o problema?

Eu pesquisei na internet, mas qualquer coisa que eu descobrir é sobre o prompt de login lento através do SSH para os usuários e isso não é algo que acontece aqui, porque eles obtêm o prompt de login imediatamente, mas após o login um para executar um comando fica lá por muitos segundos.

    

Answer 1

Primeiro, você pode expandir: "Os usuários estão reclamando que o servidor se sente lento". Algumas das suas sugestões sugerem um atraso de rede, enquanto outras sugerem lentidão no aplicativo.

Como você está usando LDOMs (agora Oracle VM for SPARC), você deve estar usando um servidor SPARC. O hardware, v11 e LDOM também seriam úteis. Você também quer dar a configuração para cada LDOM. Talvez um problema de configuração?

Também estou querendo saber se você pode obter um melhor desempenho tendo apenas (1) o Solaris 10 LDOM em seu sistema v11 (que eu suponho que não seja possível executar v10), com (3) zonas com marca Solaris 8. Vs sua configuração atual de (3) ldoms cada executando (1) zona de marca do Solaris 8.

Link útil na execução da marca Solaris 8 zone ?

    

Answer 2

Esta não é realmente uma resposta, mas um comentário não funcionará para isso e é uma ferramenta de solução de problemas que pode ajudar a obter uma resposta.

Este script do DTrace dará uma boa indicação de onde o kernel do seu sistema está gastando seu tempo:

#!/usr/sbin/dtrace -s

#pragma D option quiet

profile:::profile-1001hz
/ arg0 /
{
    @hot[ arg0 ] = count();
}

dtrace:::END
{
    printa( "%@u %a\n", @hot );
}

Ele captura muitas amostras da função atual de todos os threads do kernel, então se o seu sistema estiver gastando muito tempo executando um pequeno conjunto de tarefas, este pequeno script irá revelar isso muito rapidamente.

Para ver a pilha atual do kernel, você pode usar

#!/usr/sbin/dtrace -s

#pragma D option quiet

profile:::profile-1001hz
/ arg0 /
{
    @hot[ stack() ] = count();
}

dtrace:::END
{
    printa( "%@u %a\n", @hot );
}

Salve-o em um arquivo como hot.d , torne o arquivo executável com algo como chmod 755 hot.d e, como root, execute-o: ./hot.d . Não irá emitir nenhuma saída. Deixe-o funcionar por um bom tempo, como 30 segundos ou mais. Em seguida, pressione CTRL-C para pará-lo. Em seguida, ele emitirá toda a função atual do kernel ou rastreamentos de pilha que ele encontrou quando estava em execução, em ordem crescente de quantas vezes esse rastreio específico de pilha foi observado.

As últimas funções ou rastreamentos de pilha na saída de saída provavelmente revelarão o que seu sistema está gastando a maior parte do tempo fazendo.

Por exemplo, se seu kernel estiver gastando a maior parte do tempo fazendo algo como unir páginas de memória fragmentadas em grandes páginas exigidas por um banco de dados Oracle, você o verá imediatamente.

Execute-o no hipervisor do Solaris 11 e, em seguida, em cada uma das zonas globais.