Insights for Customers

The EDB Customer Portal now provides a new feature called Insights, which is included as part of the Production Support service.

This article offers a brief summary of Insights, how to use it, and its benefits.

Insights is a tool developed by EDB for assisting in the analysis of a PostgreSQL cluster instance. It is extensively used by Support Engineers, allowing quick analysis of all configuration parameters in an incident event. As this task is automated, Support Engineers can focus specifically on particular issues detected by Insights, reducing the time spent at this part of the analysis.

Insights has been released as a self managed tool for customers, to enable self-detection of problematic configuration parameters and proactively assist with incidents prevention. Additionally it enables a Health Check Status for Supported instance to be retrieved at any time. EDB's extensive knowledge of PostgreSQL combined with our development practices mean that Insights is constantly evolving, with new tests being added to the feature.

In the next sections you will find all you need to know to be able to use Insights.

Insights relies on the information gathered by our Lasso tool for the analysis of each instance, so you just need to run Lasso on the instance you would like to be analyzed. For more information about this step, you can follow this Knowledge base article: "Running Lasso to send diagnostic information"

Any Lasso tarballs you attach to a ticket will be automatically loaded into our systems, or you can use the --upload parameter in the command line execution of Lasso to upload it directly.

A few minutes after the Lasso has been successfully uploaded and processed, you will see the recommendations and useful findings for the instance.

NOTE: currently only the latest upload is available to view in Insights. Making older reports available is in the development plan.

There is a Insights button on the left panel of the customer portal. From there you will see a list of all the server instances for which you have previously run and uploaded a Lasso report.

From the list of Instances, you can evaluate configuration parameters from both PostgreSQL and the operating system by clicking on the Instance name. In the Failed Test and Tests Detail columns you will see the number of failing tests and a full explanation for each of them.

Clicking on Show in the Tests Details column for the Instance that you are interested in reveals recommendations on what could be done to improve the current situation on your server for tests that are generating warnings. All the findings have been graded by Severity level and will give suggestions about every specific test concluded on that instance.

Some Tests examples that Insights will carry out for you:

• Up-to-date PostgreSQL minor release (minor_upgrade): Verifies that the installed version of PostgreSQL is the latest maintenance update for that major version. Minor updates contain bug fixes as well as security fixes to known Common Vulnerabilities and Exposures (CVE).

• Autovacuum enabled (check_autovacuum): Checks that the autovacuum daemon is enabled.

• Danger of xid wraparound: Checks for danger of xid wraparound

• Transparent Huge Pages (THP): These are enabled by default in most recent Linux installations, but for PostgreSQL workloads, we suggest to disable THP. This test checks and makes recommendations.

• Number of connected PostgreSQL clients(check_backends): Check the number of PostgreSQL backends connected to the server at the time of collection. If it is higher than 95% of max_connections - superuser_reserved_connections, a critical issue is raised, whereas a warning is raised if higher than 75%.

• Sensible number of maximum client connections (max_connections): Check the max_connections settings, responsible for defining the maximum number of concurrent client connections allowed to the PostgreSQL instance.

• Sensible shared buffers amount (shared_buffers): Check that shared buffers of the PostgreSQL server are properly sized through the shared_buffers setting, based on general purpose heuristics that consider the available RAM size.

Failure example: On a 32GB RAM system: shared_buffers = 128MB.

Success example: On a 32GB RAM system (25% of the RAM) shared_buffers = 8GB

This is a very brief example of tests that Insight is performing among others and many more to come. So stay tuned and have a real Insight of your cluster!