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

Сообщения

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

42. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+11 +/–
Сообщение от анонн (ok), 06-Авг-19, 19:21
> -  Выключаем поддержку swap (sudo swapoff -a) > -  Запускаем любой веб браузер, например, Chrome/Chromium или/и Firefox > -  Начинаем открывать вкладки с сайтами и смотрим как уменьшается объём > свободной памяти Перезагружаться мне влом, но: % config -x /boot/kernel/kernel|grep SWAP                                       options    NO_SWAPPING % more /etc/sysctl.conf vm.disable_swapspace_pageouts=1 vm.pageout_oom_seq=4 kern.sched.preempt_thresh=224 # kern.sched.interact=10 % /usr/bin/time -l  python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' time: command terminated abnormally         9,80 real         0,80 user         3,91 sys    6145052  maximum resident set size          3  average shared memory size         10  average unshared data size        116  average unshared stack size    1532799  page reclaims         13  page faults          0  swaps         13  block input operations          0  block output operations          0  messages sent          0  messages received          0  signals received         21  voluntary context switches        561  involuntary context switches zsh: killed     /usr/bin/time -l python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' Для не понявших: свопа нет от слова совсем (хотя лишний SSD под него, как ни странно, имеется), но выжирание памяти не ведет к тормозам (или тем более зависанию) и заметно лишь по факту закрытия самых жирных приложений. % uname -rs                                                                       FreeBSD 12.0-STABLE Если что - лицензия позволяет утянуть^W позаимств^W вдохновиться, нам не жалко ;) ЗЫ: И да, это тебе, дорогой лап4атый с особым подгоранием и странной тягой к самозванству и изречению "вумностей" из под чужих ников, не про UNIX-сность петросянить и не проприетарными блобиками или игрульками гордиться ))
Ответить | Правка | Наверх | Cообщить модератору

	44. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	–6 +/–
	Сообщение от Аноним (5), 06-Авг-19, 19:25
	Воот! FreeBSD пишется людьми знающими, и тоже профессионалами как и MS Windows, собственно MS даже и берет код из BSD, потому что всем понятно его качество. Это вам не линуксовый "базар"!
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	–2 +/–
	Сообщение от Аноним (5), 06-Авг-19, 19:29
	Жаль только zram нету.
	Ответить | Правка | Наверх | Cообщить модератору

	539. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	–1 +/–
	Сообщение от Аноним (539), 08-Авг-19, 11:43
	Ты имел в виду нормального шедулера и драйверов?
	Ответить | Правка | Наверх | Cообщить модератору

	540. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+1 +/–
	Сообщение от анонн (ok), 08-Авг-19, 11:50
	> Ты имел в виду нормального шедулера Нормального - это как в "новости", чтоб с " система практически полностью зависает. "? Не, нету (( > драйверов? Зато у вас в WSL все есть, мы в курсе.
	Ответить | Правка | Наверх | Cообщить модератору

	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ообщить модератору

	200. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от anono (?), 06-Авг-19, 23:32
	изя залогинься...
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	498. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от Annoynymous (ok), 07-Авг-19, 22:56
	Я чёт не понял юмора… $ /usr/bin/time -v  python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' Traceback (most recent call last):   File "<string>", line 1, in <module>   File "<string>", line 1, in <dictcomp> MemoryError Command exited with non-zero status 1     Command being timed: "python -c {x:str(x)*(x**x**x) for x in range(100000000)}"     User time (seconds): 2.91     System time (seconds): 0.63     Percent of CPU this job got: 99%     Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.55     Average shared text size (kbytes): 0     Average unshared data size (kbytes): 0     Average stack size (kbytes): 0     Average total size (kbytes): 0     Maximum resident set size (kbytes): 3189080     Average resident set size (kbytes): 0     Major (requiring I/O) page faults: 0     Minor (reclaiming a frame) page faults: 796402     Voluntary context switches: 0     Involuntary context switches: 357     Swaps: 0     File system inputs: 0     File system outputs: 0     Socket messages sent: 0     Socket messages received: 0     Signals delivered: 0     Page size (bytes): 4096     Exit status: 1 Свапа в системе отродясь не было, Firefox открыт, никакие приложения закрыты не были… Ты что хотел сказать-то?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	506. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от анонн (ok), 07-Авг-19, 23:45
	> Я чёт не понял юмора… >  Maximum resident set size (kbytes): 3189080 У тебя юмор в том, что или есть лимиты: % ulimit -v 30000 % /usr/bin/time -l  python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' Traceback (most recent call last):   File "<string>", line 1, in <module>   File "<string>", line 1, in <dictcomp> MemoryError         0,06 real         0,05 user         0,00 sys       7664  maximum resident set size          4  average shared memory size или оно просто "не шмагло" зарезервировать непрерывный кусок памяти > 3ГБ. В первом случае профит от лимитов будет только при грамотной организации всего запускаемого барахла (иначе значительная часть ресурсов будет просто простаивать). Во втором, если свободной памяти было значительно поболее 3ГБ, это как бы вообще индикатор проблемы с менеджментом памяти. Из предоставленной информации не понять. Можешь попробовать python -c '{x:str(x)*1024*3 for x in range(1000000000)}' в качестве заполнялки памяти или написать свою. > Свапа в системе отродясь не было, Firefox открыт, никакие приложения закрыты не были… Ты что хотел сказать-то?
	Ответить | Правка | Наверх | Cообщить модератору

	507. "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..."	+/–
	Сообщение от Annoynymous (ok), 08-Авг-19, 00:01
	Попробовал python -c '{x:str(x)*1024*3 for x in range(1000000000)}' htop показал 100% загрузку памяти, затем питон всё равно был убит. Никакого зависания не было. > в качестве заполнялки памяти или написать свою. Я не писатель, я просто попробовал у себя.
	Ответить | Правка | Наверх | Cообщить модератору

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

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