Застереження: нижче можуть бути неточності. Я дізнався про багато цього матеріалу, коли йду разом, тому візьміть його із щіпкою солі. Це досить довго, але ви можете просто прочитати параметри, з якими ми грали, а потім перейти до висновку в кінці.
Існує ряд шарів, де можна потурбуватися про продуктивність запису SQLite:
Ми дивилися на виділені жирним шрифтом. Конкретні параметри були
- Кеш запису диска. Сучасні диски мають кеш оперативної пам’яті, який використовується для оптимізації запису диска відносно спінінг-диска. Якщо це ввімкнено, дані можна записувати в блоки, що не впорядковуються, тому, якщо трапиться збій, ви можете отримати частково записаний файл. Перевірте налаштування за допомогою hdparm -W / dev / ... та встановіть його з hdparm -W1 / dev / ... (щоб увімкнути його та -W0 - вимкнути).
- бар’єр = (0 | 1). Багато коментарів в Інтернеті: "якщо ви працюєте з barrier = 0, не вмикайте кешування запису на диск". Ви можете знайти обговорення бар'єрів на веб-сайті http://lwn.net/Articles/283161/
- data = (журнал | впорядковано | записування). Подивіться на http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html для опису цих параметрів.
- вчинити = N. Повідомляє ext3 для синхронізації всіх даних і метаданих кожні N секунд (за замовчуванням 5).
- SQLite прагма синхронна = ON | ВИКЛ. Якщо ввімкнено, SQLite гарантує, що транзакція буде "записана на диск" перед продовженням. По суті, вимкнення цього параметра робить інші параметри в значній мірі неактуальними.
- SQLite прагма cache_size. Контролює, скільки пам'яті використовує SQLite для кешу в пам'яті. Я спробував два розміри: один, де весь БД помістився б у кеш, і той, де кеш був половиною максимального розміру БД.
Детальніше про параметри ext3 читайте в документації на ext3 .
Я проводив тести на ефективність за низкою комбінацій цих параметрів. Ідентифікатор - це номер сценарію, про який йдеться нижче.
Я почав із запуску з конфігурацією за замовчуванням на моїй машині як сценарій 1. Сценарій 2 - це те, що я вважаю "найбезпечнішим", а потім спробував різні комбінації, де це доречно / запропоновано. Це, мабуть, найлегше зрозуміти з картою, яку я закінчив, використовуючи:
Я написав тестовий скрипт, в якому було здійснено багато транзакцій, із вставками, оновленнями та видаленнями, і все це на таблицях із лише INTEGER, лише TEXT (із стовпцем id) або змішаним. Я кілька разів запускав це по кожній з конфігурацій, наведених вище:
Найнижчі два сценарії - №6 та №17, які мають "прагму синхронний = вимкнено", настільки не дивно, що вони були найшвидшими. Наступні групи з трьох - це №7, №11 та №19. Ці три кольори виділені синім кольором на "карті конфігурації" вище. В основному конфігурація - це кеш запису на диск, barrier = 0, а дані встановлені на щось інше, ніж на 'journal'. Зміна фіксування між 5 секундами (# 7) та 60 секундами (# 11), здається, мало має значення. У цих тестах, здається, не так вже й багато, якщо якась різниця між даними = впорядковано та даними = записом, що мене здивувало.
Тест на змішане оновлення є середнім піком. Існує група сценаріїв, які на цьому тесті явно повільніші. Це всі з даними = журнал . Інакше між іншими сценаріями не так вже й багато.
У мене був ще один тест на терміни, який робив більш неоднорідну суміш вставок, оновлень та видалень для різних комбінацій типів. Вони зайняли набагато більше часу, тому я не включив її до вищевказаного сюжету:
Тут ви бачите, що конфігурація зворотного запису (№19) трохи повільніше, ніж впорядковані (№7 та №11). Я очікував, що скорочення буде трохи швидшим, але, можливо, це залежить від ваших моделей запису, а може, я просто ще не прочитав достатньо на ext3 :-)
Різні сценарії були дещо репрезентативними для операцій, зроблених нашою програмою. Після вибору короткого списку сценаріїв ми провели тестування хронометражу з деякими з наших автоматизованих тестових наборів. Вони відповідали наведеним вище результатам.
Висновок
- Параметр фіксації, здавалося, мало змінився, тому ми залишаємо це в 5s.
- У нас йде кеш запису диска, barrier = 0 , а дані = впорядковані . Я читав деякі речі в Інтернеті, які вважають, що це погана установка, а інші, які, здається, вважають, що це має бути типовим у багатьох ситуаціях. Я думаю, що найважливіше - ви приймаєте усвідомлене рішення, знаючи, які компроміси ви робите.
- Ми не збираємось використовувати синхронну прагму в SQLite.
- Встановлення прагми cache_size SQLite таким чином, щоб БД помістився в пам’яті для покращення продуктивності деяких операцій, як ми очікували.
- Наведена вище конфігурація означає, що ми ризикуємо трохи більше. Ми будемо використовувати API резервного копіювання SQLite, щоб мінімізувати небезпеку виходу з ладу диска при частковому записі: робити знімок кожні N хвилин і тримати останній M навколо. Я тестував цей API під час запуску тестів на ефективність, і це дало нам впевненість піти цим шляхом.
- Якщо ми все-таки хотіли більшого, ми могли б розглянути можливість спілкування з ядром, але ми вдосконалили речі, не ходивши туди.
Завдяки @Huygens за різні поради та вказівки.