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
Re: proper tuning for restoring from pg_dump in 8.3.7 Re: proper tuning for restoring from pg_dump in 8.3.7 |
Список | 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 по дате отправления: