Re: Parallel Seq Scan
От | Jim Nasby |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 54C824B1.4020305@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: