q
1 top. 1 Vmstat. 1 Iostat. 1 sar e Ksar.
Em função da arquitetura do PostgreSQL, que trata cada conexão por um processo do SO, podemos monitorar a saúde do banco monitorando os processos do SO pertencentes ao PostgreSQL.
A seguir analisaremos os utilitários e ferramentas que permitem esse monitoramento.
top
Para monitorar processos no Linux talvez a ferramenta mais famosa seja o top. O top é um utilitário básico na administração de servidores e podemos extrair informações valiosas. Basta executar “top” na shell para invocá-lo. Pode ser útil com o PostgreSQL exibir detalhes do comando com -c e filtrar apenas os processos do usuário postgres com -u.
$ top -p postgres -c
Com o top, podemos verificar facilmente o load médio dos últimos 1min, 5min e 15min, números de processos totais, número de processos em execução, total de memória usada, livre, em cache ou em swap. Percentual de CPU para processos do kernel(sys), demais processos(us) e esperando I/O (wa). Mas, principalmente, podemos verificar os processos que estão consumindo mais CPU.
Merece destaque a coluna S, que representa o estado do processo. O valor “D” indica que o processo está bloqueado, geralmente aguardando operações de disco. Deve-se acompanhar se está ocorrendo com muita frequência ou por muito tempo.
Figura 5.2
Monitoramento de processos com top.
Existem diversas variações do top: uma opção com uma interface mais amigável é o htop.
Ad m in is tr aç ão d e B an co d e D ad os
vmstat
Outra importante ferramenta é a vmstat. Ela mostra diversas informações dos recursos por linha em intervalos de tempo passado como argumento na chamada. Para executar o vmstat atualizando as informações uma vez por segundo, basta o seguinte comando:
$ vmstat 1
Na primeira parte, procs, o vmstat mostra números de processos. A coluna “r” são processos na fila prontos para executar, e “b” são processos bloqueados aguardando operações de I/O (que estariam com status D no top).
Na seção memory existem as colunas semelhantes como vimos com top: swap, livre e caches (buffer e cache). A diferença na análise com a vmstat é entender as tendências. Podemos ver no top que há, por exemplo, 100MB usados de swap. Mas com a vmstat podemos acompanhar esse número mudando, para mais ou para menos, para nos indicar uma tendência no diagnóstico de um problema.
A seção swap mostra as colunas swap in (si), que são dados saindo de disco para memória, e swap out (so), que são as páginas da memória sendo escritas no disco. Em uma situação considerada normal, o Swap nunca deve acontecer, com ambas as colunas sempre “zeradas”. Qualquer anormalidade demanda a verificação do uso de memória pelos processos, podendo ser também originada por parâmetros de configuração mal ajustados ou pela necessidade do aumento de memória física.
A seção io tem a mesma estrutura da seção swap, porém em relação a operações normais de I/O. A coluna blocks in (bi) indica dados lidos do disco para memória, enquanto a blocks out (bo) indica dados sendo escritos no disco.
As informações de memória, swap e I/O estão em blocos, por padrão de 1024 bytes. Use o parâmetro -Sm para ver os dados de memória em MBytes (não altera o formato de swap e io). Na seção system, são exibidos o número de interrupções e trocas de contexto no proces- sador. Servidores atuais, multiprocessados e multicore podem exibir números bem altos para troca de contexto; e altos para interrupções devido à grade atividade de rede.
Em cpu temos os percentuais de processador para processos de usuários (us), do kernel (si), não ocupado (id) e aguardando operações de I/O (wa). Um I/O wait alto é um alerta, indi- cando que algum gargalo de disco está ocorrendo. Percentuais de cpu para system também devem ser observados, pois se estiverem fora de um padrão comumente visto podem indicar a necessidade de se monitorar os serviços do kernel.
Figura 5.3 Monitorando seu ambiente com vmstat. Na vmstat, o ponto de vista é sempre da memória principal, então IN significa entrando na memória, e OUT saindo.
l
Capí tu lo 5 - M on ito ram en to d o amb ie nt e
iostat
Se for necessário analisar situações de tráfego de I/O, a ferramenta iostat é indicada. Ela exibe informações por device em vez de dados gerais de I/O, como a vmstat. Para invocar a iostat, informamos um intervalo de atualização, sendo útil informar também a unidade para exibição dos resultados (o padrão é trabalhar com blocos de 512 bytes). A seguinte chamada atualiza os dados a cada cinco segundos e em MB:
$ iostat -m 5
O iostat pode não estar instalado em seu ambiente. Ele faz parte do pacote sysstat e pode ser instalado através do comando sudo apt-get install sysstat (Debian/Ubuntu) ou sudo yum install sysstat (Red Hat/CentOS).
O iostat exibe um cabeçalho com os dados já conhecidos de CPU e uma linha por device com as estatísticas de I/O. A primeira coluna é a tps, também conhecida como IOPS, que é o número de operações de I/O por segundo. Em seguida exibe duas colunas com MB lidos e escritos por segundo, em média. As últimas duas colunas exibem a quantidade de dados em MB lidos e escritos desde a amostra anterior, no exemplo, a cada 5 segundos.
Repare que a primeira amostra exibe valores altíssimos porque ela conta o total de dados lidos e escritos desde o boot do sistema.
Existe uma forma estendida do iostat que mostra mais informações, acionada através do uso do parâmetro -x: $ iostat -x -m 5 Figura 5.4 Monitorando devices de I/O com iostat. Figura 5.5 Versão estendida do iostat.
74 Ad m in is tr aç ão d e B an co d e D ad os
Duas colunas merecem consideração na forma estendida: await e %util. A primeira é o tempo médio, em milissegundos, que as requisições de I/O levam para serem servidas (tempo na fila e de execução). A outra, %util, mostra um percentual de tempo de CPU em que requisições foram solicitadas ao device. Apesar de esse número não ser acurado para arrays de discos, storages e discos SSD, um percentual próximo de 100% é certamente um indicador de saturação.
A figura 5.6 mostra um exemplo de sistema próximo da saturação, com I/O wait próximo de 20% e %util do device sde próximo de 100%. Interessante notar que a carga de I/O naquela amostra não era alta, 2MB/s, porém estava apresentando fila e tempo de resposta (await) elevando.