Обсуждение: postgresql /var fill

Поиск
Список
Период
Сортировка

postgresql /var fill

От
km
Дата:
Hi all,

I have installed postgresql(8.1.4) data dir on a partition (/data) which rests on a separate disk from OS disk. The
installdir is default (usr/local/pgsql).  
Now when i use use pgbench with scaling factor of 1000 it creates a whooping 15 GB database. but i see /var partition
usedspace increases considerably - why is this happening ? i expected more free disk space to be used in /data ! 
does it mean that the actual database created lies in /var instead of /data ?
how do i fix it ?

regards,
KM


Re: postgresql /var fill

От
Ray Stell
Дата:
ls -l /
maybe /data is a symlink?



On Fri, Oct 06, 2006 at 07:10:12PM +0530, km wrote:
> Hi all,
>
> I have installed postgresql(8.1.4) data dir on a partition (/data) which rests on a separate disk from OS disk. The
installdir is default (usr/local/pgsql).  
> Now when i use use pgbench with scaling factor of 1000 it creates a whooping 15 GB database. but i see /var partition
usedspace increases considerably - why is this happening ? i expected more free disk space to be used in /data ! 
> does it mean that the actual database created lies in /var instead of /data ?
> how do i fix it ?
>
> regards,
> KM
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--

Re: postgresql /var fill

От
km
Дата:
On Fri, Oct 06, 2006 at 09:38:46AM -0400, Ray Stell wrote:
>
> ls -l /
> maybe /data is a symlink?
>
no /data is the label for  separate SCSI disk.
no symlinks !!!
/var resides on /dev/sda, and  /data in /dev/sdb
regards,
KM

Re: postgresql /var fill

От
Csaba Nagy
Дата:
> /var resides on /dev/sda, and  /data in /dev/sdb

I bet you're running a default installation of postgres which has it's
data in /var.
Check your real data directory by running 'ps auxww|grep post', and see
what's after the '-D' parameter... and then when you figure out that the
startup script is using the system default and not what you've
initdb-ed, fix your start script ;-)

Cheers,
Csaba.



Re: postgresql /var fill

От
km
Дата:
On Fri, Oct 06, 2006 at 03:57:47PM +0200, Csaba Nagy wrote:
> > /var resides on /dev/sda, and  /data in /dev/sdb
>
> I bet you're running a default installation of postgres which has it's
> data in /var.
> Check your real data directory by running 'ps auxww|grep post', and see
> what's after the '-D' parameter... and then when you figure out that the
> startup script is using the system default and not what you've
> initdb-ed, fix your start script ;-)

nope! i have purposefully deselected postgres 7.4 installation at OS install.
then downloaded postgresql sources of 8.1.4 and installed it in /usr/local/pgsql with data dir as /data/pgdata. later ,
ihave set PGDATA to /data/pgdata in startup script from contrib/scripts of sources and placed it in /etc/init.d 
to be sure, i re-checked with rpm -qa|postgres too which didnt give me any package listing.

ps auxww |grep postgresql gives /data/pgdata as the data dir.

whats happening ?

regards,
KM



Re: postgresql /var fill

От
Richard Huxton
Дата:
km wrote:
> nope! i have purposefully deselected postgres 7.4 installation at OS install.
> then downloaded postgresql sources of 8.1.4 and installed it in /usr/local/pgsql with data dir as /data/pgdata. later
,i have set PGDATA to /data/pgdata in startup script from contrib/scripts of sources and placed it in /etc/init.d 
> to be sure, i re-checked with rpm -qa|postgres too which didnt give me any package listing.
>
> ps auxww |grep postgresql gives /data/pgdata as the data dir.
>
> whats happening ?

Have you tried looking in /var to see what's there?

find /var -type f -msize +9999k

--
   Richard Huxton
   Archonet Ltd

Re: postgresql /var fill

От
Frank Finner
Дата:
Maybe you switched full statement logging on in postgresql.conf? This can result in a considerable amount of logfile
datain /var/log/somewhere, often /var/log/postgresql/ (although 15 GB is really quite a lot).
 

Regards, Frank.


On Fri, 6 Oct 2006 19:10:12 +0530 km <km@mrna.tn.nic.in> thought long, then sat down and wrote:

> Hi all,
> 
> I have installed postgresql(8.1.4) data dir on a partition (/data) which rests on a separate disk from OS disk. The
installdir is default (usr/local/pgsql). 
 
> Now when i use use pgbench with scaling factor of 1000 it creates a whooping 15 GB database. but i see /var partition
usedspace increases considerably - why is this happening ? i expected more free disk space to be used in /data !
 
> does it mean that the actual database created lies in /var instead of /data ?
> how do i fix it ?
> 
> regards,
> KM
>  
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster


-- 
Frank Finner

Invenius - Lösungen mit Linux
Köpfchenstraße 36
57072 Siegen
Telefon: 0271 231 8606    Mail: frank.finner@invenius.de
Telefax: 0271 231 8608    Web:  http://www.invenius.de
Key fingerprint = 90DF FF40 582E 6D6B BADF  6E6A A74E 67E4 E788 2651


Вложения

Re: postgresql /var fill

От
km
Дата:
> Have you tried looking in /var to see what's there?
>
> find /var -type f -msize +9999k

ya looking for files bigger than 9999KB showed only:
/var/lib/rpm/RpmPackages
/var/lib/rpm/Filemd5s

regards,
KM


Re: postgresql /var fill

От
Tom Lane
Дата:
km <km@mrna.tn.nic.in> writes:
> whats happening ?

Unless you're using tablespaces, the server will definitely not write
anywhere outside its assigned data directory.  Are you sure that the
growth in /var is related at all?  Maybe something spewing messages
to syslog?

            regards, tom lane

Re: postgresql /var fill

От
Richard Huxton
Дата:
km wrote:
>> Have you tried looking in /var to see what's there?
>>
>> find /var -type f -msize +9999k
>
> ya looking for files bigger than 9999KB showed only:
> /var/lib/rpm/RpmPackages
> /var/lib/rpm/Filemd5s

1. Try a smaller size and see if you get lots of files at say 5000k.
2. Try something else to find out why /var is being used up
    du -sm /var/*
    Then try the same a little deeper.
3. Check again that /var really is being used up.

--
   Richard Huxton
   Archonet Ltd