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

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

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

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

Настройка

Мы используем базу данныхс миллионом записей. Каждая запись имеет 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 МБ (по оценкам)

Производительность записи

Тесты "fill" создают совершенно новую базу данных, либо впоследовательный или случайный порядок.

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

fillseq: 1.765 micros / op;62,7 МБ / с

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

, случайное заполнение: 2,460 микро / операция;45,0 МБ / с

перезапись: 2,380 мкс / с;46,5 МБ / с

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

Ниже приведен тест My 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 раз медленнее, чем отчет.

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

Ответы [ 2 ]

3 голосов
/ 22 февраля 2012

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

Другие потенциальные проблемы:

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

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

1 голос
/ 22 февраля 2012

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

  • Ваш процессор в ~ 9 раз слабее 2xCores@2.2GHz против 16xCores@2.4GHz
  • Ваш жесткий диск и диск официального теста производительности не упоминались (оптоволоконный NAS против твердотельного накопителя SSD против жесткого диска жесткого диска)

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

...