Где хорош Intel Optane 900p по сравнению с Samsung 950-970 Pro

Для всего, где используется частый fsync. У всех самсов с этим плохо (даже у прошек).

А где он используется, кроме СУБД? Например, для индексации текстовых файлов программой recoll (движок xapian) используется? А то столкнулся с тем, что когда размер их становится под сотню гигабайт, то резво начавший индексер дико тормозит в итоге, так что процесс растягивается буквально на неделю.

Нашёл интересную статью про преимущества Optane, там и о fsync есть.

спасибо за ссылку, реально интересно!

А где он используется, кроме СУБД?

Там, где нужно гарантировать, что данные были записаны на диск. Вопрос настолько общий, что сложно ответить (в СУБД fsync можно отключить :)).

Например, для индексации текстовых файлов программой recoll (движок xapian) используется?

наврядли (на самом деле не знаю).

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

спасибо за ссылку, реально интересно!

Спасибо за теплые слова, ведь мы для вас, читателей, и существуем!

Обычно такие вещи покупаются под конкретную задачу (обычно- одно приложение), когда точно ясно, где затык производительности.

В общем случае, ИМХО, вопрос слишком абстрактен.

Извиняюсь.

Вот ссылка https://www.percona.com/blog/2019/09/19/update-on-fsync-performance/

Добавил в исходный пост.

… и да, «индексатор» БД тут не особо уместен, данные синькаются при фиксации транзакции.

Там, где нужно гарантировать, что данные были записаны на диск.

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

Да ничего подобного, без синка контроллер диска запишет данные в набортный кэш записи, а реально на диск данные запишет «потом». А синк гарантирует что данные из кэша будут записаны на диск. Но есть диски которые кладут на эту гарантию и у них синк ничего не делает. Поэтому по сути синк нужен всегда когда потеря данных критична, а в общем случае она всегда критична, кроме кэшей каких-то. Но здесь появляется второй стул - производительность, а точнее время отклика, ради которого кэши и городят

Да и вообще изначально странное сравнение потребительский накопитель вс промышленный

LOL. Гоблин (Дмитрий Пучков) оказывается про Optane записал видос, с таким умным видом вещает. https://www.youtube.com/watch?v=NoFHtSqWO1M

Optane 900p - тоже потребительский. По крайней мере по классификации Intel.

Поэтому по сути синк нужен всегда когда потеря данных критична, а в общем случае она всегда критична, кроме кэшей каких-то

поправка: синк нужен когда консистентность данных критична. т.е. что блок У будет записан только когда успешно запишется блок Х, а не тогда когда накопителю будет удобно. к потере данных во время записи (к примеру при отключении питания) он никоим боком не относится - даже если писать с sync() (ну или O_DIRECT), при отключении питания данные все равно запишутся частично. а вот флаг завершенной транзакции - да, потом запишется только после того, как запишутся все данные на блины/флэш.

Для всего, где используется частый fsync.

А где он используется, кроме СУБД?

Как ни странно, на десктопе.
Жирнолис/Хромиум пишут в десяток sqlite3 баз.
Поиск во взятом с потолка мылклиенте/ридере/етц скорее всего реализован с помощью БД.
Соответственно туда же пишутся и данные.

В файрфоксе, так как там профиль в sqlite. Много приложений любят дергать fsync.

Поэтому для браузеров без SSD очень помогает zvol с выставленной опцией sync=disabled.

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

Бред.

После заполнения буфера конечно уже перестанет обганять во время сброса на диски (но раз в 5 секунд, а по мере заполнения, может быть и раз в 5 минут). Т.е. целых 5 минут IDE диск снятый с первого пенька из 90х будет «уделывать» (пока диск бездействует) твой оптан :)

*НЕ раз в 5 секунд

Нет смысла возиться с настройкой ZFS под агрессивное небезопасное кеширование записи, если того же результата можно добиться запуском под eatmydata. Гарантии целостности будут те же — никакие. Скорость будет той же, а возможно и выше, потому что не будет лишнего копирования в кеш ZFS, будет использоваться штатный страничный кеш Linux.

Однако ZFS позволяет на лету, например, раз в 10 минут менять значение опции sync=disabled на обычное standard, сделать снэпшот с bash -c sync, и потом вернуть обратно в состояние до создания снэпшота sync=disabled, что очень повышает отказоустойчивость и снизить вероятность потери данных созданных ранее, чем 10 минут назад.

Наверно, что-то похожее можно выставить и другими опциями ZFS?

Кстати очень помогает при EMI атаках, когда атакущие пытаются синхронизировать интенсивную запись из управляемого ими плагина браузера Brave и одновременно давить канал SATA вредоносным полем с битыми данными, обычно еще одновременно фигачат по сети питания 220В, создавая очень сильные броски напруги.

Так вот, так сказать, «куй вам», потому что ZFS рапортуя плагинам об успешном fsync (обманывает их) задерживает запись из оперативки на минуты, нарушая синхронность атаки, а потом еще и все портит возможностью отката на любой ранее сделанный (до атаки) целостный снэпшот, вообщем полная опа для атакущих.

очень повышает отказоустойчивость

Вот вообще не понимаю, как именно. Как только приложению начинают возвращать результат fsync без сброса данных, вся надёжность вылетает в трубу. После этого уже нет смысла заморачиваться.

В трубу вылетает только надежность хранения новых данных после последнего снэпшота, до снэпшота включительно надежность хранения и целостность пула ничем не отличается от режима sync=standard.

zfs rollback и вуаля - опять все в ажуре уже через одну секунду, если это браузер, то ему такого более, чем достаточно.

Мало того, мне последнее время хватает fsck -f /dev/zvol вместо полного rollback и очень редко когда требуется rollback, но rsync всегда вытаскивает почти все файлы кроме 1-2х битых на весь датасет.

но rsync всегда вытаскивает почти все файлы кроме 1-2х битых на весь датасет.

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

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

У меня задача была закешировать браузеры, я ее решил через sync=disabled, что нитак?

Для СУБД кстати такое, наверно тоже можно использовать при условии хранения активных и архивных логов на sync=standard?

Я конечно, для хранения базы всегда использовал sync=standard.

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

Представим, у нас накрылась база по причине sync=disabled и процедура crash recovery не проходит.

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

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

Как уже упоминал, если потери данных вообще не критичны, то проще запустить через eatmydata, без необходимости возни с прикручиванием ZFS. Профиль браузера можно просто создать заново.

Но у ТСа первым в списке упоминается СУБД.

Даже восстановление из бэкапа не потребуется.

https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/t0006423.html

Но у ТСа первым в списке упоминается СУБД.

Я как раз описал вариант для СУБД с sync=disable и без Оптана для основной базы (хотя под логи можно использовать как раз его), я где-то ошибся?

я где-то ошибся?

Без понятия.

Я могу представить себе доказательство того, что журналирование (с fsync) обеспечивает конситентность данных. Чтобы убедиться в корректности работы поверх отключенных fsync, нужно все доказательства проводить заново. Я не в состоянии сделать это строго.

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

Что мешает сохранить целостность базы при откате на синхронный снэпшот и последующем rollforward синхронных логов до точки сбоя?

А хотя вот ведь какая проблемка, активные то логи не удастся применить после наката архивных?

Так что это не полная целостность, а с потерей нескольких последних минут работы? все таки базу надо хранить на синхронном хранилище.

Но ведь если сбойнет crash recovery на синхронном хранилище, то восстановление из бэкапов будет аналогично моему варианту?

А когда может сбойнуть crash recovery синхронного носителя? Только при выходе из строя оборудования?

Если бы я знал конкретный сценарий, который портит всё, уже бы написал. Но я просто не уверен, что предложенный тобой процесс не приведёт к коверканию данных.

С профилем браузера всё проще — его можно выбросить и создать заново. Базу выбрасывать не будешь. И бекапы базы хочется делать в консистентном состоянии. Так что нормальная работа важна. И вот тут вообще непонятно, есть какие-то гарантии или нет. С обычным журналированием я ещё понимаю, как работает. Твой вариант — нет.

Что такое crash recovery, тоже непонятно. Раскатывание журнала при старте это crash recovery? Или это восстановление базы из неконстстентного состояния?

Откат снапшота нагруженной БД приведет к порче БД.

Откат снапшота нагруженной БД приведет к порче БД.

С чего бы вдруг откат на ZFS снэпшот базы DB2, сделанный в режиме db2 set write suspend вдруг привел к порче базы?

Я ведь уже давал ссылку на сайт IBM, у них предусмотрены снэпшоты.

Это вам не sqlight в режиме дорвеестроения :)

кто-то еще пользуется db2 ?

Что такое crash recovery, тоже непонятно. Раскатывание журнала при старте это crash recovery? Или это восстановление базы из неконстстентного состояния?

Crash recovery для СУБД типа DB2 - это условно раскатывание активного журнала в обе стороны после условного hard reset, чтобы после запуска базы гарантировать ее консистентное состояние, причем DB2 в придачу ко всему еще и чексуммы сверяет самостоятельно, уух какая мощная и отказоустойчивая система!

Ылита голубого гиганта же :)

У них даже считается, что версионный способ программирования аля Оракл - неправильный, он для недопрограммистов.

в нормальных базах всегда можно накатить логов и всё будет акей.

а в оракле считается, что лок на локе локом лок - это от недопогроммистов.

И кстати DB2 уже лет 10 как поддерживает синтаксис Oracle и есть бесплатная редакция с ограничением на объем базы до 100 гиг для любого использования в т.ч. коммерческого.

И есть редакции DB2 за сотню USD для обучения с лимитами как у коммерческих версий.

Проблема только как бы прикупить лицуху на физлицо? Продавцы РФ заявляют, что физикам не продают.

А кстати, самозанятые - это юр. лица или кто? Как-то не успел еще вникнуть в юридический смысл самозанятости во всех его аспектах.

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

И еще вопросик по теме замозанятости:

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

что лок на локе локом лок - это от недопогроммистов.

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

в нормальных базах всегда можно накатить логов и всё будет акей.

Если есть логи и то, на что их накатывать :)