Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Сообщения

[Сортировка по времени | RSS]

	180. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от пох. (?), 06-Авг-19, 22:36
	> но выжирание памяти не ведет к тормозам приведет. А может и к зависанию, если в этом бутерброде есть zfs. Просто надо выжрать ее менее ди6ильным способом. Помочь?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	198. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от анонн (ok), 06-Авг-19, 23:21
	>> но выжирание памяти не ведет к тормозам > приведет. Ну вот описаную ситуацию > Выключаем поддержку swap (sudo swapoff -a) > Запускаем любой веб браузер, например, Chrome/Chromium или/и Firefox >  Начинаем открывать вкладки с сайтами и смотрим как уменьшается объём свободной памяти > Как только возникает ситуация, что новая вкладка требует больше оперативной памяти, чем доступно, система практически полностью зависает как-то не наблюдал. Даже при дефолте vm.pageout_oom_seq - тупит только пару секунд. > А может и к зависанию, если в этом бутерброде есть zfs. О да, использовать для настольной системы оверижЫнирнутого монстра с собственным, "правильным" менеджером ядерной памяти, это правильно! Правда, под пингвином оно на вид тоже не сильно по другому себя ведет: https://github.com/zfsonlinux/zfs/issues/3677 > rsync causes ZoL to use all memory until system crashes STILL :( https://github.com/zfsonlinux/zfs/issues?utf8=%E2%... > Просто надо выжрать ее менее ди6ильным способом. > Помочь? А давай!
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от пох. (?), 07-Авг-19, 12:51
	> Ну вот описаную ситуацию ну потому что он все неправильно делает. buffer cache настал каюк, да, а про то что в ядре полно мусоросборочных тредов, запускающихся по таймеру - не подумал. > А давай! ну подсказка - см выше. Собственно, во времена ядер 2.0 и очень медленных дисков был прекрасный способ посмотреть на ядерные дидлоки - cd /usr/src/linux ; make -j zImage (тут тебе и кэши, и память, и своп, и отсутствие у cpu времени на всякую периодическую мусоросборочную ерунду ;-) Иногда оно раньше успевало навернуться по нехватке памяти, а иногда нет. Сейчас такой эффект уже так просто не получишь, но если стараться - то тоже можно. Собственно, на ту же самую проблему я в 17м году нарвался во фре, только там хватило -j4 + zfs на медленной системе (сборка libllvm очень, _очень_ cpu intensive процедура) Причем дидлок-то не в zfs (точнее, и в ней тоже был, но его, с великим трудом, удалось, вроде бы, извести), она просто позволяла лучше рассмотреть его наличие. С тем же успехом можно было сожрать ту же память сетевыми буферами, просто воспроизводить в разы геморройнее. Механизм все тот же - отожрать cpu, иметь в системе приличное количество свободной но не "свободной с ее точки зрения" памяти (чтобы in-kernel тредам было чем заняться, но они не смогли завершиться достаточно быстро, как в тех ситуациях, которые предполагали и которые проверяли авторы) с максимальной фрагментацией (привет, abd!) и резко этой памяти захотеть.
	Ответить | Правка | Наверх | Cообщить модератору

	451. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от анонн (ok), 07-Авг-19, 15:53
	>> Ну вот описаную ситуацию > ну потому что он все неправильно делает. > buffer cache настал каюк, да, а про то что в ядре полно > мусоросборочных тредов, запускающихся по таймеру - не подумал. Только описанная ситуация вполне подходит под типичный юзкейз - открыл в дополнение жрущей виртуалочке браузер почитать опеннет - и на тебе. > Собственно, на ту же самую проблему я в 17м году нарвался во > фре, только там хватило -j4 + zfs на медленной системе (сборка > libllvm очень, _очень_ cpu intensive процедура) > Причем дидлок-то не в zfs (точнее, и в ней тоже был, но > его, с великим трудом, удалось, вроде бы, извести), она просто позволяла > лучше рассмотреть его наличие. С тем же успехом можно было сожрать > ту же память сетевыми буферами, просто воспроизводить в разы геморройнее. Собственно, я это воспроизвожу где-то раз в месяц на старенькой системе 2010года с двухядерным ЦПУ и 8ГБ ОЗУ. Там же, до недавнего разжирения еср-лисы, собирал ее c "правильными" опциями. C WRKDIRPREFIX на 5ГБ tmpfs, без свопа, с отрытым браузером, почтовиком,  и прочим. И llvm включительно 8.0 собирал в том же tmpfs. На последних версиях (то ли лисы, толи llvm, то ли обоих), под конец сборки для линковки приходилось закрывать жирную лису и вроде бы даже увеличивать tmpfs, иначе линковка завершалась с "оом". В общем, загрузка ЦПУ и ОЗУ, подходящая под описание и совсем не синтетикой - но без чудо-ZFS. А, еще, пару раз, почитав опеннет, пробовал запустить 4x-6x "python -c 'while True:pass' - правда, это больше на посмотреть разницу между дефолтным kern.sched.interact=30 и 10 в отзывчивости GUI. Никаких фризов и дедлоков не наблюдал. О своем отношении к ZFS еще раз писать не буду - тут вспоминается пословица про крейсер и небольшую, но гордую страну. В итоге и крейсер прос^Hржавел вконец и инфраструктура страны обветшала и жители большей частью слиняли. Разъясняю особо: "ненаблюдал" != "их нет, вы все врети". Но есть разница - наблюдать при достаточно типичном и легковоспроизводимом юзкейзе или же если для наблюдения придется натянуть лыжи, противогаз и забраться в гамак. А "дедлок" из-за нехватки памяти воспроизводится довольно просто: 1. не ограничивать vm.kmem_size размером (ОЗУ - пара сотен МБ) 2. отключить своп (впрочем, включенный вряд ли сильно поможет) 3. примонтировать tmpfs или MD с размерами >= ОЗУ (размер придется задать ручками, по умолчанию максимальным размером будет половина свободной памяти) 4. заполнить его записью чего угодно наблюдать за тем, как ООМ будет прибивать все нафиг, в том числе и локальные или удаленные сессии. Однако, если немного повезло, то сессию вместе с "заполнителем" отстрелило достаточно рано, чтобы осталось памяти на ssh ffo@bar 'cmd' для починки. Еще не раз видел, как при сильной фрагментации памяти (привет современные браузеры после пары дней работы), т.е. > в системе приличное количество  свободной но не "свободной с ее точки зрения" памяти (чтобы in-kernel тредам было чем заняться, но они не смогли завершиться достаточно быстро pagedaemon начинает неплохо отжирать CPU без какого либо эффекта, а вот оом киллер как раз не спешит - ведь памяти достаточно. Лечится только перезапуском браузера. Но вот чтобы еще и было особым образом отожрано все CPU (и это, повторю, на весьма средней даже по "консумерским" меркам еще 10-летней давности, системе) и наступил этот вот описанный "белый и пушистый" deadlock - ни разу не совпало. Т.е. опять или достаточно специфичная ситуевина или же вообще, очередные > (привет, abd!) "приветы" из реализации ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	494. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от пох. (?), 07-Авг-19, 22:22
	>>> Ну вот описаную ситуацию >> ну потому что он все неправильно делает. >> buffer cache настал каюк, да, а про то что в ядре полно >> мусоросборочных тредов, запускающихся по таймеру - не подумал. > Только описанная ситуация вполне подходит под типичный юзкейз - открыл в дополнение > жрущей виртуалочке браузер почитать опеннет - и на тебе. а если не браузер а разбиралку фоточек с отпуска? Отож. > Собственно, я это воспроизвожу где-то раз в месяц на старенькой системе 2010года у меня воспроизводилось 100%, чем и было ценно. Но когда дошли руки до тестов - я уже получил "фирма в ваших услугах более не нуждается" (откуда, собственно, и взялись два месяца на подобную деятельность вместо работы), а выкупать тот ноут по негуманной остаточной цене не входило в мои планы. https://imgur.com/rBBJwOU это -j3 - на больше там памяти не хватило бы. Так что успели только убедиться, что отключение arc compression и/или abd scatter проблему загоняет под ковер - когда каждая итерация занимает несколько часов, когда ноутом пользоваться толком нельзя, два месяца - ни о чем. Но дохло оно не в abd, подчеркиваю - оно дохло вполне себе в ядерном сборщике мусора. > О своем отношении к ZFS еще раз писать не буду - тут говорю же - на ней просто удобно тестировать. Так устроен zone manager. В ядре полно других zones, где сперва может застрять пол-гига, а потом очень невовремя разбудить какой-нибудь тред, который полезет их перебирать мелкими шмотками с глобальным локом (или, хуже - с ошибкой в глобальном локе - что скорее всего и происходит) именно когда и памяти не хватает, и ядер свободных нет. > - наблюдать при достаточно типичном и легковоспроизводимом юзкейзе или же если > для наблюдения придется натянуть лыжи, противогаз и забраться в гамак. владельцам раздающих cdn ничуть не веселее от того, что это неудобно воспроизвести (там такая же фигня в зоне для jumbo_mbuf). > наблюдать за тем, как ООМ будет прибивать все нафиг, в том числе > и локальные или удаленные сессии. так это не дедлок, это просто кончилась память. Вот на картинке - там он. Мертвый. При дофига свободных ресурсов. > pagedaemon начинает неплохо отжирать CPU без какого либо эффекта, а вот оом он бегает по куче сложных структур, перебирая странички по 4k (привет, линукс) - которых в гигабайте как бе 260000 - и, не найдя ничего ненужного, начинает снова. > "приветы" из реализации ZFS. из реализации любой in-kernel памяти.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема