#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

Most3 <q> Hi

HappyUser Всем привет

HappyUser Где я могу задать технический вопрос по i2pd

HappyUser ?

Leopold Привет, здесь)

orignal задавай если действительно технический

HappyUser Здорово. Делаю просирующий шлюз для доступа к i2p зайтам из вне. <site>.proxy.i2p.com (Домен как пример). Проблема следующая. Некоторые сайты в настройках веб сервера устанавливают rate limit на входящий уникальный идентефикатор из i2p сети. Е

HappyUser сть ли какой то механиз созданию уникальных маршрутов?

HappyUser В торе это делается с помощью указания уникального username для socks5

orignal а более конкретно?

orignal тебе нужен уникальный .b32 адрес или что?

HappyUser curl --socks5-host <unique_username>@127.0.0.1:9050 httpbin.org/get В такой конструкции u1 всегда будет иметь ip1, u2 всегда ip2 и т.д.

orignal я просто не понял твоего вопроса

HappyUser Т.к. тор строит уникальные маршруты исходя из уникальности proxy_username

orignal нее тут такого нету

orignal но ты можешь сделать много прокси тоннелей

HappyUser Это касается как выхода в белый интернет, так и при работа с .onion доменами. Там работает принцым уникальных circuit_id при работе с haproxy

orignal в i2p нет выхода в белый интернет. точка.

HappyUser orignal, имеешь ввиду заспавнить N i2pd процессов?

orignal нет в одном процессе насоздавать несколько прокси тоннелей

HappyUser Выглядит как решение, как мне это сделать? И есть ли механизм динамического создания без перезапуска процесса?

orignal у каждого будет свой адрес

HappyUser Есть ли какой нибудь управляющий порт с интерфейсом?

orignal можно через сэм или боб но надо клиенский код писать

HappyUser Можно ссылку?

orignal geti2p.net/en/docs/api/samv3

orignal добваление тоннелей через i2pcontrol быда такая идея

orignal пока не реализовано

orignal некогда как обычно

HappyUser Так если такого механизма нет, как мне поможет sam?

orignal так у сэма есть

HappyUser Получается единственное решение это запуск N тунеллей внутри процесса

orignal или писать клиентский код сэма

HappyUser Я правильно понимаю, что в таком случае каждыф тоннель в сегменте 1 процесса будет иметь уникальный порт подключения?

orignal твой прокси содает уникальный адрес для клиепнта а запросы отсылает как STREAM CONNECT

orignal правильно

HappyUser Тогда последний вопрос

HappyUser Как i2pd обслуживает тунели? Асинхронно или синхронно?

orignal а более конкретно в чем вопрос?

HappyUser При большом трафике, если я хочу заспавнить условные 100к тунеллей. Будет ли лучше запустить 10 процессов по 10к тунеллей

HappyUser Или 1 процесс на 100к тунелей

orignal без разницы

orignal гнлавное чтобы мощностей хватало

orignal тоненли работают независиом друг от друга

HappyUser Разница как раз таки есть, поэтому я спрашиваю как i2pd обслуживает эту тунели

orignal ну там несколько уровней

HappyUser Процесс в любом случае создает сокет для работы с пакетами.

HappyUser Сокеты должны опрашиваться

HappyUser Как правило это select, poll, epoll

orignal <orignal> ну там несколько уровней

orignal там 4 уровневый стек протоколов

orignal и на каждом уровня своя ситуация

orignal более того у тебя тоннели как правило сидят на одних и тех же траспортах

orignal во первых меньше ресурсов во вторых майору сложнее трафик анализировать

HappyUser Понятно, тогда нужно спавнить N процессов и делать балансировку

orignal не нужно

orignal как раз наоброт

orignal лучше много тоннелей в одном процессе

orignal много процессов на одном IP можешь бан получить

HappyUser Я к тому, что при задаче в 100к тунелей (условно)

HappyUser бан сети?

orignal тебя другие узлы сети будут банить

HappyUser Это не проблема, я просто у провайдера пул адресов выкуплю

orignal за 100K тоннелей кстати тоже

orignal вот с этого и надо начинать

orignal если у тебя есть много IP то разумеется лучше ранзные процессы

orignal на каждом свой

HappyUser Сервер то один будет

HappyUser Просто будет пул адресов к нему подключен через сетевое оборудование

HappyUser с вирт интерфейсами

orignal тут особой разницы нет

HappyUser Какое среднее значение тунелей перед блокировкой разрешено?

orignal 10 запросов за 50 секунд вроде у лжавистов

HappyUser Не густо

orignal у нас нет лимита такого

orignal запрос на постороение разумеется

HappyUser Ну я понял уже)

orignal мы то с любым потоком справляемся а они нет

HappyUser Не расчитан ваша технология на центровые шлюзы, где будет много клиентов на 1 процессе

HappyUser Спасибо за ответы и ясность

HappyUser Будем ждать динамическое управление тунелями

orignal да я давно хочу это сделать

orignal запрос через i2pcontrol JSON-ом

HappyUser Много там делать? Есть спецификация по интерфейсам?

HappyUser Мб я вам сделаю :D

HappyUser Вообще если вы закроете N проблем, то к вам весь тор можно перетянуть

HappyUser Я этому сильно поспособствовать могу

orignal ну смотри есть ClientContext.cpp там понятно как создаются тоннели из конфига

orignal надо то же самое вызывать из I2PControl.cpp по запросу

orignal а параметры соотвественно в JSON передавать

orignal технически ничего сложного

HappyUser Ну понятно, взять функции is ClientContext, написать rest api и сериализацию данных к ним

HappyUser На досуге гляну

HappyUser orignal, По расширению вообще интересная тема вам?

HappyUser Из наболевшего, по тору разрабы дети разбалованные. Сколько с ними не общайся, приходишь к выводу что это чисто комерческий продукт. Они делают продукт под своих закрытые задачи, а публичная версия как один большой тестовый с

HappyUser тенд

orignal у нас другая проблема

orignal просто времени на все нет

HappyUser Крупные проекты с лютыми костылями масштабируются

orignal по расширинию естественно инетресная

HappyUser Давайте общаться тогда

orignal короче к теме разговора

orignal есть идея вешать клиентские тоннели на юиксные сокеты

orignal чтобы порты на занимать

R4SAS бессмысленно

R4SAS единицы поддерживают сокеты

orignal а какой нибудь прокси?

orignal типа provoxy

orignal у него вход будет один а раскидывает на разные выхолы

acetone orignal: в последнем релизе появилась новая фича SAM для UDP. В документации вроде как этого нет. Как оно должно выглядеть?

orignal она там всегда была

orignal называется датаграммы

orignal в послденем релизе просто стало можно задавать порт явно

R4SAS он вроде не поддерживает

orignal кто?

R4SAS privoxy

orignal проксирование входяших TCP на юниксы?

R4SAS при чем здесь проксирование

R4SAS самой поддержки юниксовых сокетов в программе нет

orignal жаль

Vort захотел я сегодня проверить две гипотезы:

Vort 1. что постоянный рост потребления памяти i2pd вызван не потерями указателей, не жиреющими контейнерами, а фрагментацией кучи

Vort 2. что пики потребления памяти оставляют заметный след на структуре кучи. то есть, пик пришёл, пик ушёл: чистое потребление осталось тем же, а общее - выросло и не желает идти вниз

Vort первое предположение подтвердилось практически полностью. сделал я график, на котором видно примерно постоянное чистое потребление и растущее общее

Vort со вторым предположением интереснее - похоже, что некоторые пики замусоривают кучу сильно, а некоторые - слабо. так что подтвердилось частично

Vort вот такой график получился: paste.i2pd.xyz/?52d8de2b738a0479#AuT8czYCVzmsYyXfcFaHpCkEWFJQA68kfPfL5Y6jbGX9

Vort подтверждение пункта №2 видно около 12:10 и 13:45

orignal какие будут предложения?

orignal переписать пул как то иначе?

Vort но собрал я не только общую статистику, но и по всем блокам. так что можно разбираться детальнее. для начала сделал видео с участием кучи i2pd:

Vort paste.i2pd.xyz/?93534e9a331208ac#5jWoSLDo5KsrBBZRUMRsT2ZBxTbNou7SCGfDFC7NEs42

Vort видео не сильно информативное, особенно учитывая, что его пришлось сильно пережать для загрузки. но, может, пригодится

Vort "<~orignal> какие будут предложения?" разобраться, почему некоторые всплески потребления плохо влияют на кучу

orignal так вопрос в ченм

orignal почему они вообще влияют если мы берем из пула

Vort я пока что так и не понял, как пул помогает с фрагментацией. ускоряет выделение памяти - да. а фрагментация тут при чём?

Vort так пулы же чистятся

weko [14:26:36] <orignal> мы то с любым потоком справляемся а они нет

weko Не думаю что с любым. Лимит нужен, он логичен, но должен быть адекватным

orignal так в пулах чистится только лишнее

orignal что задействовано в данный момент оно остается

Vort пришёл пик, наполнился пул, ушёл пик - очистился пул. и что с этого?

orignal ну допустим

Vort ну суть пика в том, что он уходит

Vort а срач остаётся

orignal вот я и думаю что можно сделать

Vort вот что сделать - я пока не знаю

Vort но как минимум, теперь есть уверенность, что проблема именно в фрагментации кучи

weko [14:29:30] <orignal> да я давно хочу это сделать

weko [14:29:46] <orignal> запрос через i2pcontrol JSON-ом

weko Было бы неплохо.

weko Я кстати как то думал пол идею регулирования клиентского b32 через прокси юзернейм. Просто забыл. Тоже было бы не плохо, упростило бы клиентский код очень сильно

orignal это я думаю можно сделать

Vort вот более качественный снимок последнего кадра видео: paste.i2pd.xyz/?74d993b751cbb869#6P3854TsWuiRSqmfUtyqGqxVcPSWGajUYyCJ3zjANF9k

Vort один пиксель = 96 байт.

orignal так я не понял фрагментация кучи по какому разумеру получается?

Vort интересует какое распределение у пустых блоков?

orignal интересует какого размера блоки порожадют фрагменациб

orignal да какие пустые в середине

Vort думаю, для этого стоит проанализировать один из пиков

orignal я просто пытаюсь понять в чем проблема с выделеним блоков

orignal я обычно блоки в 1.5K выделяю

Vort поизучаю значит пик на ~12:10

Vort ну про блоки на 60 с чем-то килобайт я рассказывал уже

Vort но может в данном случае они не виноваты, надо смотреть

orignal 60 с чем то килобайт это точно SSU2 а не NTCP2?

orignal в SSU2 же они короткие

orignal в отличие от NTCP2 нде бывают вплоть до 64K

Vort сейчас по логу часа гляну, я писал уже

Vort чата*

orignal еще 64k бывают длинные I2NP

Vort "62808 байт. источник - std::make_shared<I2NPMessageBuffer<I2NP_MAX_MESSAGE_SIZE> >()"

Vort ну как я уже сказал, может, эти блоки не виновны. пошёл анализ делать )

orignal ну да такое может быть но редко

weko orignal: с юзернейм прокси остаётся лишь модифировать код любой программы чтобы в прокси отправлялся разный юзернейм, минимальное изменение из возможных (внедрение того же SAM или i2pcontrol было бы сильно сложнее)

weko Так же я уже говорил, было бы неплохо реализовать пул туннелей, ещё не назначеных какому то b32, чтобы сильно уменьшить задержку при создании дестинейшенов. Для SAM можно сделать некий Meta Destination в котором будет настраиваеться пул и от него можно будет создавать

weko уже дестинейшены. Для i2pcontrol можно сделать что-то похожее. Для прокси настройку можно либо сделать в конфиге, либо может что-то придумать

weko Думаю, это важная вещь для продакшн-решений

weko Также всё же нужно решить проблему с глюками (зависания в потоке данных); тут у меня конкретных идей не много, но очевидно что нужно строже следить за потоком данных, опять же мультипоток тоже был бы кстати.

weko Насчёт обновления туннелей, моя идея такая:

weko 1) кнопка обновления конфигурации

weko 2) кнопка обновления всех transient ключей

weko 3) отдельная кнопка для каждого дестинейшена для обновления transient ключей

weko Ещё можно сделать общий пул туннелей для дестинейшенов, чтобы в случае быстрого просёра туннелей быстро подставить их. Можно было бы уменьшить количество туннелей на каждом дестинейшене.

orignal надо ументь дестинейшин строить как в сэме

weko Да

oruge__ <oruge__> что было в сети и2п 21 числа? Января

weko Атака на сеть была

R4SAS orignal: я помню что Vort писал про это, но можно ли как то заткнуть? paste.i2pd.xyz/?27bc7627351b0938#FgHR7MgB7GJBHgEoak1yGUD6X1R4bNZncN1iMnKNiCxN

orignal так в чем конкретно проблема?

Vort более точные данные: пик был [2023-03-13 12:12:30]: paste.i2pd.xyz/?67a0b76ec6251f6a#CHs9akyHeQyC4fTM8nTWdqvz5LtTcj155FZ7XMfvwkeb

R4SAS а хз. у него тут стек вообще странный

R4SAS 'initializing': conversion from 'size_t' to '_Ty2', possible loss of data

orignal какая строка в Family.cpp ?

Vort попёрли вверх блоки 1544 и 62808. потом 62808 ушли, 1544 остались. потом и 1544 ушли

R4SAS 91

R4SAS я так понимаю он орет на m_SigningKeys

R4SAS вероятно что на m_SigningKeys.size () + 1

Vort сейчас скрины кучи ещё докину за [2023-03-13 12:12:00] [2023-03-13 12:12:30] [2023-03-13 12:13:00] [2023-03-13 12:13:30]

orignal так это I2NP господа

orignal хотя нет они по 4K врое

Vort paste.i2pd.xyz/?d6efebe031134f28#8MgrzNAyTAiq3FVzuuAessParT326fUnQc5qZN4tb9er

orignal m_SigningKeys.size () замени на (int)m_SigningKeys.size ()

orignal все

Vort paste.i2pd.xyz/?aa47c8e40c790d5f#DkuxNwrh6CmZTodtWmDpnnZeyjXsCck6AhpjVEkYrsF9

Vort paste.i2pd.xyz/?d0c0ae5c9221964b#3GdfW2Vr54cHRuE5zC9vLyahfodz8wazap49uw3yd5qn

Vort paste.i2pd.xyz/?344e243f2e35f1ef#6rTYG72GnAvSe6hH33nYv6nbn6RMPV8YZpMxve6sq3PN

R4SAS orignal: ок

Vort "<~orignal> хотя нет они по 4K врое" I2NP_MAX_MESSAGE_SIZE = 62 килобайта

Vort const size_t I2NP_MAX_MESSAGE_SIZE = 62708;

orignal да

orignal но такие редко

R4SAS 62708 vs 62808

orignal обычно выделяется Short

orignal который 4K

Vort [2023-03-13 12:12:30]

Vort 3: 3077592 (49 * 62808)

Vort 49 штук было

Vort а вот пакеты SSU2 за тот же момент: 0: 4943888 (3202 * 1544)

Vort пики редкие, да, но гадят метко. (ну и в очередной раз скажу, что я не знаю, как это чинить)

Vort на мой взгляд, надо искать литературу по фрагментации динамической памяти

R4SAS а я в очередной раз отвечу "как"

Vort но сразу скажу - тема редкая. я даже инструментов не нашёл, пришлось самому писать

R4SAS пересозданием переодически

Vort "<~R4SAS> 62708 vs 62808 " потому что std::make_shared<I2NPMessageBuffer<I2NP_MAX_MESSAGE_SIZE> >()

R4SAS хочешь сказать 100 байт на make_shared?

Vort на I2NPMessageBuffer, который наследник от I2NPMessage

Vort так и наскребается

Vort "<~R4SAS> пересозданием переодически" пересозданием чего? я только про пересоздание кучи читал. но для i2pd это не подходит

R4SAS почему?

R4SAS можно просто переключаться на новую кучу с периодом времени ?

Vort много чего пересоздавать не надо

Vort ну и я не знаю, умеют ли так линуксы

Vort с синхронизацией потоков там тоже будет веселье

Vort в общем, теоретически, может и можно. но у меня большие сомнения

R4SAS так они все равно должны вычищаться, разве нет?

R4SAS куча не должна храниться вечно ведь

Vort там ведь практически все данные программы

Vort куда же она денется?

Vort регионы как-то создаются, но я в это ещё не влазил. ну и это фишка винды, хз что в линуксах

R4SAS i2np же

Vort что i2np? специальную кучу для него делать?

R4SAS так а разве это не i2np куча?

Vort это куча всего процесса i2pd

R4SAS ну тогда отдельно делать

Vort на то она и куча, что там всё валяется

Vort а вот это надо разбираться, что линуксы думают про кучи куч

Vort винде норм

Vort можно и вообще без куч обходиться для больших блоков. страницы памяти прямо выделять

Vort но это тоже специфика платформ

R4SAS top

R4SAS Blinded message

R4SAS было бы хорошо если бы он умел показывать подробную инфу на линях

R4SAS только я вот хз как то там можно подобным образом смотреть чего куда выделено

R4SAS learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapcompact?redirectedfrom=MSDN

WayBest @R4SAS ты пытаешься на винде профилировать?

orignal ну так какой вывод?

orignal делать пулы для I2NP?

orignal о кстати я понял что не так

orignal для NTCP2 мы распозднаем тоннельные сообщение и берем из пула

orignal а в SSU2 этого скорее всего не сделано

orignal а нет тоже есть такое

R4SAS WayBest: этим Vort занимается

orignal ну так какие выводы?

orignal оооо я кажется понял в чем дело

orignal допустим у деда на отсылку два тонлльных сообщения по 1K

orignal я пошдю два пакета по SSU2

orignal а дед разобьет второй на 2 фрагмента

R4SAS всм 2 фрагмента?

WayBest @Vort помощь нужна?

R4SAS это же 2 сообщения, и они как раз влезают

orignal R4SAS разница в том что я не режу на фргаменты а дед режет

orignal лучше пример с 3 сообещиями

WayBest а что мешает для совместимости нарезать?

orignal я пошлю 3 пакета а дед 2

orignal так все раюотает проблема в другом

orignal когда приходит фрагментрованное тоннельное сообщение я создаю обычное I2NP а не тоннельное из пула

R4SAS т.е. оно не туда куда надо пихается?

orignal нет все куда надо

orignal но не из пула а каждое сообщение созается из кучи

R4SAS и каков план решения?

orignal проверять в первом фрагменте

orignal что я и собираюсь сделать

R4SAS а если фрагментов будет более чем два?

R4SAS оно как то отображается в первом?

WayBest paste.i2pd.xyz/?c928ee4ff06791ba#4njJi1kuLW4kKgS6zto7J6gYJCz72yMCthcqGmWjBivL

orignal ну и что?

orignal все равно сообщение будет длиной 1K

WayBest ворнинги)))

orignal смысл именно в типа сообщения

WayBest ==15655== LEAK SUMMARY:

WayBest ==15655== definitely lost: 3,928 bytes in 3 blocks

WayBest ==15655== indirectly lost: 17,802 bytes in 104 blocks

WayBest ==15655== possibly lost: 0 bytes in 0 blocks

WayBest ==15655== still reachable: 1,563 bytes in 5 blocks

WayBest ==15655== suppressed: 0 bytes in 0 blocks

orignal это посто ноль

WayBest типа считаешь что утечек нет?

WayBest валгринду чет не нравится на памяти которая выделяется для хранения инфы об клиентах

WayBest как вы вообще такой огромный код поддерживаете я не представляю

WayBest как все держать в голове?

orignal ну так он же логически структурирован

orignal он же не просто код а разбитый на сущности

WayBest это понятно

WayBest но все сущности держать в голове

WayBest лось, а ты прогонял код через cppcheck?

WayBest я ща прогнал и там довольно много ворнингов по поводу инициализации в конструкторе

WayBest мб имеет смысл исправить все ворнинги которые cppcheck нашел?

WayBest и утечки уйдут

WayBest если они вообще были

orignal нет

WayBest + еще куча c стайл кастов

orignal мне некогда

WayBest что тоже не оч безопасно

orignal да не уйдут утечки

orignal потому что это реально не утечки

orignal а как правильно говорит Vort это фрагментация кучи

WayBest а если я поправлю ворнинги и кину пулл?

WayBest ну актуализирую код под стандарт языка

WayBest потому что я так понимаю там куча старых фишек используется чисто из-за экономии времени

WayBest ну кучу дебажить весело

WayBest то есть это системная ошибка выходит?

orignal тут надо логику выделения памяти менять

WayBest раз из-за фрагментации утечки типа появляются

orignal так это не утечки

WayBest ну это много переписывать придется

orignal это пробелы в куче

WayBest аа типа выглядит как утечка

orignal то есть память вернули

orignal а реально вернлось меньше

WayBest а по сути раздутие кучи

WayBest из-за пробелов

WayBest в целом логично

orignal потому что часть использовать нельзя

orignal это надо пулы переделывать

orignal более правильно

WayBest а почему система не дефрагментирует ее?

WayBest это будет медленно?

orignal дефигарментирует

WayBest или это на руках разработчика?

orignal когда памяти мало

orignal а когда памяти хоть жопой ешь то ей пох

orignal типа пусть растет

WayBest то есть в целом можно дернуть этот механизм вручную

orignal а кажется что память отжирается

WayBest в линуксе это так себе пашет

orignal возможно ка кто и можно

orignal но зачем?

orignal у меня на машине с 512M память не растет

WayBest чтобы жрало меньше

WayBest а нельзя тогда на процесс ограничение повесить?

WayBest как в жабе сделано

WayBest они размер кучи жестко задают

WayBest или это не поможет

orignal там это на уровне ядра

orignal это системная вещь

WayBest @HidUserZ есть идеи как дернуть дефрагментатор?

HidUserZ Какой

WayBest кучу надо дефрагментировать после освобождения

WayBest чтобы в систему возвращалось памяти столько сколько бралось

orignal это штука сидит в ядре

orignal так не надо это

orignal зачем?

HidUserZ При аллоцировании учитываются последующие пустые блоки

HidUserZ Я не слышал чтобы там была дефрагментация

HidUserZ orignal: что в ядре?

orignal HidUserZ лефрагментации кучи

WayBest дефрагментатор кучи

HidUserZ Куча это libc, ядро причем

WayBest я хочу запускать этот механизм после высвобождении памяти

WayBest чтобы блоки плотнее сидели

HidUserZ Ядро только mmap видит

orignal так ты объясни зачем?

orignal HidUserZ вопрос то в том почему на машине с 512M память не жрет

orignal а где памяти много то как слон

HidUserZ WayBest: ну я не помню чтобы в либс была дефрагментация

orignal возможно что то можно записать в какой нибудь файл в /proc

HidUserZ WayBest: погугли, может есть

WayBest @orignal /proc/sys/vm/drop_caches

WayBest 3

WayBest я так делаю

HidUserZ Кеш эт другое же

WayBest да но памяти становится больше

WayBest и процессы освобождают

WayBest на примере i2psnark хорошо видно

HidUserZ А рут не нужен?

WayBest вроде нужен

WayBest но можно проверить

HidUserZ Говорят в таких ситуациях пишут свой аллокатор

HidUserZ Либо можно найти готовый

WayBest тут проблема не в аллокаторе

WayBest а в фрагментации при освобождении кусков памяти

HidUserZ Так это аллокатор

WayBest хотя частично аллокатор

WayBest да

HidUserZ Malloc и free

WayBest нужно чтобы он впихивал в пустые места новые куски данных

HidUserZ Ну ищет пустые места и так

HidUserZ Но про дефрагментацию не слышал

WayBest лось, а данные имеют статичный размер?

orignal всякий разный

WayBest или там все плохо и блоки разной длины могут быть?

HidUserZ Там для разных размеров свои кучи

WayBest а нельзя стандартизировать и резать на равные блоки?

HidUserZ Даже для разных потоков, но в i2pd вроде один поток

WayBest чтобы при освобождении дырки одинаковые были

orignal думать надо тут

WayBest я могу спросить у преподов своих

WayBest они занимаются системной разработкой

WayBest мб подскажут чет

WayBest один параллельным программированием, другой линукс дрочит

WayBest причем я так понимаю от платформы еще зависеть будет?

HidUserZ jemalloc.net

HidUserZ Вот другой аллокатор к примеру

HidUserZ Говорят предотвращают фрагментацию

Vort "<WayBest> мб имеет смысл исправить все ворнинги которые cppcheck нашел?" там они бестолковые. я недавно смотрел - ничего интересного

R4SAS drop_caches -- такое делать, особено с "3" - вредно

Vort "<WayBest> а почему система не дефрагментирует ее?" потому что в c++ указатели "прибиты гвоздями". это не C#, где их можно таскать туда-сюда

HidUserZ Имеются в виду освобождённые блоки

HidUserZ Их таскать можно

Vort можно слить в один блок. вроде всё

HidUserZ Ну хотя да, дефрагментации нет

HidUserZ А сливать он умеет

HidUserZ WayBest: короч дефрагментации не существует

Vort на случай если кто-то захочет повторять мой эксперимент с записью размеров блоков кучи - за 10 часов набежало данных на 3.5 гигабайта. это с записью состояния каждые 30 секунд

Vort реже писать смысла мало - так можно пик потребления пропустить

orignal может нам выделять в пуле сразу пачками? тогд есть вероятность что они все будут рядом

orignal ну самом деле я просто этой темой еще не занимался