LINUX.ORG.RU

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

 mlc, ,


0

1

Для реальных задач, а не в тестах. Чтобы имело смысл переплатить почти в 4 раза за туже ёмкость. Попробую список составить:

  • Для работы индексатора СУБД
  • Для большой нагрузки, которая быстро выработает ресурс
  • Если нужно обрабатывать очень много мелких файлов (компиляция и линковка чего-то крупного)
  • Там где есть какие-то затруднения с функцией Trim: нестандартные файловые системы для которых она не поддерживается или их отсутствие, например, для криптоконтейнеров или для СУБД, работающих на разделе.
  • Если нужна длительная нагрузка, например, непрерывно часами дрючить диск.

Я что-то упустил или лишнее вписал?

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

https://www.percona.com/blog/2019/09/19/update-on-fsync-performance/

★★★★★

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

Ответ на: комментарий от a_buchinskiy

а ты у нас исскуствовед, надо полагать

зато значительно ниже нагрузка на дисковую подсистему при сравнимых задачах это тебе в консерватории рассказали?

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

а ты у нас исскуствовед, надо полагать

Нет, увы я любитель nHibernate и даже MSSQL (а он в т.ч. и версионник!)

a_buchinskiy
()
Ответ на: комментарий от anonymous

зато значительно ниже нагрузка на дисковую подсистему при сравнимых задачах это тебе в консерватории рассказали?

Кстати да в консерватории (на форумах DB two), вруд?

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

это условно раскатывание активного журнала в обе стороны

Это высказывание не имеет смысла. По крайней мере, я его не вижу. Почему «условно»? Что за обе стороны? Если пытаешься понять, есть ли какие гарантии, поверхностного понимания не хватит.

Обратно к ZFS.

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

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

Это высказывание не имеет смысла. По крайней мере, я его не вижу. Почему «условно»? Что за обе стороны? Если пытаешься понять, есть ли какие гарантии, поверхностного понимания не хватит.

Поверхностное понимание у тебя, вернее даже его отсутствие конкретно применительно к crash recovery DB2, не в обиду, просто ты его не изучал раньше, вот смотри:

If a database fails unexpectedly before all transactions (or units of work) are committed, or before the changes associated with committed transactions are fully written to disk, then the database is left in an inconsistent state. When a database restart is performed, these transactions are rectified during a process called crash recovery. During crash recovery, the changes associated with these transactions are first replayed from the transaction logs (we often refer to this as the Forward or Redo phase of crash recovery). Transactions which were not yet committed at the time of the database failure are then rolled back (we often refer to this as the Backward or Undo phase of crash recovery)

Обе стороны - это «туда» forward прокат завершенных транзакций «обратно» backward откат незавершенных транзакций.

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

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

Перед снэпшотом включаем sync=standard (я ведь писал про синхронный снэпшот), выставляем режим работы базы write suspend, когда СУБД разрешает только чтения, сбрасываем буфера базы и … снэпшотим zvol после чего еще делаем bash -c sync; Возвращаем zfs sync=disabled и поехали дальше до следующего автоматического периодического аналогичного снэпшота по крону.

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

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

Прошу прощения, в случае rollforward to end of logs после восстановления бэкапа активные логи тоже обрабатываются конечно же. Но вот после переключения на снэпшот не уверен, наверно тоже самое? Если так, то моя схема с моей точки зрения не должна терять ни одной завершенной транзакции.

a_buchinskiy
()
Ответ на: комментарий от anonymous

у zfs нет журнала.

Как нет? Нет вообще или в моем случае? А позвольте узнать, что такое Intent Log при sync=standard?

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

И ни слова про порядок записи.

Ну давай другими словами опишу. Допустим, приложение записало блоки 4, 3, 2, 1 именно в таком порядке. Допустим, в кеше ZFS кончилось место и он решил сбросить данные на диск. В каком порядке будут записаны данные на диск? Гарантируется ли, что именно 4, 3, 2, 1? Или для ускорения он переупорядочит в виде 1, 2, 3, 4?

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

Возможно порядок менять особо нет смысла. Главное превратить случайный доступ в последовательный.

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

Зато он есть у СУБД, которую предлагают ускорять через ZFS.

Я не предлагаю ускорять СУБД именно с помощью sync=disabled в реальных промышленных условиях, там намного дешевле (с точки зрения безопасности от наличия crash recovery плюсом в full recovery) купить пару SSD-эх Intel DataCenter Edition за несколько сот тысяч руб. и они обеспечат такую же скорость в режиме sync=standard.

Просто мне стало любопытно, а сможет ли такая дикая схема обеспечить целостность базы данных DB2 с точностью до последней завершенной транзакции, и пока не вижу, почему не сможет. Просто забавно, just for fun.

a_buchinskiy
()
Ответ на: комментарий от Deleted

превратить случайный доступ в последовательный

Но ведь это сломает журналирование в СУБД, которая хостится на таком хранилище.

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

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

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

Просто забавно, just for fun.

Интересно, насколько стали совершенные технологии хранения данных, такие как ZFS и DB2 и какие фокусы можно устраивать с помощью них на очень слабом оборудовании с добавлением промышленных SSD под SLOG и L2ARC.

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

Просто мне стало любопытно, а сможет ли такая дикая схема обеспечить целостность базы данных

Уже в который раз спрашиваю, как именно работает этот кеш, потому что при некоторых вариантах можно сразу сказать, что не сможет. А ты в ответ пишешь, какие настройки куда указывать. Это не то. Важны детали реализации.

с точностью до последней завершенной транзакции

С точностью до последней завершённой транзакции точно не сможет:

  • Клиент присылает запросы, обёрнутые в транзакцию;
  • БД отвечает, что всё зафиксировано, потому что хранилище сказало, что fsync завершился;
  • Питание пропадает, кеш потерян, система перезапускается;
  • Происходит восстановление консистентности БД (предположим, что успешное);
  • Транзакция клиента потеряна, но клиент уверен, что фиксация произошла.
i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от a_buchinskiy

честно отработает все fsync

Сомневаюсь. «Честно отработает» можно сказать только если в точности воспроизведётся последовательность записей и fsync’ов. Но тогда смысла в кеше нет, всё упрётся в скорость накопителя.

какие проблемы?

По всей видимости, слово «журналирование» мы понимаем по-разному. В этом проблема. Ты можешь описать, как происходит процесс журналирования в СУБД?

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

С точностью до последней завершённой транзакции точно не сможет:

Дружище, ты скорее всего пока незнаком с тем, как работают промышленные СУБД класса DB2/MSSQL/Oracle.

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

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

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

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

Сомневаюсь. «Честно отработает» можно сказать только если в точности воспроизведётся последовательность записей и fsync’ов. Но тогда смысла в кеше нет, всё упрётся в скорость накопителя.

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

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

По всей видимости, слово «журналирование» мы понимаем по-разному. В этом проблема. Ты можешь описать, как происходит процесс журналирования в СУБД?

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

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

да и зачем они

Чтобы ответить на вопрос, который ты задаёшь. Нет понимания — не получится получить ответ. Можешь сколько угодно размышлять о том, что куда пропишешь, это не приближает к ответу. Ты либо понимаешь, как работает система, и тогда можешь давать квалифицированные оценки, либо не понимаешь, и тогда можешь гадать на кофейной гуще.

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

Они предлагают хранить

И всё это — с опорой на гарантии, которые ты отбираешь своей схемой кеширования.

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

Ты отобрал у хранилища fsync, ты же помнишь, да? Всё, нет больше доверия к точкам сохранения. Кроме того, больше нет гарантий, что база консистентна. А значит, ты не можешь уверенно сказать, какая последняя транзакция была в базе зафиксирована.

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

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

как постоянный клиент такси, ответственно заявляю тебе, что ты неправ.

Для правильного обслуживания промышленной СУБД необязательно знать как работает ее внутренняя реализация целостности данных, достаточно мыслить более высокоуровневыми понятиями, которые обозначены в доках IBM DB2:

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

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

И всё это — с опорой на гарантии, которые ты отбираешь своей схемой кеширования.

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

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

Ты отобрал у хранилища fsync

по крону то отбираю, то возвращаю

нельзя собирать валежник / можно собирать валежник / нельзя / можно и т.д.

, ты же помнишь, да? Всё, нет больше доверия к точкам сохранения.

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

Кроме того, больше нет гарантий, что база консистентна.

Это в случае сбоя или когда?

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

А архивные логи на другом хранилище для чего?

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

А архивные логи на другом хранилище для чего?

И активные кстати тоже, где как раз последние транзакции и хранятся.

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

карбюратора

А что, карбюраторные двигатели ещё производятся?

то не можешь ездить на автомобиле

Пока не лезешь в двигатель, можешь ездить. Но ты-то лезешь ручками внутрь. И такой: «я не знаю, как это работает, и мне не надо. Думаю, если вот сюда пробку вставить, будет нормально. Я её иногда буду доставать. Что? Зачем пробка? Ну, мне кажется, что всё нормально будет.»

Для правильного обслуживания промышленной СУБД необязательно знать как работает ее внутренняя реализация целостности данных, достаточно мыслить более высокоуровневыми понятиями, которые обозначены в доках IBM DB2

Там написано про отключение fsync? Если нет, то в обсуждаемом вопросе эти доки больше не релевантны.

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

по крону то отбираю, то возвращаю

Достаточно не выполнить один единственный.

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

facepalm

Это в случае сбоя или когда?

Конечно в случае сбоя! В мире, где нет сбоев, был бы ACI вместо ACID.

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

Но ты-то лезешь ручками внутрь.

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

Там написано про отключение fsync? Если нет, то в обсуждаемом вопросе эти доки больше не релевантны.

Как ты не понимаешь, что база фризится и снэпшотится в момент, когда sync=standard, уже замонался тебе это талдычить. Это гарантированная точка бэкапа с которой потом можно гарантированно накатывать архивные логи (файлы в другом каталоге, где sync=standard никогда не отключался).

ZFS гарантирует целостность таких снэпшотов, даже если ты потом опять отключишь fsync у того же самого датасета, в случае факапа со снэпшотом НИЧЕГО не случится, ты это понимаешь?

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

Достаточно не выполнить один единственный.

А для чего в языках программирования (в т.ч. bash) существует команда ветвления «IF»?

sync_state=`zfs get sync database_dataset";

If [«sync_state» == «standard»]; then

все ок, поехали фризить базу …

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

facepalm

Ненадолго к текущему состоянию dataset, а к состоянию снэпшота - постоянное доверие (по докам ZFS, если чо).

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

Конечно в случае сбоя! В мире, где нет сбоев, был бы ACI вместо ACID.

Правильнее было спросить «в момент сбоя или когда».

Ну и пусть, база неконсистента в момент сбоя, нас это не волнует, потому что мы откатимся с помощью zfs rollback к консистентному старому состоянию базы и потом сделаем rollforwarf логов до самой последней транзакции из другого консистентного хранилища.

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

Но ты-то лезешь ручками внутрь.

Образно объясню это так:

ты рассуждаешь о сортах реализации ассемблера в кодах,

но при этом не в состоянии понять как пользоваться GW basic по толстой приятной доке Microsoft в глянцевой обложке.

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

БД отвечает, что всё зафиксировано, потому что хранилище сказало, что fsync завершился;
Питание пропадает, кеш потерян, система перезапускается;

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

anonymous
()
Ответ на: комментарий от a_buchinskiy

Для правильного обслуживания промышленной СУБД необязательно знать как работает ее внутренняя реализация целостности данных

так и появляются байки про туповатых обминов энтырпрайза.

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

Если fsync завершился, то похер, что кеш потерян.

@a_buchinskiy предлагает использовать фичу ZFS «говорить приложению, что fsync() завершился успешно, но при этом его даже не запускать».

кеша

Кеш у ZFS — в ОЗУ.

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

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

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

Он писал про ZFS ARC, который при сбое незащищен батарейкой.

Но я всю эту тему пытаюсь объяснить следующее в терминологии DBA:

Промышленные СУБД предоставляют два способа восстановления базы после сбоя:

A) быстрый crash recovery: диск базы + active logs

B) более медленный full recovery: восстановить бэкап или откатиться на снэпшот и потом накатывать архивные логи

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

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

Не знаю как вам еще объяснить.

В production конечно же лучше оставить оба шанса на восстановление: A) и B), не создавая дополнительных рисков.

a_buchinskiy
()
Ответ на: комментарий от anonymous

так и появляются байки про туповатых обминов энтырпрайза.

А у обминов DBA складывается подобное впечатление о тех, кто не понимает основные высокоуровневые принципы recovery базы на промышленной СУБД.

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

Это получится использование ZFS как базой данных для отслеживания изменений без полной записи. Копировать куда-то можно. Просто фанатики тормозов будут тем самым играть на страхах, чтобы найти повод не использовать такой подход. Это как минимум высвободит от простоя сервер. А вообще что мешает скидывать данные с виртуального пула не останавливая работу всей базы? На SSD скоростей вроде бы хватает. Ну там было 24 SSD диска, сделали 6 рейдов по 4 диска в raidz2 и полетели с диким улюлюканием. По-моему тут избыточность на избыточности получается.

anonymous
()
Ответ на: комментарий от a_buchinskiy

точно не у тех, кто не понимает, как их база работает. хотя, раздутое чсв часто идёт в комплекте с таком вот «не надо знать». высокоуровневые принципы - это где-то на уровне эникея.

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

и в чём поинт? у тебя вся эта балалайка будет работать со скоростью записи логов.

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

Активные логи размещаем на небольшом промышленном зеркале SSD, архивные неспешно и самое главное ПОСЛЕДОВАТЕЛЬНО выталкиваем на другое синхронное хранилище.

Профит в том, что быстрые SSD надо только под активные логи, а это совсем немного, профит ! :)

a_buchinskiy
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.