> On 20 Jul 2020, at 15:40, Stephen John Smoogen <smo...@gmail.com> wrote:
>
> On Mon, 20 Jul 2020 at 05:04, Kevin Kofler <kevin.kof...@chello.at
> <mailto:kevin.kof...@chello.at>> wrote:
>>
>> John M. Harris Jr wrote:
>>> Userspace isn't dead when a system is thrashing. Your software is still
>>> running. If it gets killed, you're most likely going to lose your data.
>>
>> The thing is, there are various levels of thrashing. In some cases, the
>> system is so busy that you have no chance to bring it back to responsiveness
>> for many minutes, up to hours. (Other than hitting the Reset or Power
>> button, of course.) I have had cases where not even sshd would respond. (The
>> fact that login has been blocking on D-Bus since the introduction of
>> systemd-logind does not help either. Login timeouts are something that was
>> just never happening in the past, now they are common under heavy load.)
>>
>> That said, I do not see how the EarlyOOM heuristic, which allows, depending
>> on the exact settings, something like 80-90% of swap to be used IN ADDITION
>> to 90+% RAM (and will only start doing anything if BOTH RAM and swap are
>> full) can prevent thrashing in any reliable way. My thrashing scenarios have
>> had much less swap than that used. (I have twice as much swap than RAM, so
>> when the EarlyOOM heuristics trigger, my programs are already trying to use
>> almost 3 times as much RAM as is actually available!)
>>
>
> I think the problem is that you are using way too much swap for modern
> systems. The reasons for swap being 2x to 4x real memory was a 1980's
> solution when big RAM systems had 64 MB of ram but a server might need
> 128MB for certain tasks. This was 'reasonable' because the processors
> were slow but could still walk through 128 MB of space 'pretty' fast.
> As RAM got larger this 2x became 'cargo-culted' in various
> documentation and was still reasonable while processor speed went up.
> You could still have a system with 512MB of ram and walk through 1024
> to 2048 GB of swap in similar times as the 128 MB.
Also affected by the way some UNIXes handled commit and fork (the things Linux
heuristic overcommit was designed to avoid needing excess swap for). In the
best case, you needed as much swap as RAM, so that a full size process (64 MB
in your 1980s system) could allocate an extra 64 MB to fork; in the worst case,
things were using that swap and you needed some multiple just for commit
accounting.
IIRC, there were also some systems where the available space for committing was
set to the size of swap - hence the need for 2x RAM. One for matching your RAM
and allowing you to use it, one for the space consumed during a fork.
Linux's use of overcommit means that this isn't an issue for Fedora, though.
--
Simon
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
