On Mon, Oct 29, 2018 at 1:52 AM, Phil Florent wrote:
Hi, thank you for comments.
>Yes you will be able to solve bottlenecks with sampling. In interactive mode, a 1s interval is probably too large. I use 0s1 - 0s01 with my tool and it is normally OK.
With the tool you are using, can you sample at intervals shorter than 1 second?
If you can, you can get enough sampling number and you can also acquire short events.
>Since grafana is now able to connect directly to a postgresql source, I use it to display the information collected from pg_stat_activity and psutil ( e.g https://pgphil.ovh/traqueur_dashboard_02.php page is written in french but panels are in english)
It is wonderful to visualize.
Especially for beginners like me.
>Other DB have accumulated statistics but you can notice that sampling is also their most modern method.
>E.g Oracle DB : 20 years ago you already had tools like "utlbstat/utlestat" . Then you had "statspack". Those tools were based on accumulated statistics and the reports were based on differences between 2 points. It was useful to solve major problems but it was limited and not precise enough in many cases.
>The preferred feature to identify bottlenecks in the Oracle world is now ASH (active session history). It can help with major problems, specific problems AND it can identify short blockages.
>Too bad it is licensed as an option of their Enterprise Edition but similar tools exist and they are also based on sampling of the activity.
>With the "official" ASH, sampling and archiving are done internally and you have a circular memory zone dedicated to the feature. Hence the overhead is lower but that's all.
>The most advanced interactive tool is called "snapper" and it is also based on sampling.
Thanks. I will check it.
The current bottleneck survey method, from sampling, I can know the number (ratio) of waiting events.
Then, investigate from those with a high number of times (ratio).
Do you agree with this recognition?
---------------------------------------
Naoki, Yotsunaga.
