Автор статьи - инженер из VictoriaMetrics. На примере реального движка хранения VictoriaLogs разбирает выбор между системным вызовом pread и отображением файла в память mmap при чтении байтов из файлов.
Автор объясняет, что pread имеет заметную цену: каждый вызов - это дорогой переход из пользовательского пространства в ядро с копированием данных, и при миллионе мелких случайных чтений на один запрос теряется целая секунда процессорного времени только на пересечение границы ядра.
Mmap превращает эти чтения в дешевый доступ к памяти, но у него есть коварная проблема именно для Go: обращение к "холодной" странице вызывает major page fault, который блокирует поток ОС незаметно для планировщика Go. При достаточном числе таких блокировок программа может застопориться.
В итоге, оптимальное решение - это абстракция ReaderAt, которая через системный вызов mincore проверяет, находится ли нужная страница уже в оперативной памяти. Если да, то используется быстрый mmap-путь, а если нет - то безопасный pread. При этом результаты mincore кэшируются в битовой карте на срок до минуты.
В статье еще разбирается целая куча самых разных тонкостей
16.07.2026
Похожее
28.09.2026
C на Go
Интересный пропозал - добавить возможность сборки Go-пакетов, использующих cgo д...
25.09.2026
Бенчим джейсон
Автор на реальном API с нагрузкой 50M запросов/сутки)сравнивает производительнос...
24.09.2026
Rune
Команда Unstable Build заопенсорсила свою нативную IDE Rune, написанную на Go. ...
23.09.2026
Специализированные аллокаторы
В Go 1.27 появилась оптимизация выделения памяти для объектов размером до 80 бай...