Hi, On 2016-10-06 14:38:56 -0400, Robert Haas wrote: > Obviously, there's a vast increase in TPS, and the backends seem to > spend most of their time actually doing work. ClientRead is now the > overwhelmingly dominant wait event, although wal_insert and > WALWriteLock contention is clearly still a significant problem. > Contention on other locks is apparently quite rare. Notice that > client reads are really significant here - more than 20% of the time > we sample what a backend is doing, it's waiting for the next query. > It seems unlikely that performance on this workload can be improved > very much by optimizing anything other than WAL writing, because no > other wait event appears in more than 1% of the samples.
I don't think you meant that, but this sounds a bit like that there's nothing to do performance-wise - I don't think that's true. There's no significant lock-contention, yes. But that obviously doesn't mean we can use resources more efficiently. > Second, ClientRead becomes a bigger and bigger issue as the number of > clients increases; by 192 clients, it appears in 45% of the samples. > That basically means that pgbench is increasingly unable to keep up > with the server; for whatever reason, it suffers more than the server > does from the increasing lack of CPU resources. Isn't that more a question of pgbench threads beeing preemted, so server processes can run? Since there's not enough hardware threads for both servers and clients to always run, you *have* to switch between them. Usually a read from the client after processing a query will cause a directed wakeup of the other thread (which is why it's not a very frequently observed state), but if the queue of to-be-run tasks is very long that'll not happen. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
