Re: Maximum Possible Insert Performance?
От | William Yu |
---|---|
Тема | Re: Maximum Possible Insert Performance? |
Дата | |
Msg-id | bq2la9$2jh1$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Maximum Possible Insert Performance? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Maximum Possible Insert Performance?
|
Список | pgsql-performance |
Josh Berkus wrote: > William, > > >>When my current job batch is done, I'll save a copy of the dir and give >>the WAL on ramdrive a test. And perhaps even buy a Sandisk at the local >>store and run that through the hooper. > > > We'll be interested in the results. The Sandisk won't be much of a > performance test; last I checked, their access speed was about 1/2 that of a > fast SCSI drive. But it could be a feasability test for the more expensive > RAMdrive approach. Some initial numbers. I simulated a CPU increase by underclocking the processors. Most of the time, performance does not scale linearly with clock speed but since I also underclocked the FSB and memory bandwidth with the CPU, it's nearly an exact match. 1.15GHz 6.14 1.53GHz 6.97 +33% CPU = +13.5% performance I then simulated adding a heapload of extra memory by running my job a second time. Unfortunately, to keep my 25GB DB mostly cached in memory, the word heapload is too accurate. Run 1 6.97 Run 2 7.99 +14% I popped in an extra IDE hard drive to store the WAL files and that boosted the numbers by a little. From looking at iostat, the ratio looked like 300K/s WAL for 1MB/s data. WAL+Data on same disk 6.97 WAL+Data separated 7.26 +4% I then tried to put the WAL directory onto a ramdisk. I turned off swapping, created a tmpfs mount point and copied the pg_xlog directory over. Everything looked fine as far as I could tell but Postgres just panic'd with a "file permissions" error. Anybody have thoughts to why tmpfs would not work?
В списке pgsql-performance по дате отправления: