FEATURE REQUEST: Role vCPU limit/priority
It would be useful to have the ability to define for a role default vCPU
affinity limits/thread priority settings so that more active sessions could
coexist similar to MySQL resource groups
<https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html>.
Best Regards,
Yoni Sade
Hi Yoni,
It would be useful to have the ability to define for a role default vCPU affinity limits/thread priority settings so that more active sessions could coexist similar to MySQL resource groups.
To me this sounds like a valuable feature.
Would you be interested in working on it? Typically it is a good idea
to start with an RFC document and discuss it with the community.
--
Best regards,
Aleksander Alekseev
Well, I'm not a developer, I just wanted to pitch this idea as a DBA who
would make use of this feature.
Best Regards,
Yoni Sade
בתאריך יום ב׳, 22 בינו׳ 2024 ב-12:43 מאת Aleksander Alekseev <
aleksander@timescale.com>:
Show quoted text
Hi Yoni,
It would be useful to have the ability to define for a role default vCPU
affinity limits/thread priority settings so that more active sessions could
coexist similar to MySQL resource groups.To me this sounds like a valuable feature.
Would you be interested in working on it? Typically it is a good idea
to start with an RFC document and discuss it with the community.--
Best regards,
Aleksander Alekseev
Yoni Sade schrieb am 21.01.2024 um 19:07:
It would be useful to have the ability to define for a role default
vCPU affinity limits/thread priority settings so that more active
sessions could coexist similar to MySQL resource groups
<https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html>.
To a certain extent, you can achieve something like that using Linux cgroups
https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/
Hi,
Well, I'm not a developer, I just wanted to pitch this idea as a DBA who would make use of this feature.
I don't think one shouldn't be a developer in order to write an RFC
and drive its discussion within the community. On top of that I'm
pretty confident as a DBA you can contribute tests and documentation.
--
Best regards,
Aleksander Alekseev
Hi,
On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
Yoni Sade schrieb am 21.01.2024 um 19:07:
It would be useful to have the ability to define for a role default
vCPU affinity limits/thread priority settings so that more active
sessions could coexist similar to MySQL resource groups
<https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html>.To a certain extent, you can achieve something like that using Linux cgroups
https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/
If you do that naively, you just run into priority inversion issues. E.g. a
backend holding a critical lwlock not getting scheduled for a while because it
exceeded it CPU allocation, preventing higher priority processes from
progressing.
I doubt you can implement this in a robust manner outside of postgres.
Regards,
Andres
On Tue, Jan 23, 2024 at 10:10:27AM -0800, Andres Freund wrote:
Hi,
On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
Yoni Sade schrieb am 21.01.2024 um 19:07:
It would be useful to have the ability to define for a role default
vCPU affinity limits/thread priority settings so that more active
sessions could coexist similar to MySQL resource groups
<https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html>.To a certain extent, you can achieve something like that using Linux cgroups
https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/
If you do that naively, you just run into priority inversion issues. E.g. a
backend holding a critical lwlock not getting scheduled for a while because it
exceeded it CPU allocation, preventing higher priority processes from
progressing.I doubt you can implement this in a robust manner outside of postgres.
FYI, here is an article about priority inversion:
https://www.geeksforgeeks.org/priority-inversion-what-the-heck/
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.