From: | "Burgholzer, Robert (DEQ)" <Robert(dot)Burgholzer(at)deq(dot)virginia(dot)gov> |
---|---|
To: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: proper tuning for restoring from pg_dump in 8.3.7 |
Date: | 2010-07-14 17:45:25 |
Message-ID: | B6C40D17104BEF47B1CB85623CDFAC63895EFE@COVMSGCES-EMB13.cov.virginia.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
OK, thanks to multiple folks for letting me know that I was looking at
the wrong "top" metric. That said, my performance in most definitely
suffering -- does this "swap" number seem excessive (looks like ~100 G
to me):
Swap: 102399992k total
> Cached data is not a problem. Don't worry about that.
As for my concerns about the cache'ing of files, we have found that we
can reclaim our servers performance by doing the following:
sync
echo 1 > /proc/sys/vm/drop_caches
But I am really squeamish about this - it just seems like something is
wrong with this approach. The grinding halt will occur when doing
either a large copy from PG, or from tests where we created then closed
a huge number of largeish files. CentOS (regularly updated) is the
Linux that we are running.
Thanks also for the settings pointers, and the notion that I can do a
restore with different settings than production. And also, I will give
the alternatives to "cat" a whirl.
Thanks to everyone,
r.b.
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Deugau | 2010-07-14 18:00:28 | Re: proper tuning for restoring from pg_dump in 8.3.7 |
Previous Message | Tom Lane | 2010-07-14 17:19:37 | Re: proper tuning for restoring from pg_dump in 8.3.7 |