3.3. Informações Específicas do Red Hat Enterprise Linux
Monitorar a largura de banda e utilização da CPU sob o Red Hat Enterprise Linux implica usar as ferramentas abordadas no Capítulo 2; portanto, se você ainda não leu este capítulo, deve fazê-lo antes de prosseguir.
3.3.1. Monitorando a Largura de Banda no Red Hat Enterprise Linux
Conforme apresentado na Seção 2.4.2, é difícil monitorar diretamente a utilização da banda (bandwidth). No entanto, ao examinar as estatísticas a nível dos dispositivos, é possível detectar se a banda insuficiente é um problema em seu sistema.
Usando o vmstat, é possível determinar se a atividade geral dos dispositivos é excessiva, examinando os campos bi e bo. Anotar os campos si e so dá mais algumas pistas sobre o quanto de atividade do disco está designada a atividades I/O relacionadas a swap:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 248088 158636 480804 0 0 2 6 120 120 10 3 87
|
Neste exemplo, o campo bi mostra dois blocos/segundo gravados nos dispositivos de bloco (principalmente drives de disco), enquanto o campo bo mostra seis blocos/segundo lidos pelos dispositivos de bloco. Podemos determinar que nenhuma destas atividades era relacionada ao swapping, já que ambos campos si e so mostram uma taxa de zero kilobytes/segundo de I/O relacionada a swap.
Usando o iostat é possível ter mais algumas pistas sobre as atividades relacionadas ao disco:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003
avg-cpu: %user %nice %sys %idle
5.34 4.60 2.83 87.24
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
dev8-0 1.10 6.21 25.08 961342 3881610
dev8-1 0.00 0.00 0.00 16 0
|
Este output nos mostra que o dispositivo com maior número 8 (/dev/sda, o primeiro disco SCSI) teve média um pouco acima de uma operação I/O por segundo (o campo tsp). A maior parte das atividades I/O deste dispositivo foram gravações (o campo Blk_wrtn), com um pouco mais de 25 blocos gravados a cada segundo (o campo Blk_wrtn/s).
Se você precisar de mais detalhes, use a opção -x do iostat:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003
avg-cpu: %user %nice %sys %idle
5.37 4.54 2.81 87.27
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz
/dev/sda 13.57 2.86 0.36 0.77 32.20 29.05 16.10 14.53 54.52
/dev/sda1 0.17 0.00 0.00 0.00 0.34 0.00 0.17 0.00 133.40
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11.56
/dev/sda3 0.31 2.11 0.29 0.62 4.74 21.80 2.37 10.90 29.42
/dev/sda4 0.09 0.75 0.04 0.15 1.06 7.24 0.53 3.62 43.01
|
Sobre e acima das linhas mais longas contendo mais campos, a primeira coisa para ter em mente é que este output do iostat agora mostra as estatísticas por partição. Usando o df para associar os pontos de montagem aos nomes dos dispositivos, é possível usar este relatório para determinar, por exemplo, se a partição contendo o /home/ está sobrecarregada de trabalho.
Na verdade, cada linha do output do iostat -x é mais longa e contém mais informações que esta. Aqui está o resto de cada linha (com a adição da coluna dos dispositivos para facilitar a leitura):
Device: avgqu-sz await svctm %util
/dev/sda 0.24 20.86 3.80 0.43
/dev/sda1 0.00 141.18 122.73 0.03
/dev/sda2 0.00 6.00 6.00 0.00
/dev/sda3 0.12 12.84 2.68 0.24
/dev/sda4 0.11 57.47 8.94 0.17
|
Neste exemplo é interessante notar que /dev/sda2 é a partição swap do sistema. É óbvio que o swapping não é um problema neste sistema, devido os diversos campos apresentando 0.00 para esta partição.
Um outro ponto interessante é o /dev/sda1. As estatísticas desta partição são incomuns - a atividade geral parece baixa, mas por que o tamanho médio do pedido I/O (o campo avgrq-sz), o tempo médio de espera (o campo await) e o tempo médio de serviço (o campo svctm) são tão maiores que os das outras partições? A resposta é que a partição contém o diretório /boot/, onde o kernel e o disco ram inicial estão armazenados. Quando o sistema inicializar, as I/Os de leitura (note que somente os campos rsec/s e rkB/s são diferentes de zero; nenhuma gravação é feita aqui regularmente) usados durante o processo de inicialização são destinados a números grandes de blocos, resultando na espera e tempos de serviço relativamente longos apresentados pelo iostat.
É possível usar o sar para uma visão geral mais longa das estatísticas I/O. Por exemplo: o sar -b apresenta um relatório geral de I/O:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003
12:00:00 AM tps rtps wtps bread/s bwrtn/s
12:10:00 AM 0.51 0.01 0.50 0.25 14.32
12:20:01 AM 0.48 0.00 0.48 0.00 13.32
…
06:00:02 PM 1.24 0.00 1.24 0.01 36.23
Average: 1.11 0.31 0.80 68.14 34.79
|
Aqui, assim como na apresentação inicial do iostat, as estatísticas são agrupdas para todos os dispositivos de bloco.
Um outro relatório relacionado a I/O é produzido usando o sar -d:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003
12:00:00 AM DEV tps sect/s
12:10:00 AM dev8-0 0.51 14.57
12:10:00 AM dev8-1 0.00 0.00
12:20:01 AM dev8-0 0.48 13.32
12:20:01 AM dev8-1 0.00 0.00
…
06:00:02 PM dev8-0 1.24 36.25
06:00:02 PM dev8-1 0.00 0.00
Average: dev8-0 1.11 102.93
Average: dev8-1 0.00 0.00
|
Este relatório oferece informações por dispositivo, mas com poucos detalhes.
Apesar de não haver estatísticas explícitas sobre a utilização da banda para um determinado canal ou central de dados, nós podemos pelo menos determinar o que os dispositivos estão fazendo e usar suas atividades para determinar indiretamente a carga do canal.
3.3.2. Monitorando a Utilização da CPU no Red Hat Enterprise Linux
Ao contrário da banda, monitorar a utilização da CPU é bem mais simples. Desde uma porcentagem da utilização da CPU no Sistema de Monitoramento GNOME às estatísticas mais aprofundadas reportadas pelo sar, é possível determinar com acuracidade o quanto de poder da CPU está sendo consumido e pelo que.
Além do Sistema de Monitoramento GNOME, o top é a primeira ferramenta de monitoramento de recursos abordada no Capítulo 2 para oferecer uma representação mais profunda da utilização da CPU. Aqui está um relatório do top sobre uma estação de trabalho com processador duplo:
9:44pm up 2 days, 2 min, 1 user, load average: 0.14, 0.12, 0.09
90 processes: 82 sleeping, 1 running, 7 zombie, 0 stopped
CPU0 states: 0.4% user, 1.1% system, 0.0% nice, 97.4% idle
CPU1 states: 0.5% user, 1.3% system, 0.0% nice, 97.1% idle
Mem: 1288720K av, 1056260K used, 232460K free, 0K shrd, 145644K buff
Swap: 522104K av, 0K used, 522104K free 469764K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
30997 ed 16 0 1100 1100 840 R 1.7 0.0 0:00 top
1120 root 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X
1260 ed 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal
888 root 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail
1264 ed 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui
1 root 15 0 476 476 424 S 0.0 0.0 0:05 init
2 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0
3 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1
4 root 15 0 0 0 0 SW 0.0 0.0 0:01 keventd
5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
6 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1
7 root 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd
8 root 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush
9 root 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated
10 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd
|
A primeira informação relativa a CPU está na primeira linha: a média de carga (load average). A média de carga corresponde ao número médio de processos executáveis no sistema. A média de carga é frequentemente listada como um conjunto de três números (como o top faz), que representam a média da carga nos últimos 1, 5 e 15 minutos, indicando que o sistema não estava muito ocupado neste exemplo.
A próxima linha, apesar de não ser restritamente relativa à utilização da CPU, tem uma relação indireta, pois mostra o número de processos executáveis (aqui, somente um - lembre este número pois significa algo especial neste exemplo). O número de processos executáveis é um bom indicador do quão intregrado à CPU o sistema deve ser.
Em seguida, há duas linhas apresentando a utilização corrente de cada uma das duas CPU no sistema. As estatísticas de utilização estão detalhadas para mostrar se os ciclos da CPU foram gastos para processamento no nível de usuário ou no nível do sistema. Também há estatísticas que mostram quanto tempo de CPU foi gasto com processos com prioridades de agendamento alteradas. Finalmente, há uma estatística de tempo ocioso.
Um pouco mais abaixo, na seção relativa a processos, nós podemos observar que o processo usando a maior parte do poder da CPU é o próprio top; ou seja, o único processo executável neste sistema era o top tirando uma "foto" de si mesmo.
 | Dica |
|---|---|
É importante lembrar que o próprio ato de rodar o monitoramento do sistema afeta as estatísticas de utilização dos recursos que você recebe. Todos os monitores baseados em software fazem isso de alguma maneira. |
Para obter um conhecimento mais detalhado sobre a utilização da CPU, nós devemos mudar de ferramentas. Se examinarmos o output do vmstat, obteremos um entendimento ligeiramente diferente de nosso sistema exemplo:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 233276 146636 469808 0 0 7 7 14 27 10 3 87
0 0 0 0 233276 146636 469808 0 0 0 0 523 138 3 0 96
0 0 0 0 233276 146636 469808 0 0 0 0 557 385 2 1 97
0 0 0 0 233276 146636 469808 0 0 0 0 544 343 2 0 97
0 0 0 0 233276 146636 469808 0 0 0 0 517 89 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 32 518 102 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 91 2 1 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 72 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 88 2 0 97
0 0 0 0 233276 146636 469808 0 0 0 0 516 81 2 0 97
|
Usamos aqui o comando vmstat 1 10 para examinar o sistema a todo segundo por dez vezes. Primeiramente, as estatísticas relativas à CPU (os campos us, sy e id) parecem similares ao output do top, e pode até parecer um pouco menos detalhado. No entanto, ao contrário do top, nós também podemos obter alguma pista sobre como a CPU está sendo utilizada.
Se examinarmos os campos do system, percebemos que a CPU está tendo em média aproximadamente 500 interrupções por segundo e está alternando entre processos entre 80 e 400 vezes por segundo. Se você acha que isto parece muito ativo, pense novamente, pois o processamento a nível do usuário (o campo us) está apenas na média de 2%, enquanto o processamento a nível do sistema (o campo sy) geralmente está abaixo de 1%. Mais uma vez, este é um sistema ocioso.
Ao rever as ferramentas que o Sysstat oferece, percebemos que o iostat e o mpstat oferecem poucas informações adicionais em relação ao que vimos anteriormente com top e vmstat. Entretanto, o sar produz uma variedade de relatórios muito úteis ao monitorar a utilização da CPU.
O primeiro relatório é obtido através do comando sar -q, que apresenta o comprimento da fila de execução, o número total de processos e as médias de carga nos últimos um e cinco minutos. Eis uma exemplo:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003
12:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5
12:10:00 AM 3 122 0.07 0.28
12:20:01 AM 5 123 0.00 0.03
…
09:50:00 AM 5 124 0.67 0.65
Average: 4 123 0.26 0.26
|
Neste exemplo, o sistema está sempre ocupado (dado que mais de um processo é executável ao mesmo tempo), mas não está sobrecarregado (devido o fato que este sistema em particular tem mais de um processador).
O próximo relatório do sar relativo à CPU é produzido pelo comando sar -u:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003
12:00:01 AM CPU %user %nice %system %idle
12:10:00 AM all 3.69 20.10 1.06 75.15
12:20:01 AM all 1.73 0.22 0.80 97.25
…
10:00:00 AM all 35.17 0.83 1.06 62.93
Average: all 7.47 4.85 3.87 83.81
|
As estatísticas contidas neste relatório não são diferentes daquelas produzidas por muitas das outras ferramentas. O maior benefício deste é que o sar disponibiliza os dados intermitentemente e, portanto, é mais útil para obter médias a longo prazo ou para a produção de gráficos de utilização da CPU.
Em sistemas com multi-processadores, o comando sar -U pode produzir estatísticas para um determinado processador ou para todos os processadores. Aqui está um exemplo do output do sar -U ALL:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003
12:00:01 AM CPU %user %nice %system %idle
12:10:00 AM 0 3.46 21.47 1.09 73.98
12:10:00 AM 1 3.91 18.73 1.03 76.33
12:20:01 AM 0 1.63 0.25 0.78 97.34
12:20:01 AM 1 1.82 0.20 0.81 97.17
…
10:00:00 AM 0 39.12 0.75 1.04 59.09
10:00:00 AM 1 31.22 0.92 1.09 66.77
Average: 0 7.61 4.91 3.86 83.61
Average: 1 7.33 4.78 3.88 84.02
|
O comando sar -w reporta o número de alternações de contexto por segundo, possibilitando obter pistas adicionais sobre onde os ciclos da CPU estão sendo gastos:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003
12:00:01 AM cswch/s
12:10:00 AM 537.97
12:20:01 AM 339.43
…
10:10:00 AM 319.42
Average: 1158.25
|
Também é possível produzir dois relatórios diferentes do sar sobre a atividade da interrupção. O primeiro (produzido usando o comando sar -I SUM) apresenta apenas uma estatística de "interrupções por segundo":
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003
12:00:01 AM INTR intr/s
12:10:00 AM sum 539.15
12:20:01 AM sum 539.49
…
10:40:01 AM sum 539.10
Average: sum 541.00
|
Usando o comando sar -I PROC, é possível detalhar a atividade por processo (em sistemas com multi-processadores) e por nível de interrupção (de 0 a 15):
Linux 2.4.21-1.1931.2.349.2.2.entsmp (pigdog.example.com) 07/21/2003
12:00:00 AM CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s
12:10:01 AM 0 512.01 0.00 0.00 0.00 3.44 0.00 0.00
12:10:01 AM CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s
12:20:01 AM 0 512.00 0.00 0.00 0.00 3.73 0.00 0.00
…
10:30:01 AM CPU i000/s i001/s i002/s i003/s i008/s i009/s i010/s
10:40:02 AM 0 512.00 1.67 0.00 0.00 0.00 15.08 0.00
Average: 0 512.00 0.42 0.00 N/A 0.00 6.03 N/A
|
Este relatório (que foi truncado horizontalmente para caber na página) inclui uma coluna para cada nível de interrupção (ex.: o campo i002/s ilustrando a taxa do nível 2 de interrupção). Se este fosse um sistema com multi-processador, haveria uma linha por período de amostra para cada CPU.
Um outro ponto importante a notar sobre este relatório é que o sar adiciona ou remove campos de interrupção específicos se não houver dados coletados parta este campo. O relatório exibido acima oferece um exemplo disto - o fim do relatório inclui os níveis de interrupção (3 e 10) que não estavam presentes no início do período de amostragem.
 | Nota | ||
|---|---|---|---|
Há outros dois relatórios do sar relativos à interrupções — sar -I ALL e sar -I XALL. No entanto, a configuração default do utilitário de levantamento de dados sadc não coleta as informações necessárias para estes relatórios. Isto pode ser alterado ao editar o arquivo /etc/cron.d/sysstat e alterar esta linha:
para esta:
Tenha em mente que esta alteração faz com que o sadc levante informações adicionais, resultando em tamanhos maiores de arquivos de dados. Portanto, assegure que a configuração de seu sistema possa suportar o consumo de espaço adicional. |