2013/7/2 Luiz Carlos L. Nogueira Jr. <lcnogueir...@gmail.com> > > > Em 2 de julho de 2013 09:51, Luiz Carlos L. Nogueira Jr. < > lcnogueir...@gmail.com> escreveu: > >> Infelizmente não temos esse canal de "comunicação" com quem desenvolve. >> Apenas tentamos fazer o banco ficar vivo com a aplicação que nos mandam. >> >> Não sei se você está comentando sobre minha reposta (já que não a adicionou), mas....
Nem sempre otimizar uma consulta significa modificá-la, em muitos casos (muitos mesmo), a criação de um índice resolve o problema. >> Já tinha solicitado mudar voltar o work_mem ao que era antes, mas estou >> no aguardo. >> A mudança pra 4MB foi depois das 10:00h. (antes era 50MB) >> > De 50MB para 4MB me parece uma mudança muito brusca! Out of memory é nosso maior problema hoje em dia e o pessoal fica atacando >> todos os lados para tentar resolver esse problema. >> > É um servidor dedicado ao banco? A solução é simples, adicione uma área de swap maior. ( claro que você já tem área de swap, né?! ) Você ainda poderá ter problema de performance (ou não), mas se out-of-memory for uma situação com baixa frequência, então isso resolveria. > Mandei o resultado do pgbadger de ontem (anexo) pra vocês terem uma noção >> do que estou falando..... >> >> DayHourTemporary filesCheckpointsCountAv. sizeWrote buffers Added >> RemovedRecycledWrite time (sec)Sync time (sec)Total time (sec)Jul 0100001,782 >> 006318.5350.845319.555 01001,706006299.776 4.28306.012 02001,706006 >> 291.277 2.641294.667 0300850007154.751 0.536155.579 040022800644.7120.347 >> 45.183 0500220063.343 0.0593.691 06007000612.97 0.19213.246 070013,267 >> 0061,342.563 2.3821,345.067 080041,76200171,799.65 2.4071,802.207 0900 >> 50,34300231,799.473 3.331,803.222 103,5041,422,158.8674,9940037 1,570.57 >> 4.7711,576.218 116,5891,555,362.3448,7610023 1,799.4533.1991,803.115 12 >> 4,4141,617,694.5444,0350021 1,799.8031.8921,801.845 134,2661,591,733.97 >> 24,4850011 1,799.2091.6781,801.092 145,5901,544,146.8046,65000191,799.546 >> 2.7381,802.66 157,4401,596,696.5850,5600024 1,795.2952.4971,797.963 16 >> 6,3151,487,407.7272,5920034 1,798.6753.81,802.758 174,1971,811,036.99 >> 28,6950016 1,799.1621.5221,801.012 182,9221,885,185.649,6740071,614.54 >> 1.2131,616.126 191,6721,897,135.944,150006830.22 0.82831.138 202,083 >> 1,724,297.358,6080061,380.218 0.6971,380.993 212,3141,628,368.376,761006 >> 1,339.318 0.7921,340.218 221,2841,832,566.919,133007830.726 1.255832.391 >> 231,0441,573,491.845,3800061,031.07 0.6541,032 >> > > É difícil determinar com certeza, mas pelas médias, vários desses arquivos estão com menos de 2MB, logo um work_mem de 6MB já poderia evitar boa parte desses. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
