pg.ddx.io pgsql-benchmarks@postgresql.org mailing list archive
help / color / mirror / Atom feedLargest DATABASE
2+ messages / 2 participants
[nested] [flat]
* Largest DATABASE
@ 2004-09-14 18:40 Jamil <jamil.figueira@ibi.com.br>
2004-09-14 20:46 ` Re: Largest DATABASE Rod Taylor <pg@rbt.ca>
0 siblings, 1 reply; 2+ messages in thread
From: Jamil @ 2004-09-14 18:40 UTC (permalink / raw)
To: pgsql-benchmarks
Hello everyone,
I would like to know witch was the largest database that you ever
had to administrate. My database is about to 160GB and I´ve got some
problems to backup it using the pg_dump command and I too have some problems
to run vaccum.
Do you know any other way to do this operations?
My hardware is a IBM F50 with 4 processors and 2GB RAM and 163GB of
hard disks plus 16GB of disks to the AIX Operation System. My backup unit is
a 20/40 DAT and if I do a pg_dump them compress it, I can put all the
database in only one tape.
> Best Regards,
>
> Jamil Marques Figueira Junior
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Largest DATABASE
2004-09-14 18:40 Largest DATABASE Jamil <jamil.figueira@ibi.com.br>
@ 2004-09-14 20:46 ` Rod Taylor <pg@rbt.ca>
0 siblings, 0 replies; 2+ messages in thread
From: Rod Taylor @ 2004-09-14 20:46 UTC (permalink / raw)
To: Jamil <jamil.figueira@ibi.com.br>; +Cc: pgsql-benchmarks
> I would like to know witch was the largest database that you ever
> had to administrate. My database is about to 160GB and I´ve got some
> problems to backup it using the pg_dump command and I too have some problems
> to run vaccum.
Tell me about it. We started to do more fine grained scheduling of
vacuum a little while back we we past the 120GB mark.
You can try out the vacuum daemon, but it really didn't help me (little
tables were ignored too much, big tables done too often).
Check VACUUM VERBOSE output to see if you need to vacuum all of the
structures at the current rate.
We're still doing the dump, but running pg_dump on a different machine.
Most of the CPU time it eats up is in formatting the data for the dump.
Another option (which can take some effort) is to take the database
offline, fsync, take a filesystem snapshot, restart the database, tar up
the snapshot, remove the snapshot.
Database downtime can be short enough that if clients reattempt a failed
connection for some time (a couple of minutes), they'll simply see a
hicup and not a failure.
Looking forward to PITR making backups much friendlier.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2004-09-14 20:46 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-09-14 18:40 Largest DATABASE Jamil <jamil.figueira@ibi.com.br>
2004-09-14 20:46 ` Rod Taylor <pg@rbt.ca>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox