Skip to content

Commit b1ef6ee

Browse files
authored
Merge pull request #241808 from ShawnJackson/three-flexible-server-articles
[AQ] edit pass: Three Flexible Server articles (intelligent tuning)
2 parents 84309d6 + 8260338 commit b1ef6ee

File tree

3 files changed

+135
-144
lines changed

3 files changed

+135
-144
lines changed

articles/postgresql/flexible-server/concepts-intelligent-tuning.md

Lines changed: 69 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -13,125 +13,117 @@ ms.date: 06/02/2023
1313

1414
[!INCLUDE [applies-to-postgresql-flexible-server](../includes/applies-to-postgresql-flexible-server.md)]
1515

16-
The intelligent tuning feature of Azure Database for PostgreSQL - Flexible Server is designed to enhance overall
17-
performance automatically and help prevent possible issues. It continuously monitors the database instance's overall
18-
status and performance and automatically optimizes the workload's performance.
19-
20-
The Azure Database for PostgreSQL - Flexible Server is equipped with an inherent intelligence mechanism that can
21-
dynamically adapt the database to your workload, thereby automatically enhancing performance. This feature comprises two
22-
automatic tuning functionalities:
23-
24-
* **Autovacuum tuning**: This function diligently tracks the bloat ratio and adjusts autovacuum settings accordingly. It
25-
factors in both current and predicted resource usage to ensure your workload isn't disrupted.
26-
* **Writes tuning**: This feature persistently monitors the volume and patterns of write operations, modifying
27-
parameters that affect write performance. These parameters
28-
include `bgwriter_delay`, `checkpoint_completion_target`, `max_wal_size`, and `min_wal_size`. The primary aim of these
29-
adjustments is to enhance both system performance and reliability, thereby proactively averting potential
16+
Azure Database for PostgreSQL - Flexible Server has an intelligent tuning feature that's designed to enhance
17+
performance automatically and help prevent problems. Intelligent tuning continuously monitors the PostgreSQL database's
18+
status and dynamically adapts the database to your workload.
19+
20+
This feature comprises two
21+
automatic tuning functions:
22+
23+
* **Autovacuum tuning**: This function tracks the bloat ratio and adjusts autovacuum settings accordingly. It
24+
factors in both current and predicted resource usage to prevent workload disruptions.
25+
* **Writes tuning**: This function monitors the volume and patterns of write operations, and it modifies
26+
parameters that affect write performance. These adjustments enhance both system performance and reliability, to proactively avert potential
3027
complications.
3128

32-
Learn how to enable intelligent tuning using [Azure portal](how-to-enable-intelligent-performance-portal.md) or [CLI](how-to-enable-intelligent-performance-cli.md).
29+
You can enable intelligent tuning by using the [Azure portal](how-to-enable-intelligent-performance-portal.md) or the [Azure CLI](how-to-enable-intelligent-performance-cli.md).
3330

3431
## Why intelligent tuning?
3532

3633
The autovacuum process is a critical part of maintaining the health and performance of a PostgreSQL database. It helps
37-
to reclaim storage occupied by "dead" rows, freeing up space and ensuring the database continues to run smoothly.
38-
Equally important is the tuning of write operations within the database, a task that typically falls to database
39-
administrators (DBAs).
34+
reclaim storage occupied by "dead" rows, freeing up space and keeping the database running smoothly.
4035

41-
However, constantly monitoring a database and fine-tuning write operations can be challenging and time-consuming. This
42-
becomes increasingly complex when dealing with multiple databases, and might even become an impossible task when
43-
managing a large number of them.
36+
Equally important is the tuning of write operations within the database. This task typically falls to database
37+
administrators. Constantly monitoring a database and fine-tuning write operations can be challenging and time-consuming. This
38+
task becomes increasingly complex when you're dealing with multiple databases.
4439

45-
This is where intelligent tuning steps in. Rather than manually overseeing and tuning your database, the intelligent
46-
tuning feature can effectively shoulder some of the load. It helps in the automatic monitoring and tuning of the
47-
database, allowing you to focus on other important tasks.
40+
This is where intelligent tuning steps in. Rather than manually overseeing and tuning your database, you can use intelligent
41+
tuning to automatically monitor and tune the
42+
database. You can then focus on other important tasks.
4843

49-
Intelligent tuning provides an autovacuum tuning feature that vigilantly monitors the bloat ratio, adjusting settings as needed to ensure optimal resource utilization. It proactively manages the "cleaning" process of the database, mitigating performance issues caused by outdated data.
44+
The autovacuum tuning function in intelligent tuning monitors the bloat ratio and adjusts settings as needed for optimal resource utilization. It proactively manages the "cleaning" process of the database and mitigates performance problems that outdated data can cause.
5045

51-
In addition, the Writes Tuning aspect of intelligent tuning observes the quantity and transactional patterns of write operations. It intelligently adjusts parameters such as `bgwriter_delay`, `checkpoint_completion_target`, `max_wal_size`, and `min_wal_size`. By doing so, it effectively enhances system performance and reliability, ensuring smooth and efficient operation even under high write loads.
46+
The writes tuning function observes the quantity and transactional patterns of write operations. It intelligently adjusts parameters such as `bgwriter_delay`, `checkpoint_completion_target`, `max_wal_size`, and `min_wal_size`. By doing so, it enhances system performance and reliability, even under high write loads.
5247

53-
In summary, intelligent tuning provides an efficient solution for database monitoring and tuning, taking the hard and
54-
tedious tasks off your plate. By using this automatic tuning feature, you can rely on the Azure Database for
55-
PostgreSQL - Flexible Server to maintain the optimal performance of your databases, saving you valuable time and
56-
resources.
48+
When you use intelligent tuning, you can save valuable time and resources by relying on Azure Database for
49+
PostgreSQL - Flexible Server to maintain the optimal performance of your databases.
5750

58-
### How does intelligent tuning work?
51+
## How does intelligent tuning work?
5952

60-
Intelligent Tuning is an ongoing monitoring and analysis process that not only learns about the characteristics of your
61-
workload but also tracks your current load and resource usage such as CPU or IOPS. By doing so, it makes sure not to
53+
Intelligent tuning is an ongoing monitoring and analysis process that not only learns about the characteristics of your
54+
workload but also tracks your current load and resource usage, such as CPU or IOPS. It doesn't
6255
disturb the normal operations of your application workload.
6356

6457
The process allows the database to dynamically adjust to your workload by discerning the current bloat ratio, write
65-
performance, and checkpoint efficiency on your instance. Armed with these insights, intelligent tuning deploys tuning
66-
actions designed to not only enhance your workload's performance but also to circumvent potential pitfalls.
58+
performance, and checkpoint efficiency on your instance. With these insights, intelligent tuning deploys tuning
59+
actions that enhance your workload's performance and avoid potential pitfalls.
6760

68-
## Autovacuum tuning
61+
### Autovacuum tuning
6962

70-
Intelligent tuning adjusts five significant parameters related to
63+
Intelligent tuning adjusts five parameters related to
7164
autovacuum: `autovacuum_vacuum_scale_factor`, `autovacuum_cost_limit`, `autovacuum_naptime`, `autovacuum_vacuum_threshold`,
72-
and `autovacuum_vacuum_cost_delay`. These parameters regulate components such as the fraction of the table that sets off
73-
a VACUUM process, the cost-based vacuum delay limit, the pause interval between autovacuum runs, the minimum count of
74-
updated or dead tuples needed to start a VACUUM, and the pause duration between cleanup rounds.
65+
and `autovacuum_vacuum_cost_delay`. These parameters regulate components such as:
7566

76-
> [!IMPORTANT]
77-
> Autovacuum tuning is currently supported for the General Purpose and Memory Optimized server compute tiers that have
78-
> four or more vCores, Burstable server compute tier is not supported.
67+
- The fraction of the table that sets off
68+
a `VACUUM` process.
69+
- The cost-based vacuum delay limit.
70+
- The pause interval between autovacuum runs.
71+
- The minimum count of
72+
updated or dead tuples needed to start a `VACUUM` process.
73+
- The pause duration between cleanup rounds.
7974

8075
> [!IMPORTANT]
81-
> It's important to keep in mind that intelligent tuning modifies autovacuum-related parameters at the server level, not
82-
> at individual table levels. Also, if autovacuum is turned off, intelligent tuning cannot operate correctly. For
83-
> intelligent tuning to optimize the process, the autovacuum feature must be enabled.
76+
> Intelligent tuning modifies autovacuum-related parameters at the server level, not at individual table levels. Also, if autovacuum is turned off, intelligent tuning can't operate correctly. For intelligent tuning to optimize the process, the autovacuum feature must be enabled.
8477
85-
While the autovacuum daemon triggers two operations - VACUUM and ANALYZE, intelligent tuning only fine-tunes the VACUUM
86-
process. The ANALYZE process, which gathers statistics on table contents to help the PostgreSQL query planner choose the
87-
most suitable query execution plan, is currently not adjusted by this feature.
78+
Although the autovacuum daemon triggers two operations (`VACUUM` and `ANALYZE`), intelligent tuning fine-tunes only the `VACUUM`
79+
process. This feature currently doesn't adjust the `ANALYZE` process, which gathers statistics on table contents to help the PostgreSQL query planner choose the
80+
most suitable query execution plan.
8881

89-
One key feature of intelligent tuning is that it includes safeguards to measure resource utilization like CPU and IOPS.
90-
This means that it will not ramp up autovacuum activity when your instance is under heavy load. This way, intelligent
82+
Intelligent tuning includes safeguards to measure resource utilization like CPU and IOPS.
83+
It won't increase autovacuum activity when your instance is under heavy load. This way, intelligent
9184
tuning ensures a balance between effective cleanup operations and the overall performance of your system.
9285

93-
When optimizing autovacuum, intelligent tuning considers the server's average bloat, using statistics about live and
94-
dead tuples. To lessen bloat, intelligent tuning might reduce parameters like the scale factor or naptime, triggering
95-
the VACUUM process sooner and, if necessary, decreasing the delay between rounds.
86+
When intelligent tuning is optimizing autovacuum, it considers the server's average bloat by using statistics about live and
87+
dead tuples. To lessen bloat, intelligent tuning might reduce parameters like the scale factor or naptime. It might trigger
88+
the `VACUUM` process sooner and, if necessary, decrease the delay between rounds.
9689

97-
On the other hand, if the bloat is minimal and the autovacuum process is too aggressive, then parameters such as delay,
98-
scale factor, and naptime may be increased. This balance ensures minimal bloat and the efficient use of the resources by
99-
the autovacuum process.
90+
On the other hand, if the bloat is minimal and the autovacuum process is too aggressive, intelligent tuning might increase parameters such as delay,
91+
scale factor, and naptime. This balance minimizes bloat and helps ensure that the autovacuum process is using resources efficiently.
10092

101-
102-
## Writes tuning
93+
### Writes tuning
10394

10495
Intelligent tuning adjusts four parameters related to writes
105-
tuning:`bgwriter_delay`, `checkpoint_completion_target`, `max_wal_size`, and `min_wal_size`. The behavior and benefits of adjusting some of these are described below.
96+
tuning: `bgwriter_delay`, `checkpoint_completion_target`, `max_wal_size`, and `min_wal_size`.
97+
98+
The `bgwriter_delay` parameter determines the frequency at which the background writer process is awakened to clean "dirty" buffers (buffers that are new or modified). The background writer process is one of three processes in PostgreSQL
99+
that handle write operations. The other are the checkpointer process and back-end writes (standard client processes, such
100+
as application connections).
106101

107-
The `bgwriter_delay` parameter determines the frequency at which the background writer process is awakened to clean "dirty" buffers (those buffers that are new or modified). The background writer process is one of three processes in PostgreSQL
108-
that handle write operations, the other two being the checkpointer process and backends (standard client processes, such
109-
as application connections). The background writer process's primary role is to alleviate the load from the main
110-
checkpointer process and decrease the strain of backend writes. By adjusting the `bgwriter_delay` parameter, which governs the frequency of background writer rounds, we can also optimize the performance of DML queries.
102+
The background writer process's primary role is to alleviate the load from the main
103+
checkpointer process and decrease the strain of back-end writes. The `bgwriter_delay` parameter governs the frequency of background writer rounds. By adjusting this parameter, you can also optimize the performance of Data Manipulation Language (DML) queries.
111104

112-
The `checkpoint_completion_target` parameter is part of the second write mechanism supported by PostgreSQL, specifically
113-
the checkpointer process. Checkpoints occur at constant intervals defined by `checkpoint_timeout` (unless forced by
105+
The `checkpoint_completion_target` parameter is part of the second write mechanism that PostgreSQL supports, specifically
106+
the checkpointer process. Checkpoints occur at constant intervals that `checkpoint_timeout` defines (unless forced by
114107
exceeding the configured space). To avoid overloading the I/O system with a surge of page writes, writing dirty buffers
115-
during a checkpoint is spread out over a period of time. This duration is controlled by
116-
the `checkpoint_completion_target`, specified as a fraction of the checkpoint interval, which is set
117-
using `checkpoint_timeout`.
118-
While the default value of `checkpoint_completion_target` is 0.9 (since PostgreSQL 14), which generally works best as it
119-
spreads the I/O load over the maximum time period, there might be rare instances where, due to unexpected fluctuations
120-
in the number of WAL segments needed, checkpoints may not complete in time. Hence, due to its potential impact on
121-
performance, `checkpoint_completion_target` has been chosen as a target metric for intelligent tuning.
108+
during a checkpoint is spread out over a period of time. The `checkpoint_completion_target` parameter controls this duration by using `checkpoint_timeout` to specify the duration as a fraction of the checkpoint interval.
122109

110+
The default value of `checkpoint_completion_target` is 0.9 (since PostgreSQL 14). This value generally works best, because it
111+
spreads the I/O load over the maximum time period. In rare instances, checkpoints might not finish in time because of unexpected fluctuations
112+
in the number of needed Write-Ahead Logging (WAL) segments. Potential impact on
113+
performance is the reason why `checkpoint_completion_target` is a target metric for intelligent tuning.
123114

124115
## Limitations and known issues
125116

126117
* Intelligent tuning makes optimizations only in specific ranges. It's possible that the feature won't make any changes.
127-
* ANALYZE settings are not adjusted by intelligent tuning.
118+
* Intelligent tuning doesn't adjust `ANALYZE` settings.
119+
* Autovacuum tuning is currently supported for the General Purpose and Memory Optimized server compute tiers that have four or more vCores. The Burstable server compute tier is not supported.
128120

129121
## Next steps
130122

131-
* [Configure intelligent performance for Azure Database for PostgreSQL - Flexible Server using Azure portal](how-to-enable-intelligent-performance-portal.md)
132-
* [Configure intelligent performance for Azure Database for PostgreSQL - Flexible Server using Azure CLI](how-to-enable-intelligent-performance-cli.md)
123+
* [Configure intelligent tuning for Azure Database for PostgreSQL - Flexible Server by using the Azure portal](how-to-enable-intelligent-performance-portal.md)
124+
* [Configure intelligent tuning for Azure Database for PostgreSQL - Flexible Server by using the Azure CLI](how-to-enable-intelligent-performance-cli.md)
133125
* [Troubleshooting guides for Azure Database for PostgreSQL - Flexible Server](concepts-troubleshooting-guides.md)
134-
* [Autovacuum Tuning in Azure Database for PostgreSQL - Flexible Server](how-to-autovacuum-tuning.md)
126+
* [Autovacuum tuning in Azure Database for PostgreSQL - Flexible Server](how-to-autovacuum-tuning.md)
135127
* [Troubleshoot high IOPS utilization for Azure Database for PostgreSQL - Flexible Server](how-to-high-io-utilization.md)
136128
* [Best practices for uploading data in bulk in Azure Database for PostgreSQL - Flexible Server](how-to-bulk-load-data.md)
137129
* [Troubleshoot high CPU utilization in Azure Database for PostgreSQL - Flexible Server](how-to-high-cpu-utilization.md)

0 commit comments

Comments
 (0)