Performance analysis and tuning v15

Suggest edits

EDB Postgres Advanced Server provides tools for analyzing performance and tuning.

Dynatune

EDB Postgres Advanced Server supports dynamic tuning of the database server to make the optimal use of the system resources available on the host machine where it's installed. The two parameters that control this functionality are located in the postgresql.conf file. These parameters are:

  • edb_dynatune
  • edb_dynatune_profile

edb_dynatune

edb_dynatune determines how much of the host system's resources for the database server to use. It bases the determination on the host machine's total available resources and the intended use of the host machine.

When EDB Postgres Advanced Server is first installed, you set the edb_dynatune parameter according to the host machine's use as a development machine, mixed-use machine, or dedicated server. For most purposes, the database administrator doesn't need to adjust the configuration parameters in the postgresql.conf file to improve performance.

You can change the value of the edb_dynatune parameter after the initial installation of EDB Postgres Advanced Server by editing the postgresql.conf file. You must restart the postmaster for the new configuration to take effect.

You can set the edb_dynatune parameter to any integer value from 0 to 100. A value of 0 turns off the dynamic tuning feature, leaving the database server resource use under the control of the other configuration parameters in the postgresql.conf file.

A low, non-zero value, that is, 1–33, dedicates the least amount of the host machine's resources to the database server. Use this setting for a development machine where many other applications are being used.

A value in the range of 34—66 dedicates a moderate amount of resources to the database server. You might use this setting for a dedicated application server that has a fixed number of other applications running on the same machine as EDB Postgres Advanced Server.

The highest values, that is, 67–100, dedicate most of the server's resources to the database server. Use this setting for a host machine that's totally dedicated to running EDB Postgres Advanced Server.

After you select a value for edb_dynatune, you can further fine-tune database server performance by adjusting the other configuration parameters in the postgresql.conf file. Any adjusted setting overrides the corresponding value chosen by edb_dynatune.

To change the value of a parameter:

  1. Uncomment the configuration parameter.
  2. Specify the desired value.
  3. Restart the database server.

edb_dynatune_profile

Use the edb_dynatune_profile parameter to control tuning aspects based on the expected workload profile on the database server. This parameter takes effect when you start the database server.

The table shows the possible values for edb_dynatune_profile.

ValueUsage
oltpRecommended when the database server is processing heavy online transaction processing workloads.
reportingRecommended for database servers used for heavy data reporting.
mixedRecommended for servers that provide a mix of transaction processing and data reporting.

EDB wait states

The EDB wait states contrib module contains two main components.

EDB Wait States Background Worker (EWSBW)

When the wait states background worker is registered as one of the shared preload libraries, EWSBW probes each of the running sessions at regular intervals.

For every session, it collects information such as:

  • The database to which it's connected
  • The logged-in user of the session
  • The query running in that session
  • The wait events on which it's waiting

This information is saved in a set of files in a user-configurable path and directory folder given by the edb_wait_states.directory parameter to add to the postgresql.conf file. The path must be a full, absolute path, not a relative path.

To install EWSBW on a Linux system:

  1. Install EDB wait states with the edb-asxx-server-edb_wait_states RPM package, where xx is the EDB Postgres Advanced Server version number.

  2. To launch the worker, register it in the postgresql.conf file using the shared_preload_libraries parameter. For example:

    shared_preload_libraries = '$libdir/edb_wait_states'

  3. Restart the database server. After a successful restart, the background worker begins collecting data.

  4. To review the data, create the following extension:

    CREATE EXTENSION edb_wait_states;

  5. To terminate the EDB wait states worker, remove $libdir/edb_wait_states from the shared_preload_libraries parameter, and restart the database server.

To install EWSBW on a Windows system:

  1. To install the EDB wait states module with the EDB Modules installer, invoke the StackBuilder Plus utility. Follow the onscreen instructions to finish installing the EDB Modules.

  2. To register the worker, modify the postgresql.conf file to include the wait states library in the shared_preload_libraries configuration parameter. The parameter value must include:

    shared_preload_libraries = '$libdir/edb_wait_states.dll'

    The EDB wait states installation places the edb_wait_states.dll library file in the following path:

    C:\Program Files\edb\as14\lib\

  3. Restart the database server to make the changes take effect. After a successful restart, the background worker starts and begins collecting the data.

  4. To view the data, create the following extension:

    CREATE EXTENSION edb_wait_states;

The installer places the edb_wait_states.control file in the following path:

C:\Program Files\edb\as14\share\extension

Terminating the wait states worker

To terminate the EDB wait states worker:

  1. Use the DROP EXTENSION command to drop the edb_wait_states extension.
  2. Modify the postgresql.conf file, removing $libdir/edb_wait_states.dll from the shared_preload_libraries parameter.
  3. To apply your changes, restart the database server.

The wait states interface

Each of the functions in the interface has common input and output parameters. Those parameters are:

  • start_ts and end_ts (IN). Together these specify the time interval and the data to read. If you specify only start_ts, the data starting from start_ts is output. If you specify only end_ts, data up to end_ts is output. If you don't specify either, all the data is output.
  • query_id (OUT). Identifies a normalized query. It's internal hash code computed from the query.
  • session_id (OUT). Identifies a session.
  • ref_start_ts and ref_end_ts (OUT). Provides the timestamps of a file containing a particular data point. A data point might be a wait event sample record, a query record, or a session record.

The examples that follow are based on the following three queries. They are executed simultaneously on four different sessions connected to different databases using different users:

SELECT schemaname FROM pg_tables, pg_sleep(15) WHERE schemaname <>
'pg_catalog'; /* ran on 2 sessions */
SELECT tablename FROM pg_tables, pg_sleep(10) WHERE schemaname <>
'pg_catalog';
SELECT tablename, schemaname FROM pg_tables, pg_sleep(10) WHERE schemaname
<> 'pg_catalog';

edb_wait_states_data

Use this function to read the data collected by EWSBW:

edb_wait_states_data(
  IN start_ts timestamptz default '-infinity'::timestamptz,
  IN end_ts timestamptz default 'infinity'::timestamptz,
  OUT session_id int4,
  OUT <dbname> text,
  OUT <username> text,
  OUT <query> text,
  OUT <query_start_time> timestamptz,
  OUT <sample_time> timestamptz,
  OUT <wait_event_type> text,
  OUT <wait_event> text
)

You can use this function to find out the following:

  • The queries running in the given duration (defined by start_ts and end_ts) in all the sessions, and the wait events, if any, they were waiting on. For example:

    SELECT query, session_id, wait_event_type, wait_event
  FROM edb_wait_states_data(start_ts, end_ts);

  • The progress of a session within a given duration, that is, the queries run in a session (session_id = 100000) and the wait events the queries waited on. For example:

    SELECT query, wait_event_type, wait_event
  FROM edb_wait_states_data(start_ts, end_ts)
  WHERE session_id = 100000;

  • The duration for which the samples are available. For example:

    SELECT min(sample_time), max(sample_time)
  FROM edb_wait_states_data();

Parameters

In addition to the common parameters described previously, each row of the output gives the following:

dbname

The session's database.

username

The session's logged-in user.

query

The query running in the session.

query_start_time

The time when the query started.

sample_time

The time when wait event data was collected.

wait_event_type

The type of wait event the session (backend) is waiting on.

wait_event

The wait event the session (backend) is waiting on.

Example

The following is a sample output from the edb_wait_states_data() function:

edb=# SELECT * FROM edb_wait_states_data();
Output
-[ RECORD 1 ]----+-------------------------------------------------------------------------
session_id       | 4398
dbname           | edb
username         | enterprisedb
query            | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time      | 17-AUG-18 11:56:19.700236 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
-[ RECORD 2 ]----+-------------------------------------------------------------------------
session_id       | 4398
dbname           | edb
username         | enterprisedb
query            | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time      | 17-AUG-18 11:56:18.699938 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
-[ RECORD 3 ]----+-------------------------------------------------------------------------
session_id       | 4398
dbname           | edb
username         | enterprisedb
query            | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time      | 17-AUG-18 11:56:17.700253 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
                    .
                    .
                    .

edb_wait_states_queries

This function gives information about the queries sampled by EWSBW.

edb_wait_states_queries(
  IN start_ts timestamptz default '-infinity'::timestamptz,
  IN end_ts timestamptz default 'infinity'::timestamptz,
  OUT query_id int8,
  OUT <query> text,
  OUT ref_start_ts timestamptz
  OUT ref_end_ts timestamptz
)

A new queries file is created periodically. Multiple query files can be generated corresponding to specific intervals.

This function returns all the queries in query files that overlap with the given time interval. A query gives all the queries in query files that contained queries sampled between start_ts and end_ts:

SELECT query FROM edb_wait_states_queries(start_ts, end_ts);

In other words, the function can output queries that didn't run in the given interval. To do that, use edb_wait_states_data().

Parameters

In addition to the common parameters described previously, each row of the output gives the following:

query

Normalized query text.

Example

The following is a sample output from the edb_wait_states_queries() function:

edb=# SELECT * FROM edb_wait_states_queries();
Output
-[ RECORD 1 ]+-----------------------------------------------------------------------------
query_id     | 4292540138852956818
query        | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 2 ]+-----------------------------------------------------------------------------
query_id     | 3754591102365859187
query        | SELECT tablename FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 3 ]+-----------------------------------------------------------------------------
query_id     | 349089096300352897
query        | SELECT tablename, schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00

edb_wait_states_sessions

This function gives information about the sessions sampled by EWSBW:

edb_wait_states_sessions(
  IN start_ts timestamptz default '-infinity'::timestamptz,
  IN end_ts timestamptz default 'infinity'::timestamptz,
  OUT session_id int4,
  OUT <dbname> text,
  OUT <username> text,
  OUT ref_start_ts timestamptz
  OUT ref_end_ts timestamptz
)

You can use this function to identify the databases that were connected and the users that started those sessions. For example:

SELECT dbname, username, session_id
  FROM edb_wait_states_sessions();

Similar to edb_wait_states_queries(), this function outputs all the sessions logged in session files that contain sessions sampled in the given interval. It doesn't necessarily output only the sessions sampled in the given interval. To identify that, use edb_wait_states_data().

Parameters

In addition to the common parameters described previously, each row of the output gives the following:

dbname

The database to which the session is connected.

username

Login user of the session.

Example

The following is a sample output from the edb_wait_states_sessions() function:

edb=# SELECT * FROM edb_wait_states_sessions();
Output
-[ RECORD 1 ]+---------------------------------
session_id   | 4340
dbname       | edb
username     | enterprisedb
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 2 ]+---------------------------------
session_id   | 4398
dbname       | edb
username     | enterprisedb
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 3 ]+---------------------------------
session_id   | 4410
dbname       | db1
username     | user1
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 4 ]+---------------------------------
session_id   | 4422
dbname       | db2
username     | user2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts   | 18-AUG-18 11:52:38.698793 -04:00

edb_wait_states_samples

This function gives information about wait events sampled by EWSBW:

edb_wait_states_samples(
  IN start_ts timestamptz default '-infinity'::timestamptz,
  IN end_ts timestamptz default 'infinity'::timestamptz,
  OUT query_id int8,
  OUT session_id int4,
  OUT <query_start_time> timestamptz,
  OUT <sample_time> timestamptz,
  OUT <wait_event_type> text,
  OUT <wait_event> text
)

Usually, you don't need to call this function directly.

Parameters

In addition to the common parameters described previously, each row of the output gives the following:

query_start_time

The time when the query started in this session.

sample_time

The time when wait event data was collected.

wait_event_type

The type of wait event on which the session is waiting.

wait_event

The wait event on which the session (backend) is waiting.

Example

The following is a sample output from the edb_wait_states_samples() function:

edb=# SELECT * FROM edb_wait_states_samples();
Output
-[ RECORD 1 ]----+---------------------------------
query_id         | 4292540138852956818
session_id       | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time      | 17-AUG-18 11:56:00.699934 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
-[ RECORD 2 ]----+---------------------------------
query_id         | 4292540138852956818
session_id       | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time      | 17-AUG-18 11:56:01.699003 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
-[ RECORD 3 ]----+---------------------------------
query_id         | 4292540138852956818
session_id       | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time      | 17-AUG-18 11:56:02.70001 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
-[ RECORD 4 ]----+---------------------------------
query_id         | 4292540138852956818
session_id       | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time      | 17-AUG-18 11:56:03.700081 -04:00
wait_event_type  | Timeout
wait_event       | PgSleep
                    .
                    .
                    .

edb_wait_states_purge

The function deletes all the sampled data files (queries, sessions, and wait-event samples) that were created after start_ts and aged (rotated) before end_ts:

edb_wait_states_purge(
  IN start_ts timestamptz default '-infinity'::timestamptz,
  IN end_ts timestamptz default 'infinity'::timestamptz
)

Usually you don't need to run this function. The backend usually purges those according to the retention age. However, if that doesn't happen for some reason, you can use this function.

To find out how long the samples were retained, use edb_wait_states_data().

Example

This code shows the $PGDATA/edb_wait_states directory before running edb_wait_states_purge():

[root@localhost data]# pwd
/var/lib/edb/as14/data
[root@localhost data]# ls -l edb_wait_states
total 12
-rw------- 1 enterprisedb ...  253 Aug 17 11:56 edb_ws_queries_587836358698793_587922758698793
-rw------- 1 enterprisedb ... 1600 Aug 17 11:56 edb_ws_samples_587836358698793_587839958698793
-rw------- 1 enterprisedb ...   94 Aug 17 11:56 edb_ws_sessions_587836358698793_587922758698793

This code shows the $PGDATA/edb_wait_states directory after running edb_wait_states_purge():

edb=# SELECT * FROM edb_wait_states_purge();
Output
edb_wait_states_purge
-----------------------

(1 row)
[root@localhost data]# pwd
/var/lib/edb/as14/data
[root@localhost data]# ls -l edb_wait_states
total 0
← Prev

Debugger

Next →

EDB clone schema