Re: Troubleshooting a brief spike in active sessions
| От | Nikolay Samokhvalov |
|---|---|
| Тема | Re: Troubleshooting a brief spike in active sessions |
| Дата | |
| Msg-id | CAM527d-Udxg5NSg_kEsEuTm-gB5GJ8z=84znpTQQT-tu2VQW_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Troubleshooting a brief spike in active sessions ("Dirschel, Steve-CW" <Steve.Dirschel@bestbuy.com>) |
| Ответы |
Re: Troubleshooting a brief spike in active sessions
|
| Список | pgsql-performance |
On Fri, Jan 9, 2026 at 1:41 PM Dirschel, Steve-CW <Steve.Dirschel@bestbuy.com> wrote:
>
> Aurora Postgres version 17.4
>
> ...
>
> The app sessions will show as wait_event_type and wait_event as null which I understand means they are on CPU
>
> ...
Not necessarily. It also might be an uninstrumented wait event.
Do the spikes of "CPU" AAS (I prefer to call them "CPU*") correspond well to the spikes of high usage?
If you have N active sessions marked as CPU in ASH, does it match to the CPU load of similar scale?
If the VM has much less than 400 vCPUs and you see overall CPU load far from 100%, then we should suspect some missing wait event.
Nik
>
> Aurora Postgres version 17.4
>
> ...
>
> The app sessions will show as wait_event_type and wait_event as null which I understand means they are on CPU
>
> ...
Not necessarily. It also might be an uninstrumented wait event.
Do the spikes of "CPU" AAS (I prefer to call them "CPU*") correspond well to the spikes of high usage?
If you have N active sessions marked as CPU in ASH, does it match to the CPU load of similar scale?
If the VM has much less than 400 vCPUs and you see overall CPU load far from 100%, then we should suspect some missing wait event.
Nik
В списке pgsql-performance по дате отправления: