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

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

Хотя Тед Т'со объяснил почему в первые дни ext3 произошло небольшое повреждение данных (по умолчанию барьеры были отключены до ядра 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:

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

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

Подробнее о параметрах ext3 читайте в документация ext3.

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

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

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

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

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

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

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

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

Вывод

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

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