[systemd-devel] Memory in systemctl status
Reindl Harald
h.reindl at thelounge.net
Mon Sep 28 12:10:38 UTC 2020
can you stop "reply-all" and breaking threads when respond to lists?
Am 28.09.20 um 13:55 schrieb Benjamin Berg:
> On Mon, 2020-09-28 at 11:37 +0200, Reindl Harald wrote:
>>
>> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
>>>> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it
>>>> when the
>>>> caches are accounted in that context
>>>
>>> No, the kernel kicks in and reclaims memory at that point. Which can
>>> mean either swapping or just dropping caches.
>>
>> caches have *nothing* to do with the service itself
>
> They really do. Try running multiple concurrent services that are
> actually competing for limited memory resources. Caches are only boring
> as long as you have plenty of extra memory available so that there is
> no competition for it.
and?
>>> It really sounds to me like ulimit fits better what you are trying to
>>> do. That is available through Limit*=, see systemd.exec.
>>
>> hell first i want a output in "systemctl status whatever" which is true
>> and don't contain a ISO image downloaded by someone two days ago
>
> The output does not match your expectation. But that really doesn't
> mean it is false. If you really want more detail, then have a look at
> /sys/fs/cgroup/system.slice/httpd.service/memory.stat
> but
> /sys/fs/cgroup/system.slice/httpd.service/memory.current
> really is important. It is the one that tells you how much system
> memory is used by the kernel to keep the service running.
9191358464
that cache part contains downloads from a week ago which are not freed
because there is no reason, the kernel even uses that cache when a
cronjob or wahtever other service / process is doing something with that
files
pretend it's used by httpd.service in the output is completly wrong,
"Memory: 8.5G" is wrong, plain wrong
the service is using what htop shows
/sys/fs/cgroup/system.slice/httpd.service/memory.current maybe nice an
additional output, but pretend that's the memory the service is using is
wrong
More information about the systemd-devel
mailing list