Problem analysis methodology
Performance issues in PolarDB for PostgreSQL almost always trace back to a resource bottleneck. The analysis process has three steps: identify which resource is most constrained, find what is driving the high consumption, then dig deeper to isolate the root cause.
Resource types
PolarDB for PostgreSQL uses two categories of resources that can become bottlenecks:
System resources
-
CPU
-
I/O
-
Network
-
Memory
-
Disk
Database resources
-
Locks — including LWLock (lightweight lock) and other lock types
-
Caches — including the buffer pool cache and the Simple Least Recently Used (SLRU) cache
How wait events fit in
During normal operation, sessions regularly wait. A single wait is not a problem — reading data from disk when a page is not in memory, or pausing while another session holds a lock, are both expected behaviors. What signals a bottleneck is a sustained high volume of waits concentrated on a specific resource.
The standard approach is to analyze wait events, identify which resource the waits point to, then use that as the starting point for deeper analysis. Wait events are the bridge between an observed symptom (slow queries, high latency) and the underlying resource constraint.