(2012/10/14 13:26), Fujii Masao wrote:
> On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu <snaga@uptime.jp> wrote:
>> HEAD
>> ====
>> number of transactions actually processed: 3439971
>> tps = 57331.891602 (including connections establishing)
>> tps = 57340.932324 (excluding connections establishing)
> <snip>
>> pg_stat_lwlocks patch (reporting disabled)
>> ==========================================
>> number of transactions actually processed: 3429370
>> tps = 57155.286475 (including connections establishing)
>> tps = 57163.996943 (excluding connections establishing)
>>
>> So, I think some additional hack to reduce reporting is needed.
>> Would it be acceptable in terms of the performance?
>
> The tracing lwlock usage seems to still cause a small performance
> overhead even if reporting is disabled. I believe some users would
> prefer to avoid such overhead even if pg_stat_lwlocks is not available.
> It should be up to a user to decide whether to trace lwlock usage, e.g.,
> by using trace_lwlock parameter, I think.
Frankly speaking, I do not agree with disabling performance
instrument to improve performance. DBA must *always* monitor
the performance metrix when having such heavy workload.
But it's ok to add a parameter to switch enable/disable it.
Any other comments?
>>> Another comment is; local_calls/waits/time_ms are really required?
>>> I'm not sure how those info would help the performance debugging.
>>
>>
>> I think there are some needs to observe/determine how your test
>> query is affected by the other workload from the other sessions.
>> So, splitting local and shared statistics would be nice to have.
>> Just my thought though.
>
> What I don't like is that a session can see only local stats of its own
> session. It's hard to monitor local stats. Imagine the case where you'd
> like to monitor local stats of each pgbench session. To monitor such
> stats, you need to modify pgbench so that its each session monitors
> its own local stats. Even if you run a monitoring software, it cannot
> collect those stats because they don't belong to the session that it uses.
Ok. I'm waiting more comments from others.
Dropping it is easy for me, but any other comments? Josh?
Regards,
>
> Regards,
>
--
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp