> > > > Desculpe mas ficou confuso pois pelo que entendi lendo emails anteriores > o seu "pior" foi por conta da falha do arquivamento... posso também ter > entendido errado. > > O que vc julga como "pior"?? Performance?? Vc tem dados para nos > fornecer?? Além disso vc disse que ao alterar o shared_buffers o > PostgreSQL não iniciou, vc poderia fornecer as entradas no log que > indicam o problema? > > Como o Euler já mencionou um valor de shared_buffers impacta em um > checkpoint mais demorado e durante o stop do serviço o PostgreSQL efetua > um para ele poder "parar em um estado consistente" e não necessitar de > um "recovery" no próximo "start". Se vc forçou o "stop" do serviço para > ser mais rápido então no próximo "start" ele entrará em "recovery" e > isso pode demorar algum tempo. > >
Olá pessoal... tudo bem? Desculpem pelas frases mal colocadas ontem... na correria aqui acabei escrevendo de qualquer jeito. Vou explicar o que aconteceu.. Pois eu descobri o problema. - Estamos enfrentando problemas de IO há meses.. Utilizamos discos sata em todos os servidores (1 master e 2 slaves). A empresa não quer gastar em discos SAN (Não podemos utilizar SSD por causa da limitação de tamanho, uma vez que a empresa em que temos os servidores permite o máximo de 3TB, nossa DB hoje já é 2.2TB)... ... então estamos fazendo de tudo para melhorar a performance... reescrevendo SQLs... criando novos índices e mudando os que já estão em funcionamento e são precários... Porém.. isso tem ajudado com o read... mas nosso problema é write. Meses de pesquisas.. meses de testes... e cheguei a conclusão de que diminuir o shared_buffer (atualmente 51GB) seria o mais adequado para ajudar nesse quesito IO. Claro que todos os testes que fiz, foi em minha VM. Não tenho como ter um servidor igual ao de produção só para testes.... Sendo assim, ontem, alterei o shared_buffer de 51GB para 32 GB. O problema, é que quando parei o postgres para reiniciar ele novamente, ele não subia de volta.... dava falha. Tentei por alguns minutes descobrir o que estava acontecendo, e, sem sucesso, decidimos reiniciar o servidor. Até porque fazia mais de um ano que o mesmo não era reiniciado. Quando reiniciamos o servidor, já com o shared_buffer alterado, a DB se comportou bem por 3 horas. Após as 9h, começamos a ter spikes de 20 em 20 minutos... Fizemos de tudo... voltamos o shared_buffer para 51GB... desativamos autovacuum.. desativamos backups... tudo.. e o problema persistia. Finalmente, às 17h, descobri o problema. /sys/kernel/mm/transparent_hugepage/defrag = always > /sys/kernel/mm/transparent_hugepage/enabled = always hugepage estava ativo.... temos um script que desativa ele na inicialização do sistema, mas o mesmo não funcionou... armazenamos todos os nossos logs em um servidor remoto, e, por incível que pareça, o servidor de logs deu problema bem quando reiniciamos o master, e com isto, perdemos os logs daquele período... por isto não descobrimos antes. O shared_buffer está de volta como estava, 51GB... mas agora.. após descobrir o problema, acredito que será alterado para 32GB de novo.. só não sei quando heheheh
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
