TGViewer
Бессонный кодер Бессонный кодер @sleeplesscode · 4.25K subscribers
Post #637 3.17K
Бессонный кодер Что может быть лучше технического поста? Технический пост, за которым стоит бэкграунд трёх дней мучений! Появилась у меня необычная потребность — ускорить выполнение одного метода. Изучив его работу, я понял: можно добиться ускорения через внедрение кэша.…
Дальше начался метод научного тыка. Сократил объём операций до 56 250 000 и начал тестировать разные гипотезы. Вот что получилось:

Результаты:
База (2 ГБ, batch = 1000): 8m 11s
Расширенный Block Cache (10 ГБ): 7m 59s
Уменьшенный batch (500): 8m 09s
Увеличенный batch (2000): 8m 06s
Лексикографически отсортированный batch: 7m 57s
Лексикографически отсортированный весь get: 7m 57s
Сокращение потоков вдвое: 7m 18s
Увеличение потоков вдвое: 9m 32s
Увеличение параллелизма и фоновых задач RocksDB: 8m 05s


Что стало ясно:
1. Block Cache:
Увеличение с 2 до 10 ГБ дало прирост всего ~2%.
➝ Значит, либо данные не влезают в кэш, либо узкое место — не RAM.

2. Batch size:
Изменения в пределах 500–2000 почти не влияют.
➝ Значит, размер уже оптимален под текущий паттерн доступа.

3. Сортировка:
Минимальный выигрыш от сортировки ключей (~14 секунд).
➝ Либо ключи уже достаточно локализованы, либо RocksDB сам всё делает неплохо.

4. Потоки:
Вот где интересно: меньше потоков → быстрее (7:18), больше потоков → медленнее (9:32).
➝ Классический bottleneck по диску или lock'ам:
➝ меньше потоков → меньше переключений и блокировок,
➝ больше потоков → хаос и случайные I/O.

5. Параллелизм RocksDB:
Изменение этих параметров почти не повлияло.
➝ Узкое место в другом.


Когда идеи начали заканчиваться, пришла мысль — а что если всё загрузить в память и забыть про диск?
Ну... не хватило 30 ГБ ОЗУ 😃 Больно, больно.

И тут чёрт меня дёрнул проверить версию JNI-обёртки.
Оказалось — она отстаёт на 2 мажорных версии. Обновил с RocksDB JNI 8 → 10 и...

БАХ — 833 171 операций в секунду с диска.
Время выполнения метода: 390 секунд.
ПОБЕДА.


🧠 Итого:
Три дня, куча боли, и в итоге:
- Ускорение метода в десятки раз
- Глубокое погружение в RocksDB
- Новые знания о высоконагруженных системах

А теперь слово моему копилоту:
Итоги оптимизации:
Обновление rocksdbjni дало основной прирост
Точное количество потоков имеет критичное значение
Сортировка ключей даёт минимальный, но стабильный прирост
Batch и cache — важны, но эффект умеренный
Использование NVMe SSD — must-have

Что дальше?
Архитектурные изменения: шардирование, горизонтальное масштабирование
Или full in-memory при небольших объёмах


Именно вот этим и интересна разработка в целом, это целый логический квест, где ты не знаешь что будет дальше, но точно уверен, главная ошибка тут - ты.

#tech
  • ❤ 26
  • 🔥 5
  • ⚡ 3
  • 👾 2
  • ❤‍🔥 1
  • 🕊 1
  • 🆒 1
More from @sleeplesscode
  1. Oct 2, 2026⚡️ JavaScript, архитектура и ИИ: о чем будут говорить на юбилейной HolyJS 2026 Autumn 📆 2…
  2. Oct 1, 2026Post #914
  3. Sep 18, 2026Post #913
  4. Sep 17, 2026Post #912
  5. Sep 15, 2026Post #911
  6. Sep 14, 2026Post #909
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →