В чем я уверен:
- Я работаю с Java/Eclipse в Linux и пытаюсь хранить на диске очень большое количество пар ключ/значение размером 16/32 байта соответственно. Ключи полностью случайны, сгенерированы с помощью SecureRandom.
- Скорость остается постоянной на уровне ~ 50000 вставок в секунду, пока не достигнет ~ 1 миллиона записей.
- Как только этот предел достигнут, процесс Java колеблется каждые 1-2 секунды от 0% ЦП до 100%, от 150 МБ памяти до 400 МБ и от 10 вставок в секунду до 100.
- Я пробовал и с Berkeley DB, и с Kyoto Cabinet, и с Btrees, и с Hashtables. Те же результаты.
Что может способствовать:
- Пишет на SSD.
- На каждую вставку приходится в среднем 1,5 операции чтения — постоянно чередующиеся операции чтения и записи.
Я подозреваю, что хорошая скорость 50000 сохраняется до тех пор, пока не будет достигнут какой-то предел кеша/буфера. Тогда большое замедление может быть связано с тем, что SSD не обрабатывает смешанные операции чтения/записи, как это предлагается в этом вопросе: Хранилище ключей и значений с малой задержкой для SSD.
Вопрос:
Откуда может быть такое сильное замедление? Это не может быть полностью вина SSD. Многие люди с радостью используют SSD для высокоскоростного процесса БД, и я уверен, что они много смешивают чтение и запись.
Спасибо.
Редактировать: я удалил все ограничения памяти, и у процесса java всегда есть место для выделения дополнительной памяти.
Изменить: удаление чтений и выполнение только вставок не меняет проблемы.
Последнее редактирование: для записи, для хэш-таблиц это, похоже, связано с первоначальным числом сегментов. В кабинете Киото это число не может быть изменено и по умолчанию равно примерно 1 миллиону, поэтому лучше получить число прямо во время создания (от 1 до 4 раз больше максимального количества записей для хранения). Для BDB он предназначен для постепенного увеличения количества сегментов, но, поскольку он потребляет ресурсы, лучше заранее определить количество.