Matheus de Oliveira.
Bem, na minha opinião um tablespace sobre NFS é uma péssima ideia, eu tenho
fortes suspeitas que seja algum problema relacionado ao NFS (falha ao
realizar fsync, problema na extensão do arquivo, algum bug, etc.).
Antes de descabelar, verifique de que relação estamos falando, conecte-se
no banco em questão (se não souber qual é passe o caminho completo do
arquivo que te falo), e execute o seguinte comando:
SELECT oid::regclass FROM pg_class WHERE relfilenode = 53907;
oid
------------
metric_old
(1 row)
Essa tabela (os dados dela de fato) são dispensáveis ou podem ser
recuperados de um backup? Se não, talvez possamos tentar truncar o arquivo,
mas para isso você vai precisar parar o sistema ou copiar tudo para um
ambiente de testes.
Por politica da empresa hoje ela não entra em backup. No momento seus dados
ainda não são dispensáveis, mas após resolver este problema vou usar de uma
BOA politica para desativa-la permanentemente, :) preciso de somente pegar
algumas informações antes.
Outra coisa, eu recomendo que faça um planejamento imediato para sair do
NFS, é realmente uma péssima ideia.
Vou providenciar um compartilhamento NFS, ja que hoje é em um NTFS.
(Obrigado Matheus e Flavio)
Outra informação pertinente essa tabela só tem dados antigos (metric_old),
não recebe escrita.
Quando você fala truncar, seria remove este arquivo? (claro, em teste antes)
Em 27 de outubro de 2014 13:30, Matheus de Oliveira <
matioli.math...@gmail.com> escreveu:
>
> 2014-10-27 11:45 GMT-02:00 Ariel Alves <arielalves...@gmail.com>:
>
>> 1) Algum problema no ambiente (principalmente relacionado à IO/disco)
>> aconteceu recentemente?
>> Não temos nenhum problema de discos
>>
>> 2) Remoto? Como? NFS? Algum problema na rede?
>> É um compartilhamento NTFS montado como CIFS.
>> O monitoramento não informou de problema de rede e nem o
>> datacer comunicou nada.
>>
>> 3) O PostgreSQL foi compilado/configurado fora do padrão? Na dúvida
>> execute o comando "pg_config" e poste o resultado aqui.
>> Foi instalado por apt-get do debian.
>>
>> ...
>> CONFIGURE = '--with-tcl' '--with-perl' '--with-python' '--with-pam'
>> '--with-openssl' '--with-libxml' '--with-libxslt'
>> '--with-tclconfig=/usr/lib/tcl8.5' '--with-includes=/usr/include/tcl8.5'
>> 'PYTHON=/usr/bin/python' '--mandir=/usr/share/postgresql/9.1/man'
>> '--docdir=/usr/share/doc/postgresql-doc-9.1'
>> '--sysconfdir=/etc/postgresql-common' '--datarootdir=/usr/share/'
>> '--datadir=/usr/share/postgresql/9.1'
>> '--bindir=/usr/lib/postgresql/9.1/bin' '--libdir=/usr/lib/'
>> '--libexecdir=/usr/lib/postgresql/' '--includedir=/usr/include/postgresql/'
>> '--enable-nls' '--enable-integer-datetimes' '--enable-thread-safety'
>> '--enable-debug' '--disable-rpath' '--with-ossp-uuid' '--with-gnu-ld'
>> '--with-pgport=5432' '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-g
>> -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
>> -Werror=format-security -fPIC -pie -fno-omit-frame-pointer'
>> 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ=0' 'LDFLAGS=-Wl,-z,relro
>> -Wl,-z,now -Wl,--as-needed' '--with-krb5' '--with-gssapi' '--with-ldap'
>> CC = gcc
>> ...
>>
>
> Aparentemente tudo OK.
>
>
>
>> 4) Alguma atualização de versão/hardware/SO recentes que devamos saber?
>> Não tivemos atualização de versão de SO ou Hardware.
>>
>> 5) Verifique quais são os arquivos que possuem mais que 1GB, encontrou
>> algum? Poste aqui.
>> Tenho um arquivo com 2,3G
>>
>> -rwx------ 0 postgres postgres 1,0G Out 23 10:12 53907
>> -rwx------ 0 postgres postgres 1,0G Ago 13 19:17 53907.1
>> -rwx------ 0 postgres postgres 1,0G Ago 13 19:17 53907.10
>> ...
>> -rwx------ 0 postgres postgres 2,3G Out 23 19:23 53907.2
>>
>
> Bem, na minha opinião um tablespace sobre NFS é uma péssima ideia, eu
> tenho fortes suspeitas que seja algum problema relacionado ao NFS (falha ao
> realizar fsync, problema na extensão do arquivo, algum bug, etc.).
>
> Antes de descabelar, verifique de que relação estamos falando, conecte-se
> no banco em questão (se não souber qual é passe o caminho completo do
> arquivo que te falo), e execute o seguinte comando:
>
> SELECT oid::regclass FROM pg_class WHERE relfilenode = 53907;
>
> Essa tabela (os dados dela de fato) são dispensáveis ou podem ser
> recuperados de um backup? Se não, talvez possamos tentar truncar o arquivo,
> mas para isso você vai precisar parar o sistema ou copiar tudo para um
> ambiente de testes.
>
> Outra coisa, eu recomendo que faça um planejamento imediato para sair do
> NFS, é realmente uma péssima ideia.
>
> 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
>
>
--
José Ariel Ferreira Alves
arielalves...@gmail.com
ariel.al...@msn.com
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
