нашёл команду nice

См. также Контрольная группа (Linux): cgoups.

zvezdochiot

Добавил игру в эту группу, выделил всю память, игра вместо 2ГБ есть 1ГБ и тормозит.

:-) https://www.kernel.org/doc/Documentation/cgroup-v2.txt

https://docs.fedoraproject.org/ru-RU/Fedora/17/html/Resource_Management_Guide...

fearOfSociety

В силу того что я новичок, ничего нового в этих ссылках я для себя не узнал. По инструкции добавил pid процесса в группу, выделил максимальное кол-во памяти (2GB), но игра все равно использует 1GB и зависает

Как мне выделить всю оперативную память (2ГБ) под конкретное приложение/процесс?

Любое приложение и так имеет возможность использовать всю доступную память. Если не использует, значит не хочет, и командами ты его это делать не заставишь. В любом случае недоиспользованная приложениями память используется для кеширования данных с диска. Так что она всё равно не простаивает.

http://www.linuxatemyram.ru/

https://wiki.archlinux.org/index.php/Swap_(Русский) подключи swap и засунь все ненужное в него

почему зависает?

но игра

Что за игра? Через «что» работает?

но только диск со swap будет загружен, если игра на том-же диске опять не поиграешь

Потому что линуксом невозможно пользоваться на компьютерах с небольшим количеством оперативки.

https://bugzilla.kernel.org/show_bug.cgi?id=196729

zvezdochiot

cs source. Не стимовская, а загруженная от сюда https://counter-strike.com.ua/games-linux/cs-linux/1557-counter-strike-source...

экий Вы, сударь, простофиля.
не устал тупизной сиять?

было такое что мишь и ctrlaltfn тормозил и долго думал, что-то компилял, 8GB оперативка и почти столькоже свопа занято было, т.к. hdd молотил жестко, я не задумывался, подумал тормодиск не замена оперативке, через неделю отпустило, и вроде без ошибок получилось.

так что это? регрес-баг, а не тормодиск?

Please refer also to this bug report. It is the same problem and has existed for eleven (11!) years if one can believe that.

я был плохим полным хомяком тогда

Да, Windows работает гораздо лучше на аналогичных конфигурациях. У RussianNeuroMancer есть планшет с 1 ГБ оперативки, и на нем линукс почти не работает.

Кое-как работает, но если повыкидывать всякое из автозагрузки и включить максимальный vm.swappiness. Бисект между 4.11 и 4.12 всё ещё в процессе, буквально два-три шага осталось, но отвлёкся на другие дела. Постараюсь вернуться к этому вопросу летом.

У меня слабый компьютер
Линуксом невозможно пользоваться на компьютерах с небольшим количеством оперативки

2 Гб разве это небольшое количество? Я кучу софта открываю.

Regression since 4.10.x

В Ubuntu 16.04 - 4.4, если ставил с 16.04 или 16.04.1.

Э, ну нет. blkio контроллер применяется и к свопингу (это тоже i/o).
Можно без проблем с помощью cgroups удушить и поставить раком процесс, безудержно жрущий память, вместо того, чтобы ставить раком систему.

Тут недавно новость была про очередной бессмысленный и беспощадный улучшайзер OOM,
так вот старый сниппет

#include <stdio.h>
#include <stdlib.h>

#define MEGABYTE 1024*1024

int main(int argc, char *argv[])
{
	void *memblock = NULL;
	int count = 0;

	while (1)
	{
		memblock = malloc(MEGABYTE);
		if (!memblock) {
			printf("\nOut of memory but no OOM in sight after %d MB\n", ++count);
			break;
		}
		memset(memblock, 1, MEGABYTE);
		printf("\rHogged %d MB", ++count);
		fflush(stdout);  // prevent cursor jumping
	}

	exit(0);
}

Здорово, конечно, но на моем компьютере с 8 ГБ RAM и SSD запуск виртуалки при запущенном Firefox, при достаточном количестве оперативной памяти, полностью кладёт юзерспейс на десятки минут (даже мышка не двигается), а на этом же компьютере, но с 2 ГБ оперативки, открытие 10 вкладок в браузере приводит примерно к тому же самому, только чуть слабее.

И неважно, со включенным свопом, или без. Дело не в свопе, а в трешинге, похоже. Значительно улучшил ситуацию, установив:

vm.swappiness=100
vm.watermark_scale_factor=200

На Windows 10 я могу запустить две виртуалки и браузер, всё будет подтормаживать (как и должно при такой нагрузке), но мышка не зависнет, программы продолжат переключаться, графика не будет тормозить.

Говорят ещё min_free_kbytes поднимать помогает вплоть до сотен мегабайт.

Не помогает, пробовал, даже хуже становится.

Почему это не делается из коробки по-дефолту и зачем есть возможгсть не делать это, а ставить систему раком, причём как раз по-умолчанию?

Потому что это не решение, а обход проблемы: где-то что-то сломали, а эти настройки помогают сгладить поломку, но не устранить её.

полностью кладёт юзерспейс

И у меня без групп ровно такой же локап UI. Хотя не на 10, а минуты на три, пока не придёт лесник.
Мой месседж в том, что простейшая конфигурация cgroups решает эти проблемы.

В какой-то степени верно, что это заплатка.
Но поскольку средствами ядра, костыльность решения не очень высока.

KISS же. Потом придётся выслушивать в багтрекере вопросы, почему софтина не может сожрать больше ~80% памяти и начинает свопиться.
За примером далеко идти не надо, он в оппосте есть.


А вообще я за memory cgroups в дистрибутивах по дефолту.
У нас тут недавно инстанс с AWS Linux словил хардлок.
Не рассосалось ни через 10 минут, ни через 10 часов.

Повесился наглухо, оставив предсмертную записку с отчаянным трешингом i/o.

я за memory cgroups в дистрибутивах по дефолту

Хотелось бы услышать конкретику, что предлагаешь.

Не рассосалось ни через 10 минут, ни через 10 часов.

Повесился наглухо, оставив предсмертную записку с отчаянным трешингом i/o.

А могли бы этого избежать, если б применяли патч https://github.com/hakavlad/le9-patch

Вот мой шаблон, который при загрузке заполняется жёсткими лимитами на память:

group anyprocess {
  cpu {
      cpu.shares="100";
  }
  blkio {
      blkio.weight="100";
  }
  memory {
      # RAM max anyprocess
      memory.limit_in_bytes="{anyprocess.memory.limit_in_bytes}";
      # RAM + SWAP
      # memory.memsw.limit_in_bytes="8G";
  }
}


group realtime {
  cpu {
      cpu.shares="1000";
  }
  blkio {
      blkio.weight="1000";
  }
}


group avoidswap {
  memory {
      # Avoid swapping out sensitive data
      memory.swappiness=0;
  }
}


group system {
  cpu {
      cpu.shares="500";
  }
  blkio {
      blkio.weight="500";
  }
}


group desktop {
  cpu {
      cpu.shares="399";
  }
  blkio {
      blkio.weight="390";
  }
}


group idle {
  perm {
      admin {
          uid = root;
          gid = root;
      }
      task {
          uid = aidaho;
          gid = users;
      }
  }
  cpu {
      cpu.shares="1";
  }
  memory {
      # RAM max idle
      memory.limit_in_bytes="{idle.memory.limit_in_bytes}";
      # RAM + SWAP
      # memory.memsw.limit_in_bytes="8G";
  }
  blkio {
      blkio.weight="10";
  }
}

Некропостеры, что ж вы творите =)

По патчу — почему он до сих пор не в апстриме?

Недостаточно обобщенный? Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?

Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?

Это. Корпоративные админы админят серверные парки сидя за маками.

почему он до сих пор не в апстриме

Никто этот патч особо не продвигал. Но мы-то начнем. Вот, в pf-kernel уже принято.

Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?

Сервера тоже страдают:

«The traditional Linux OOM killer works fine in some cases, but in others it kicks in too late, resulting in the system entering a livelock for an indeterminate period.»

https://engineering.fb.com/production-engineering/oomd/

Какое поведение ожидается, когда:

• Своп есть.
• Своп есть, но в zram.

?

1. Со свопом на медленном диске в прцессе активного своппинга эффект не заметен. При исчерпании свопа быстрее придет киллер.

2. Своп на zram - лагов нет. https://www.youtube.com/watch?v=d4Sc80TMEtA - толстенькая компиляция

https://www.youtube.com/watch?v=c5bAOJkX_uc игра со стрессом

Без свопа: зависания нет, киллер приходит (ядерный, а не юзерспейсный) https://youtu.be/iU3ikgNgp3M

ядерный, а не юзерспейсный

Вот это мне больше всего в этом патче нравится.

А мне наоборот. Убивать можно и юзерспейсными - более гибко и безопасно, через SIGTERM и с тонкой приоретизацией выбора жертвый, опционально с гуи уведомлением.

А вот что нового дает патч - это снижение IO при своппинге - при стрессах и активном своппинге гуй еще жив и здравствует.

Есть ли эквивалент для cgroup2? Эпоха v1 уходит в небытие.

Я бы на десктопе вообще не убивал OOM-ом процессы - только в самом крайнем случае. А все некритичные для базовой работы системы приложения можно загонять в своп вплоть до полной остановки их работы, если необходимо. Главное, чтобы сохранялась возможность оператору отдавать команды системе. Он сам разберется, что убить в первую очередь, лучше любого демона.

Но это для опытных пользователей.

Если пользователь опыта администрирования не имеет, то лучше OOM.

через SIGTERM

Ты уверен, что чем-то поможет SIGTERM, если процесс не имеет возможности на него оперативно отреагировать? Всё равно следом нужен SIGKILL.

опционально с гуи уведомлением

Ну это наверное и к ядру прикрутить можно. Там же должен быть какой-то ивент на приход OOM? Для целей логгирования и оперативного уведомления на серверах.

где-то что-то сломали, а эти настройки помогают сгладить поломку, но не устранить её

Сломали защиту файловых страниц при нехватке памяти. К счастью, решение найдено: https://github.com/hakavlad/le9-patch

Юзеры на десктопе обычно предпочитают низкие задержки. Система должна оставаться управляемой несмотря ни на что. Лучше потерять вкладку, чем повиснуть на неопределенный срок. О чем и заявили создатели патча:

We also see very slow browser tab switching under low memory. Instead of an unresponsive system, we’d really like the kernel to OOM as soon as it starts to thrash. If it can’t keep the working set in memory, then OOM. Losing one of many tabs is a better behaviour for the user than an unresponsive system.

Ты уверен, что чем-то поможет SIGTERM

Большинство таки реагируют быстро. Конечно, нет гарантий быстрой реакции всех процессов, но для части случаев это лучшее решение. При отстутствии ответа на SIGTERM отправляется SIGKILL.

Ну это наверное и к ядру прикрутить можно.

Но никто это делать, конечно, не будет.

Со свопом на медленном диске в прцессе активного своппинга эффект не заметен. При исчерпании свопа быстрее придет киллер.

А вот что нового дает патч - это снижение IO при своппинге - при стрессах и активном своппинге гуй еще жив и здравствует.

Так, пытаюсь сообразить, что к чему.

Список свободных страниц истощается, и на каком-то этапе система прекращает освобождение файловых страниц.

Если есть своп, начинается исключительно выгрузка анонимной памяти. Если нет, приходит OOM.

Так как расход памяти у жирных процессов идёт в основном на анонимную память, такой режим работы не дружественен к ним и дружественен к процессам, имеющий малый объем анонимной памяти.

Из-за этого отзывчивость улучшается.

Вроде так получается.

Это прям хорошо. Осталось прикрутить еще возможность динамически управлять защитой рабочего набора per process, и будет универсальное решение.

Но никто это делать, конечно, не будет.

У ядра нет механизма уведомления на этот счёт? Я просто не в курсе.

Написать юзерспейсный-то демон не дофига делов.

Когда я тестировал эти патчи, они больше вредили.

возможность динамически управлять защитой рабочего набора per process

per cgroup уже в федоре по дефолту https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

Юзеры на десктопе обычно предпочитают низкие задержки. Система должна оставаться управляемой несмотря ни на что.

Она и будет управляемой, если у тебя висит только браузер, но не оболочка рабочего стола. Я об этом говорю уже который месяц.

Лучше потерять вкладку, чем повиснуть на неопределенный срок. О чем и заявили создатели патча

Для мобилки решение оптимально. Но я не про мобилки.

Лучше потерять вкладку

Пользователю лучше знать, что ему потерять. Вкладку в браузере или протёкший gimp.

Сейчас все исправлено. Порог держится побочки изучены. Найдены способы устранения побочек. Мягкое и жесткое резервирование на выбор.

Бывают проблемы со встройкуами интел, но костыль для тлечения описан в ридми.

Разные патчи протестированы.

Читай всю ветку - отсюда и до конца Linux 5.10 (комментарий) - разговор с post-factum

Уже применяется в pf-kernel.

Есть copr для федоры, ребята живут с этим ядром https://copr.fedorainfracloud.org/coprs/atim/kernel-futex/ и довольны, отмечают отличный эффект https://youtu.be/d4Sc80TMEtA

Пользователю лучше знать

Сейчас выбора нет - гуй мерзнет, зачастую юзеры делают хардресет. Патч дает выбор - зависать или иметь низкие задержки.

Это уже хорошо. Нужно двигаться дальше.