> Нет, всё с точностью наоборот. Если кто-то просит fsync или буфер наполнился,
> то все программы блокируются до полного(!) опустошения буфера.1) Вас не смущает что ядро не выбито в камне и эвристика у него на эту тему эволюционирует? Современным ядрам ваша мануальщина вообще не очень уперлась - потому что они сами dirty для медленных сторажей лимитируют. А для быстрых - с большим dirty никаких проблем нет. Представляете?! Напрягает же вот та латенси от операции расчистки памяти. Для современных ядер ваш совет в общем то протух. Хотя если вы друг сэра Поха с вечным полшестого и 2.6.32, тогда конечно вариант.
1.1) Современные ядра, особенно с всякими MGLRU субъективно стали несколько консервативнее в отращивании кешей. При том не сильно в ущерб перфомансу.
2) Если RAM много (e.g. 16..32Gb и более) и много свободной RAM - практически все записи завершаются "со скоростью RAM диска" - и это очень круто. По сравнению с вон тем.
3) А даже если и не завершаются - чем больше буфер тем больше шансов что упомянутая механика сыграет.
4) Единственное что выигрывается это ланенси активно пишущей программы, оно могло интересовать а могло и не интересовать. Для меня это скорее вопрос ухнуло оно мгновенно в буфер, так что я могу продолжить интерактив - или я отсюда сваливаю и занимаюсь чем-то иным.
5) Вы обуваете систему на оптимизации отмены записи стриниц файлов которые решили стереть, типа временных файлов и де-оптимизируете ряд сценариев, налетая на worst case. Когда файл всегда надо целиком записать. Даже если через секунду его сотрут.
> Отсюда и брался 12309: никакой софт не мог писать вообще и ждал.
12309 возникал не так. Там была ситуация: прога хочет себе солидный кус памяти. Оказывается что в системе ща нет RAM. Где его взять? Ага, много dirty, давайте выжмем его на диск и отдатим программе дисковые буфера. Ядро идет их выжимать, в хучшем случае - гигазы dirty на мееееедленный накопитель. Программа которая хотела память все это время висит тряпочкой. Ее нельзя возобновить пока RAM ей не наковыряли. Она упадет. Что врядли лучше. Что еще хуже, другие программы которым понадобилась память тоде могут начать ловить клина по той же механике, пока ядро там не разрулится со своим dirty. Это ведет к ужасной латенси. И это идет дальше чем только записи, это mem management/paging нагибался. А это реальный задник.
Есть куча "похожих на вид" проблем. Но они могут отличаться механикой, а конкретно 12309 - был описан см. выше как, насколько я помню. Если это не оно, окей, может быть у вас какой-то ДРУГОЙ баг. Он должен быть явно заведен с ДРУГИМ номером - потому что это ДРУГАЯ проблема.
Например, если у вас механический диск, вы его озадачили записью в полку и он надрывается, а тут стало с памятью душно, кернел оказывается юзал бинари программ как расширение свопа и мог отбросить страницы памяти, зная что всегда можно подчитать их из файлов бинарей. Это же причина по которой выполняемые файлы перезаписать не дают: эта механика сломается. Можно "стереть" файл но он лишь потеряет имя и будет существовать с 0 имен, его деаллокация только после завершения программы. Вон то может вызвать нехилые тупняки на механическом системном диске озадаченом записью. Но вообще это неудачная конфигурация. Она может встрять по 9000 иных причин. Скажем ожидания чтения конфига программы. Так лучше просто не делать.
> Что быстрее запишется 3-6-15GB (дефолт - зависит от размера памяти) или
> 100MB прежде чем другие программы смогут писать?
Опять же - запись пары гигз на скоростной SSD может и не парить. А вот безусловно деоптимизнуть работу кеша во имя луны - весьма спорная идея.
>> часть операций может быть оптимизирована.
> Нет, всё с точность наоборот. Современный сторадж (по сути любой не IDE)
> имеет контроллер и внутреннюю память. Внутри он сам реорганизует данные так,
> как надо, оптимизация на стороне ОС ничего не даёт
Вы не поняли. Если кернел в фоне все еще писал страницы файла на девайс - и еще не дописал - но write() уже вернулся, прога что-то поделала с файлом и ему вообще unlink() закатила, а кернел еще педалил ту запись - оставшиеся недописанные страницы можно отбросить из буфера НЕ ЗАВЕРШАЯ ЗАПИСЬ. А зачем - если файла уже нет?! В результате суммарный объем записей ниже - "не успели дописать и хрен с ним!". Но "отменить запись" можно только если было что отменять. Т.е. какие-то страницы висели в буфере. А вы как раз это предотвратили и налетаете на worst case когда вы таки пишете ВСЕ страницы. А что это было не надо т.к. файл сотрут вы узнаете опосля. Уже просадив перфоманс. Собссно "delayed writes" с агрессивной и длинной буферизацией основательно оптимизируют IO - отменяя операции ставшие ненужными или сливая много мелких в 1 большую и непрерывную, снижая оверхед а возможно и seeks.
> т.к. контроллер о ней не знает и вообще плевать хотел и всё переделает.
А это вообще не про контроллер было - а про отмену недописаного dirty если поняли что файло вообще снесли. Если меня не подводит склероз такую опмизиацию в ядре сделали. При такой "асинхронщине" записей (оказавшихся ненужными!) в девайс успеет улететь меньше чем в вашем сценарии. PROFIT - меньше IO с ТЕМ ЖЕ суммарным эффектом. Не любая семантика IO прокатит для такого трюка, но для типовых апликух вариант.
> Более того, современный Linux с nvme ничего и не оптимизирует, он
> просто валит всё "как есть" "по трубе вниз".
Вон то про возможность отмены записи недописаного если оно перестало требоваться. Ну и в случае штук типа NVME ваши объемы dirty выглядят издевательски, только оверхед добавят на частые дергания, не дав забацать большие непрерывные сегменты которые в целом все же флешовым девайсам - удобнее чем куча мелких разбросаных операций.
> Это неактуально вообще. Во-первых это супер-редкий сценарий в принципе. Во-вторых размер
> временных файлов несущественный (порядок мегабайтов почти всегда) для современных дисков,
> например nvme.
Для NVME вообще неактуальны предложенные вами величины параметров. Т.к. те объемы вообще не вызывают заметный латенси - зато опять же деоптимизируют записи. Чем больше удалось забуферить тем меньше записей будет в финале и они будут непрерывнее. Да, это идет в ущерб латенси и плохая идея на медленном накопителе, особенно системном. Но NVME не тот случай.
> Тут да, мысль верная, но до верного вывода вы не дошли. Потерять
> 3 гига или потерять 30 мегабайт это разного порядка проблемы.
Если вы перепишете 30 мегов из 5 гигового файла в in-place файлухе, и тут питание гавкнется, вы получите нечитаемый 5-гиговый файл, состоящий из разных головы и хвоста, и софт ЭТО прочитаьт скорее всего уже не сможет. Так что фактический объем потерь вовсе не 30 мегов - а весь 5-гиговый файл. С другой стороны если он весь в буфере висел, возможно он целиком в старом виде останется. Особенно актуально для ФС с cow семантикой, для них отбросить неудавшуюся запись - логичный фикс консистентности ФС, дешево, сердито, и ведет к чуть более старому view файлухи. Но файло имеет все шансы быть консистентным с точки зрения софта: там либо старая версия либо новая. А полупереписанная - в cow так не бывает, это ж не inplace запись а отапдейтить указатели на новый вариант как раз и не успели еще, ну и остался старый.
> -> выше производительность" и "чем быстрее девайс, тем больше можно иметь
> буфер" в корне неверные.
Мой тезис: больше буфер - оптимальнее IO паттерны, меньше оверхед и даже их объем при случае. А чем быстрее девайс - тем более похрен размер буфера. Просто потому что когда кернелу станет надо расчистить ту RAM он _БЫСТРО_ ее выжмет на тот девайс и проблем с латенси не возникнет. Это же элеметарно, Ватсон.
> По сути с большим буфером становятся быстрее только синтетические бенчмарки и всё!
А таки софт практикует самые странные IO и кроме бенчмарков могут и реальные ситуации выиграть. Особенно если рамы много и есть где развернуться с delayed alloc и оптимизациями. На NVME еще и записей будет меньше и они будут оптимальнее сгруппированы в большие сегменты.
> Все реальные задачи тормозят. Есть несколько исследований на этот счёт.
Если стораж быстрый то и выжимка на него более крупного блока занимает умеренное время. И вон те размеры адекватны для какойнить ноутбучной механики но уж точно не про NVME.
> Помню одно непубличное от разрабов Postgres (но вы можете найти как они после
> всех тестов советуют УМЕНЬШАТЬ буферы,
Активное использование больших баз данных - это специфичный топик. У баз могут быть свои кеши, лучше знающие что и как оно там хотело и может иметь смысл дать базе больше RAM а общий кеш урезать. Аналогичные соображения есть еще в некоторых вещах, типа качки торентов. И в этом месте вы начинаете наверное уже догадываться на кой черт мог быть нужен Direct IO (unbuffered IO). Иногда он бывает полезен, если у вас есть app-level cache специфичный для задачи и лучше, не хотилось выносить системные кеши, и/или вы уверены что запись будет большая и непрерывная. У меня есть и кейс без кеша но с большими непрерывными сегментами (запись специфичных паттернов оптом) - где direct IO получило свой пойнт.
> а для ДБ, сами понимаете, производительность диска решает всё), его ещё
> публично воспроизводили ребята из IBM, оно было в паблике, возможно найдёте.
Для больших активных БД соотношения иные чем для десктопника. И это вообще специфичный топик. Если бы вы сказали тот тюнинг для сервера БД, а потом еще внутренние кеши бд отожрать по максимуму, я бы и не возражал возможно. Но мы вроде про другие сценарии тут говорили...
> Ещё раз, дело не в скорости диска. Дело в том, что с дефолтами первые 1.5 гига
> записи диск просто простаивает (background_ratio/background_bytes)
И прекрасно. Может половина из них будет стерта к хренам и отменена как ненужное, или как минимум сгруппирована, снизив amplification factor и оверхед операций. Не понимаю стремление насиловать накопитель при любом удобном случае. На механике это тормозно. На SSD ведет к его ускоренному протиранию.
> ещё не достигнут. Т.е. ядро не пишет на диск в момент
> интенсивной записи софтом. По этой и другим причинам производительность падает.
Да вообще-то delayed alloc придумали не просто так. И в дофига случаев от него много улучшений. Это очень мощная техника оптимизаций.
>> Btrfs в общем случае тоже использует ту механику страничного кеша. По поводу чего прекрасно живет даже на роутере с 64 метрами оперативы
> Нет конечно. Вы, как я и говорил, понятия не имеете, как оно
> работает: https://github.com/pop-os/default-settings/issues/111
Это что-то совершенно левое.
1) Это не разработчик ядра и не какой либо известный эксперт в области.
2) Этот кадр ссылается на нечто 2013 года, с _флешками_ у Ташкинова. Как сие относится к быстрым SSD - загадка природы.
3) "несколько минут" не стыкуется с "быстрый SSD". Быстрый SSD вообще нереально заякорить чем-то типа полутора гигз записи или сколько там. Тем более на минуты. Такое ощущение что SSD не такой уж и быстрый был и даже откровенно хлам, который в какой-то момент резко проваливается по скорости до "похабной флешки". Или какие-то паттерны IO к нему неудачные. Может btrfs + дискард синхронный (discard=async НАМНОГО лучше, и по скорости и по IOPS в стораж), или еще какое УГ. Там недостаточно инфо для понимания как это случается а отсыл к кейсу ташкинова с флехой в 2013 только усугубляет подозрения насчет "быстрый SSD".
>> И btrfs уж точно не "драйвер стоража".
> Разве что для тех, кто не писал драйвера для ФС
Я как бы кернел компилял - и наруливал загрузку систем от и до. Очень способствует пониманию иерархии IO. Драйвер файлухи совершенно точно не драйвер стоража, и вообще. У btrfs есть свои особенности из-за многодевайсовости, но это лишь взаимодействие с блочным уровнем. И между нами - btrfs хорошая штука, но вот именно тот аспект для многодевайсных штук как говорится "leaves a lot to be desired". Там точно есть что и куда улучшать. Потому что вот это там вообще не оптимально пока. Одна из причин по которой хочется видеть вокруг еще и Кента с свежими идеями. У него с его bcache есть интересный опыт, возможно сможет показать мастеркласс как это надо было. Он уже достал половину майнтайнеров подсистем - и давно пора было, вообщет :)
