Pois é Leandro, cheguei a pensar nisso mesmo... A questão é que conseguir identificar isso é muito mais "caro"...
Agora que entendi o problema queria ver se conseguia resolver isso com configurações, pq correr atrás de queries dentro de uma aplicação é dureza! :/ Mas valeu.. Se alguém tiver mais alguma informação que possa ser útil eu agradeço, senão o jeito é deixar ele comer todo o espaço mesmo, já que tem bastante memória (hd) disponível... 2009/5/22 Leandro Henrique Pereira Neto < [email protected]> > > > Wagner Bonfiglio escreveu: > > Entendi sim Danilo, valeu... > Mas a questão é que aumentei até para 8192 (8MB) e continua criando arquivo > atrás de arquivo na tal pasta!! > > Ta estranho isso... > > > > Procure ver pelo outro lado. Identifique quais os comandos estão precisando > de área temporária e porque. Pode existir algum desvio na elaboração destes > comandos SQL ou na modelagem do banco. > Por exemplo se todos os usuários fizerem ao mesmo tempo um SQL que faz > order by em todas as linhas de uma tabela grande, não vai adiantar muito > ficar alterando o tamanho da work_mem. > > 2009/5/22 Danilo - InfoCont Sistemas Integrados <[email protected]> > >> Wagner, só para esclarecer (caso não saibas). >> >> Para cada select, é reservado um espaço na memória para o "order by"... se >> o order by for maior que esse espaço reservado, vai usar arquivo. >> Como esse espaço resevado deve estar sendo pequeno, os vários "select's" >> estão criando um monte de arquivo (pois vários deles estão ultrapassando 1 >> MB)... por isso que apenas 2 MB possa resolve (ou no mínimo dimuniur). >> >> Blz? Espero ter ajudado. >> >> JotaComm escreveu: >> >> Olá, >> >> Tem tudo a ver. Se o work_mem for suficiente ele não vai criar os arquivos >> temporários, caso não seja suficiente ele vai criar os arquivos temporários. >> >> 2009/5/22 Wagner Bonfiglio <[email protected]> >> >> Opa, valeu, vou tentar!! >> >> Mas me diz uma coisa... Se está crescendo na casa dos GB em pouco tempo >> (chutando pelo que eu me lembro da ultima checagem, coisa de 5GB em meia >> hora), esse valor de 2MB pode ser que seja pequeno? Ou uma coisa não tem >> nada a ver com a outra e 2MB deve resolver?? >> >> De qualquer maneira vou tentar 2MB agora, qualquer coisa aumento depois... >> >> Valeu cara!! >> >> >> >> 2009/5/22 JotaComm <[email protected]> >> >> Olá, >> >> Isso acontece quando o parâmetro work_mem é ultrapassado. O parâmetro >> work_mem define o quanto de memória serÁ utilizado para ordenação e o valor >> padrão deste parâmetro é 1MB. >> >> Os arquivos estão sendo gerados porque está sendo requisitado um valor >> maior do que o valor padrão, e ai a ordenação é feita em disco. Para >> diminuir o crescimento é interessante aumentar o valor de work_mem. >> >> Você pode mudar de três maneiras: >> >> 1) Arquivo de configuração postgresql.conf >> 2) Por sessão: SET WORK_MEM TO "2MB"; >> 3) Por usuário: ALTER ROLE postgres SET WORK_MEM TO "2MB"; >> >> >> >> 2009/5/22 Wagner Bonfiglio <[email protected]> >> >> Boa tarde senhores.. >> >> Dentro do diretório /var/lib/pgsql/data/base/NUMERO_BASE/pgsql_tmp/ estão >> sendo criados vários arquivos no formato "pgsql_tmpXXX.YY" (sendo XXX e YY >> numeros) continuamente, e eles chegam a ocupar 99% do espaço em disco... >> Quando limpo esse diretório cai para menos de 10% da capacidade do disco... >> >> Eu li por aí que esses arquivos são temporários e servem para ajudar nos >> "order by" da vida... >> O problema que eles estão ficando muito grandes e eu não sei exatamente >> para que servem, por que demoram para ser excluídos (no caso quando não tem >> mais espaço em disco), por que crescem tanto, etc... >> >> Alguém poderia me dar mais informações sobre ele? E principalmente como >> posso limitar o crescimento deles? >> >> Desde já agradeço... >> >> Att, >> Wagner Bonfiglio >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> >> []s >> -- >> JotaComm >> http://jotacomm.wordpress.com >> http://www.dextra.com.br/postgres >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> >> []s >> -- >> JotaComm >> http://jotacomm.wordpress.com >> http://www.dextra.com.br/postgres >> >> ------------------------------ >> >> _______________________________________________ >> pgbr-geral mailing >> [email protected]https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> >> -- >> >> Danilo Pacheco Martins >> >> InfoCont Sistemas Integrados Ltda. >> >> Diretor >> Fone: >> (47) 3422-3536 >> >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > ------------------------------ > > _______________________________________________ > pgbr-geral mailing > [email protected]https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), > empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é > enviada exclusivamente a seu destinatário e pode conter informações > confidenciais, protegidas por sigilo profissional. Sua utilização > desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a > recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, > esclarecendo o equívoco." > > "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a > government company established under Brazilian law (5.615/70) -- is directed > exclusively to its addressee and may contain confidential data, protected > under professional secrecy rules. Its unauthorized use is illegal and may > subject the transgressor to the law's penalties. If you're not the addressee, > please send it back, elucidating the failure." > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
