From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Kellerer <shammat(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: FEATURE REQUEST: Role vCPU limit/priority |
Date: | 2024-01-23 18:10:27 |
Message-ID: | 20240123181027.hoezdrxyf5brsrc5@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-01-23 18:22:58 | Re: core dumps in auto_prewarm, tests succeed |
Previous Message | Alexander Lakhin | 2024-01-23 18:00:01 | Re: On login trigger: take three |