Исходное сообщение
"Ядро Linux не может мягко обрабатывать ситуации с нехваткой ..." Отправлено Аноним, 13-Авг-19 07:21
Какие же фейсбуковцы *********ы, ****** просто. >oomd uses about 6% CPU whith desktop.json and --interval 1. >Is it OK? >We see this internally too. Something like 4.5% of a core all the time. When we profiled it we saw most of the cost coming from walking/reading cgroupfs. https://github.com/facebookincubator/oomd/issues/79 >oomd fails to see the problem if SwapTotal=0 and MemAvailable=0 >I ran memory hog, and at the end system hangs, oomd doesn't kill anything. >PSI based oom killing doesn't work well without swap. Without swap, the system runs out of physical memory too fast and enter the "death spiral" before oomd has time to react. >Closing b/c this will be a wontfix. https://github.com/facebookincubator/oomd/issues/80 >oomd works and kills memory hogs (and innocent processes too, seems like oomd kills all processes in memhog.scope, not only fattest process, it is not good for desktop) >Yeah that's by design. The smallest granularity oomd will operate on is a cgroup. Doing per-process is kind of a mess, especially when multiple teams own different services on a system. It's much easier to delegate a cgroup tree than to try and manage individual processes everywhere. https://github.com/facebookincubator/oomd/issues/61

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Какие же фейсбуковцы *********ы, ****** просто. >>oomd uses about 6% CPU whith desktop.json and --interval 1. >>Is it OK? >>We see this internally too. Something like 4.5% of a core all the time. When we profiled it we saw most of the cost coming from walking/reading cgroupfs. > https://github.com/facebookincubator/oomd/issues/79 >>oomd fails to see the problem if SwapTotal=0 and MemAvailable=0 >>I ran memory hog, and at the end system hangs, oomd doesn't kill anything. >>PSI based oom killing doesn't work well without swap. Without swap, the system runs out of physical memory too fast and enter the "death spiral" before oomd has time to react. >>Closing b/c this will be a wontfix. > https://github.com/facebookincubator/oomd/issues/80 >>oomd works and kills memory hogs (and innocent processes too, seems like oomd kills all processes in memhog.scope, not only fattest process, it is not good for desktop) >>Yeah that's by design. The smallest granularity oomd will operate on is a cgroup. Doing per-process is kind of a mess, especially when multiple teams own different services on a system. It's much easier to delegate a cgroup tree than to try and manage individual processes everywhere. > https://github.com/facebookincubator/oomd/issues/61
	Введите код, изображенный на картинке: