public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: squid 5.1 gone stable
Date: Mon, 16 Aug 2021 10:40:52 +0100	[thread overview]
Message-ID: <DA5494C5-C748-454A-8EEB-B2256EC5DB6D@ipfire.org> (raw)
In-Reply-To: <5451127f-d52d-1cb5-1ea7-92aecffd94b3@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

Hello,

> On 15 Aug 2021, at 08:53, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> On 13.08.2021 11:22, Michael Tremer wrote:
>> Hello,
>> 
>>> On 7 Aug 2021, at 17:13, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> ...for the records...: ;-)
>>> 
>>> Today I tested building 'squid 5.1' with our usual configure options:
>>> 
>>> ...
>>> --with-dl \
>>> --with-filedescriptors=$(( 16384 * 64 )) \
>>> --with-large-files \
>>> --without-gnutls \
>>> ...
>>> 
>>> No errors in '_build.ipfire.log' for this 'squid' - except:
>>> 
>>> ...
>>> checking for library containing log... none required
>>> configure: forcing default of 1048576 filedescriptors (user-forced)
>>> checking Default FD_SETSIZE value... 1024
>>> checking for getrlimit... yes
>>> checking for setrlimit... yes
>>> checking Maximum number of filedescriptors we can open... 32768
>>> configure: Default number of filedescriptors: 1048576
>>> ...
>>> 
>>> So the maximum number of filedescriptors which are possible for 'squid
>>> 5.1' are 32768!?
>>> 
>>> Ok then. I rebuilt the whole thing with the "maximum":
>>> 
>>> ...
>>> --with-filedescriptors=32768 \
>>> ...
>>> 
>>> But no change. During starting, 'squid 5.1.' still complains:
>>> ...
>>> NOTICE: Could not increase the number of filedescriptors
>>> With 4096 file descriptors available
>>> ...
>>> 
>>> This is the value reported by 'ulimit -n' on my IPFire / Core 158.
>>> 
>>> Currently, only 'squid 4.16' can increase this number under *exactly*
>>> the same environment.
>>> 
>>> What consequences could it have, respectively!?
>> 
>> This is the maximum amount of connections squid can open.
> 
> What makes me wonder: during build, 'squid' says it can open '32768',
> during start its '4096'. If someone knows why, please enlighten me... ;-)

4096 is the default maximum number of files any process can open at the same.

This is to protect the system from going crazy by having too many open files (because I think the file descriptor table used to be of a static size in older versions of the kernel).

>> I suppose this is enough and I can live with 32k. We should remove the field from the UI then.
> 
> Me too, but are 4096 enough?

No. I don’t know why the squid team isn’t handling this better. We are hitting this problem every time we update to a new version.

I suppose this is fine for testing.

You can try adding “ulimit -n 32768” to the squid init script and then it should be able to open up to 32k files.

-Michael

> Besides, I would wait to push '5.1' - I even didn't see an official
> annoncement yet.
> 
> Best,
> Matthias


  reply	other threads:[~2021-08-16  9:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-07 16:13 Matthias Fischer
2021-08-13  9:22 ` Michael Tremer
2021-08-15  7:53   ` Matthias Fischer
2021-08-16  9:40     ` Michael Tremer [this message]
2021-08-18 16:42       ` Matthias Fischer
2021-08-19 13:57         ` Michael Tremer
2021-08-19 16:32           ` Matthias Fischer
2021-08-23 13:29             ` Michael Tremer
2021-08-23 16:25               ` Matthias Fischer
  -- strict thread matches above, loose matches on Subject: below --
2021-08-02 16:12 Matthias Fischer
2021-08-02 16:39 ` Michael Tremer
2021-08-05 17:12   ` Matthias Fischer
2021-08-06 10:46     ` Michael Tremer
2021-08-06 17:55       ` Matthias Fischer
2021-08-07  8:40         ` Matthias Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DA5494C5-C748-454A-8EEB-B2256EC5DB6D@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox