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

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

После долгих поисков и поисков мы взглянули на параметры монтирования:

    data=ordered,barrier=1

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

    data=writeback,barrier=0

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

Вопросов

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

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

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

Благодарность

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

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

Хотя Тед Тсо (Ted T'so) объяснил, почему в первые дни ext3 произошло несколько повреждений данных (по умолчанию барьеры были отключены до Kernel 3.1 ), журнал размещается таким образом, что если не происходит перенос журнала журнала (журнал - циклический журнал) данные записываются на диск в безопасном порядке - сначала журнал, затем данные - даже если жесткий диск поддерживает переупорядочение записей.
По сути, было бы не повезло, что сбой системы или отключение питания происходит при переносе журнала журнала. Тем не менее, вы должны сохранить 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, поэтому его можно использовать в производстве.

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

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

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

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

• Кэш записи на диск. Современные диски имеют кэш-память 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 прагма синхронный = ON | OFF. Когда ON, SQLite будет гарантировать, что транзакция будет «записана на диск» перед продолжением. Отключение этого по существу делает другие настройки в значительной степени неактуальными.
• SQLite прагма cache_size. Управляет тем, сколько памяти SQLite будет использовать для хранения в кеше. Я попробовал два размера: один, где вся БД помещалась в кеш, и другой, где кэш был наполовину от максимального размера БД.

Узнайте больше о параметрах ext3 в документации ext3 .

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

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

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

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

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

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

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

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

Вывод

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

Спасибо @Huygens за различные советы и указатели.