commit -m "better"

😁13👍3🤩2🔥1

933 views21:08

https://vgel.me/posts/mmap-arena-alloc/ "mmap(1Tb): A Rust arena allocator (ab)using Linux overcommit" Чувак написал memory pool поверх mmap. Как обычно, 2/3 статьи восхваляют Rust, еще 1/3 - некрасивые врапперы над системным примитивом(mmap, в данном случае)…

Мне, пока я писал про memory pool на 1TB, вспомнилась история с одной нашей программой, которая ласково называется "движочек".

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

Как?

char buf[1000000];
MemoryPool pool(buf, sizeof(buf));
someFunc(pool);

В какой-то момент времени заметили, что программа снова утекает.

(почему снова? Потому что программа была сложная, со сложной судьбой, берущей свои начала в C. А санитайзеры с ней тогда еще не умели работать)

Долго с этим ковырялись, в конце концов выяснилось красивое:

Стеки выделялись с overcommit, и переиспользовались. Запросы, которые обрабатывала программа, могли сожрать как 2 килобайта стека, так и 16 мегабайт.

Поэтому, с течением времени, каждый стек из пула обрабатывал "тяжелый" запрос, и "закоммичивался" на свой полный размер.

Выглядело это как утечка.

Как это починили?

Рассматривалось несколько разных решений:

* тред-реклеймер, который бы с каким-то постоянным rate возвращал бы пулы в систему

* В конце каждого запроса бросать кубик, и, с небольшой вероятностью, возвращать(или munmap, или madvise, это неважно) память в систему.

* Завести счетчик использования для каждого пула.

Как конкретно было сделано в движочке, я не помню, коллеги, которые меня читают, если захотят, расскажут в комментариях :)

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

Чаще всего его надо использовать, когда у вас горит здесь и сейчас, и проблему надо решить быстро - за единицы и десятки минут. Например, разросся какой-то кеш в программе, и все начало oom-иться - можно добавить в code path на добавление элемента бросание кубика и очистку кеша.

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

🔥9👍4🐳3

1.06K views11:40