Для LevelDB, как я могу получить производительность произвольной записи, такую же, как заявленный «официальный» отчет о производительности?

Question

На официальном сайте leveldb (http://code.google.com/p/leveldb/) есть отчет о производительности. Я вставил, как показано ниже.

Ниже приведен официальный тест leveldb

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

< sizesНастройка

Мы используем базу данных с миллионом записей. Каждая запись имеет 16-байтовый ключ и 100-байтовое значение. Значения, используемые эталоном, сжимаются примерно до половины своего исходного размера. LevelDB: версия 1.1

ЦП: 4 x Intel (R) Core (TM) 2 Quad CPU Q6600 @ 2,40 ГГц

CPUCache: 4096 КБ

Ключи: по 16 байт

Значения: 100 байт каждое (50 байт после сжатия)

Записей: 1000000

Исходный размер: 110,6 МБ (ориентировочно)

Размер файла: 62,9 МБ (ориентировочно)

Эффективность записи

Тесты «заполнения» создают новую базу данных в последовательном или случайном порядке.

Тест "fillsync" сбрасывает данные из операционной системы на диск после каждой операции; другие операции записи на некоторое время оставляют данные в буферном кэше операционной системы. Тест «перезаписи» выполняет произвольную запись, обновляя существующие ключи в базе данных.

fillseq: 1,765 микрос / оп; 62,7 МБ / с

fillsync: 268,409 микрос / оп; 0,4 МБ / с (10000 операций в секунду)

fillrandom: 2,460 микросекунд / операцию; 45,0 МБ / с

перезапись: 2.380 микросекунд / операцию; 46,5 МБ / с

Каждая операция, указанная выше, соответствует записи одной пары ключ / значение. То есть, эталонный тест произвольной записи составляет примерно 400 000 операций записи в секунду .

Ниже приведен тест "Мой leveldb"

Я провел несколько тестов для leveldb, но получил скорость записи в 100 раз меньше, чем в отчете.

Вот мои настройки эксперимента:

1. Процессор: Intel Core2 Duo T6670 2,20 ГГц
2. 3,0 ГБ памяти
3. 32-битная Windows 7
4. без сжатия
5. options.write_buffer_size= 100 МБ
6. options.block_cache= 640 МБ

Я сделал очень просто: я просто поместил 2 миллиона {ключ, значение} и не читал вообще. Ключ - это байтовый массив, состоящий из 20 случайных байтов, а значение также представляет собой байтовый массив со 100 случайными байтами. Я постоянно добавляю новый случайный {ключ, значение} 2 миллиона раз без каких-либо дополнительных операций.

В своем эксперименте я вижу, что скорость письма снижается с самого начала. Мгновенная скорость (измерение скорости каждых 1024 записей) колеблется от 50 до 10 000 / с. И моя общая средняя скорость записи для 2 миллионов пар составляет около 3000 / с. Пиковая скорость записи - 10 000 / с.

Поскольку в отчете утверждалось, что скорость записи может составлять 400 000 / с, скорость записи моего теста в 40–130 раз ниже , и мне просто интересно, что не так с моим тестом.

Мне не нужно вставлять сюда свои тестовые коды, это очень просто, у меня есть цикл while 2 миллиона раз, а внутри цикла для каждой итерации я генерирую 20 байт ключа и 100 байтов значения, а затем поместите их в базу данных leveldb. Я также измерил время, потраченное на генерацию {key, value}, оно стоит 0 мс.

Кто-нибудь может мне с этим помочь? Как я могу достичь скорости записи 400 000 / с с помощью leveldb? Какие настройки мне следует улучшить?

Спасибо

Более того

Я только что запустил официальный файл db_bench.cc на моем компьютере. Это в 28 раз медленнее отчета.

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

Answer 1

У вас есть 2 миллиона пар "ключ-значение", и каждая пара "ключ-значение" составляет в общей сложности 120 байт, поэтому 2 миллиона * 120 байт= 228 МБ данных! Ваш кеш составляет 640 МБ, поэтому вполне возможно, что все ваши данные все еще находятся в ОЗУ и никогда не попадали на диск. Как заметил Кицунэ: ваше оборудование далеко не так быстро, как то, с которым тестировал Google, и если бы у Google был такой же размер кеша, это легко могло бы дать разницу в 30 раз.

Другие возможные проблемы:

• Трудно точно сказать, насколько «случайными» были ключи: LevelDB работает по-разному в зависимости от распределения ключей (даже если оно «случайное»).
• 20-байтовые ключи будут менее эффективны, чем 16-байтовые ключи, потому что они также не выравниваются.
• В зависимости от вашего жесткого диска скорость записи на него может быть ниже ( проверьте свое ).

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

Answer 2

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

• Ваш ЦП примерно в 9 раз слабее 2xCores@2,2GHz по сравнению с 16xCores@2,4GHz
• Ваш жесткий диск и диск официального эталонного теста не упоминались (оптоволоконный NAS, твердотельный накопитель SSD или жесткий диск HDD).

Нельзя сравнивать яблоки с апельсинами или яблоки с [неизвестным фруктом].