Исходное сообщение
"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!) и резко этой памяти захотеть.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Ну вот описаную ситуацию > ну потому что он все неправильно делает. > buffer cache настал каюк, да, а про то что в ядре полно > мусоросборочных тредов, запускающихся по таймеру - не подумал. >> А давай! > ну подсказка - см выше. Собственно, во времена ядер 2.0 и очень > медленных дисков был прекрасный способ посмотреть на ядерные дидлоки - cd > /usr/src/linux ; make -j zImage > (тут тебе и кэши, и память, и своп, и отсутствие у cpu > времени на всякую периодическую мусоросборочную ерунду ;-) > Иногда оно раньше успевало навернуться по нехватке памяти, а иногда нет. Сейчас > такой эффект уже так просто не получишь, но если стараться - > то тоже можно. > Собственно, на ту же самую проблему я в 17м году нарвался во > фре, только там хватило -j4 + zfs на медленной системе (сборка > libllvm очень, _очень_ cpu intensive процедура) > Причем дидлок-то не в zfs (точнее, и в ней тоже был, но > его, с великим трудом, удалось, вроде бы, извести), она просто позволяла > лучше рассмотреть его наличие. С тем же успехом можно было сожрать > ту же память сетевыми буферами, просто воспроизводить в разы геморройнее. > Механизм все тот же - отожрать cpu, иметь в системе приличное количество > свободной но не "свободной с ее точки зрения" памяти (чтобы in-kernel > тредам было чем заняться, но они не смогли завершиться достаточно быстро, > как в тех ситуациях, которые предполагали и которые проверяли авторы) с > максимальной фрагментацией (привет, abd!) и резко этой памяти захотеть.
	Введите код, изображенный на картинке: