Re: pgbench throttling latency limit
От | Heikki Linnakangas |
---|---|
Тема | Re: pgbench throttling latency limit |
Дата | |
Msg-id | 5416C0A6.8040407@vmware.com обсуждение исходный текст |
Ответ на | Re: pgbench throttling latency limit (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgbench throttling latency limit
|
Список | pgsql-hackers |
On 09/13/2014 11:25 AM, Fabien COELHO wrote: > >> [about logging...] > > Here is an attempt at updating the log features, including the aggregate > and sampling stuff, with skipped transactions under throttling. > > I moved the logging stuff into a function which is called when a > transaction is skipped or finished. Makes sense. I spent some time on this, and this is what I ended up with. Notable changes: * I split this into two patches for easier review. The first patch contains the refactoring of the logging stuff, and the second patch contains the new functionality. * I renamed many of the variables, to be more consistent with existing similar variables * progress reporting was broken with !PTHREAD_FORK_EMULATION. Need to collect the number of skipped xacts from all threads. * I renamed the long option to --latency-limit. --limit is too generic. Please have a look. I have not looked at the docs changes yet. One thing that needs some thinking and changing is the progress reporting. It currently looks like this: progress: 1.0 s, 4863.0 tps, lat 3.491 ms stddev 2.487, lag 1.809 ms, 99 skipped progress: 2.0 s, 5042.8 tps, lat 3.265 ms stddev 2.264, lag 1.584 ms, 16 skipped progress: 3.0 s, 4926.1 tps, lat 2.731 ms stddev 2.371, lag 1.196 ms, 45 skipped progress: 4.0 s, 4963.9 tps, lat 1.904 ms stddev 1.212, lag 0.429 ms, 0 skipped progress: 5.0 s, 4971.2 tps, lat 2.592 ms stddev 1.722, lag 0.975 ms, 0 skipped The absolute number of skipped transactions doesn't make much sense when all the other numbers are averages, and tps is a 1/s value. If you don't know the total number of transactions executed, the absolute number is meaningless. (Although you can calculate the absolute number of transactions executed by multiplying the TPS value with the interval). I think a percentage would be better here. Should we also print the number of late transactions here? I think that would be an even more important detail than the number of skipped transactions. It might be better to print only the percentage of late transactions, including skipped ones. Or both, but it's difficult to cram everything on a single line. This needs some further thinking.. - Heikki
Вложения
В списке pgsql-hackers по дате отправления: