- Newest
- Most votes
- Most comments
Hi,
IO:SLRURead when a pg process is waiting for a read of a simple least-recently used (SLRU) page.
An example of such situation with solution of heavy use of SLRU pages is here: https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/
This deck is a similar issue: https://pgconf.in/files/presentations/2023/Dilip_Kumar_RareExtremelyChallengingPostgresPerformanceProblems.pdf
Maybe it matches your use case?
Another possibility is lots of sequential table scans: are EXPLAIN ANALYZE plans for your queries indicating a lot of sequential scans?
Best,
Didier
Thank you for the answer, Didier.
I spent the last couple of weeks monitoring, trying to figure out the cause of the slow queries I was seeing, and in the end it turned out it was mostly the fault of sequelize generating inefficient queries, in a few specific instances. I rewrote them as raw SQL queries, and everything is back to normal now, performance-wise.
The IO:SLRURead really threw me off, but I think it was just a coincidence that I started seeing this after migrating to Aurora I/O Optimized.
For anybody in the future, that has a similar issue, and suspects that using Aurora I/O Optimized could be the root of performance issues, I can say that one can expect the performance to be pretty much on par with running on plain RDS for PostgreSQL.
Thanks again!
Relevant content
- asked 4 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated a year ago