Ну вот я в эту сторону и думаю, но если у меня там будут строки в рантайме создаваться, то всё равно они будут новую память "откусывать", а не переиспользовать буфер из пула
Ну обычно создаётся один буфер на весь запрос и потом с ним работают. Что бы каждый создавать новый буфер
Ну во всяких C и товарищи с этим проще. А в питоне те же строки имутабельны, и я не могу взять из пула словарик или объект, и присвоить его полю новую строку так, что бы она легла в памяти на место старой.
Ну вот я в эту сторону и думаю, но если у меня там будут строки в рантайме создаваться, то всё равно они будут новую память "откусывать", а не переиспользовать буфер из пула
Ну во всяких C и товарищи с этим проще. А в питоне те же строки имутабельны, и я не могу взять из пула словарик или объект, и присвоить его полю новую строку так, что бы она легла в памяти на место старой.
можно написать обертку над bytearray и сделать билдер
А как сказать балансеру, что он должен новые запросы слать в новый контейнер, но не обрывать имеющиеся запросы к старому? И потом ещё как-то определить, что все запросы к старому закончились, что бы удалить его?
а почему бы не написать простенький балансер на Go или Rust?
Пока я грешу на всякие "объекты", которые я создаю в процессе обработки запроса пользователя и сохраняю в "глобальный" стейт (в некий менеджер, который лежит в объекте приложения). Скорее всего вот такие объекты и создают "фрагментацию".
systemd может по условиям макс памяти перезапускать процесс, а мягкий shutdown существующих коннектов в существующем процессе, чтобы новые обрабатывал новый навернео можно несложно сделать. вот что сходу попадалось https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation
systemd может по условиям макс памяти перезапускать процесс, а мягкий shutdown существующих коннектов в существующем процессе, чтобы новые обрабатывал новый навернео можно несложно сделать. вот что сходу попадалось https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation
Просто была необходимость одну самопальную фигню изолировать от основной системы - в итоге просто в подмане стартует tmux и все что надо в разных окнах.