{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Fundamentos do monitoramento PostgreSQL. Alexey Lesovskiy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Convido voc\u00ea a conhecer a transcri\u00e7\u00e3o da apresenta\u00e7\u00e3o de Alexey Lesovski do Data Egret "Fundamentos da Monitoriza\u00e7\u00e3o do PostgreSQL"<\/strong><\/p>\n

<\/p>\n

Nesta apresenta\u00e7\u00e3o, Alexey Lesovski discutir\u00e1 os pontos-chave da estat\u00edstica do PostgreSQL, o que eles significam e por que devem estar presentes na monitoriza\u00e7\u00e3o; quais gr\u00e1ficos devem ser inclu\u00eddos na monitoriza\u00e7\u00e3o, como adicion\u00e1-los e como interpret\u00e1-los. A apresenta\u00e7\u00e3o ser\u00e1 \u00fatil para administradores de bancos de dados, administradores de sistemas e desenvolvedores interessados na resolu\u00e7\u00e3o de problemas do Postgres.<\/p>\n

\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Meu nome \u00e9 Alexey Lesovskiy, represento a empresa Data Egret. <\/p>\n

<\/p>\n

Um pouco sobre mim. Eu comecei, h\u00e1 muito tempo atr\u00e1s, como administrador de sistemas. <\/p>\n

<\/p>\n

Administrei v\u00e1rias distribui\u00e7\u00f5es Linux, envolvi-me em diversas atividades relacionadas ao Linux, ou seja, virtualiza\u00e7\u00e3o, monitoramento, trabalhei com proxies etc. Mas em determinado momento, comecei a me dedicar mais a bancos de dados, especificamente ao PostgreSQL. Eu gostei muito disso. E em algum momento, passei a trabalhar com PostgreSQL a maior parte do meu tempo. Gradualmente, me tornei um DBA de PostgreSQL.<\/p>\n

<\/p>\n

E ao longo de toda a minha carreira, sempre tive interesse em temas como estat\u00edstica, monitoramento e coleta de telemetria. Quando era administrador de sistemas, me envolvi intensamente com o Zabbix. E escrevi um pequeno conjunto de scripts como zabbix-extensions<\/a><\/noindex>. Ele foi bastante popular na sua \u00e9poca. E l\u00e1 era poss\u00edvel monitorar diversas coisas importantes, n\u00e3o apenas Linux, mas tamb\u00e9m v\u00e1rios outros componentes.<\/p>\n

<\/p>\n

Atualmente, estou focado no PostgreSQL. Estou escrevendo outra ferramenta que permite trabalhar com estat\u00edsticas do PostgreSQL. Ela se chama pgCenter<\/a><\/noindex> (artigo no Habr\u00e9 \u2014 Estat\u00edsticas do PostgreSQL sem estresse nem complica\u00e7\u00f5es<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Uma breve introdu\u00e7\u00e3o. Quais s\u00e3o as situa\u00e7\u00f5es que nossos clientes enfrentam? Acontece algum tipo de falha relacionada ao banco de dados. E quando o banco de dados \u00e9 recuperado, o chefe do departamento ou o gerente de desenvolvimento diz: \"Pessoal, precisamos monitorar o banco de dados, porque algo ruim aconteceu e precisamos evitar que isso ocorra novamente no futuro\". E aqui come\u00e7a um interessante processo de escolha de um sistema de monitoramento ou a adapta\u00e7\u00e3o de um sistema de monitoramento existente para que possamos monitorar nosso banco de dados \u2013 PostgreSQL, MySQL ou outros. E os colegas come\u00e7am a sugerir: \"Ouvi dizer que existe tal banco de dados. Vamos us\u00e1-lo\". Os colegas come\u00e7am a discutir entre si. E, no final, acabamos escolhendo algum banco de dados, mas o monitoramento do PostgreSQL nele \u00e9 bastante fraco e sempre precisamos ajustar algo. Precisamos pegar alguns reposit\u00f3rios do GitHub, clon\u00e1-los, adaptar scripts, reconfigurar de alguma forma. E, no final, isso se torna uma tarefa manual. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Portanto, nesta apresenta\u00e7\u00e3o, tentarei fornecer a voc\u00eas alguns conhecimentos sobre como escolher monitoramento n\u00e3o apenas para PostgreSQL, mas tamb\u00e9m para bancos de dados em geral. E fornecer o conhecimento que permitir\u00e1 que voc\u00eas aprimorem seu monitoramento, a fim de obter alguma utilidade com isso, permitindo monitorar seu banco de dados de maneira eficaz, prevenindo poss\u00edveis situa\u00e7\u00f5es de falha que possam surgir. <\/p>\n

<\/p>\n

As ideias que ser\u00e3o apresentadas nesta palestra podem ser diretamente adaptadas a qualquer banco de dados, seja um SGBD ou noSQL. Portanto, n\u00e3o se trata apenas de PostgreSQL, mas haver\u00e1 muitas dicas sobre como fazer isso no PostgreSQL. Haver\u00e1 exemplos de consultas, exemplos de entidades existentes no PostgreSQL para monitoramento. E se seu SGBD tiver elementos semelhantes que permitam integr\u00e1-los no monitoramento, voc\u00ea tamb\u00e9m pode adapt\u00e1-los, adicion\u00e1-los e ficar\u00e1 \u00f3timo.<\/p>\n

<\/p>\n

\"FundamentosNa apresenta\u00e7\u00e3o, n\u00e3o irei
\nfalar sobre como coletar e armazenar m\u00e9tricas. N\u00e3o falarei sobre p\u00f3s-processamento de dados e sua apresenta\u00e7\u00e3o ao usu\u00e1rio. E n\u00e3o falarei sobre alertas.
\nMas ao longo da narrativa, eu vou mostrar v\u00e1rias capturas de tela de monitoramentos existentes, e irei critic\u00e1-los de alguma forma. Contudo, tentarei n\u00e3o mencionar marcas para evitar promover ou desconvidar esses produtos. Portanto, todas as coincid\u00eancias s\u00e3o aleat\u00f3rias e ficam \u00e0 sua imagina\u00e7\u00e3o.
\n\"Fundamentos
\nPara come\u00e7ar, vamos entender o que \u00e9 monitoramento. Monitoramento \u00e9 uma coisa muito importante que precisamos ter. Todos sabem disso. Mas, ao mesmo tempo, o monitoramento n\u00e3o \u00e9 um produto comercial e n\u00e3o afeta diretamente o lucro da empresa, por isso, geralmente, o monitoramento recebe aten\u00e7\u00e3o apenas como um recurso secund\u00e1rio. Se tivermos tempo, fazemos monitoramento; se n\u00e3o tivermos, tudo bem, colocamos no backlog e voltamos a essas tarefas mais tarde. <\/p>\n

<\/p>\n

Portanto, pela nossa experi\u00eancia, quando chegamos aos clientes, o monitoramento muitas vezes n\u00e3o est\u00e1 bem desenvolvido e carece de funcionalidades interessantes que nos ajudariam a trabalhar melhor com o banco de dados. Por isso, o monitoramento sempre precisa ser aprimorado. <\/p>\n

<\/p>\n

Os bancos de dados s\u00e3o sistemas complexos que tamb\u00e9m precisam ser monitorados, porque eles s\u00e3o dep\u00f3sitos de informa\u00e7\u00f5es. E a informa\u00e7\u00e3o \u00e9 muito importante para a empresa, n\u00e3o pode ser perdida de forma alguma. Mas, ao mesmo tempo, os bancos de dados s\u00e3o peda\u00e7os muito complexos de software. Eles consistem em muitos componentes. E muitos desses componentes precisam ser monitorados. <\/p>\n

<\/p>\n

\"FundamentosSe falamos especificamente sobre o PostgreSQL, ele pode ser representado como um esquema que consiste em muitos componentes. Esses componentes interagem entre si. E, ao mesmo tempo, no PostgreSQL existe uma subsistema chamada Stats Collector, que permite coletar estat\u00edsticas sobre o funcionamento desses subsistemas e fornecer uma interface para o administrador ou usu\u00e1rio, para que ele possa visualizar essas estat\u00edsticas. <\/p>\n

<\/p>\n

Essas estat\u00edsticas s\u00e3o apresentadas na forma de um conjunto de fun\u00e7\u00f5es e vis\u00f5es (view). Elas tamb\u00e9m podem ser chamadas de tabelas. Ou seja, com um cliente psql comum, voc\u00ea pode se conectar ao banco de dados, fazer um select nessas fun\u00e7\u00f5es e vis\u00f5es, e obter alguns n\u00fameros concretos sobre o funcionamento dos subsistemas do PostgreSQL. <\/p>\n

<\/p>\n

Voc\u00ea pode adicionar esses n\u00fameros ao seu sistema de monitoramento favorito, criar gr\u00e1ficos, adicionar fun\u00e7\u00f5es e obter an\u00e1lises a longo prazo. <\/p>\n

<\/p>\n

Mas neste relat\u00f3rio, n\u00e3o vou abordar todas essas fun\u00e7\u00f5es, porque isso poderia levar um dia inteiro. Vou me limitar a duas, tr\u00eas ou quatro coisas e irei explicar como elas ajudam a melhorar a monitora\u00e7\u00e3o.
\n\"Fundamentos
\nE quando se fala em monitorar um banco de dados, o que precisa ser monitorado? Primeiramente, \u00e9 crucial monitorar a disponibilidade, pois o banco \u00e9 um servi\u00e7o que fornece acesso a dados aos clientes, e precisamos monitorar a disponibilidade, bem como algumas caracter\u00edsticas qualitativas e quantitativas. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Tamb\u00e9m \u00e9 necess\u00e1rio monitorar os clientes que se conectam ao nosso banco, pois eles podem ser tanto clientes normais quanto clientes maliciosos que podem prejudicar o banco de dados. \u00c9 importante monitor\u00e1-los e acompanhar suas atividades.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Quando os clientes se conectam ao banco de dados, \u00e9 evidente que come\u00e7am a trabalhar com nossos dados, portanto, precisamos monitorar tamb\u00e9m como os clientes interagem com os dados: com quais tabelas, e em menor grau, com quais \u00edndices. Ou seja, precisamos avaliar a carga de trabalho (workload) que nossos clientes geram.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Mas a carga de trabalho tamb\u00e9m \u00e9 composta, claro, por consultas. Aplicativos se conectam ao banco e acessam dados por meio de consultas, por isso \u00e9 importante avaliar quais consultas temos em nosso banco de dados, acompanhar sua adequa\u00e7\u00e3o, garantir que n\u00e3o estejam mal formuladas, e que algumas op\u00e7\u00f5es precisem ser reescritas para funcionar mais rapidamente e com melhor desempenho. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

E j\u00e1 que falamos sobre bancos de dados, eles s\u00e3o sempre acompanhados de processos em segundo plano. Os processos em segundo plano permitem que o desempenho do banco de dados se mantenha em um bom n\u00edvel, portanto, para seu funcionamento, eles exigem uma certa quantidade de recursos. Ao mesmo tempo, podem competir com os recursos das solicita\u00e7\u00f5es dos clientes, por isso, um consumo excessivo de recursos pelos processos em segundo plano pode impactar diretamente o desempenho das solicita\u00e7\u00f5es dos clientes. Assim, tamb\u00e9m \u00e9 necess\u00e1rio monitor\u00e1-los e garantir que n\u00e3o haja desequil\u00edbrios em rela\u00e7\u00e3o aos processos em segundo plano. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

E isso tudo no plano de monitoramento de banco de dados permanece na m\u00e9trica do sistema. Mas considerando que, na maior parte do tempo, toda a nossa infraestrutura est\u00e1 indo para a nuvem, as m\u00e9tricas do sistema de um host espec\u00edfico sempre ficam em segundo plano. No entanto, nos bancos de dados, elas ainda s\u00e3o relevantes e monitorar as m\u00e9tricas do sistema, \u00e9 claro, tamb\u00e9m \u00e9 necess\u00e1rio. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Com as m\u00e9tricas do sistema mais ou menos tudo vai bem, todos os sistemas modernos de monitoramento j\u00e1 suportam essas m\u00e9tricas, mas, no geral, ainda faltam alguns componentes e precisamos adicionar algumas coisas. Sobre isso, tamb\u00e9m falarei, haver\u00e1 alguns slides sobre eles. <\/p>\n

<\/p>\n

\"Fundamentos
\nO primeiro ponto do plano \u00e9 a disponibilidade. O que \u00e9 disponibilidade? Disponibilidade, na minha compreens\u00e3o, \u00e9 a capacidade do banco de atender conex\u00f5es, ou seja, o banco est\u00e1 ativo, ele, como um servi\u00e7o, aceita conex\u00f5es de clientes. E essa disponibilidade pode ser avaliada por algumas caracter\u00edsticas. Essas caracter\u00edsticas s\u00e3o muito convenientes de serem exibidas nos pain\u00e9is de controle. <\/p>\n

<\/p>\n

\"Fundamentos
\nTodos sabem o que s\u00e3o pain\u00e9is de controle. \u00c9 quando voc\u00ea d\u00e1 uma olhada na tela onde as informa\u00e7\u00f5es necess\u00e1rias est\u00e3o resumidas. E voc\u00ea j\u00e1 pode imediatamente determinar se h\u00e1 um problema no banco ou n\u00e3o.
\nPortanto, a disponibilidade do banco de dados e outras caracter\u00edsticas-chave sempre precisam ser exibidas nos pain\u00e9is de controle, para que essa informa\u00e7\u00e3o esteja \u00e0 m\u00e3o, sempre ao seu lado. Alguns detalhes adicionais, que ajudam na investiga\u00e7\u00e3o de incidentes ou em situa\u00e7\u00f5es de emerg\u00eancia, devem ser exibidos em pain\u00e9is secund\u00e1rios ou escondidos em links de drilldown, que levam a sistemas de monitoramento externos. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Um exemplo de um conhecido sistema de monitoramento. \u00c9 um sistema de monitoramento muito bom. Ele coleta muitos dados, mas, na minha opini\u00e3o, ele tem uma no\u00e7\u00e3o estranha de pain\u00e9is de controle. H\u00e1 um link \"criar painel de controle\". Mas quando voc\u00ea cria um painel, voc\u00ea cria uma lista, composta por duas colunas, uma lista de gr\u00e1ficos. E quando voc\u00ea precisa ver algo, voc\u00ea come\u00e7a a clicar com o mouse, rolar, procurar o gr\u00e1fico necess\u00e1rio. E isso leva tempo, ou seja, n\u00e3o h\u00e1 pain\u00e9is de controle propriamente ditos. H\u00e1 apenas listas de gr\u00e1ficos.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

O que deve ser adicionado nesses pain\u00e9is? Podemos come\u00e7ar com uma m\u00e9trica como o tempo de resposta. No PostgreSQL, existe a view pg_stat_statements. Por padr\u00e3o, ela est\u00e1 desativada, mas \u00e9 uma das views do sistema mais importantes que devem sempre ser ativadas e utilizadas. Ela armazena informa\u00e7\u00f5es sobre todas as consultas executadas que foram realizadas no banco de dados. <\/p>\n

<\/p>\n

Assim, podemos come\u00e7ar pelo fato de que podemos pegar o tempo total de execu\u00e7\u00e3o de todas as consultas e dividir pelo n\u00famero de consultas usando os campos mencionados acima. Mas isso \u00e9 como uma m\u00e9dia geral. Podemos nos basear em outros campos \u2013 tempo m\u00ednimo, m\u00e1ximo e mediano de execu\u00e7\u00e3o das consultas. E mesmo podemos construir percentis, pois o PostgreSQL tem fun\u00e7\u00f5es correspondentes para isso. E podemos obter alguns n\u00fameros que caracterizam o tempo de resposta do nosso banco de dados com base nas consultas j\u00e1 realizadas, ou seja, n\u00e3o estamos executando uma consulta fict\u00edcia ‘select 1’ e observando o tempo de resposta, mas estamos analisando os tempos de resposta de consultas j\u00e1 realizadas e apresentando isso como um \u00fanico n\u00famero ou construindo um gr\u00e1fico a partir disso. <\/p>\n

<\/p>\n

Tamb\u00e9m \u00e9 importante monitorar a quantidade de erros que o sistema est\u00e1 gerando no momento. Para isso, podemos usar a view pg_stat_database. N\u00f3s nos baseamos no campo xact_rollback. Esse campo mostra n\u00e3o apenas o n\u00famero de rollbacks que ocorrem no banco, mas tamb\u00e9m contabiliza a quantidade de erros. Em outras palavras, podemos exibir esse n\u00famero no nosso painel e monitorar quantos erros temos no momento. Se houver muitos erros, esse \u00e9 um bom motivo para verificar os logs e ver que tipo de erros s\u00e3o esses e por que est\u00e3o ocorrendo, e depois investigar e resolv\u00ea-los.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Pode-se adicionar algo como um Tac\u00f4metro. Isso \u00e9 o n\u00famero de transa\u00e7\u00f5es por segundo e a quantidade de consultas por segundo. Em outras palavras, voc\u00ea pode usar esses n\u00fameros como um indicador de desempenho atual do seu banco de dados e observar se h\u00e1 picos de consultas, picos de transa\u00e7\u00f5es ou, ao contr\u00e1rio, se o banco n\u00e3o est\u00e1 sobrecarregado, porque algum backend falhou. Esse n\u00famero \u00e9 algo que deve ser sempre monitorado, e lembrar que para o nosso projeto, esse desempenho \u00e9 considerado normal, enquanto valores acima ou abaixo j\u00e1 s\u00e3o problem\u00e1ticos e desconhecidos, e, portanto, \u00e9 necess\u00e1rio investigar por que esses n\u00fameros est\u00e3o assim.<\/p>\n

<\/p>\n

Para avaliar o n\u00famero de transa\u00e7\u00f5es, podemos novamente nos referir \u00e0 vis\u00e3o pg_stat_database. Podemos somar o n\u00famero de commits e o n\u00famero de rollbacks e obter o n\u00famero de transa\u00e7\u00f5es por segundo. <\/p>\n

<\/p>\n

Todos entendem que v\u00e1rias consultas podem estar inclu\u00eddas em uma \u00fanica transa\u00e7\u00e3o? Por isso, TPS e QPS s\u00e3o um pouco diferentes. <\/p>\n

<\/p>\n

O n\u00famero de consultas por segundo pode ser obtido pelo pg_stat_statements e basta calcular a soma de todas as consultas executadas. \u00c9 claro que comparamos o valor atual com o anterior, subtra\u00edmos, obtemos a delta e chegamos \u00e0 quantidade.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Podemos adicionar m\u00e9tricas adicionais conforme desejado, que tamb\u00e9m ajudam a avaliar a disponibilidade do nosso banco e monitorar se houve algum tempo de inatividade. <\/p>\n

<\/p>\n

Uma dessas m\u00e9tricas \u00e9 o uptime. Mas o uptime no PostgreSQL \u00e9 uma coisa um pouco complicada. Vou explicar por qu\u00ea. Quando o PostgreSQL \u00e9 iniciado, o uptime come\u00e7a a ser contabilizado. Mas se em determinado momento, por exemplo, \u00e0 noite, uma tarefa foi executada e o OOM-killer for\u00e7ou o encerramento de um processo filho do PostgreSQL, nesse caso, o PostgreSQL encerra as conex\u00f5es de todos os clientes, libera a \u00e1rea de mem\u00f3ria shardada e come\u00e7a a recupera\u00e7\u00e3o a partir do \u00faltimo ponto de verifica\u00e7\u00e3o. E enquanto essa recupera\u00e7\u00e3o a partir do ponto de verifica\u00e7\u00e3o dura, o banco n\u00e3o aceita conex\u00f5es, ou seja, essa situa\u00e7\u00e3o pode ser avaliada como um tempo de inatividade. No entanto, o contador de uptime n\u00e3o ser\u00e1 zerado, pois ele considera o tempo desde o primeiro momento em que o postmaster foi iniciado. Portanto, tais situa\u00e7\u00f5es podem ser ignoradas.<\/p>\n

<\/p>\n

Tamb\u00e9m \u00e9 importante monitorar o n\u00famero de workers do autovacuum. Todos sabem o que \u00e9 o autovacuum no PostgreSQL? \u00c9 um subsistema interessante no PostgreSQL. Muitas mat\u00e9rias foram escritas sobre ele, v\u00e1rias palestras foram feitas. Houve muitas discuss\u00f5es sobre o vacuum e como ele deve funcionar. Muitos o consideram um mal inevit\u00e1vel. Mas \u00e9 isso mesmo. \u00c9 uma esp\u00e9cie de coletor de lixo que limpa vers\u00f5es obsoletas de linhas que n\u00e3o s\u00e3o necess\u00e1rias para nenhuma transa\u00e7\u00e3o e libera espa\u00e7o nas tabelas e \u00edndices para novas linhas. <\/p>\n

<\/p>\n

Por que \u00e9 necess\u00e1rio monitor\u00e1-lo? Porque o vacuum \u00e0s vezes causa s\u00e9rios problemas. Ele consome um grande n\u00famero de recursos e as consultas dos clientes come\u00e7am a sofrer por isso. <\/p>\n

<\/p>\n

E devemos monitorar isso atrav\u00e9s da vis\u00e3o pg_stat_activity, sobre a qual falarei na se\u00e7\u00e3o seguinte. Essa vis\u00e3o mostra a atividade atual no banco de dados. Atrav\u00e9s dessa atividade, podemos rastrear o n\u00famero de v\u00e1cuos que est\u00e3o funcionando no momento. Podemos acompanhar os v\u00e1cuos e ver que, se o nosso limite for ultrapassado, isso \u00e9 um motivo para revisar as configura\u00e7\u00f5es do PostgreSQL e otimizar o funcionamento do v\u00e1cuo. <\/p>\n

<\/p>\n

Outra caracter\u00edstica do PostgreSQL \u00e9 que ele sofre muito com transa\u00e7\u00f5es longas. Especialmente, com transa\u00e7\u00f5es que ficam pendentes por muito tempo e n\u00e3o fazem nada. Essas s\u00e3o as chamadas transa\u00e7\u00f5es idle-in-transaction. Tal transa\u00e7\u00e3o mant\u00e9m bloqueios, o que interfere no funcionamento do v\u00e1cuo. Como consequ\u00eancia, as tabelas aumentam, o seu tamanho cresce. E as consultas que trabalham com essas tabelas come\u00e7am a ficar mais lentas, porque \u00e9 necess\u00e1rio mover todas as vers\u00f5es antigas das linhas da mem\u00f3ria para o disco e vice-versa.<\/strong> Portanto, \u00e9 necess\u00e1rio monitorar o tempo, a dura\u00e7\u00e3o das transa\u00e7\u00f5es mais longas, e as mais longas consultas do v\u00e1cuo tamb\u00e9m. Se vemos alguns processos que est\u00e3o funcionando h\u00e1 muito tempo, mais de 10-20-30 minutos para a carga OLTP, devemos prestar aten\u00e7\u00e3o e finaliz\u00e1-los \u00e0 for\u00e7a, ou otimizar o aplicativo para que n\u00e3o sejam chamados e n\u00e3o fiquem pendentes tanto tempo.<\/strong> Para carga anal\u00edtica, 10-20-30 minutos \u00e9 normal; \u00e0s vezes at\u00e9 mais longas ocorrem. <\/p>\n

<\/p>\n

\"Fundamentos
\nA seguir, temos a op\u00e7\u00e3o com clientes conectados. Quando j\u00e1 formamos o painel, exibimos nele as m\u00e9tricas chave de disponibilidade, tamb\u00e9m podemos adicionar informa\u00e7\u00f5es adicionais sobre os clientes conectados. <\/p>\n

<\/p>\n

As informa\u00e7\u00f5es sobre os clientes conectados s\u00e3o importantes porque, do ponto de vista do PostgreSQL, os clientes podem ser diferentes. Existem bons clientes e clientes ruins. <\/p>\n

<\/p>\n

Um exemplo simples. Por cliente, entendo o aplicativo. O aplicativo se conectou ao banco de dados e come\u00e7a a enviar seus pedidos, o banco de dados os processa e executa, retornando os resultados ao cliente. Esses s\u00e3o clientes bons e corretos. <\/p>\n

<\/p>\n

Existem situa\u00e7\u00f5es em que o cliente se conectou, mant\u00e9m a conex\u00e3o, mas n\u00e3o faz nada. Ele est\u00e1 em estado idle. <\/p>\n

<\/p>\n

Mas existem clientes problem\u00e1ticos. Por exemplo, um cliente se conecta, abre uma transa\u00e7\u00e3o, faz alguma coisa no banco de dados e depois vai para o c\u00f3digo, digamos, para acessar uma fonte externa ou para processar os dados recebidos. No entanto, ele n\u00e3o fecha a transa\u00e7\u00e3o. E a transa\u00e7\u00e3o fica pendurada no banco e mant\u00e9m um bloqueio na linha. Isso \u00e9 uma situa\u00e7\u00e3o ruim. E se, de repente, o aplicativo falhar em algum ponto devido a uma exce\u00e7\u00e3o (Exception), a transa\u00e7\u00e3o pode permanecer aberta por muito tempo. E isso afeta diretamente o desempenho do PostgreSQL. O PostgreSQL funcionar\u00e1 mais lentamente. Portanto, \u00e9 importante monitorar esses clientes e for\u00e7\u00e1-los a encerrar suas atividades. Al\u00e9m disso, \u00e9 necess\u00e1rio otimizar seu aplicativo para evitar tais situa\u00e7\u00f5es. <\/p>\n

<\/p>\n

Outros clientes problem\u00e1ticos s\u00e3o os clientes em espera. Mas eles se tornam problem\u00e1ticos por causa das circunst\u00e2ncias. Por exemplo, uma transa\u00e7\u00e3o simples em espera: pode abrir uma transa\u00e7\u00e3o, obter bloqueios em algumas linhas e depois falhar em algum ponto do c\u00f3digo, deixando uma transa\u00e7\u00e3o pendurada. Um outro cliente chega e tenta solicitar os mesmos dados, mas ele encontrar\u00e1 bloqueio, pois aquela transa\u00e7\u00e3o pendurada j\u00e1 mant\u00e9m bloqueios em algumas linhas necess\u00e1rias. Assim, a segunda transa\u00e7\u00e3o ficar\u00e1 em espera at\u00e9 que a primeira seja conclu\u00edda ou seu administrador a feche for\u00e7adamente. Dessa forma, transa\u00e7\u00f5es em espera podem se acumular e superar o limite de conex\u00f5es ao banco de dados. E quando o limite \u00e9 excedido, o aplicativo n\u00e3o consegue mais trabalhar com o banco. Essa j\u00e1 \u00e9 uma situa\u00e7\u00e3o de emerg\u00eancia para o projeto. Portanto, \u00e9 necess\u00e1rio monitorar os clientes problem\u00e1ticos e reagir a eles de forma oportuna. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Outro exemplo de monitoramento. E aqui j\u00e1 temos um painel decente. H\u00e1 informa\u00e7\u00f5es sobre as conex\u00f5es no topo. Conex\u00e3o DB \u2013 8 unidades. E s\u00f3 isso. N\u00e3o temos informa\u00e7\u00f5es sobre quais clientes est\u00e3o ativos, quais clientes est\u00e3o apenas ociosos, sem fazer nada. N\u00e3o h\u00e1 informa\u00e7\u00f5es sobre transa\u00e7\u00f5es penduradas e sobre conex\u00f5es em espera, ou seja, \u00e9 apenas um n\u00famero que mostra a quantidade de conex\u00f5es e nada mais. Quanto ao restante, adivinhe voc\u00ea mesmo.
\n\"Fundamentos
\nPortanto, para adicionar essas informa\u00e7\u00f5es ao monitoramento, \u00e9 necess\u00e1rio consultar a vis\u00e3o do sistema pg_stat_activity. Se voc\u00ea passa muito tempo no PostgreSQL, essa \u00e9 uma vis\u00e3o muito \u00fatil que deve se tornar sua aliada, pois mostra a atividade atual no PostgreSQL, ou seja, o que est\u00e1 acontecendo nele. Para cada processo, h\u00e1 uma linha separada que informa sobre esse processo: de qual host a conex\u00e3o foi realizada, sob qual usu\u00e1rio, qual nome, quando a transa\u00e7\u00e3o foi iniciada, qual consulta est\u00e1 sendo executada no momento, qual consulta foi executada por \u00faltimo. E, assim, podemos avaliar o estado do cliente pelo campo stat. Podemos, por exemplo, agrupar por esse campo e obter as stats que existem atualmente no banco de dados e o n\u00famero de conex\u00f5es associadas a esse stat no banco de dados. E ent\u00e3o, os n\u00fameros obtidos podem ser enviados ao nosso monitoramento para criar gr\u00e1ficos a partir deles.
\nTamb\u00e9m \u00e9 importante avaliar a dura\u00e7\u00e3o da transa\u00e7\u00e3o. J\u00e1 mencionei que \u00e9 essencial medir a dura\u00e7\u00e3o dos vacuums, mas as transa\u00e7\u00f5es s\u00e3o avaliadas da mesma forma. Existem os campos xact_start e query_start. Eles, por assim dizer, mostram o momento de in\u00edcio da transa\u00e7\u00e3o e o momento de in\u00edcio da consulta. Pegamos a fun\u00e7\u00e3o now(), que mostra o timestamp atual, e subtra\u00edmos o timestamp da transa\u00e7\u00e3o e da consulta. E obtemos a dura\u00e7\u00e3o da transa\u00e7\u00e3o e a dura\u00e7\u00e3o da consulta. <\/p>\n

<\/p>\n

Se observarmos transa\u00e7\u00f5es longas, devemos finaliz\u00e1-las. Para carga OLTP, transa\u00e7\u00f5es longas s\u00e3o aquelas que duram mais de 1-2-3 minutos.<\/strong>. Para carga OLAP, transa\u00e7\u00f5es longas s\u00e3o normais, mas se elas duram mais de duas horas, isso tamb\u00e9m \u00e9 um sinal de que h\u00e1 algum desvio.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentos
\nQuando os clientes se conectam ao banco de dados, eles come\u00e7am a trabalhar com nossos dados. Eles acessam tabelas, consultam \u00edndices para obter dados da tabela. E \u00e9 importante avaliar como os clientes interagem com esses dados.<\/p>\n

<\/p>\n

Isso \u00e9 necess\u00e1rio para avaliar nossa carga de trabalho e entender aproximadamente quais tabelas s\u00e3o as mais \"quentes\". Por exemplo, isso \u00e9 \u00fatil em situa\u00e7\u00f5es em que queremos colocar tabelas \"quentes\" em algum armazenamento SSD r\u00e1pido. Por outro lado, tabelas de arquivo que n\u00e3o usamos h\u00e1 muito tempo podem ser movidas para um \"frio\" arquivo, em discos SATA, e elas podem l\u00e1 permanecer, sendo acessadas conforme a necessidade. <\/p>\n

<\/p>\n

Isso tamb\u00e9m \u00e9 \u00fatil para detectar anomalias ap\u00f3s lan\u00e7amentos e implanta\u00e7\u00f5es. Suponha que o projeto tenha lan\u00e7ado um novo recurso. Por exemplo, adicionamos uma nova funcionalidade para trabalhar com o banco de dados. Se construirmos gr\u00e1ficos de uso das tabelas, conseguiremos facilmente identificar essas anomalias nesses gr\u00e1ficos. Por exemplo, picos de atualiza\u00e7\u00e3o ou picos de exclus\u00e3o. Isso ser\u00e1 muito evidente.<\/p>\n

<\/p>\n

Al\u00e9m disso, \u00e9 poss\u00edvel detectar anomalias em estat\u00edsticas \"desviadas\". O que isso significa? O PostgreSQL possui um planejador de consultas muito forte e eficiente. E os desenvolvedores dedicam muito tempo ao seu aprimoramento. Como ele funciona? Para construir bons planos, o PostgreSQL coleta estat\u00edsticas sobre a distribui\u00e7\u00e3o de dados nas tabelas em intervalos de tempo regulares. Esses dados incluem os valores mais frequentes: a quantidade de valores \u00fanicos, informa\u00e7\u00f5es sobre NULL nas tabelas, e muitas outras informa\u00e7\u00f5es. <\/p>\n

<\/p>\n

Com base nessas estat\u00edsticas, o planejador constr\u00f3i v\u00e1rias consultas, escolhe a mais otimizada e utiliza esse plano de consulta para realizar a consulta e retornar os dados. <\/p>\n

<\/p>\n

E \u00e0s vezes, as estat\u00edsticas \"desviam-se\". A qualidade e a quantidade de dados mudaram de alguma forma na tabela, mas as estat\u00edsticas n\u00e3o foram coletadas. E os planos formados podem acabar sendo n\u00e3o otimizados. E se nossos planos forem n\u00e3o otimizados com base no monitoramento coletado sobre as tabelas, conseguiremos ver essas anomalias. Por exemplo, onde os dados mudaram qualitativamente e, em vez de usar \u00edndices, um acesso sequencial \u00e0 tabela foi adotado. Ou seja, se a consulta precisa retornar apenas 100 linhas (com uma limita\u00e7\u00e3o de limit 100), ser\u00e1 realizado um percurso completo. E isso sempre impacta negativamente na performance. <\/p>\n

<\/p>\n

E podemos ver isso no monitoramento. E j\u00e1 olhar para essa consulta, executar um explain para ela, coletar estat\u00edsticas, construir um novo \u00edndice adicional. E ent\u00e3o reagir a esse problema. Por isso, isso \u00e9 importante. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Outro exemplo de monitoramento. Acho que muitos o reconheceram, porque \u00e9 muito popular. Quem usa em seus projetos Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Mas h\u00e1 um detalhe negativo. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Existem v\u00e1rios gr\u00e1ficos. E em como unidade s\u00e3o indicados bytes, ou seja, h\u00e1 5 gr\u00e1ficos. Esses s\u00e3o Insert data, Update data, Delete data, Fetch data e Return data. Como unidade de medida, est\u00e3o indicados bytes. Mas o fato \u00e9 que as estat\u00edsticas no PostgreSQL retornam dados em tuples (linhas). E, consequentemente, esses gr\u00e1ficos s\u00e3o uma maneira muito boa de subestimar seu workload v\u00e1rias vezes, dezenas de vezes, porque uma tuple n\u00e3o \u00e9 um byte, uma tuple \u00e9 uma linha, s\u00e3o muitos bytes e sempre tem tamanho vari\u00e1vel. Ou seja, calcular o workload em bytes usando tuples \u00e9 uma tarefa irreal ou muito complexa. Portanto, ao usar um dashboard ou monitoramento incorporado, \u00e9 sempre importante entender que ele funciona corretamente e retorna dados avaliados de forma precisa. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Como obter estat\u00edsticas dessas tabelas? Para isso, no PostgreSQL h\u00e1 uma certa fam\u00edlia de views. E a view principal \u00e9 pg_stat_user_tables<\/a><\/noindex>. User_tables significa que as tabelas foram criadas em nome do usu\u00e1rio. Em contraste, existem views sist\u00eamicas que s\u00e3o utilizadas pelo pr\u00f3prio PostgreSQL. E h\u00e1 uma tabela resumida Alltables, que inclui tanto as sist\u00eamicas quanto as de usu\u00e1rios. Voc\u00ea pode se basear em qualquer uma delas, que voc\u00ea preferir.<\/p>\n

<\/p>\n

Com base nos campos mencionados, \u00e9 poss\u00edvel avaliar a quantidade de inserts, updates e deletes. O exemplo de dashboard que eu usei utiliza exatamente esses campos para avaliar as caracter\u00edsticas do workload. Por isso, tamb\u00e9m podemos nos basear neles. Mas \u00e9 importante lembrar que s\u00e3o tuples, n\u00e3o bytes, portanto n\u00e3o podemos simplesmente fazer isso em bytes.<\/p>\n

<\/p>\n

Com base nesses dados, podemos construir as chamadas tabelas TopN. Por exemplo, Top-5, Top-10. E podemos monitorar aquelas tabelas quentes que s\u00e3o processadas mais do que as outras. Por exemplo, as 5 tabelas 'quentes' em inser\u00e7\u00e3o. E com essas tabelas TopN avaliamos nosso workload e podemos avaliar picos de workload ap\u00f3s diversos lan\u00e7amentos, atualiza\u00e7\u00f5es e implanta\u00e7\u00f5es. <\/p>\n

<\/p>\n

Tamb\u00e9m \u00e9 importante avaliar o tamanho das tabelas, pois \u00e0s vezes os desenvolvedores lan\u00e7am um novo recurso e nossas tabelas come\u00e7am a aumentar de tamanho, porque decidem adicionar um volume extra de dados, mas n\u00e3o preveem como isso impactar\u00e1 o tamanho do banco de dados. Esses casos tamb\u00e9m nos pegam de surpresa. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

E agora uma pergunta pequena para voc\u00ea. Qual \u00e9 a primeira d\u00favida que surge quando voc\u00ea percebe uma carga no servidor com o banco de dados? Qual \u00e9 a pr\u00f3xima pergunta que voc\u00ea se faz? <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Mas na verdade, a pergunta que surge \u00e9 a seguinte. Quais consultas est\u00e3o gerando a carga? Ou seja, n\u00e3o \u00e9 interessante olhar para os processos que geram a carga. \u00c9 claro que se o host cont\u00e9m o banco de dados, ele est\u00e1 executando o banco de dados e, portanto, ser\u00e3o apenas os bancos de dados a utiliz\u00e1-lo. Se abrirmos o Top, veremos uma lista de processos no PostgreSQL que est\u00e3o fazendo algo. Pelo Top, n\u00e3o ser\u00e1 claro o que eles est\u00e3o fazendo. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Portanto, \u00e9 necess\u00e1rio identificar aquelas consultas que geram a maior carga, porque o ajuste de consultas, geralmente, traz um retorno maior do que o ajuste da configura\u00e7\u00e3o do PostgreSQL, do sistema operacional ou at\u00e9 mesmo do hardware. Na minha avalia\u00e7\u00e3o, isso \u00e9 cerca de 80-85-90%. E isso \u00e9 feito muito mais rapidamente. \u00c9 mais r\u00e1pido corrigir uma consulta do que ajustar a configura\u00e7\u00e3o, planejar uma reinicializa\u00e7\u00e3o, especialmente se n\u00e3o for poss\u00edvel reiniciar o banco ou adicionar hardware. \u00c9 mais simples reescrever uma consulta ou adicionar um \u00edndice para obter um resultado melhor dessa consulta. <\/p>\n

<\/p>\n

\"Fundamentos
\nPortanto, \u00e9 necess\u00e1rio monitorar as consultas e sua adequa\u00e7\u00e3o. Vamos pegar outro exemplo de monitoramento. E aqui tamb\u00e9m parece um \u00f3timo monitoramento. H\u00e1 informa\u00e7\u00f5es sobre replica\u00e7\u00e3o, informa\u00e7\u00f5es sobre largura de banda, bloqueios, utiliza\u00e7\u00e3o de recursos. Tudo perfeito, mas n\u00e3o h\u00e1 informa\u00e7\u00f5es sobre as consultas. N\u00e3o est\u00e1 claro quais consultas est\u00e3o sendo executadas em nosso banco de dados, quanto tempo elas levam para ser executadas, quantas dessas consultas existem. Precisamos sempre ter essas informa\u00e7\u00f5es dispon\u00edveis no monitoramento. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

E para obter essas informa\u00e7\u00f5es, podemos usar o m\u00f3dulo pg_stat_statements. Com base nele, podemos construir diversos gr\u00e1ficos. Por exemplo, podemos obter informa\u00e7\u00f5es sobre as consultas mais frequentes, ou seja, aquelas que s\u00e3o executadas com mais frequ\u00eancia. Sim, ap\u00f3s implanta\u00e7\u00f5es, \u00e9 muito \u00fatil analis\u00e1-lo e entender se houve algum pico nas consultas. <\/p>\n

<\/p>\n

Podemos monitorar as consultas mais longas, ou seja, aquelas que levam mais tempo para serem executadas. Elas utilizam a CPU e consomem I\/O. Tamb\u00e9m podemos avaliar isso pelos campos total_time, mean_time, blk_write_time e blk_read_time. <\/p>\n

<\/p>\n

Podemos avaliar e monitorar as consultas mais pesadas em termos de uso de recursos, aquelas que leem do disco, que trabalham com mem\u00f3ria ou, ao contr\u00e1rio, criam alguma carga de escrita.<\/p>\n

<\/p>\n

Podemos avaliar as consultas mais generosas. Estas s\u00e3o aquelas que retornam um grande n\u00famero de linhas. Por exemplo, pode ser uma consulta onde algu\u00e9m esqueceu de definir um limite. E ela simplesmente retorna todo o conte\u00fado da tabela ou das tabelas solicitadas.<\/p>\n

<\/p>\n

E tamb\u00e9m podemos monitorar as consultas que utilizam arquivos tempor\u00e1rios ou tabelas tempor\u00e1rias. <\/p>\n

<\/p>\n

\"Fundamentos
\nE temos os processos em segundo plano. Processos em segundo plano s\u00e3o, antes de tudo, checkpoints, ou como tamb\u00e9m s\u00e3o chamados, pontos de controle, autovacuum e replica\u00e7\u00e3o. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Outro exemplo de monitoramento. H\u00e1 uma aba chamada Manuten\u00e7\u00e3o \u00e0 esquerda, vamos para ela e esperamos ver algo \u00fatil. Mas aqui s\u00f3 aparece o tempo de execu\u00e7\u00e3o do vacuum e da coleta de estat\u00edsticas, nada mais. Esta \u00e9 uma informa\u00e7\u00e3o muito escassa, por isso \u00e9 sempre necess\u00e1rio ter informa\u00e7\u00f5es sobre como os processos em segundo plano est\u00e3o funcionando em nosso banco de dados e se h\u00e1 problemas decorrentes de seu funcionamento. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Ao considerarmos os pontos de controle, devemos lembrar que os pontos de controle descartam p\u00e1ginas \"sujas\" da \u00e1rea de mem\u00f3ria fragmentada para o disco, e em seguida criam um ponto de controle. E esse ponto de controle pode ser utilizado como um local para recupera\u00e7\u00e3o, caso o PostgreSQL tenha sido encerrado de forma abrupta. <\/p>\n

<\/p>\n

Portanto, para descarregar todas as p\u00e1ginas 'sujas' para o disco, \u00e9 necess\u00e1rio realizar um certo volume de grava\u00e7\u00e3o. E, como regra geral, em sistemas com grande volume de mem\u00f3ria, isso representa uma quantidade imensa. E se tivermos checkpoints realizados com muita frequ\u00eancia em um curto intervalo, o desempenho do disco ser\u00e1 seriamente afetado. As solicita\u00e7\u00f5es dos clientes sofrer\u00e3o com a falta de recursos. Eles ir\u00e3o competir por recursos e ter\u00e3o dificuldades de desempenho. <\/p>\n

<\/p>\n

Assim, atrav\u00e9s do pg_stat_bgwriter, podemos monitorar o n\u00famero de checkpoints que ocorrem pelos campos especificados. E se em um determinado intervalo de tempo (10-15-20 minutos ou meia hora) tivermos muitos checkpoints, por exemplo, 3-4-5, isso j\u00e1 pode ser um problema. \u00c9 necess\u00e1rio verificar o banco de dados e a configura\u00e7\u00e3o para descobrir o que est\u00e1 causando essa abund\u00e2ncia de checkpoints. Pode ser que haja uma grande grava\u00e7\u00e3o em andamento. Com a carga de trabalho, j\u00e1 podemos avaliar, uma vez que temos gr\u00e1ficos de carga de trabalho dispon\u00edveis. Podemos ajustar os par\u00e2metros dos checkpoints para que n\u00e3o impactem tanto o desempenho das consultas.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Estou retornando ao autovacuum, porque, como j\u00e1 mencionei, \u00e9 uma coisa que pode facilmente comprometer o desempenho tanto dos discos quanto das consultas. Portanto, \u00e9 sempre importante avaliar a quantidade de autovacuum. <\/p>\n

<\/p>\n

O n\u00famero de trabalhadores autovacuum no banco de dados \u00e9 limitado. Por padr\u00e3o, s\u00e3o tr\u00eas; portanto, se tivermos sempre tr\u00eas trabalhadores ativos no banco, isso significa que nosso autovacuum n\u00e3o est\u00e1 configurado corretamente. Precisamos aumentar os limites, revisar as configura\u00e7\u00f5es do autovacuum e ajustar a configura\u00e7\u00e3o.
\n\u00c9 importante avaliar quais trabalhadores do vacuum est\u00e3o ativos. Pode ser que um vacuum tenha sido iniciado manualmente por um usu\u00e1rio, um DBA que acionou algum vacuum, gerando carga. Assim, aparece um problema. Ou trata-se da quantidade de vacuums que reduzem o contador de transa\u00e7\u00f5es. Para algumas vers\u00f5es do PostgreSQL, esses s\u00e3o vacuums muito pesados. E eles podem, facilmente, comprometer o desempenho, pois leem toda a tabela inteiramente, escaneando todos os blocos dessa tabela. <\/p>\n

<\/p>\n

E, claro, a dura\u00e7\u00e3o dos vacuums. Se tivermos vacuums longos que funcionam por muito tempo, isso significa que devemos prestar aten\u00e7\u00e3o na configura\u00e7\u00e3o do vacuum e, possivelmente, revisar suas defini\u00e7\u00f5es. Porque pode surgir uma situa\u00e7\u00e3o em que o vacuum funciona em uma tabela por um longo per\u00edodo (3-4 horas), mas durante esse tempo, um grande volume de linhas mortas se acumulou novamente na tabela. E assim que o vacuum termina, ele precisa novamente fazer o vacuum nessa tabela. E chegamos \u00e0 situa\u00e7\u00e3o de um vacuum infinito. Nesses casos, o vacuum n\u00e3o consegue fazer seu trabalho, e as tabelas come\u00e7am a aumentar gradualmente de tamanho, embora o volume de dados \u00fateis nelas permane\u00e7a o mesmo. Portanto, em vacuums longos, sempre olhamos para a configura\u00e7\u00e3o e tentamos otimiz\u00e1-la, sem que isso prejudique o desempenho das consultas dos clientes. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Atualmente, praticamente n\u00e3o existe uma instala\u00e7\u00e3o do PostgreSQL sem replica\u00e7\u00e3o em fluxo. Replica\u00e7\u00e3o \u00e9 o processo de transfer\u00eancia de dados do mestre para a r\u00e9plica.<\/p>\n

<\/p>\n

A replica\u00e7\u00e3o no PostgreSQL \u00e9 estruturada atrav\u00e9s do log de transa\u00e7\u00f5es. O mestre gera um log de transa\u00e7\u00f5es. O log de transa\u00e7\u00f5es \u00e9 enviado para a r\u00e9plica atrav\u00e9s da conex\u00e3o de rede e, em seguida, \u00e9 reproduzido na r\u00e9plica. \u00c9 simples. <\/p>\n

<\/p>\n

Assim, para monitorar o lag da replica\u00e7\u00e3o, usamos a visualiza\u00e7\u00e3o pg_stat_replication. Mas com ela n\u00e3o \u00e9 tudo t\u00e3o simples. Na vers\u00e3o 10, a visualiza\u00e7\u00e3o passou por algumas mudan\u00e7as. Primeiro, parte dos campos foi renomeada. E parte dos campos foi adicionada. Na vers\u00e3o 10 surgiram campos que permitem avaliar o lag da replica\u00e7\u00e3o em segundos. Isso \u00e9 muito conveniente. Antes da vers\u00e3o 10, havia a possibilidade de avaliar o lag da replica\u00e7\u00e3o em bytes. Essa possibilidade foi mantida na vers\u00e3o 10, ou seja, voc\u00ea pode escolher o que for mais conveniente \u2013 avaliar o lag em bytes ou em segundos. Muitos fazem ambos.<\/p>\n

<\/p>\n

Mas, para avaliar o lag da replica\u00e7\u00e3o, \u00e9 necess\u00e1rio saber a posi\u00e7\u00e3o do log na transa\u00e7\u00e3o. E essas posi\u00e7\u00f5es do log de transa\u00e7\u00e3o est\u00e3o precisamente na visualiza\u00e7\u00e3o pg_stat_replication. De forma simplificada, podemos usar a fun\u00e7\u00e3o pg_xlog_location_diff() para pegar dois pontos no log de transa\u00e7\u00f5es. Calcular a diferen\u00e7a entre eles e obter o lag da replica\u00e7\u00e3o em bytes. Isso \u00e9 muito conveniente e simples. <\/p>\n

<\/p>\n

Na 10\u00aa vers\u00e3o, essa fun\u00e7\u00e3o foi renomeada para pg_wal_lsn_diff(). De modo geral, em todas as fun\u00e7\u00f5es, vis\u00f5es e utilit\u00e1rios onde a palavra \u201cxlog\u201d aparecia, ela foi substitu\u00edda pelo valor \u201cwal\u201d. Isso se aplica tanto nas vis\u00f5es quanto nas fun\u00e7\u00f5es. Essa \u00e9 uma nova implementa\u00e7\u00e3o. <\/p>\n

<\/p>\n

Al\u00e9m disso, na 10\u00aa vers\u00e3o, foram adicionadas linhas que mostram especificamente o atraso. Esses s\u00e3o write lag, flush lag e replay lag. Ou seja, \u00e9 importante monitorar essas m\u00e9tricas. Se observarmos que h\u00e1 atraso na replica\u00e7\u00e3o, precisamos investigar por que ele ocorreu, de onde veio e solucionar o problema. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Em rela\u00e7\u00e3o \u00e0s m\u00e9tricas do sistema, praticamente est\u00e1 tudo em ordem. Quando qualquer monitoramento \u00e9 iniciado, ele come\u00e7a com as m\u00e9tricas do sistema. Isso inclui a utiliza\u00e7\u00e3o de CPU, mem\u00f3ria, swap, rede e disco. No entanto, muitos par\u00e2metros n\u00e3o est\u00e3o presentes por padr\u00e3o. <\/p>\n

<\/p>\n

Se a utiliza\u00e7\u00e3o do processo est\u00e1 em ordem, existem problemas com a utiliza\u00e7\u00e3o do disco. Geralmente, os desenvolvedores de monitoramentos adicionam informa\u00e7\u00f5es sobre a largura de banda. Isso pode ser em iops ou bytes. Mas eles esquecem sobre a lat\u00eancia e a utiliza\u00e7\u00e3o dos dispositivos de disco. Esses s\u00e3o par\u00e2metros mais importantes, que permitem avaliar o qu\u00e3o carregados est\u00e3o os discos e qu\u00e3o lentos est\u00e3o. Se temos alta lat\u00eancia, isso significa que h\u00e1 problemas com os discos. Se a nossa utiliza\u00e7\u00e3o \u00e9 alta, isto indica que os discos n\u00e3o est\u00e3o lidando com a carga.<\/strong> Essas s\u00e3o caracter\u00edsticas de maior qualidade do que a largura de banda.<\/p>\n

<\/p>\n

Embora essa estat\u00edstica possa ser obtida tamb\u00e9m do sistema de arquivos \/proc, como feito para a utiliza\u00e7\u00e3o da CPU, n\u00e3o sei por que essa informa\u00e7\u00e3o n\u00e3o \u00e9 adicionada aos monitoramentos. No entanto, \u00e9 importante ter isso no seu monitoramento.<\/strong> <\/p>\n

<\/p>\n

O mesmo se aplica aos interfaces de rede. H\u00e1 informa\u00e7\u00f5es sobre a largura de banda da rede em pacotes, em bytes, mas n\u00e3o h\u00e1 informa\u00e7\u00f5es sobre lat\u00eancia e nem sobre utiliza\u00e7\u00e3o, embora essas tamb\u00e9m sejam informa\u00e7\u00f5es \u00fateis.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Todo monitoramento tem suas desvantagens. E n\u00e3o importa qual monitoramento voc\u00ea escolha, sempre haver\u00e1 algo que n\u00e3o atende a alguns crit\u00e9rios. No entanto, eles est\u00e3o se desenvolvendo, novas funcionalidades est\u00e3o sendo adicionadas, portanto escolha algo e fa\u00e7a as melhorias necess\u00e1rias. <\/p>\n

<\/p>\n

E para efetuar essas melhorias, \u00e9 necess\u00e1rio sempre entender o que significa a estat\u00edstica fornecida e como utiliz\u00e1-la para resolver problemas. <\/p>\n

<\/p>\n

E alguns pontos chave:<\/p>\n

<\/p>\n