On 1/27/15 3:46 PM, Stephen Frost wrote:
>> With 0 workers, first run took 883465.352 ms, and second run took 295050.106 ms.
>> >With 8 workers, first run took 340302.250 ms, and second run took 307767.758 ms.
>> >
>> >This is a confusing result, because you expect parallelism to help
>> >more when the relation is partly cached, and make little or no
>> >difference when it isn't cached. But that's not what happened.
> These numbers seem to indicate that the oddball is the single-threaded
> uncached run. If I followed correctly, the uncached 'dd' took 321s,
> which is relatively close to the uncached-lots-of-workers and the two
> cached runs. What in the world is the uncached single-thread case doing
> that it takes an extra 543s, or over twice as long? It's clearly not
> disk i/o which is causing the slowdown, based on your dd tests.
>
> One possibility might be round-trip latency. The multi-threaded case is
> able to keep the CPUs and the i/o system going, and the cached results
> don't have as much latency since things are cached, but the
> single-threaded uncached case going i/o -> cpu -> i/o -> cpu, ends up
> with a lot of wait time as it switches between being on CPU and waiting
> on the i/o.
This exactly mirrors what I've seen on production systems. On a single SeqScan I can't get anywhere close to the IO
performanceI could get with dd. Once I got up to 4-8 SeqScans of different tables running together, I saw iostat
numbersthat were similar to what a single dd bs=8k would do. I've tested this with iSCSI SAN volumes on both 1Gbit and
10Gbitethernet.
This is why I think that when it comes to IO performance, before we start worrying about real parallelization we should
investigateways to do some kind of async IO.
I only have my SSD laptop and a really old server to test on, but I'll try Tom's suggestion of adding a PrefetchBuffer
callinto heapgetpage() unless someone beats me to it. I should be able to do it tomorrow.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
