* [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy
@ 2025-11-20 9:27 Christian Ebner
2025-11-20 13:02 ` Fabian Grünbichler
2025-11-20 14:32 ` Christian Ebner
0 siblings, 2 replies; 4+ messages in thread
From: Christian Ebner @ 2025-11-20 9:27 UTC (permalink / raw)
To: pbs-devel
Since commit 86d5d073 ("GC: fix race with chunk upload/insert on s3
backends"), per-chunk file locks are acquired during phase 2 of
garbage collection for datastores backed by s3 object stores. This
however means that up to 1000 file locks might be held at once, which
can result in the limit of open file handles to be reached.
Therefore, bump the nolimit for the proxmox-backup-proxy in the systemd
service unit, while keeping the hard limit as defined in
/etc/systemd/system.conf.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
---
Changes since version 1:
- Bumpt the limit directly in the systemd service unit
etc/proxmox-backup-proxy.service.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/etc/proxmox-backup-proxy.service.in b/etc/proxmox-backup-proxy.service.in
index 7ca806aa4..52ad99356 100644
--- a/etc/proxmox-backup-proxy.service.in
+++ b/etc/proxmox-backup-proxy.service.in
@@ -10,6 +10,7 @@ Type=notify
ExecStart=%LIBEXECDIR%/proxmox-backup/proxmox-backup-proxy
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/proxmox-backup/proxy.pid
+LimitNOFILE=4096:524288
Restart=on-failure
User=%PROXY_USER%
Group=%PROXY_USER%
--
2.47.3
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy
2025-11-20 9:27 [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy Christian Ebner
@ 2025-11-20 13:02 ` Fabian Grünbichler
2025-11-20 13:32 ` Christian Ebner
2025-11-20 14:32 ` Christian Ebner
1 sibling, 1 reply; 4+ messages in thread
From: Fabian Grünbichler @ 2025-11-20 13:02 UTC (permalink / raw)
To: Proxmox Backup Server development discussion
On November 20, 2025 10:27 am, Christian Ebner wrote:
> Since commit 86d5d073 ("GC: fix race with chunk upload/insert on s3
> backends"), per-chunk file locks are acquired during phase 2 of
> garbage collection for datastores backed by s3 object stores. This
> however means that up to 1000 file locks might be held at once, which
> can result in the limit of open file handles to be reached.
>
> Therefore, bump the nolimit for the proxmox-backup-proxy in the systemd
> service unit, while keeping the hard limit as defined in
> /etc/systemd/system.conf.
>
> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
> ---
> Changes since version 1:
> - Bumpt the limit directly in the systemd service unit
>
> etc/proxmox-backup-proxy.service.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/etc/proxmox-backup-proxy.service.in b/etc/proxmox-backup-proxy.service.in
> index 7ca806aa4..52ad99356 100644
> --- a/etc/proxmox-backup-proxy.service.in
> +++ b/etc/proxmox-backup-proxy.service.in
> @@ -10,6 +10,7 @@ Type=notify
> ExecStart=%LIBEXECDIR%/proxmox-backup/proxmox-backup-proxy
> ExecReload=/bin/kill -HUP $MAINPID
> PIDFile=/run/proxmox-backup/proxy.pid
> +LimitNOFILE=4096:524288
this change is not quite identical to the previous one though ;)
is 4k really enough? that means (not even) 4 GC runs, which could easily
happen with many datastores?
some sort of rationale why it's okay to do this would also be great,
after all there is a reason the default limit is so low..
> Restart=on-failure
> User=%PROXY_USER%
> Group=%PROXY_USER%
> --
> 2.47.3
>
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
>
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy
2025-11-20 13:02 ` Fabian Grünbichler
@ 2025-11-20 13:32 ` Christian Ebner
0 siblings, 0 replies; 4+ messages in thread
From: Christian Ebner @ 2025-11-20 13:32 UTC (permalink / raw)
To: Proxmox Backup Server development discussion, Fabian Grünbichler
On 11/20/25 2:02 PM, Fabian Grünbichler wrote:
> On November 20, 2025 10:27 am, Christian Ebner wrote:
>> Since commit 86d5d073 ("GC: fix race with chunk upload/insert on s3
>> backends"), per-chunk file locks are acquired during phase 2 of
>> garbage collection for datastores backed by s3 object stores. This
>> however means that up to 1000 file locks might be held at once, which
>> can result in the limit of open file handles to be reached.
>>
>> Therefore, bump the nolimit for the proxmox-backup-proxy in the systemd
>> service unit, while keeping the hard limit as defined in
>> /etc/systemd/system.conf.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> Changes since version 1:
>> - Bumpt the limit directly in the systemd service unit
>>
>> etc/proxmox-backup-proxy.service.in | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/etc/proxmox-backup-proxy.service.in b/etc/proxmox-backup-proxy.service.in
>> index 7ca806aa4..52ad99356 100644
>> --- a/etc/proxmox-backup-proxy.service.in
>> +++ b/etc/proxmox-backup-proxy.service.in
>> @@ -10,6 +10,7 @@ Type=notify
>> ExecStart=%LIBEXECDIR%/proxmox-backup/proxmox-backup-proxy
>> ExecReload=/bin/kill -HUP $MAINPID
>> PIDFile=/run/proxmox-backup/proxy.pid
>> +LimitNOFILE=4096:524288
>
> this change is not quite identical to the previous one though ;)
> is 4k really enough? that means (not even) 4 GC runs, which could easily
> happen with many datastores?
That is true, for multiple datastores this could still be problematic.
So I will push this to the hard limit then...
>
> some sort of rationale why it's okay to do this would also be great,
> after all there is a reason the default limit is so low..
Yes, with respect to select() calls, will add this to the commit message
as well, thanks.
>
>> Restart=on-failure
>> User=%PROXY_USER%
>> Group=%PROXY_USER%
>> --
>> 2.47.3
>>
>>
>>
>> _______________________________________________
>> pbs-devel mailing list
>> pbs-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>>
>>
>>
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy
2025-11-20 9:27 [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy Christian Ebner
2025-11-20 13:02 ` Fabian Grünbichler
@ 2025-11-20 14:32 ` Christian Ebner
1 sibling, 0 replies; 4+ messages in thread
From: Christian Ebner @ 2025-11-20 14:32 UTC (permalink / raw)
To: pbs-devel
superseded-by version 3:
https://lore.proxmox.com/pbs-devel/20251120143149.480899-1-c.ebner@proxmox.com/T/
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-11-20 14:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-20 9:27 [pbs-devel] [PATCH proxmox-backup v2] etc: raise nofile soft limit for proxmox-backup-proxy Christian Ebner
2025-11-20 13:02 ` Fabian Grünbichler
2025-11-20 13:32 ` Christian Ebner
2025-11-20 14:32 ` Christian Ebner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.