LINUX.ORG.RU
ФорумTalks

Умом Linux не понять, аршином общим не измерить

 , ,


0

1

Итак, недавно я сделал небольшой апгрейд — купил комплект памяти от HyperX на 16 гигов и Samsung 870 Evo. Ради эксперимента накатил на SSD никсось (пока вроде бы все нравится). По привычке выставил vm.overcommit_memory = 2. Включил zram. А потом обнаружил, что система практически моментально прибивает tail /dev/zero. Никаких юзерспейсных киллеров в списке запускаемых юнитов не обнаружил. Что произошло?

★☆

Последнее исправление: hateWin (всего исправлений: 1)

uname -a
Linux nixos 5.10.60 #1-NixOS SMP Wed Aug 18 06:59:19 UTC 2021 x86_64 GNU/Linux
hateWin ★☆
() автор топика

Дискового свапа нет. Но и раньше его не было! Но система вела себя по другому.

hateWin ★☆
() автор топика
Ответ на: комментарий от TheNewDragon

Дык, наоборот же. Он как раз прямой. Или не он? Просто конфигурация железа поменялась?

hateWin ★☆
() автор топика

купил комплект памяти от HyperX на 16 гигов

Ты память заменил или добавил? Это очень важно. Если добавил, то там неведомая хрень может быть с таймингами, несоотвтствие частот.

xwicked ★★☆
()
Ответ на: комментарий от xwicked

Заменил. Куда мне добавлять? Всего два слота.

hateWin ★☆
() автор топика
Ответ на: комментарий от t184256

Почему же он раньше так странно работал? Я же точно помню, что не делал свап-раздел или файл. memory_overcommit=2, конечно, помогало, но все равно киллер приходил с небольшим запозданием. Индикатор нагрузки на диск начинал мигать. Можно было заметить подлагивания.

hateWin ★☆
() автор топика
Последнее исправление: hateWin (всего исправлений: 1)

Может там теперь резервируется место под дисковый кэш? Раньше оно приводило к тому что все щагруженные в память юзерские страницы с дисков выгружались и выполнение кода в любом юзерском процессе требовало сначала считать страницу повторно в память,отчего всё тормозило.
ну и собственно ssd уменьшает задержку

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

ну и собственно ssd уменьшает задержку

Так индикатор нагрузки на жесткий диск даже не загорается.

hateWin ★☆
() автор топика

А сколько памяти было раньше? Использовался ли swap? Какие значения были у vm.overcommit_memory и vm.overcommit_ratio? Использовался ли zsram? Какие ядро раньше было?

Сколько сейчас в vm.overcommit_ratio? Точно система убила tail /dev/zero, а не он сам упал из-за невозможности выделить память?

kmeaw ★★★
()
Ответ на: комментарий от kmeaw
tail /dev/zero 
tail: memory exhausted

Раньше было 8 гигабайт, теперь 16. Дисковый свап был выключен, ядро пробовал в том числе и 5.10.

hateWin ★☆
() автор топика

zsram

zs

Это как-то связано с «Зеленым слоником»?

hakavlad ★★★
()

vm.overcommit_memory = 2

практически моментально прибивает tail /dev/zero

По умолчанию overcommit_ratio=50 - очень низкое значение.

hakavlad ★★★
()
Ответ на: комментарий от hateWin

Дискового свапа нет.

Вот и разгадка. 8 гиг - это будет общесистемный лимит виртуальной памяти.

hakavlad ★★★
()
Ответ на: комментарий от TheNewDragon

Может он кривой.

Нет, это ОП выстрелил себе в ногу, установив overcommit=2 без свопа, не увеличив предварительно overcommit_ratio.

hakavlad ★★★
()
Ответ на: комментарий от t184256

Это не не киллер отработал, это tail упал с ошибкой cannot allocate memory. Киллер не был задействован. Это были последствия ограничения оверкоммита.

hakavlad ★★★
()
Ответ на: комментарий от hateWin

tail: memory exhausted

Вот это оно и есть - невозможно выделить память. Увеличь overcommit ratio хотя бы до 500.

hakavlad ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.