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?
