[question] How to verify if profiler is running? How to disable profiling if connection is lost? #10
Comments
|
It sounds like you want to run the profiler on a production database.
It's a bad idea... Replicate your performance problem in a dev/test
environment and profile there.
…--Denis
On Fri, May 20, 2022 at 5:08 PM markosutic ***@***.***> wrote:
Hello,
It is mentioned in the docs:
"*As with any database maintenance operations, this should only be done
in a connection loss safe environment as losing the connection in the
middle of the monitoring would leave those settings behind permanently.*"
In case profiling was running when connection was lost, can we verify
somehow that profiling is active on the database?
How can we disable profiling if connection is lost in the middle of the
monitoring?
Sorry for asking duplicate question if this is already mentioned
somewhere. I couldn't find this information.
Thank you for the info.
—
Reply to this email directly, view it on GitHub
<#10>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHWD4DM2IHLJHC46IQTVK75LXANCNFSM5WQSZGFA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Thank you @luss for the advice, I am aware that running profiler on the live production is not recommended and should be avoided. But still, is it possible to disable global profiling if connection is lost? Maybe running Or can I check somehow that profilling is enabled and that diagnostic info is being collected? Thanks |
|
Jan would have to answer your specific question. I can mostly only
pontificate. ;-)
…On Sat, May 21, 2022 at 4:05 AM markosutic ***@***.***> wrote:
Thank you @luss <https://github.com/luss> for the advice, I am aware that
running profiler on the live production is not recommended and should be
avoided.
But still, is it possible to disable global profiling if connection is
lost? Maybe running ALTER SYSTEM and pg_reload_conf() manually?
Or can I check somehow that profilling is enabled and that diagnostic info
is being collected?
Thanks
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHULWRGCKKCPIBBMPDLVLCKK3ANCNFSM5WQSZGFA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
On 5/21/22 11:02, Denis Lussier wrote:
Jan would have to answer your specific question. I can mostly only
pontificate. ;-)
plprofiler no longer uses settings in GUCs to control global collection.
Instead it is a shared memory flag that causes collection at transaction
end.
The flag is set and cleared with the function
pl_profiler_set_enabled_global(bool)
The flag is not automatically cleared if the connection that set it
disconnects. As Denis said, none of this is supposed to be used in
production. But you can disable collection by calling that function.
Best Regards, Jan
…
On Sat, May 21, 2022 at 4:05 AM markosutic ***@***.***> wrote:
> Thank you @luss <https://github.com/luss> for the advice, I am aware that
> running profiler on the live production is not recommended and should be
> avoided.
>
> But still, is it possible to disable global profiling if connection is
> lost? Maybe running ALTER SYSTEM and pg_reload_conf() manually?
>
> Or can I check somehow that profilling is enabled and that diagnostic
info
> is being collected?
>
> Thanks
>
> —
> Reply to this email directly, view it on GitHub
> <#10 (comment)>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AAMWOHULWRGCKKCPIBBMPDLVLCKK3ANCNFSM5WQSZGFA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#10 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACYRMUMO6KXJMFSSSA6MADVLD3IHANCNFSM5WQSZGFA>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Jan Wieck
|
|
@wieck thank you very much for the info. Best regards, |
|
@wieck, sorry, one more question. Is session-level local profiling safe enough to be used on the production system? |
|
On 5/23/22 05:26, markosutic wrote:
@wieck <https://github.com/wieck>, sorry, one more question.
Using /Global Profiling/ is risky and it should be avoided on the
production system due to noted reasons.
Is session-level local profiling safe enough to be used on the
production system?
The reason for discouraging usage of the profiler in production is that
this code is far less reviewed and tested against all the different
versions of PostgreSQL than PostgreSQL itself. Therefore the risk of
encountering a bug is higher. Every extension that implements functions
in C has that risk. Using the profiler global or local makes little
difference.
Best Regards, Jan
|
|
Thank you Jan for the info. |
|
Hey Jan, I added you back as a committer to bigsql/plprofiler. I will
drop the pgsql-io/plprofiler project.
…On Mon, May 23, 2022 at 4:20 PM markosutic ***@***.***> wrote:
Thank you Jan for the info.
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHVBJNHFHPBYWQM3NEDVLPSBJANCNFSM5WQSZGFA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Seems a lot of things are getting done. Let me know when a release is
tagged and i'll do some independent testing.
…On Thu, Jun 2, 2022 at 5:26 PM Jan Wieck ***@***.***> wrote:
Closed #10 <#10> as completed.
—
Reply to this email directly, view it on GitHub
<#10 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMWOHQJCXHRYPX3BLNJQS3VNERJXANCNFSM5WQSZGFA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
On 10/11/22 04:41, Denis Lussier wrote:
Seems a lot of things are getting done. Let me know when a release is
tagged and i'll do some independent testing.
The release 4.2 was tagged on October 4th. The corresponding PyPI client
module was uploaded that same day. I opened a case to add the packages
to the pgrpms repository (driving the PGDG build farm) on October 5th,
but have not heard back from Devrim yet. I will follow on that shortly.
https://github.com/bigsql/plprofiler/tags
https://pypi.org/project/plprofiler-client/#history
https://redmine.postgresql.org/issues/7725
…
On Thu, Jun 2, 2022 at 5:26 PM Jan Wieck ***@***.***> wrote:
> Closed #10 <#10> as completed.
>
> —
> Reply to this email directly, view it on GitHub
> <#10 (comment)>, or
> unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AAMWOHQJCXHRYPX3BLNJQS3VNERJXANCNFSM5WQSZGFA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#10 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACYRMWIJWIH65UTKVZLR4LWCUR5DANCNFSM5WQSZGFA>.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
It is mentioned in the docs:
"As with any database maintenance operations, this should only be done in a connection loss safe environment as losing the connection in the middle of the monitoring would leave those settings behind permanently."
In case profiling was running when connection was lost, can we verify somehow that profiling is active on the database?
How can we disable profiling if connection is lost in the middle of the monitoring?
Sorry for asking duplicate question if this is already mentioned somewhere. I couldn't find this information.
Thank you for the info.
The text was updated successfully, but these errors were encountered: