Eugene Suprun writes:
21.03.2021 17:56, Sam Varshavchik пишет:Increased its value from 128 to 4096, no problems in an hour. Thanks for the tip. I am going to check it tomorrow, when there will be much more mail users.Eugene Suprun writes: Try increasing /proc/sys/fs/inotify/max_user_instancesIn any case, I think enabling inotify notification facility should be configurable: inotify structures require non-negligible amount of memory to maintain (and it can't be swapped out to disk)
That's what that post said. Technically, that's obviously true. I am not very knowledgeable of the Linux kernel's internals; but this doesn't sound like something that demands megabytes of additional overhead per file descriptor.
The difference between the two models is one process using a single inotify file descriptor to monitor all directories, versus each process using its own individual inotify file descriptors. Either way, the same set of directories gets monitored. I'd think the book-keeping for that will be what's taking up most of the resources.
It's one inotify file descriptor having to carry around the necessary baggage to monitor a thousand directories, versus a few hundred processes using a couple of inotify file descriptors to monitor the same thousand directories (imapd monitors cur+new+keyword directories on one inotify descriptor). I can't see this by itself amounting to anything significant.
Plus, I'd say that most of that would be recovered by not having the gam_server process around, or its predecessor, famd. That's worth a few megabytes, easily. I see that gam_server is linked with libglib:
$ ldd /usr/libexec/gam_server
linux-vdso.so.1 (0x00007ffda33ba000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2508a02000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2508837000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f25087be000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f250879c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2508b75000)
$ size /lib64/libglib-2.0.so.0
text data bss dec hex filename
1230769 4672 3112 1238553 12e619 /lib64/libglib-2.0.so.0
Unless someone also has something else running that requires Gnome stuff,
that's an extra meg and a half (counting gam-server itself, but excluding
pcre, it's likely there's something else that links with it), that's no
longer needed. And, the less dependencies there is on the Gnome cruft, the
better.
As for alerting a user? It frustrates the user. May be also configurable setting?
I definitely need to update the message itself. I don't know, though, of a better alerting mechanism. This is really exposing how bad IMAP clients respond to IMAP alerts. This alert does not break the connection, the IMAP client can continue, the IMAP session is still there.
pgpDmR12MiA7Q.pgp
Description: PGP signature
_______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
