Since this thread is already as pointless as it can get, I at least
change the subject line so its clear there is nothing about disabling
akonadi in this post.
René J.V. Bertin - 03.09.18, 10:54:
> On Monday September 03 2018 03:03:25 Draciron Smith wrote:
> >I've been using 1 for 1 for on my swap partitions for about 15 years
> >now and not really had issues, but it probably is a good idea to
> >switch to 2 for 1 as you suggest.
>
> It's the commonly suggested approach.
And still unsuitable in some cases. See my mail about swap.
> >I don't use ANY Akondi apps. None, zero, zilch. The memory problems
> >start at boot before I've even opened an application.
>
> You should probably report that as a bug, esp. if you can reproduce it
> after creating a new user.
As I showed in my post about memory usage of an empty and unused
Akonadi: It is certainly not a memory hog. So if it uses more than 120
or say 150 MiB I´d file a bug.
> > Linux is a superb multi-tasker and
> >usually handles memory very gracefully.
>
> With the risk of attracting Martin's ire: I agree and I don't. The
> kernel will pretend that every memory allocation succeeds by default,
> even if you ask for an insane amount. I'm not sure I call that
> graceful ;)
I agree with you that there is not much grace in Linux kernel memory
management. It acts like a bank: Handing out more than it has.
So I agree with you that the kernel accepts over the top memory
allocations. This is due to Linux using a virtual memory manager.
Processes allocate address space, not memory. Linux only allocates
memory once the application writes something into it. And some
applications allocate address space like mad in order not to have to
allocate every single bit individually. That is the difference between
virtual set size (VSS/VSZ) and resident set size (RSS). Just look in
atop, top, htop the top of your choice and you see that the virtual
memory figures have nothing to do at all with physical memory.
However insane amounts the kernel rejects as long as one process
requests it. On this ThinkPad with 16 GiB of RAM, with about 11299 still
available and 0 in /proc/sys/vm/overcommit_memory (heuristic
measurement):
% stress -m 1 --vm-keep --vm-bytes 30g
stress: info: [27006] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [27007] (494) hogvm malloc failed: Cannot allocate memory
stress: FAIL: [27006] (394) <-- worker 27007 returned error 1
stress: WARN: [27006] (396) now reaping child worker processes
stress: FAIL: [27006] (451) failed run completed in 0s
And that with it even having 20 GiB of swap. However the kernel by
default takes into account only half of the memory and all of the swap.
That makes 16 / 2 = 8 GiB for memory and 20 GiB for swap, thus 28 GiB.
However, you can easily trick it:
% stress -m 20 --vm-keep --vm-bytes 5g
stress: info: [27107] dispatching hogs: 0 cpu, 0 io, 20 vm, 0 hdd
stress: FAIL: [27107] (415) <-- worker 27126 got signal 9
stress: WARN: [27107] (417) now reaping child worker processes
stress: FAIL: [27107] (451) failed run completed in 140s
That is 20 processes with 5 GiB each, totalling to 100 GiB.
WARNING: Do not try this at home until you made sure you saved all
important unsaved data to persistent storage! You have been warned.
Above command stalled this ThinkPad T520 to an halt due to excessive
memory and swap pressure. Until the kernel started to kick out processes
with SIGKILL:
% egrep "invoked|Killed" /var/log/kern.log
Sep 3 11:09:16 merkaba kernel: [166660.678838] mysqld invoked oom-
killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null),
order=0, oom_score_adj=0
Sep 3 11:09:16 merkaba kernel: [166660.714822] Killed process 29678
(QtWebEngineProc) total-vm:2173724kB, anon-rss:36kB, file-rss:0kB,
shmem-rss:0kB
Sep 3 11:09:16 merkaba kernel: [166661.752937] systemd invoked oom-
killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null),
order=0, oom_score_adj=0
Sep 3 11:09:16 merkaba kernel: [166661.753903] Killed process 29908
(QtWebEngineProc) total-vm:2123752kB, anon-rss:432kB, file-rss:0kB,
shmem-rss:0kB
Sep 3 11:09:17 merkaba kernel: [166662.976390] thermald invoked oom-
killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null),
order=0, oom_score_adj=0
Sep 3 11:09:38 merkaba kernel: [166662.977380] Killed process 27126
(stress) total-vm:5246780kB, anon-rss:1883932kB, file-rss:196kB, shmem-
rss:0kB
Yep, that is right: It first killed QtWebEngine processes in Akregator
and only then got the true culprit, one of the stress processes. The
stress master processes then quitted the other child processes. It does
so by default when only of the child processes quits.
I certainly would not call this graceful and I am happy it did not kill
KMail :), although its saved letter functionality usually recovers most
of a not yet finished mail.
> FWIW, when I start to notice slow-downs on my own (8Gb) system it is
> usually a sign that I'm using over 800Mb or so of swap memory as
> reported by htop. They get significant enough to start restarting
> applications when that figure grows over 1.2Gb or so. Thing is, I
> only restart Chrome, Kontact, the window manager and (sometimes) the
> Plasma shell (`kquitapp plasma-desktop ; kstart plasma-desktop`).
> Restarting akonadi rarely makes a significant difference (sorry, a
> difference big enough to be noticeable and remember doing that
> restart no matter how statistically significant :) ). Yet I have what
> I think a representative set of agents : 2 IMAP accounts (one for
> this GMail address), Google calendar, contacts, the baloo indexer
> etc.
The baloo indexer for files in home directory and the Akonadi indexing
are separate meanwhile. KDEPIM developers separated the mail part of
Baloo out into akonadi_indexing_agent.
Ciao,
--
Martin
