LINUX.ORG.RU
решено ФорумTalks

Почему линукс так лениво сбрасывает dirty память?

 ,


0

2

К примеру распаковал я гигабайтный архив. tar уже завершился. Делаю grep Dirty /proc/meminfo, он мне показывает гигабайт. Ну т.е. по сути всё распакованное лежит в памяти. Запускаю я этот grep в цикле раз в секунду, мониторю. И он секунд 10-15 показывает этот гигабайт, вообще не меняя ничего. Потом «просыпается» и быстро к нулю улетает за пару секунд.

В системе ничего не запущено, нагрузка процессора на нуле. Диск быстрый NVMe SSD. Ну единственное - на luks2 шифровании раздел, но по-моему это не влияет. Ну и гигабайт зашифровать 10 секунд не надо в любом случае.

В моём понимании он dirty память должен сбрасывать моментально, тем более, если системе нечего делать в настоящий момент. Почему моё понимание неверно?

Менять я ничего не хочу, я в курсе, что там есть ручки покрутить такое поведение, я просто хочу понять, почему оно вообще так сделано.

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

★★★★★

может чего там в федоре встроенного есть, не знаю

Вполне возможно, это настройки tlp. Не исключено, что на ноуте он ставится по дефолту.

dogbert ★★★★★ ()

В общем я так понял, что таймаут зависит от /proc/sys/vm/dirty_expire_centisecs у меня там 3000, это 30 секунд, то бишь он примерно раз в 30 секунд будет сбрасывать кеши и это так задумано. Странно сделано на мой взгляд.

Legioner ★★★★★ ()

В моём понимании он dirty память должен сбрасывать моментально, тем более, если системе нечего делать в настоящий момент. Почему моё понимание неверно?

Это оптимизация на уровне файловой системы. Для записи на диск нужно сначала выяснить, куда записывать. Если записывать куда попало, сначала взлетит фрагментация свободного пространства, а потом и фрагментация файлов. Поэтому ФС пытается отложить выделение блоков до последнего момента, чтобы удержать фрагментацию.

i-rinat ★★★★★ ()

dirty память должен сбрасывать моментально

Это как, побайтно? На блочном устройстве?

Может, тебе просто direct I/O нужно где-то, но ты стесняешься?

post-factum ★★★★★ ()
Ответ на: комментарий от i-rinat

На уровне ФС уже всё давно записано, т.к. tar завершил работу, если я сделаю ls, очевидно, все файлы будут на месте. Это именно на уровне блочного устройства.

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

Во-первых лишняя память не тратится. Во-вторых если свет выключат/ядро от чего-нибудь запаникует, то больше данных останется на диске. Второе для меня даже важней.

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

Последующие записи в те же блоки. Представь, что у тебя софтина делает write побайтно, ты на каждый write весь блок сбрасывать будешь?

Чел, ты полжизни назад был заносчивее, но умнее. Ты может не будешь на каждый акт мыслительной активности свои грязные мысли на форум сбрасывать, а таймаут какой-то выставишь?

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

На уровне ФС уже всё давно записано, т.к. tar завершил работу

И че теперь, sync после каждого tar делать? Не, ты делай если хочешь, но пеняй на себя.

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

Те кому надо чтобы в кэше ничего не задерживалось - используют driect I/O. Те, кому надо чтобы данные гарантированно долетали на диск прямо в момент записи - используют fsync/fdatasync или O_SYNC/O_DSYNC. А еще есть data=journal и вообще много всяких механизмов.

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

При чём тут sync. Я тебе про фому, ты мне про ерёму. Не нужен мне sync после каждого tar. Мне нужно, чтобы компьютер работал, а не стоял. Я выполнил tar, данные должны моментально лететь на диск, а не лежать в памяти ещё 15 секунд просто так. Открой винду, посмотри, как там ядро работает. Любая деятельность с диском и сразу идёт запись на диск. Программа завершилась, через несколько секунд завершилась запись на диск, если там что-то объёмное было. Если в этот момент у меня в фоне какая-то СУБД там работает, то бишь более важная задача, без вопросов, пускай грязные страницы ждут, для этого I/O планировщик и нужен, чтобы I/O запросы с разными приоритетами работали в нужном порядке.

В общем ладно, вопрос закрыт, судя по всему кому надо, те настраивают все эти таймауты и соотношения как надо, а по умолчанию там от балды выставлено что-то не особо задумываясь, чтобы было и всё. Хотя это печально, сколько ещё таких параметров в линуксе настроено от балды.

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

данные должны моментально лететь на диск, а не лежать в памяти ещё 15 секунд просто так.

Кому должеы?

Открой винду, посмотри, как там ядро работает.

И давно это у нас винда эталоном стала? )

zemidius ()
Ответ на: комментарий от Legioner

Пока ты не сделал fsync, может быть и не записано. Данные тебе отдаются из кэша. Хочешь убедиться — сделай запись большого файла и рубани питание сразу после завершения tar. А после включения проверь, сколько данных реально можно прочитать из получившегося файла. Есть немалый шанс увидеть файл нулевого размера.

В ext4 и xfs есть эвристики, которые принудительно сбрасывают данные на диск при определённых манипуляциях с файлами, но создание tar-архива эти эвристики, кажется, не задевает.

i-rinat ★★★★★ ()
Ответ на: комментарий от Legioner

данные должны моментально лететь на диск

Добавь в опции монтирования sync. Расскажешь нам тут потом, как всё плохо стало.

i-rinat ★★★★★ ()

Менять я ничего не хочу, я в курсе, что там есть ручки покрутить такое поведение, я просто хочу понять, почему оно вообще так сделано.

Делать нормальные дефолтные параметры в Линуксе хронически не умеют. И это не удивительно, параметры изначально для серверов подстраиваются, а для десктопа Линукс не предназначен. В Android и Chrome OS подозреваю настроено как надо.

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

На уровне ФС уже всё давно записано, т.к. tar завершил работу, если я сделаю ls, очевидно, все файлы будут на месте. Это именно на уровне блочного устройства.

Нет, это банально не так. man page cache.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Legioner

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

А вот тут я согласен.

Обычно рекомендуется подходить к этому с другой стороны — выставлять низкие значения vm.dirty_background_bytes (десятки мегабайт) и опционально vm.dirty_bytes (сотни мегабайт). Но это тоже костыль, а глобально ты прав (хоть и не прав в деталях) — линукс не умеет по-человечески управлять writeback’ом грязных страниц.

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

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

вот то ли дело... ну вы поняли.

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

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

Например, пользователь запустил gcc -o example example.c, что привело к запуску cc1 и появлению временного файла ccUTrpmK.s, запу, затем к запуску as и появлению временного файла ccUTrpmK.o, и, наконец, к запуску collect2 и появлению ожидаемого пользователем файла example. Два из трёх файлов, которые записывались на файловую систему, уже не нужны, и если ядро не начнёт их писать сразу, а немного подождёт, то их не придётся записывать на диск.

Или пользователь запустил zcat foo-0.2.1.diff.gz | patch -p1 поверх уже распакованного foo-0.2.0.tar.gz. В результате из нескольких тысяч файлов половина последовательно изменилась, и драйверу файловой системы нужно обновить mtime. Чтобы не перезаписывать несколько тысяч раз блок диска, где лежат эти иноды, можно немного подождать, и обновить блок только один раз (batching).

Похожий механизм есть и в TCP (Nagle algorithm), и по-умолчанию он тоже включен. Ядро не будет сразу слать в сеть каждый write в сокет на единицы-десятки байт, а чуть-чуть подождёт - вдруг следом за одним write придёт другой, и можно будет отправить их одним сегментом.

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

Спасибо, единственный разумный аргумент за всю тему.

Legioner ★★★★★ ()
dirty_writeback_centisecs

The pdflush writeback daemons will periodically wake up and write `old' data
out to disk.  This tunable expresses the interval between those wakeups, in
100'ths of a second.

Setting this to zero disables periodic writeback altogether.
int13h ★★★★★ ()

Может ты сейчас это распакованное редактировать будешь, откуда ядру знать? Память для того и нужна, чтобы держать там то, что может понадобиться. Оно уже в памяти лежит, чтобы сбросить на диск нужна причина. Например память понадобится для чего-то другого, вот тогда и сбросит.

vlad9486 ()
Ответ на: комментарий от Legioner

Для того ручки тебе и даны. Крути как нравится. У юзеров разные мнения об оптимумах.

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

От того, что данные сбросятся на диск, из памяти они не исчезнут.

Грязные файловые страницы станут чистыми, а чистые уже можно отбросить очень быстро.

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

hakavlad ★★ ()

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

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

Если фура будет ездить на воздухе? Буду, а что? Тем более аналогия кривая. У меня там гигабайт записан. Гигабайт. Это по твоей аналогии груза на 1000 вагонов. И поезда стоят, готовые ехать. Но не едут, расписание раз в месяц.

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

Если фура будет ездить на воздухе?

ДВС и так на воздухе.

Но не едут, расписание раз в месяц.

Ну то измени расписание.

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

Значительно падает скорость записи. На и без того медленных флешках может и в десяток раз уменьшиться, потому что приходится постоянно обновлять FAT. Древние флешки вообще от такого обращения могли придти в негодность; и для это достаточно было один раз на флешку файлы закинуть.

Вместо этого внешние накопители с FAT сейчас обычно монтируют с опцией flush. С этой опцией vfat кеширует запись, пока файл открыт, но сразу сбрасывает на накопитель, как только приложение файл закрывает.

i-rinat ★★★★★ ()
Ответ на: комментарий от Legioner

Мне нужно, чтобы компьютер работал, а не стоял. Я выполнил tar, данные должны моментально лететь на диск, а не лежать в памяти ещё 15 секунд просто так.

Тебе на что-то не хватило памяти? Если нет, то не пофиг-ли когда она будет освобождена? (есть подозрение, что это будет делаться по мере исчерпания свободной памяти).

Мне кажется проблема грязных страниц актуальна только с точки зрения информационной безопасности. Например ключи в грязных страницах (впрочем если они не зануляются при очистке, то и в чистой памяти тоже, если повезет) вполне себе будут извлечены атакой с помощью заморозки плашки памяти... забыл как это праивльно называется. Впрочем тут кейс, требующий физического доступа к оборудованию.

RiseOfDeath ★★★★ ()
Последнее исправление: RiseOfDeath (всего исправлений: 4)
Ответ на: комментарий от RiseOfDeath

Тебе на что-то не хватило памяти? Если нет, то не пофиг-ли когда она будет освобождена? (есть подозрение, что это будет делаться по мере исчерпания свободной памяти).

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

Мне кажется проблема грязных страниц актуальна только с точки зрения информационной безопасности. Например ключи в грязных страницах (впрочем если они не зануляются при очистке, то и в чистой памяти тоже, если повезет) вполне себе будут извлечены атакой с помощью заморозки плашки памяти… забыл как это праивльно называется. Впрочем тут кейс, требующий физического доступа к оборудованию.

Страницы не зануляются (если только памяти достаточно), в этом плане на безопасность никакого влияния нет. Не думаю, что кто-то всерьёз продумывает противодействие такой атаке, слишком много векторов. Вроде в некоторых процессорах есть технология прозрачного шифрования оперативной памяти, я бы в эту сторону смотрел, если такая опасность есть.

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

Не жалко. В масштабах ресурса это абсолютная ерунда.

Legioner ★★★★★ ()

Ядро не знает, каким образом ты будешь работать с распакованными файлами. Может быть, ты их не будешь менять, а, может быть, будешь. Или удалишь эти файлы насовсем. Поэтому оно оптимизирует сброс грязных страниц под некоторого среднего пользователя.

Если параллельно запустить процесс, который активно отъедает память, то сброс грязных страниц ускорится. Сначала они запишутся на диск, а после вообще будут выкинуты из памяти.

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

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

Любая деятельность с диском и сразу идёт запись на диск.

Ога. У меня 2 одинаковых SSD стоит и венда при наработке в часах в 3 раза меньше насрала на диск больше, чем Linux. В перду такую логику.

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

У тебя логики точно нет. У винды в фоне куча процессов идёт, открой и посмотри, там постоянно то один то другой просыпается. Поэтому и записала больше. У линукса этого функционала нет.

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

Это, конечно, отчасти, объясняет ситуацию, но не в масштабах нескольких террабайт. В любом случае, сборка одного и того же проекта, на одной и той же системе (SSD тоже одинаковые) на Windows стабильно занимает х2 времени относительно Linux. Я в дебри жопы лося не лез, но мне кажется I/O и политика окон по работе с диском в этом сильно замешаны.

Jefail ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)