Forum Debian Users Gang

Za małe wartości w swappiness też są niedobre, bo programy ładując do pamięci dane podczas uruchamiania, czasem się do części z nich w ogóle nie odwołują. Więc te dane są potrzebne jedynie podczas startu programu i sobie leżą nieużywane w RAM marnując ją. A tak to system je sobie zrzuci za jakiś czas do swap i masz przez to więcej miejsca na nowe programiki w RAM.

SWAP nie jest po to by system se dał radę jak mu zabraknie pamięci RAM. :] System operuje tylko i wyłącznie na RAM i jak masz zapełniony RAM, to SWAP ci nie pomoże w niczym. Bo jak będziesz chciał podnieść okienko firefox'a, to zanim je zobaczysz, to system dane ze SWAP będzie musiał przenieść do RAM, a dopiero potem je może odczytać. No a jak masz RAM zapełniony, to jakieś dane muszą zostać zrzucone do SWAP no i zaczyna się zabawa i system nie robi nic innego tylko przerzuca dane z RAM do SWAP i ze SWAP do RAM no i wpada w swapstorm i jak nie pozamykasz aplikacji, to ci się albo system powiesi albo stanie się tak niesamowicie wolny, że go tak czy inaczej zresetujesz. xD

Podałem ci przykład jak się zachowuje system w przypadku wyczerpania pamięci RAM, gdy masz SWAP. xD Choć wszystko zależy od indywidualnego wykorzystania systemu.

Co do samego OOM-killer'a, to jego zachowanie można skonfigurować przez sysctl — są dwie opcje: 1) ubijaj ten proces, który doprowadził do OOM, 2) ubijaj ten proces, który w sytuacji OOM zjada najwięcej zasobów, w tym przypadku pewnie poleciałby firefox, lub jeden z jego procesów, bo ten killer może faworyzować zabijanie procesów głównych lub potomnych. Dodatkowo, każdy proces w systemie może podać wskazówki dla OOM-killer'a i poinformować go jak ma traktować ten konkretny proces:

3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score
--------------------------------------------------------------------------------

These file can be used to adjust the badness heuristic used to select which
process gets killed in out of memory conditions.

The badness heuristic assigns a value to each candidate task ranging from 0
(never kill) to 1000 (always kill) to determine which process is targeted.  The
units are roughly a proportion along that range of allowed memory the process
may allocate from based on an estimation of its current memory and swap use.
For example, if a task is using all allowed memory, its badness score will be
1000.  If it is using half of its allowed memory, its score will be 500.

There is an additional factor included in the badness score: the current memory
and swap usage is discounted by 3% for root processes.

The amount of "allowed" memory depends on the context in which the oom killer
was called.  If it is due to the memory assigned to the allocating task's cpuset
being exhausted, the allowed memory represents the set of mems assigned to that
cpuset.  If it is due to a mempolicy's node(s) being exhausted, the allowed
memory represents the set of mempolicy nodes.  If it is due to a memory
limit (or swap limit) being reached, the allowed memory is that configured
limit.  Finally, if it is due to the entire system being out of memory, the
allowed memory represents all allocatable resources.

The value of /proc/<pid>/oom_score_adj is added to the badness score before it
is used to determine which task to kill.  Acceptable values range from -1000
(OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX).  This allows userspace to
polarize the preference for oom killing either by always preferring a certain
task or completely disabling it.  The lowest possible value, -1000, is
equivalent to disabling oom killing entirely for that task since it will always
report a badness score of 0.

Consequently, it is very simple for userspace to define the amount of memory to
consider for each task.  Setting a /proc/<pid>/oom_score_adj value of +500, for
example, is roughly equivalent to allowing the remainder of tasks sharing the
same system, cpuset, mempolicy, or memory controller resources to use at least
50% more memory.  A value of -500, on the other hand, would be roughly
equivalent to discounting 50% of the task's allowed memory from being considered
as scoring against the task.

For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also
be used to tune the badness score.  Its acceptable values range from -16
(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17
(OOM_DISABLE) to disable oom killing entirely for that task.  Its value is
scaled linearly with /proc/<pid>/oom_score_adj.

The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
requires CAP_SYS_RESOURCE.

Caveat: when a parent task is selected, the oom killer will sacrifice any first
generation children with separate address spaces instead, if possible.  This
avoids servers and important system daemons from being killed and loses the
minimal amount of work.


3.2 /proc/<pid>/oom_score - Display current oom-killer score
-------------------------------------------------------------

This file can be used to check the current score used by the oom-killer is for
any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which
process should be killed in an out-of-memory situation.

Instalacja systemu w RAM nie daje takiego kopa, jak się niektórym wydaje.

Jeżeli masz np 25GB partycję root i 32GB ram, to wystarczy nie wyłączać kompa,
a po jakimś czasie wszystko, co było uruchamiane jest w pamięci RAM zbuforowane.

Dlatego używam s2ram, nie wyłączam kompa,99% restartów to u mnie aktualizacja kernela.

Jest też kilka opcji ładowania programów i bibliotek do ram przy starcie jak np e4rat-preload.

W Linuxie sporo optymalizacji dodają Developerzy kernela, także niewiele już można poprawić we własnym zakresie, poza gimnastykami na netbookach z małymi bateriami czy starych kompach z malutkim prockiem czy RAM.

Pozdro

Ostatnio edytowany przez Jacekalex (2019-06-13 16:42:51)