From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |
Date: | 2013-06-11 21:13:05 |
Message-ID: | alpine.DEB.2.02.1306112254010.10500@localhost6.localdomain6 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Liming Hu | 2013-06-11 21:23:26 | Re: request a new feature in fuzzystrmatch |
Previous Message | Alvaro Herrera | 2013-06-11 20:57:26 | Re: request a new feature in fuzzystrmatch |