Re: proper tuning for restoring from pg_dump in 8.3.7

Поиск
Список
Период
Сортировка
От Burgholzer, Robert (DEQ)
Тема Re: proper tuning for restoring from pg_dump in 8.3.7
Дата
Msg-id B6C40D17104BEF47B1CB85623CDFAC63895EFE@COVMSGCES-EMB13.cov.virginia.gov
обсуждение исходный текст
Ответ на Re: proper tuning for restoring from pg_dump in 8.3.7  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proper tuning for restoring from pg_dump in 8.3.7  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: proper tuning for restoring from pg_dump in 8.3.7  (Kris Deugau <kdeugau@vianet.ca>)
Re: proper tuning for restoring from pg_dump in 8.3.7  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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.

В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: proper tuning for restoring from pg_dump in 8.3.7
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: proper tuning for restoring from pg_dump in 8.3.7