On Fri Sep 6, 2024 at 6:48 PM AEST, Stuart Henderson wrote: > On 2024/09/06 09:44, Dylan D'Silva wrote: > > > > > > > > > > > > > > > > > > I run aerc from a staff account. Therefore I updated my > > > > > > > > > /etc/login.conf > > > > > > > > > under staff to increase the openfile-cur size to 71600 and > > > > > > > > > openfile-max > > > > > > > > > to 72000 > > > > > > > > > :openfiles-cur=71600:\ > > > > > > > > > :openfiles-max=72000:\ > > > > > > > > > > > > > > > > If you're going to do this, I would recommend a "normal" > > > > > > > > openfiles-cur, > > > > > > > > just raise openfiles-max. Then start such software from a > > > > > > > > script or > > > > > > > > shell alias which uses ulimit -n to raise the limit just for > > > > > > > > that > > > > > > > > software. > > > > > > > > What do you consider normal? In your comment below, you made comment > > > > about not many people running computers from the 80's. > > > > > > I think Stuart meant that you could leave openfiles-cur with it's > > > default value (in case you hadn't changed it before for something else) > > > and only increase openfiles-max to your desired value. Then you can > > > start aerc from a script like the following: > > I understood what Stuart meant in regards to the cur-max comment. You > > missed the point I was making. Stuart thinks its pointless to use > > cap_mkdb as modern systems are fast enough to handle larger login.conf > > files. Yet Stuart thinks an openfile-cur of 128 is sufficient. So I > > I don't think that openfiles-cur=128 is sufficient in most cases. > 128 is the default for the "daemon" login class, but other classes are > higher, and daemons expecting to use more than this in normal use either > do the equivalent of ulimit -n to raise to openfiles-max (default 1024 > for daemon at least on the archs I checked) or have separate login.conf > classes. > > I even think the current default limits may be a little low for standard > use on average machines of some arch, but there's a wide range of > hardware supported by say OpenBSD/amd64, some much smaller than others, > and we'd need to first talk about raising kernel limits because the > current login.conf defaults (openfiles-cur=512, openfiles-max=1024) are > I think appropriate for the default kern.maxfiles.
int maxfiles =3D 5 * (NPROCESS + MAXUSERS) + 80; /* [a] */ #define NPROCESS (30 + 16 * MAXUSERS) amd system maxusers 80 # estimated number of users Why these constants? Have these values changed since Jonathan Lemon 2001 paper and code implementations?=20 >From his paper in the performance section "Measurements for performance numbers in this section were taken on a Dell PowerEdge 2300 equipped with an Intel Pentium-III 600Mhz CPU and 512MB memory, running FreeBSD 4.3-RC." > > asked what is his definition of normal. I then pointed to the inotify > > change of 2020 in Linux kernel which set a range of 8192 to 104576. Does > > he have a standard or something to reference or is this just opinion? > > Limit ranges in the Linux kernel don't really have anything to do with > what's done in OpenBSD. True, but that doesn't provide any reason as to why it can't be within those ranges. > > > #!/bin/sh > > > > > > ulimit -n 72000 > > > aerc > > How does that solve the mentioned problem of people running multiple > > aerc instances? > > It doesn't, but it does provide bounds to at least stop other out of > control processes consuming large amounts of kernel memory and limits it > to just aerc. > > > > > It's worth mentioning but the syncthing pkg-readme suggest a openfile of > > > > 4096. > > If this with aerc was talking about 4096 then I'd be more inclined to > document it in the readme like we do with syncthing. But the sizes > needed for some mailboxes at one open FD per email are pretty huge and > the proposed 72000 is so far above the default whole-system limit that > it seems irresponsible to recommend, at least without analysis from > someone who has a better handle on the kernel impact of this. > (Also if doing that, someone else later may say "oh but aerc's > pkg-readme says 72000 is ok, so why can't we have 100000?") That is fair enough. Thanks for the response. To be honest, I didn't pluck 72000 out of the air or suggest it as the standard for the pkg-readme. I mentioned on the aerc mailing list a work around to get the MAILDIR+Notmuch+aerc to work on OpenBSD. That figure was determined by "find ~/MAILDIR -type f | wc -l" and was specific for my mailbox size. > > > > > > > > We are mostly not running on computer systems from the 80s and > > > > > > > > the file > > > > > > > > is not really slow to parse - however having the db files > > > > > > > > around does > > > > > > > > cause trouble when someone forgets to rerun cap_mkdb after > > > > > > > > changing the > > > > > > > > file later. I would not recommend this. > > > > > > > > The man page for login(5).conf has that comment. > > Along with a note "Using a database version for small files does not > result in a performance improvement" and a reminder that it be re-run > after every change to the file. Also it is a bit more buried there > and less likely to be seen by not-so-technical users than the > pkg-readme instructions. > > > > > How about improving Kqueue to support recursive watching? > > I think it may still need the watches on individual files if you want > to detect when they are changed - so while it might help in some ways, > I'm not sure it would actually lower the FD requirements.
