Comments 7
Хмм... В raspberry pi часто видел что управляют GPIO через mmap. Интересно какие есть более быстрые альтернативы
При всех вышеперечисленных проблемах возникает вопрос - а есть ли случаи, когда использование mmap оправдано и даёт наилучшую производительность?
Так дизайн приложения проще. Отмапил файл - и всё, он как будто загружен. Не все сидят на 64-ядерных процессорах в сотню потоков на raid из десятка топовых SSD.
а есть ли случаи, когда использование mmap оправдано и даёт наилучшую производительность
zero-copy принцип. Когда у тебя вся база данных отображена в локальную память, то ORM строится очень просто - какой объект типа Клиент или Документ целиком, ну или строковые поля из него (это если каждое поле бизнес объекта это отдельный value со своим key) реализуются просто как указатель на нужный адрес в этой самой mmap, т.е. просто ссылаются на участок в файле базы данных. Ничего никуда копировать, пересылать по сети и преобразовывать не нужно, просто сразу ссылаешься на нужный адрес в файле с данными и все. И перебирая запросом сотни тысяч записей - тебе не нужно каждый раз конструировать (аллоцировать) и удалять эти самые бизнес-объекты.
Но когда сервер баз данных живет в отдельном процессе и обменивается с приложением данными через сетевой сокет, то действительно, никакого особого смысла в mmap() нет, ибо натужное копирование данных неизбежно.
Естественно - нужно понимать, что такая mmap() база данных может жить только в режиме read/only, а изменения в базу данных лучше реализовывать через отдельный буфер с изменениями, и уже потом write(), как защита от dangling pointer, reuse after free и подобного, плюс логирование изменений. Об этом (read/only mmap() + write() одновременно) авторы этой чудесной статьи с синтетическими тестами в выводах несколько умалчивают, предпочитая пугать ну очень страшным mmap(), обязательно потеряющими все ваши данные.
Да, mmap() в разумном применении может жить только как read/only, ну а т.к. 99.9% операций с БД и так идут только в режиме чтения, запросы-отчеты и т.д., то применение его вполне оправдано, если у тебя конечно не про конкурентный рандомный перекрестный доступ 100 потоков на 100 особо быстрых NVMe в RAID-0 массиве с инвалидацией TLB (шардирование? партицирование? нет, не слышали!)
А вот read/write mmap() - это скорее сценарии кеширования, когда персистентная консистентность (?) не нужна и данные можно относительно безопасно потерять, пересоздав после рестарта.
Заголовочек кликбейтным получился, даже в оригинале явно написано что рассматривается кейс СУБД. Ожидал тут увидеть что-то менее специфичное.
Так и не нашёл ответ на вопрос: "Что же делать, если не использовать mmap для высоконагруженных систем?". Так же не нашёл перечня рекомендуемых библиотек в которых устранены все перечисленные недостатки mmap. Без предоставления альтернативных решений полезность статьи под вопросом.
Что я только что прочитал?
Почему тут mmap противопоставляется операциям с буфером? Откуда вообще между ними существенные различия в производительности (а не только в удобстве использования в разных сценариях)?
Почему MMAP не лучший выход