Re: FEATURE REQUEST: Role vCPU limit/priority

[Bruce Momjian]

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
> > > .
> > 
> > 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  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: FEATURE REQUEST: Role vCPU limit/priority

[Andres Freund]

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
> > .
> 
> 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

Re: FEATURE REQUEST: Role vCPU limit/priority

[Aleksander Alekseev]

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

Re: FEATURE REQUEST: Role vCPU limit/priority

[Thomas Kellerer]

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
> .

To a certain extent, you can achieve something like that using Linux cgroups

https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/

Re: FEATURE REQUEST: Role vCPU limit/priority

[Yoni Sade]

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‬‏ <‪
aleksan...@timescale.com‬‏>:‬

> 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
>

Re: FEATURE REQUEST: Role vCPU limit/priority

[Aleksander Alekseev]

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