Re: [systemd-devel] Memory in systemctl status
Am 28.09.20 um 19:32 schrieb Dave Howorth: >> the far slower copy from the list-server is silently purged by >> intention to avoid receive ever ymessage twice on mailing lists where >> people can't handle a MUA > > Well then, it's not Benjamin breaking the threading, it's you :P > You need to rewrite your processing rules to prefer the list copy how should the mail server supressing duplicates by intention smell that the first message is a off-list copy? * it's received * it's stored * later another with the same message ID arrives * the later one is supressed > Assuming Tbird is capable; else change your MUA. not everyone is poor soul relying on client side rules, not for filter duplicates and not for move messages in subfolders, that's what mailservers are supposed to do so that the processing is independent from the device in your hands maybe Benjamin should switch the MUA or configure it correctly so that he have a "reply-list" button which is based on the list headers if he can't or don't want he can just delete everything but the list address after "reply-all" as i did when respond to his messages ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, 28 Sep 2020 16:39:05 +0200 Reindl Harald wrote: > Am 28.09.20 um 16:34 schrieb Dave Howorth: > > On Mon, 28 Sep 2020 14:10:38 +0200 > > Reindl Harald wrote: > >> can you stop "reply-all" and breaking threads when respond to > >> lists? > > > > I can't answer for the reply-all, that would annoy me as well. > > But the thread isn't broken, my MUA is showing it nicely. > > hardly when the off-list copy is faster (and contains no list-headers) > and i need to reply-all and manually only keep the list because my > "reply-list" button is gone > > the far slower copy from the list-server is silently purged by > intention to avoid receive ever ymessage twice on mailing lists where > people can't handle a MUA Well then, it's not Benjamin breaking the threading, it's you :P You need to rewrite your processing rules to prefer the list copy. Assuming Tbird is capable; else change your MUA. > anyways, i am more shocked that the only people replyign don#t > understand the simle fact that "Memory: 500 MB / 8.5 GB (with caches)" > would make sense but not "Memory: 8.5 GB" as the only RAM dependent > output ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
Am 28.09.20 um 18:33 schrieb Lennart Poettering: > On Mo, 28.09.20 14:22, Reindl Harald (h.rei...@thelounge.net) wrote: > >> honestly: do you realize that i know very well how the memory management >> of Linux works and that it's pretty fine but not part of the topic at all? > > Reindl, did you see who you are replying to here? surely, that's why i tried to make clear that i don't need any education about the memory management of the Linux kernel, *it's not* topic at all > Maybe don't try to > argue with Linus' second-in-command about what Linux memory management > doesn't or does do i don't and didn't ever hell: the Linux memory management *is not* part of the discussion, it's about what *you* show in systemd and given that htop can easily distinct between VIRT/RES/SHARED i expect that systemd could also display proper values without cache i don't give a fuck about 12Gi *systemwide cache* which is a large part of the 8.5GB you are showing fro httpd.service, it makes sense to display that as *additional info* but not saying "that's the memory used by this service" [root@arrakis:~]$ systemctl status httpd.service ● httpd.service - Apache Webserver Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/httpd.service.d └─lockdown.conf Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks 1 days ago Process: 2456787 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS) Main PID: 713 (httpd) Tasks: 16 (limit: 1024) Memory: 8.5G [root@arrakis:~]$ free totalusedfree shared buff/cache available Mem: 15Gi 2.3Gi 361Mi 206Mi12Gi 12Gi Swap:0B 0B 0B ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mo, 28.09.20 14:22, Reindl Harald (h.rei...@thelounge.net) wrote: > honestly: do you realize that i know very well how the memory management > of Linux works and that it's pretty fine but not part of the topic at all? Reindl, did you see who you are replying to here? Maybe don't try to argue with Linus' second-in-command about what Linux memory management doesn't or does do. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
Am 28.09.20 um 16:34 schrieb Dave Howorth: > On Mon, 28 Sep 2020 14:10:38 +0200 > Reindl Harald wrote: >> can you stop "reply-all" and breaking threads when respond to lists? > > I can't answer for the reply-all, that would annoy me as well. > But the thread isn't broken, my MUA is showing it nicely. hardly when the off-list copy is faster (and contains no list-headers) and i need to reply-all and manually only keep the list because my "reply-list" button is gone the far slower copy from the list-server is silently purged by intention to avoid receive ever ymessage twice on mailing lists where people can't handle a MUA anyways, i am more shocked that the only people replyign don#t understand the simle fact that "Memory: 500 MB / 8.5 GB (with caches)" would make sense but not "Memory: 8.5 GB" as the only RAM dependent output ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, 28 Sep 2020 14:10:38 +0200 Reindl Harald wrote: > can you stop "reply-all" and breaking threads when respond to lists? I can't answer for the reply-all, that would annoy me as well. But the thread isn't broken, my MUA is showing it nicely. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, Sep 28, 2020 at 02:22:17PM +0200, Reindl Harald wrote: > honestly: do you realize that i know very well how the memory management > of Linux works and that it's pretty fine but not part of the topic at all? *plonk* ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
honestly: do you realize that i know very well how the memory management of Linux works and that it's pretty fine but not part of the topic at all? Am 28.09.20 um 14:08 schrieb Greg KH: > How do you know this? And why wouldn't they be "charged" to the task > that caused the cache to fill up? What "should" they do? it's memory the OS is using and not httpd > If you don't like the current way that Linux manages memory resources > like this, please discuss it with the kernel developers the way Linux manages memory is perfect > there's not > much that systemd can do about it, right? surely, display what is truly used by the processes in the cgroup wich are currently 11 workers with around 40-80 MB and so we are at around 900 MB plus some shared memory for opcache > Why shouldn't httpd use all the ram it was allowed to, if possible? > What's wrong with that happening if the kernel is still caching those > resources? NOTHING IS WRONG by the kernel caching, but it's wrong to have only *one* memory output in "systemctl status" pretending the service is actively using 8 GB which it don't > If you want to tell httpd to "flush the data from the kernel" after it > is done downloading that ISO image, please modify httpd to do so, > otherwise how is the kernel to know that it isn't to be asked for again > within the next minute or so? nobody is asking the kernel to flush caches the kernel is pretty fine systemctl is wrong by showing a pointless value it maybe is a *nice additional* information but *not* the value one cares for when it's the one and only memory output > memory management is hard :) the memory management is fine, the output of systemctl is wrong >> the only interesting memory is RES of all the processes > > Interesting to whom? to the admin looking which service is using how much memory and when you have a machine with 200 GB RAM running httpd on a large system for weeks pretending it's using 190 GB RAM is pointless this is *not* active memory used by the process and even if it's showing 100% memory usage in that output you can still start a process allocating 20 GB RAM without any issue ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, Sep 28, 2020 at 11:37:20AM +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 How do you know this? And why wouldn't they be "charged" to the task that caused the cache to fill up? What "should" they do? If you don't like the current way that Linux manages memory resources like this, please discuss it with the kernel developers, there's not much that systemd can do about it, right? > > 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 > > not more and not less > > httpd don't use 8.7 GB RAM - period Why shouldn't httpd use all the ram it was allowed to, if possible? What's wrong with that happening if the kernel is still caching those resources? If you want to tell httpd to "flush the data from the kernel" after it is done downloading that ISO image, please modify httpd to do so, otherwise how is the kernel to know that it isn't to be asked for again within the next minute or so? memory management is hard :) > the only interesting memory is RES of all the processes Interesting to whom? > my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that > and even if the latest download of a 10 GB file is somewhere in the OS > caches in case it's opened later - it's *free* memory How do you know that Firefox does not tell the kernel to release that memory after the download finishes? Best of luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
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. > > 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. Benjamin > not more and not less > > httpd don't use 8.7 GB RAM - period > > the only interesting memory is RES of all the processes > > my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that > and even if the latest download of a 10 GB file is somewhere in the OS > caches in case it's opened later - it's *free* memory > > Main PID: 713 (httpd) > Tasks: 16 (limit: 1024) >Memory: 8.7G > CPU: 2h 24min 14.348s >CGroup: /system.slice/httpd.service >├─713 /usr/sbin/httpd -D FOREGROUND >├─2435242 /usr/sbin/httpd -D FOREGROUND >├─2435243 /usr/sbin/httpd -D FOREGROUND >├─2435931 /usr/sbin/httpd -D FOREGROUND >├─2435942 /usr/sbin/httpd -D FOREGROUND >├─2435944 /usr/sbin/httpd -D FOREGROUND >├─2435947 /usr/sbin/httpd -D FOREGROUND >├─2435948 /usr/sbin/httpd -D FOREGROUND >├─2435952 /usr/sbin/httpd -D FOREGROUND >├─2435954 /usr/sbin/httpd -D FOREGROUND >├─2435960 /usr/sbin/httpd -D FOREGROUND >├─2435966 /usr/sbin/httpd -D FOREGROUND >├─2435968 /usr/sbin/httpd -D FOREGROUND >├─2435969 /usr/sbin/httpd -D FOREGROUND >├─2435970 /usr/sbin/httpd -D FOREGROUND >└─2435972 /usr/sbin/httpd -D FOREGROUND > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
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 > 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 not more and not less httpd don't use 8.7 GB RAM - period the only interesting memory is RES of all the processes my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that and even if the latest download of a 10 GB file is somewhere in the OS caches in case it's opened later - it's *free* memory Main PID: 713 (httpd) Tasks: 16 (limit: 1024) Memory: 8.7G CPU: 2h 24min 14.348s CGroup: /system.slice/httpd.service ├─713 /usr/sbin/httpd -D FOREGROUND ├─2435242 /usr/sbin/httpd -D FOREGROUND ├─2435243 /usr/sbin/httpd -D FOREGROUND ├─2435931 /usr/sbin/httpd -D FOREGROUND ├─2435942 /usr/sbin/httpd -D FOREGROUND ├─2435944 /usr/sbin/httpd -D FOREGROUND ├─2435947 /usr/sbin/httpd -D FOREGROUND ├─2435948 /usr/sbin/httpd -D FOREGROUND ├─2435952 /usr/sbin/httpd -D FOREGROUND ├─2435954 /usr/sbin/httpd -D FOREGROUND ├─2435960 /usr/sbin/httpd -D FOREGROUND ├─2435966 /usr/sbin/httpd -D FOREGROUND ├─2435968 /usr/sbin/httpd -D FOREGROUND ├─2435969 /usr/sbin/httpd -D FOREGROUND ├─2435970 /usr/sbin/httpd -D FOREGROUND └─2435972 /usr/sbin/httpd -D FOREGROUND ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, 2020-09-28 at 10:43 +0200, Reindl Harald wrote: > > Am 28.09.20 um 10:37 schrieb Tomasz Torcz: > > On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote: > > > Am 27.09.20 um 23:39 schrieb Benjamin Berg: > > > > > > > however, that value makes little to no sense and if that's the > > > > > > > same > > > > > > > value as accounted for "MemoryMax" it's plain wrong > > > > But it does make sense. File caches are part of the working set of > > > > memory that a process needs. Setting MemoryMax=/MemoryMin= > > > > limits/guarantees the size of this working set. These kinds of limits > > > > or protections would be a lot less meaningful if caches were not > > > > accounted for. > > > > > > sorry but that is complete nosense > > > > > > caches are freed as soon whatever process asks for RAM and so they are > > > *not* part of the working set > > > > > > my webserver is killed because it served at monday, tuesday, thursday > > > and friday 4 different files with 2 GB? > > > > Why "killed", you wrote yourself caches are freed. So are they freed > > or aren't they? > > 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. > why should the caches be freed as long as no other process allocates memory? Because it means different parts of the system are properly isolated from each other. > "These kinds of limits or protections would be a lot less meaningful if > caches were not accounted for" is nonsense - os caches are part of the > VFS and have nothing to do with protect from a process allocating 10 GB > private memory which can't be freed other than swap it out It really sounds to me like ulimit fits better what you are trying to do. That is available through Limit*=, see systemd.exec. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
Am 28.09.20 um 10:37 schrieb Tomasz Torcz: > On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote: >> Am 27.09.20 um 23:39 schrieb Benjamin Berg: >> however, that value makes little to no sense and if that's the same >> value as accounted for "MemoryMax" it's plain wrong >>> But it does make sense. File caches are part of the working set of >>> memory that a process needs. Setting MemoryMax=/MemoryMin= >>> limits/guarantees the size of this working set. These kinds of limits >>> or protections would be a lot less meaningful if caches were not >>> accounted for. >> >> sorry but that is complete nosense >> >> caches are freed as soon whatever process asks for RAM and so they are >> *not* part of the working set >> >> my webserver is killed because it served at monday, tuesday, thursday >> and friday 4 different files with 2 GB? > > Why "killed", you wrote yourself caches are freed. So are they freed > or aren't they? if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the caches are accounted in that context why should the caches be freed as long as no other process allocates memory? "These kinds of limits or protections would be a lot less meaningful if caches were not accounted for" is nonsense - os caches are part of the VFS and have nothing to do with protect from a process allocating 10 GB private memory which can't be freed other than swap it out ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote: > Am 27.09.20 um 23:39 schrieb Benjamin Berg: > however, that value makes little to no sense and if that's the same > value as accounted for "MemoryMax" it's plain wrong > > But it does make sense. File caches are part of the working set of > > memory that a process needs. Setting MemoryMax=/MemoryMin= > > limits/guarantees the size of this working set. These kinds of limits > > or protections would be a lot less meaningful if caches were not > > accounted for. > > sorry but that is complete nosense > > caches are freed as soon whatever process asks for RAM and so they are > *not* part of the working set > > > my webserver is killed because it served at monday, tuesday, thursday > and friday 4 different files with 2 GB? Why "killed", you wrote yourself caches are freed. So are they freed or aren't they? -- Tomasz Torcz “Never underestimate the bandwidth of a station to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
Am 27.09.20 um 23:39 schrieb Benjamin Berg: however, that value makes little to no sense and if that's the same value as accounted for "MemoryMax" it's plain wrong > But it does make sense. File caches are part of the working set of > memory that a process needs. Setting MemoryMax=/MemoryMin= > limits/guarantees the size of this working set. These kinds of limits > or protections would be a lot less meaningful if caches were not > accounted for. sorry but that is complete nosense caches are freed as soon whatever process asks for RAM and so they are *not* part of the working set that kind of limits are completly useless when i would limit a service to 4 GB but because it served a few million different files within the last weeks which are accounted to it's cache and working set it's now killed? my webserver is killed because it served at monday, tuesday, thursday and friday 4 different files with 2 GB? frankly my webserver can't even do anything against caching of teh VFS layer and is not responsible at all nor do other services BTW: stop "reply-all" to mailing-lists ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Sun, 2020-09-27 at 17:45 +0200, Reindl Harald wrote: > > Am 27.09.20 um 14:08 schrieb Greg KH: > > On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote: > > > Memory: 8.6G > > > > > > looks like there is a large part of os-caching included where i wonmder > > > how that's done because a file can be read by muliple processes / > > > services and is hopfefully only once cached I believe it is generally accounted against the cgroup that caused it to be read into main memory. The cgroup documentation probably has more details. > > > however, that value makes little to no sense and if that's the same > > > value as accounted for "MemoryMax" it's plain wrong But it does make sense. File caches are part of the working set of memory that a process needs. Setting MemoryMax=/MemoryMin= limits/guarantees the size of this working set. These kinds of limits or protections would be a lot less meaningful if caches were not accounted for. Benjamin > > > [root@arrakis:~]$ free > > > totalusedfree shared buff/cache > > > available > > > Mem: 15Gi 2.2Gi 585Mi 309Mi12Gi > > >12Gi > > > Swap:0B 0B 0B > > > > The kernel does this, it's nothing to do with systemd or anything else. > > > > You can get "back" that memory for a short while if you really want it > > by doing: > > echo 3 > /proc/sys/vm/drop_caches > > > > For more details, see https://www.linuxatemyram.com/ > > you completly miss the point and should not cut in the middle of a post! > > Memory: 8.6G > > *no* httpd don't consume 8.6GB RAM > > the question is *why* systemd takes the os-cache into account of the > memory a service is using > > [root@arrakis:~]$ systemctl status httpd.service > ● httpd.service - Apache Webserver >Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; > vendor preset: disabled) > Drop-In: /etc/systemd/system/httpd.service.d >└─lockdown.conf >Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks > 0 days ago > Process: 1935633 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful > (code=exited, status=0/SUCCESS) > Main PID: 713 (httpd) > Tasks: 17 (limit: 1024) >Memory: 8.6G > CPU: 2h 8min 5.442s >CGroup: /system.slice/httpd.service >├─713 /usr/sbin/httpd -D FOREGROUND >├─2151772 /usr/sbin/httpd -D FOREGROUND >├─2151803 /usr/sbin/httpd -D FOREGROUND >├─2151805 /usr/sbin/httpd -D FOREGROUND >├─2152130 /usr/sbin/httpd -D FOREGROUND >├─2152132 /usr/sbin/httpd -D FOREGROUND >├─2152188 /usr/sbin/httpd -D FOREGROUND >├─2152189 /usr/sbin/httpd -D FOREGROUND >├─2152199 /usr/sbin/httpd -D FOREGROUND >├─2152211 /usr/sbin/httpd -D FOREGROUND >├─2152213 /usr/sbin/httpd -D FOREGROUND >├─2152214 /usr/sbin/httpd -D FOREGROUND >├─2152215 /usr/sbin/httpd -D FOREGROUND >├─2152217 /usr/sbin/httpd -D FOREGROUND >├─2152220 /usr/sbin/httpd -D FOREGROUND >├─2152756 /usr/sbin/httpd -D FOREGROUND >└─2152886 /usr/sbin/httpd -D FOREGROUND > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
Am 27.09.20 um 14:08 schrieb Greg KH: > On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote: >> Memory: 8.6G >> >> looks like there is a large part of os-caching included where i wonmder >> how that's done because a file can be read by muliple processes / >> services and is hopfefully only once cached >> >> however, that value makes little to no sense and if that's the same >> value as accounted for "MemoryMax" it's plain wrong >> >> [root@arrakis:~]$ free >> totalusedfree shared buff/cache >> available >> Mem: 15Gi 2.2Gi 585Mi 309Mi12Gi >>12Gi >> Swap:0B 0B 0B > > The kernel does this, it's nothing to do with systemd or anything else. > > You can get "back" that memory for a short while if you really want it > by doing: > echo 3 > /proc/sys/vm/drop_caches > > For more details, see https://www.linuxatemyram.com/ you completly miss the point and should not cut in the middle of a post! Memory: 8.6G *no* httpd don't consume 8.6GB RAM the question is *why* systemd takes the os-cache into account of the memory a service is using [root@arrakis:~]$ systemctl status httpd.service ● httpd.service - Apache Webserver Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/httpd.service.d └─lockdown.conf Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks 0 days ago Process: 1935633 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS) Main PID: 713 (httpd) Tasks: 17 (limit: 1024) Memory: 8.6G CPU: 2h 8min 5.442s CGroup: /system.slice/httpd.service ├─713 /usr/sbin/httpd -D FOREGROUND ├─2151772 /usr/sbin/httpd -D FOREGROUND ├─2151803 /usr/sbin/httpd -D FOREGROUND ├─2151805 /usr/sbin/httpd -D FOREGROUND ├─2152130 /usr/sbin/httpd -D FOREGROUND ├─2152132 /usr/sbin/httpd -D FOREGROUND ├─2152188 /usr/sbin/httpd -D FOREGROUND ├─2152189 /usr/sbin/httpd -D FOREGROUND ├─2152199 /usr/sbin/httpd -D FOREGROUND ├─2152211 /usr/sbin/httpd -D FOREGROUND ├─2152213 /usr/sbin/httpd -D FOREGROUND ├─2152214 /usr/sbin/httpd -D FOREGROUND ├─2152215 /usr/sbin/httpd -D FOREGROUND ├─2152217 /usr/sbin/httpd -D FOREGROUND ├─2152220 /usr/sbin/httpd -D FOREGROUND ├─2152756 /usr/sbin/httpd -D FOREGROUND └─2152886 /usr/sbin/httpd -D FOREGROUND ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote: > Memory: 8.6G > > looks like there is a large part of os-caching included where i wonmder > how that's done because a file can be read by muliple processes / > services and is hopfefully only once cached > > however, that value makes little to no sense and if that's the same > value as accounted for "MemoryMax" it's plain wrong > > [root@arrakis:~]$ free > totalusedfree shared buff/cache > available > Mem: 15Gi 2.2Gi 585Mi 309Mi12Gi >12Gi > Swap:0B 0B 0B The kernel does this, it's nothing to do with systemd or anything else. You can get "back" that memory for a short while if you really want it by doing: echo 3 > /proc/sys/vm/drop_caches For more details, see https://www.linuxatemyram.com/ good luck! greg k-h- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
