Re: Common slow query reasons - help with a special log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10.12.2011 23:40, Daniel Cristian Cruz wrote:
> At work we have a 24 cores server, with a load average around 2.5.

A single query is processes by a single CPU, so even if the system is
not busy a single query may hit CPU bottleneck. The real issue is the
instrumentation overhead - timing etc. On some systems (with slow
gettimeofday) this may be a significant problem as the query hits the
CPU boundary sooner.

> I don't know yet if a system which use some unused CPU to minimize the
> load of a bad query identified early is bad or worse.

Not really, due to the "single query / single CPU" rule.

> Indeed, I don't know if my boss would let me test this at production
> too, but it could be good to know how things work in "auto-pilot" mode.

What I was pointing out is that you probably should not enable loggin
"explain analyze" output by "auto_explain.log_analyze = true". There are
three levels of detail:

1) basic, just log_min_duration_statement

2) auto_explain, without 'analyze' - just explain plain

3) auto_explain, with 'analyze' - explain plan with actual values

Levels (1) and (2) are quite safe (unless the minimum execution time is
too low).

Tomas

> 
> 2011/12/10 Tomas Vondra <tv@xxxxxxxx <mailto:tv@xxxxxxxx>>
> 
>     There's auto_explain contrib module that does exactly what you're asking
>     for. Anyway, explain analyze is quite expensive - think twice before
>     enabling that on production server where you already have performance
>     issues.
> 
>     Tomas
> 
>     On 10.12.2011 17:52, Daniel Cristian Cruz wrote:
>     > Hi all,
>     >
>     > I'm trying to figure out some common slow queries running on the
>     server,
>     > by analyzing the slow queries log.
>     >
>     > I found debug_print_parse, debug_print_rewritten, debug_print_plan,
>     > which are too much verbose and logs all queries.
>     >
>     > I was thinking in something like a simple explain analyze just for
>     > queries logged with log_min_duration_statement with the query too.
>     >
>     > Is there a way to configure PostgreSQL to get this kind of
>     information,
>     > maybe I'm missing something? Is it too hard to hack into sources
>     and do
>     > it by hand? I never touched PostgreSQL sources.
>     >
>     > I'm thinking to write a paper that needs this information for my
>     > postgraduate course. The focus of my work will be the log data, not
>     > PostgreSQL itself. If I succeed, maybe it can be a tool to help
>     all of us.
>     >
>     > Thank you,
>     > --
>     > Daniel Cristian Cruz
>     > クルズ クリスチアン ダニエル
> 
> 
>     --
>     Sent via pgsql-performance mailing list
>     (pgsql-performance@xxxxxxxxxxxxxx
>     <mailto:pgsql-performance@xxxxxxxxxxxxxx>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-performance
> 
> 
> 
> 
> -- 
> Daniel Cristian Cruz
> クルズ クリスチアン ダニエル


-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux