Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
От | Fabien COELHO |
---|---|
Тема | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |
Дата | |
Msg-id | alpine.DEB.2.02.1306112254010.10500@localhost6.localdomain6 обсуждение исходный текст |
Ответ на | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) (Greg Smith <greg@2ndQuadrant.com>) |
Список | pgsql-hackers |
>> - ISTM that there "thread start time" should be initialized at the >> beginning of threadRun instead of in the loop *before* thread creation, >> otherwise the thread creation delays are incorporated in the >> performance measure, but ISTM that the point of pgbench is not to >> measure thread creation performance... > > I noticed that, but it seemed a pretty minor issue. Not for me, because the "max lag" measured in my first version was really the threads creation time, not very interesting. > Did you look at the giant latency spikes at the end of the test run I > submitted the graph for? I've looked at the graph you sent. I must admit that I did not understand exactly what is measured and where it is measured. Because of its position at the end of the run, I thought of some disconnection related effects when pgbench run is interrupted by a time out signal, so some things are done more slowly. Fine with me, we are stopping anyway, and out of the steady state. > I wanted to nail down what was causing those before worrying about the > startup timing. Well, the short answer is that I'm not worried by that, for the reason explained above. I would be worried if it was anywhere else but where the transactions are interrupted, the connections are closed and the threads are stopped. I may be wrong:-) -- Fabien.
В списке pgsql-hackers по дате отправления: