Re: 8.3 / 8.2.6 restore comparison
От | Greg Smith |
---|---|
Тема | Re: 8.3 / 8.2.6 restore comparison |
Дата | |
Msg-id | Pine.GSO.4.64.0802071139470.10403@westnet.com обсуждение исходный текст |
Ответ на | 8.3 / 8.2.6 restore comparison ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: 8.3 / 8.2.6 restore comparison
|
Список | pgsql-hackers |
On Wed, 6 Feb 2008, Joshua D. Drake wrote: > 8.2.6 after 2 hours has restored 41GB. I've been doing a long bulk import job recently (COPY) on a box with more spindles than yours (but with a dumb controller) and I too am stuck at that speed; I calculate a consistant 19.6GB/hour. The actual disk I/O is very low as that works out to only 5.7MB/s of progress. Mine was bottlenecked by capacity of a single CPU (4X Opteron system). I think this is one of those barriers it's hard to crack without a caching controller, for reasons I haven't figured out completely yet. > I am thinking the way we are going to need to do this is to have an > extended outage and write a custom script to do a concurrent dump and > load. If you look at the -performance list this week I've been yelping about this issue and trying to figure out how to setup a useful multi-CPU loader for cases like these. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: