Re: General DB Tuning

Поиск
Список
Период
Сортировка
От Tom Arthurs
Тема Re: General DB Tuning
Дата
Msg-id 42D4621D.4060803@jobflash.com
обсуждение исходный текст
Ответ на Re: General DB Tuning  (Brent Henry <bh_pgperf@yahoo.com>)
Ответы Re: General DB Tuning
Список pgsql-performance
we are using jdbc -- the "log_min_duration_statement = 3000 " statement
works fine for me.  Looks like there's no other work around for the
bug(?).  Not sure since I have no interest in logging a million
statements a day, I only want to see the poorly performing hits.

Brent Henry wrote:
> Yes, that is exactly what I want to use!
>
> Unfortunately, it doesn't work if you access postgres
> through a JDBC connection.  I don't know why.  I found
> a posting from back in February which talks aobut this
> a little:
>
> http://archives.postgresql.org/pgsql-admin/2005-02/msg00055.php
>
> But I can't find anywhere where someone has fixed it.
> Am I the only one accessing postgres through JDBC?
>
> -Brent
>
>
> --- Tom Arthurs <tarthurs@jobflash.com> wrote:
>
>
>>I have this in my postgresql.conf file and it works
>>fine (set the min to
>>whatever you want to log)
>>log_min_duration_statement = 3000 # -1 is disabled,
>>in milliseconds.
>>
>>Another setting that might get what you want:
>>
>>#log_duration = false
>>
>>uncomment and change to true.
>>
>> From the docs:
>>
>
> (http://www.postgresql.org/docs/8.0/interactive/runtime-config.html)
>
>>  Causes the duration of every completed statement
>>which satisfies
>>log_statement to be logged. When using this option,
>>if you are not using
>>syslog, it is recommended that you log the PID or
>>session ID using
>>log_line_prefix so that you can link the statement
>>to the duration using
>>the process ID or session ID. The default is off.
>>Only superusers can
>>change this setting.
>>
>>Brent Henry wrote:
>>
>>>Help!  After recently migrating to Postgres 8,
>>
>>I've
>>
>>>discovered to my horror that I can't determine
>>
>>which
>>
>>>queries are poorly performing anymore because the
>>>logging has drastically changed and no longer
>>
>>shows
>>
>>>durations for anything done through JDBC.
>>>
>>>So I'm desperately trying to do performance tuning
>>
>>on
>>
>>>my servers and have no way to sort out which
>>>statements are the slowest.
>>>
>>>Does anyone have any suggestions?  How do you
>>>determine what queries are behaving badly when you
>>>can't get durations out of the logs?
>>>
>>>I have a perl script that analyzes the output from
>>>Postgres 7 logs and it works great!  But it relies
>>
>>on
>>
>>>the duration being there.
>>>
>>>I did some searches on postgresql.org mailing
>>
>>lists
>>
>>>and have seen a few people discussing this
>>
>>problem,
>>
>>>but noone seems to be too worried about it.  Is
>>
>>there
>>
>>>a simple work-around?
>>>
>>>Sincerely,
>>>
>>>Brent
>>>
>>>
>>>
>>>
>>
>>____________________________________________________
>>
>>>Sell on Yahoo! Auctions – no fees. Bid on great
>>
>>items.
>>
>>>http://auctions.yahoo.com/
>>>
>>>---------------------------(end of
>>
>>broadcast)---------------------------
>>
>>>TIP 5: don't forget to increase your free space
>>
>>map settings
>>
>>>
>>>
>>---------------------------(end of
>>broadcast)---------------------------
>>TIP 2: Don't 'kill -9' the postmaster
>>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>
>

В списке pgsql-performance по дате отправления:

Предыдущее
От: Brent Henry
Дата:
Сообщение: Re: General DB Tuning
Следующее
От: Dennis
Дата:
Сообщение: Re: General DB Tuning