Вопрос: Должны ли мы монтироваться с данными = обратной записью и барьером = 0 на ext3?


Мы запустили сервер на виртуальной машине в хостинговой компании и только что подписались на выделенный хост (AMD Opteron 3250, 4 ядра, 8 ГБ оперативной памяти, 2 х 1 ТБ в программном RAID-массиве, ext3).

При выполнении тестов производительности мы заметили, что некоторые транзакции SQLite (комбинация вставок, удалений и / или обновлений) занимали от 10x до 15 раз больше, чем в моем MacBook Pro 2010 года.

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

    data=ordered,barrier=1

Мы провели эксперименты и получили лучшие результаты с

    data=writeback,barrier=0

Я прочитал об этом и понимаю основы того, что они делают, но у меня нет хорошего чувства / чувства, правильно ли нам вести себя так?

Вопросов

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

Если бы у нас был перерыв в электропитании или жесткий сбой, тогда мы могли бы потерять данные или испортить файлы. Если бы мы делали снимки БД каждые 15 минут, это могло бы смягчить ситуацию, но БД не может быть синхронизирована при снятии моментального снимка. Каким образом (может?) Мы обеспечиваем целостность такого моментального снимка?

Существуют ли другие варианты, которые мы должны рассмотреть?

благодаря


13
2018-03-11 14:53


Источник


При этом задействованы многие факторы. Вы ожидаете много тяжелых аварий? У вас есть ИБП (или что-то подобное), подключенное к вашей размещенной машине? Вы проводили бенчмаркинг с другими файловыми системами (например, ext4, XFS и т. Д.)? Можете ли вы управлять ((de) активировать) кэш жесткого диска? Как вы настроили свой программный RAID? Правильно ли вы настроили жесткий диск (если есть блоки 4K)? - Huygens
Мы не ожидаем много тяжелых аварий. У нас нет ИБП. Спецификация машины была стандартной «с полки» от хостинговой компании, поэтому: мы не сравнивали другие fs, ext3 - это то, что мы получили. Не знаю, что в кэше жесткого диска, посмотрите на это и аналогично для выравнивания RAID и HDD. Благодарю. - NeilB
Еще один вопрос, который я забыл, - сколько стоит история, которую вы можете позволить себе потерять? Или вы не можете позволить себе потерять? Примечание. SQLite поддерживает моментальный снимок или, другими словами, резервное копирование работающей базы данных. sqlite.org/backup.html - Huygens
Какова версия вашего ядра? Барьеры соблюдаются md с 2.6.33, а не в предыдущем выпуске ядра. - Huygens
uname -r "2.6.32-220.2.1.el6.x86_64". Что такое «md»? Если в этой версии ядра не соблюдаются барьеры, почему я вижу улучшение производительности при отключении барьеров? - NeilB


Ответы:


Первый совет
Если вы не можете позволить себе потерять какие-либо данные (я имею в виду, когда пользователь вводил новые данные, если это не может быть потеряно в ближайшие секунды), и потому что у вас нет чего-то вроде ИБП, тогда я бы не удалял барьер записи, Я переключаюсь на обратную запись.

Удаление барьеров записи
Если вы удалите барьер записи, тогда в случае сбоя или потери мощности файловой системе необходимо будет выполнить fsck для восстановления структуры диска (обратите внимание, что даже при включенной защите от барьера большая часть файловой системы журналов все равно будет выполнять fsck, даже если воспроизведение журнала должно быть достаточно). При удалении барьера для записи рекомендуется, если это возможно, удалять любое кэширование диска (на аппаратном обеспечении), это помогает минимизировать риск. Тем не менее, вы должны проверить влияние такого изменения. Вы можете попробовать эту команду (если ваше оборудование поддерживает ее) hdparm -W0 /dev/<your HDD>,
Обратите внимание, что ext3 использует 2 барьера для изменения метаданных, тогда как ext4 использует только один при использовании опции mount journal_async_commit,

Несмотря на то что Тед Т'со объяснил почему в начале дней ext3 произошло несколько сбоев данных (барьеры были отключены по умолчанию до ядра 3.1), журнал помещается таким образом, что, если обход журнала журнала не происходит (журнал является циклическим журналом), данные записываются на диск в безопасно order - журнал сначала, второй - даже с жестким диском поддерживает переупорядочение записей.
В принципе, было бы не повезло, что при сбое журнала журнала произойдет сбой системы или потеря мощности. Однако вам нужно сохранить data=ordered, Попробуйте сравнить data=ordered,barrier=0 к тому же.

Если вы можете позволить себе потерять несколько секунд данных, вы можете активировать обе опции data=writeback,barrier=0 но затем попытайтесь поэкспериментировать с commit=<nrsec> параметр. Проверьте руководство по этому параметру Вот, В основном вы даете несколько секунд, в течение которых файловая система ext3 будет синхронизировать свои данные и метаданные.
Вы можете попробовать также попробовать скриптировать и сравнить некоторые настройки ядра в отношении грязных страниц (те, которые требуют записи на диск), есть хорошая статья здесь, что объясняет все об этих настройках и как играть с ними.

Резюме в отношении барьеров
Вы должны сравнить еще несколько комбинаций перегонов:

  1. использование data=writeback,barrier=0 в сочетании с hdparm -W0 /dev/<your HDD>
  2. использование data=ordered,barrier=0
  3. использование data=writeback,barrier=0 в сочетании с другим вариантом монтирования commit=<nrsec> и попробуйте разные значения для nrsec
  4. Используйте опцию 3. и повторите настройку на уровне ядра относительно грязных страниц.
  5. Использовать сейф data=ordered,barrier=1, но попробуйте другие настройки: особенно файловый контроллер (CFQ, Deadline или Noop) и их перестраиваемые настройки.

Учитывая переход к ext4 и его сравнение
Поскольку для ext4 требуется меньше барьера, чем ext3 для записи. Кроме того, ext4 поддерживает экстенты, которые для больших файлов могут обеспечить лучшую производительность. Таким образом, это решение стоит изучить, тем более, что легко перейти с ext3 на ext4 без переустановки: официальная документация; Я сделал это на одной системе, но используя это Руководство для Debian, Ext4 действительно стабилен с ядра 2.6.32, поэтому он безопасен в использовании.

Последнее рассмотрение
Этот ответ далек от завершения, но он дает вам достаточно материалов, чтобы начать расследование. Это настолько зависит от требований (на уровне пользователя или системы), что трудно получить прямой ответ, извините за это.


14
2018-03-12 16:20



Спасибо - там много полезного. Я уже прочитал файл ext3 на kernel.org и попытался изменить фиксацию, но не имел смысла для того, что было большим значением. Установите на 15, а не на 5 секунд, я не увидел никаких изменений. Я сделаю еще один бенчмаркинг, чтобы осветить предложенные вами перестановки. Еще раз спасибо. - NeilB
Было бы неплохо попытаться увеличить время фиксации, сохранив безопасные значения по умолчанию! Возможно, что SQLite - это одна очистка / синхронизация, которая может быть объяснением того, почему вы не измеряли изменения производительности с помощью опции commit. - Huygens
@NeilB просто наткнуться на эти статьи: 1. sqlite.org/draft/lockingv3.html искать ext3 в этом. Это дает, возможно, более простое (или упрощенное) объяснение того, что я пытался решить в своем ответе. 2. sqlite.1065341.n5.nabble.com/... вы можете попытаться сохранить безопасные значения ext3 по умолчанию (упорядоченный + барьер), но удалить синхронизацию в SQLite. Я скоро обновлю ответ на этот второй аспект. - Huygens
Спасибо за это. Я собираюсь выработать все перестановки и выполнить с ними тесты производительности по очереди. Раньше я пытался с синхронизацией в SQLite и получил хорошие показатели производительности. Мне нужно написать некоторый код, чтобы сначала собрать ряд данных для разных комбинаций операций записи. Я опубликую здесь резюме, но если вы хотите получить более подробную информацию, я буду незваным в bowers dot com. - NeilB


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

Существует несколько уровней, где вы можете беспокоиться о производительности записи SQLite:

different levels for thinking about performance

Мы посмотрели на выделенные жирным шрифтом. Конкретные параметры

  • Хранение записи на диск. Современные диски имеют RAM-кеш, который используется для оптимизации записи на диск в отношении вращающегося диска. При этом данные могут быть записаны в блоках вне порядка, поэтому, если произойдет сбой, вы можете получить частично написанный файл. Проверьте настройку с помощью hdparm -W / dev / ... и установите его с помощью hdparm -W1 / dev / ... (чтобы включить его, и -W0, чтобы отключить его).
  • Барьер = (0 | 1). Много комментариев в Интернете, говорящих «если вы работаете с барьером = 0, тогда не включается кэширование записи на диск». Вы можете найти обсуждение барьеров в http://lwn.net/Articles/283161/
  • data = (журнал | упорядоченный | обратный вызов). смотреть на http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html для описания этих параметров.
  • совершают = N. Сообщает ext3 синхронизировать все данные и метаданные каждые N секунд (по умолчанию 5).
  • SQLite pragma synchronous = ON | OFF. Когда ON, SQLite будет гарантировать, что транзакция будет «записана на диск», прежде чем продолжить. Отключение этого параметра существенно не влияет на другие настройки.
  • SQLite pragma cache_size. Контролирует, сколько памяти SQLite будет использовать для кэша в памяти. Я попробовал два размера: один, где вся БД поместилась бы в кеш, и тот, где кеш составлял половину максимального размера БД.

Подробнее о вариантах ext3 в документация ext3,

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

scenarios I tried

Я начал работать с настройкой по умолчанию на моей машине в качестве сценария 1. Сценарий 2 - это то, что я считаю «самым безопасным», а затем пробовал различные комбинации, когда это необходимо / подсказывалось. Это, вероятно, проще всего понять с помощью карты, в которой я закончил:

map relating scenarios to parameters

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

plot showing timings for scenarios

Нижние два сценария: # 6 и # 17, которые имеют «pragma synchronous = off», поэтому неудивительно, что они были самыми быстрыми. Следующий кластер из трех: # 7, # 11 и # 19. Эти три выделены синим цветом на «карте конфигурации» выше. В основном конфигурация - это кеш-запись на диске, барьер = 0, а набор данных - нечто иное, чем «журнал». Изменение фиксации между 5 секундами (# 7) и 60 секунд (# 11), похоже, мало чем отличается. На этих тестах, похоже, не было много различий между данными = упорядоченный и data = writeback, что меня удивило.

смешанное обновление тест - средний пик. Существует кластер сценариев, которые более явно медленнее в этом тесте. Все это с Данные = журнал, В противном случае между другими сценариями не так много.

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

mixed types and insert/update/delete

Здесь вы можете видеть, что конфигурация обратной записи (# 19) немного медленнее, чем упорядоченные (# 7 и # 11). Я ожидал, что writeback будет немного быстрее, но, возможно, это зависит от ваших шаблонов записи, или, может быть, я еще недостаточно читал на ext3 :-)

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

Вывод

  • совершить параметр, казалось, мало изменился, поэтому мы оставляем это на 5 секунд.
  • Мы собираемся с кэшем записи на диск, Барьер = 0, а также Данные = заказаны, Я читал некоторые вещи в Интернете, которые думали, что это плохая настройка, и другие, которые, казалось, думали, что это должно быть дефолтом во многих ситуациях. Я думаю, самое главное, что вы принимаете обоснованное решение, зная, какие компромиссы вы делаете.
  • Мы не будем использовать синхронную прагму в SQLite.
  • Настройка SQLite размер кэша прагма, чтобы DB поместила в память улучшенную производительность на некоторых операциях, как мы и ожидали.
  • Вышеупомянутая конфигурация означает, что мы берем немного больше риска. Мы будем использовать API резервного копирования SQLite чтобы свести к минимуму опасность отказа диска при частичной записи: снимать моментальный снимок каждые N минут и поддерживать последний M вокруг. Я тестировал этот API при выполнении тестов производительности, и это дало нам уверенность в этом.
  • Если бы мы по-прежнему хотели большего, мы могли бы посмотреть на то, что сработало с ядром, но мы улучшили ситуацию достаточно, не дойдя туда.

Благодаря @Huygens для различных советов и указателей.


10
2018-03-26 23:47