Освобождение памяти после статических переменных

@КиберСталкер21 · Регистрация: 13.11.2014

Студворк — интернет-сервис помощи студентам

Всем доброго времени суток)
Знааю знаю, избитая тема, но всё-таки хотелось бы прочесть что-то конкретное по этому поводу и вообще получше понять как это работает.
В общем и целом имеем на борту под виртуалкой "Centos 7" с "GCC 4.8.5" (поддерживается максимум C++14 стандарт) компилятором и пытаемся сделать так, чтобы у нас после выполнения функции произошло высвобождение памяти, которая ей выделилась. Потому-что перед стартом функции мы имеем в ОП 168 Кб, а после уже все 30 Мб. Хотелось бы как-то устранить это досадное недоразумение, ведь если и дальше так выстраивать работу программы, то после пары десятков вызовов различных ёмких функций у неё же никаких ресурсов ОП не хватит(
Собстно вот код для примера в main.cpp:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#include <iostream>
#include <vector>
 
#include <chrono>
#include <thread>
 
//небольшая функция, которая должна будет у нас стартануться через секунд 25 в основном теле программы
//отработать своё и успешно свалить в закат
int test_load_OP()
{
    int ik_ = 655357; //даём размерность будущего вектора, достаточно большую, 
    //чтоб мы могли точно увидеть разницу в ОП
    std::vector<std::string> hexCh; //для полного счастья у нас ещё и вектор типа string,
    //чтоб побольше неоптимальным образом занять ОП
 
    for (int i = 0; i < ik_; i++)
    {   //забиваем вектор всякой ерундой
        hexCh.push_back("sdf574 " + std::to_string(ik_));
    }
    //hexCh.resize(1); //тут мы уже просто пробовали по разному высвобождать память как вы видели
    //hexCh.clear(); //но ничего из этого увы не сработало
    //std::vector<std::string>().swap(hexCh);
    hexCh.clear();
    hexCh.shrink_to_fit();
    //malloc_trim(0);
    return 1;
}
 
int main(int argc, char* argv[])
{   //теперь в основном теле программы имитируем некоторую жизнедеятельность
    // и по умолчанию сначала выводим Hello word!
    //чтоб хотя-бы в консоли понимать, что она запустилась
    std::cout << "Hello word!" << std::endl;
    int irt = 0;
    while (irt < 5)
    {   //далее немного подождём, т.к. нам ещё надо в системный монитор заглянуть успеть 
        //или htop, а лучше и туда и туда, и зафиксировать расход ОП
        irt++;
        std::this_thread::sleep_for(std::chrono::milliseconds(5000));
    }
    int res_run_LoadOP = test_load_OP(); //Ok теперь пускаём имитацию отработки дорогой функции
    int ipewq = 5;
    //нуу и теперь небольшая имитация жизнедеятельности дальнейшей программы
    // пока мы не нажмём Ctrl+C в консоли
    //чтоб прекратить это безобразие)
    //а заодно пока оно идёт фиксируем увеличение ОП визуально)
    while (true)
    {
        ipewq++;
        ipewq--;
    }
    return 0;
}

Компилим всё это дело в командной строке:

Bash
1
g++ -std=c++1y main.cpp

И далее запускаем:

Bash
1
./a.out

И бежим в системный монитор, а заодно ещё открываем новое окно консоли с htop, находим везде наш процесс и начинаем бдить за сжиранием ОП.
А то что мы там увидим прикреплено в картинках в приложении.
Была естественно догадка, что это всё освободится, если чем-то забить память другим, НО чуда увы не произошло( Там вообще после 4Гб всё в своп полезло и стало хорошо подтормаживать, а 30Мб как были, так и остались на месте.
Да я конечно знаю про указатели и delete, НО мне интересно, а как в этом случае освобождать память?
//которая ещё и по идее сама должна была освободиться после выполнения функции, но чуда не произошло, да и вообще не предвидится на горизонте(
_
Да и вообще с чем связано такое поведение? Это особенности C++14 или так моя версия GCC с ним работает или это ещё всё и вкупе на не самой новой CentOS7? Откуда вообще у такого поведения ноги растут и как с этим бороться?

@КиберСталкер21 · 28.09.2023, 11:27 **[ТС]**

Сообщение от DrOffset

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

С радостью бы с вами согласился, да вот только прога потом может начать занимать столько, что всё остальное лезет в своп и ничего хорошего с высвобождением не происходит, а это не есть хорошо и надо что-то с этим делать.
Я учту ваш совет и постараюсь пооптимальнее страницы памяти высвобождать и занимать, да и вообще пооптимальнее использовать вызов функций. Но вы пока как-то так, так как есть критика по использованию по обязательному использованию выше перечисленных систем, чтоб на них точно оптимально работало, а далее уже по идее будет лучше, нуу или немного подгоним)

Добавлено через 1 минуту

Сообщение от Алексей1153

непонятно. У всех элементов вектора должен был вызваться деструктор

Аналогично надеялся на подобное, но видимо в той системе, где я это делаю что-то пошло не так и надо ковырять вручную(

@DrOffset · 28.09.2023, 11:28

Сообщение от КиберСталкер21

, да вот только прога потом может начать занимать столько, что всё остальное лезет в своп

Нет, не начнет, если вы не будете сами поддерживать такую активность по памяти.
Главное, что вам нужно понять: у вас все корректно освободилось, никакой std::string никакую память не зажимал. Память осталась у аллокатора и он отдаст ее, при первой же возможности.

Читайте больше специальных источников и не позволяйте себе делать поспешные выводы на основании первого впечатления.

@Aledveu · 28.09.2023, 11:37

КиберСталкер21,
Вы путает освобождение памяти когда вы вызываете деструктор для объекта или вызываете функцию free с передачей высвободившейся памяти обратно системе. Менеджер управления памятью в вашей программе не всегда и не сразу отдаёт память обратно операционной системе.

Если вы за один раз выделили большой кусок памяти а потом освободили его - то с большой вероятностью этот кусок памяти запрашивался у ОС и потом ей и вернулся. А если вы использовали много мелких кусков - то менеджер памяти продолжает хранить у себя информацию об этих кусках, хранит внутренние структуры данных о разделении памяти на эти мелкие куски и с большой вероятностью при их освобождении не отдаст их операционной системе а будет ждать пока вы снова не захотите выделить память в своей программе и тогда будет использовать эту память.

@DrOffset · 28.09.2023, 11:40

Сообщение от КиберСталкер21

где я это делаю что-то пошло не так и надо ковырять вручную(

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

Начинайте разбираться, не поддавайтесь на легкость сделанных выводов - это самообман.
https://azeria-labs.com/heap-e... mentation/
https://azeria-labs.com/heap-e... free-bins/

@КиберСталкер21 · 28.09.2023, 13:47 **[ТС]**

Сообщение от DrOffset

Главное, что вам нужно понять: у вас все корректно освободилось, никакой std::string никакую память не зажимал. Память осталась у аллокатора и он отдаст ее, при первой же возможности.

Хмм, ok обязательно почитаю и углублюсь в тему.
А пока просто для лишних буферов std::string везде повыставлял .clear() после использования, надеюсь это лучше чем ничего)

Добавлено через 2 минуты

Сообщение от Aledveu

...и с большой вероятностью при их освобождении не отдаст их операционной системе а будет ждать пока вы снова не захотите выделить память в своей программе и тогда будет использовать эту память.

Так а если там куча этих маленьких кусочков надробилось и всё остальное полезло в swap, тогда как быть? ...просто я бы хотел по максимуму этого избежать.

Добавлено через 4 минуты

Сообщение от DrOffset

На данном этапе вы можете сделать только хуже.

...надеюсь всё ещё не так плохо)
Пока я только на буферы всякие и временные строковые переменные понаставил .clear() после использования. И для некоторых больших прям объёмов заюзал std::shared_ptr<std::string> вместо обычного std::string с прописыванием потом .reset() после использования.
Нуу и скомпилил, запустил, тестирую как себя будет вести и сколько отжирать ОП + потом ещё запущу что-то ёмкое, посмотрю как и что в своп полезет, но пока вроде всё штатно, нуу и поменьше на десяток Мб из 500 стало жрать ОП)

@DrOffset · 28.09.2023, 14:26

Сообщение от КиберСталкер21

А пока просто для лишних буферов std::string везде повыставлял .clear() после использования, надеюсь это лучше чем ничего)

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

Сообщение от КиберСталкер21

И для некоторых больших прям объёмов заюзал std::shared_ptr<std::string> вместо обычного std::string с прописыванием потом .reset() после использования.

Это бессмысленное шаманство.
Вы не решаете так никаких проблем, вы просто переливаете ситуацию из одного стакана в другой.

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

Добавлено через 19 минут

Сообщение от КиберСталкер21

Так а если там куча этих маленьких кусочков надробилось и всё остальное полезло в swap, тогда как быть?

А как оно так получилось? Покажите хоть код. Может быть там в коде логическая ошибка просто или утечка. Тогда надо эту утечку фиксить, а не std::string на shared_ptr менять.

Добавлено через 3 минуты
В любом случае, то, что вы делаете искусственно в примере из шапки темы, никак не отражает ситуацию в вашем реальном приложении. Это только кажется, что там то же самое.
Т.е. не абстрактная какая-то неправильная работа std::string тут виновата, а именно баг или неэффективная реализация в вашем реальном коде.

@КиберСталкер21 · 28.09.2023, 15:51 **[ТС]**

Сообщение от DrOffset

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

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

Сообщение от DrOffset

Это бессмысленное шаманство...

Я был бы очень рад увидеть код того, как следует сделать, но пока его не увидел и пока решаю как умею и тем способом, что нашёл... и стараюсь это делать аккуратно, чтоб не много накосячить, т.к. времени на вычитывания того объёма спец.литературы у меня пока не очень(
...ии пока не оч. понимаю тоже почему там сложно привести пример кода на основе той програмки, что скинул в топике.
И вот её если расширить, то все остальные проги улетают в своп - это мы уже имели. Поэтому я начал элементарно с ухода от этого момента. Да там возможно вполне себе есть и ещё где-то утечки и я их ещё найду и устраню, но пока начал с этой.

Сообщение от DrOffset

А как оно так получилось?

Ооох) Это долгая история) Сомневаюсь, что она вам интересна) Но в общих чертах там происходит что-то вроде агрегации всех микросервисов под одно крыло, для чего делается куча синхронизаций между данными в них во всевозможных БД. И даже типо получается всю БД объединили в одну, НО в тоже время она на разных серверах и с разными API от разных микросервисов, которые в итоге взаимодействуют через друг друга через это глобальное приложение/сервис. Там мы в итоге имеем некоторое количество жёстких моделей данных, которые являются общими для всех сервисов и БД, но в тоже время все они могут подтягивать к ней свои дополнения, которые и хранят у себя, но и которые тоже можно от кого надо запросить - это уже более динамические модели и они подгружаются с сервисов. Ну так вот пока было замечено, что именно при синхронизации оно отжирает около 3Гб памяти в ОП, если её отрубить, то всё норм, врубаем и после пары дней имеем расход.
Собственно там мы и имеем кучу мелких функций и процедур, когда транслим данные из одного сервиса/бд в другой. В основном они касаются того, чтобы просто конвертировать некоторые форматы в удобный для тех или иных сервисов/бд, начиная от формата дат/времени и заканчивая переливом из json в xml/soap и обратно. Также там имеем в некоторых буферах и таблицы на N количество записей и столбцов. И вроде бы как они и чистятся, но моя тень сомнений пала них в первую очередь. Нуу и вот я выяснил, что они по крайней мере и показывают в htop, что забивают ОП.
Нуу и начал с них.
Я думаю если вы на CentOS7 попробуете воспроизвести тот пример, то прочувствуете о чём я говорю, там реально потом открываешь пару браузеров, особенно если у тебя 2Гб выставить ОП, и у тебя уже отожрано 500 Мб тем примером, то лезет в своп и ни разу не показывает, что освобождает там 500 Гб.

@DrOffset · 28.09.2023, 16:48

Сообщение от КиберСталкер21

почему там сложно привести пример кода на основе той програмки, что скинул в топике.

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

Добавлено через 8 минут

Сообщение от КиберСталкер21

И вроде бы как они и чистятся, но моя тень сомнений пала них в первую очередь

В общем понятно, есть большой проект, который тут нельзя показывать и вы думаете, что синтетический пример, который вы тут выложили, сможет как-то помочь решить эту проблему в большом проекте.
Только вот я уверен, что не поможет. Потому что явления разной природы. И возможно ваш большой проект можно починить только через существенный рефакторинг.
Главная загвоздка здесь в том, что вы ищете легких путей, начали с шаманства, авось что-то подкрутится. Но скорее всго если это и даст какой-то эффект, то незначительный, а истинная причина проблем так и останется нерешенной. В общем без действительной экспертизы в вашем проекте по-нормальному вам никто не поможет. Я могу только дать совет не рассчитывать, что через шаманство вы проблему победите и что не сделаете хуже.

@КиберСталкер21 · 28.09.2023, 17:01 **[ТС]**

Сообщение от DrOffset

Потому что в той программке нет никаких проблем. Нечего приводить.

...вот тут даже мне стало немного весело)
Хорошо, а почему у меня тогда своп забивался?
...или там не в этом проблема, а в чём-то другом? ...там нужно что-то заново программкой использовать и оно очистится или что? ...нуу нуже не мучайте меня в догадках.
Я честно стараюсь Вас понять, но пока так и не понял почему забитие свопа - это не проблема?

@КиберСталкер21 · 28.09.2023, 17:31 **[ТС]**

...или мне нет доверия, что всё лезет в swap?)
Вот немного скрина)
Собственно, что хочу по нему отметить, таки да я немного слукавил)
НО в целом прав остался, она в итоге хоть и понемногу отдавала съеденную у себя ОП, НОООО всё равно всё лезло в swap!(
Т.е. во время выделения ОП система сначала выгружает что-то в swap, а только потом пытается там на что-то воздействовать и где-то подчистить... с переменным успехом надобно сказать ииии это не очень устраивает(
Там на сервере и без моей программки достаточно всякого и отправлять их лишний раз в swap - это прям плохо(
Вот от этого бы я точно хотел уйти.
Если проблема этого кроется где-то в другом, там в системе, приоритетах процессов или чём-то ещё, то я бы очень хотел об этом узнать, чтобы далее всё корректно запускать и прочее.

Алексей1153 · 28.09.2023, 17:56

КиберСталкер21, а просто добавить ОЗУ не вариант? Хотя бы для теста, как оно будет себя вести

понятно, что программу это не исправит, но, возможно, "решит проблему"

@DrOffset · 28.09.2023, 18:21

Сообщение от КиберСталкер21

Хорошо, а почему у меня тогда своп забивался?

Ну вот вы выложили программу, которая забивает своп. Вы ее специально написали, чтобы забить его. Почему вообще такой вопрос? Он забивается, потому что вы написали для этой темы такую программу.

Ваша же рабочая программа, в отличие от этой, написана совершенно не для того, чтобы забить своп. Если он и збивается, то не нарочно.

А теперь вы почему-то поставили между этими программами знак равенства и думаете, что в рабочей программе у вас своп забился по той же причине, что и в этой тестовой. А я вам говорю, что нифига это не так.

@КиберСталкер21 · 28.09.2023, 18:33 **[ТС]**

Сообщение от Алексей1153

а просто добавить ОЗУ не вариант?

Я таки исхожу из масштабирования проблемы.
И нет ОЗУ добавить не вариант, оно там всё тупо сожрёт и всё. Там трабла в том, что сжирание идёт около 50-100 Мб при каждой синхронизации, а она проходит каждый день по 1 разу, месяц работы сервера и всё 3Гб куда-то ушло(
Можно конечно написать костыль с тупо перезапуском раз в месяц, но как-то хочется без этого вот всего.

@DrOffset · 28.09.2023, 18:34

КиберСталкер21, Естественно методы устранения проблемы для тестовой программы - это просто перстать выделять дофига памяти, и все, проблема решена.
А в рабочей вашей программе что нужно сделать нам неизвестно. Но возможно, возможно, и скорее всего, что микропотимизациями вы не отделаетесь. Т.е. недостаточно просто будет где-то что-то подкрутить и хоп - все работает. Вы же именно так хотите? Я же вам говорю, что так не будет. Потому что если уж большая боевая программа полезла в своп, то все эти shrink_to_fit и clear как мертвому припарка.

А что конкретно вам советовать, если здесь нужна экспертиза вашего проекта?
Советы могут быть только общие
1) Выясните настоящую причину того, что программа полезла в своп. Для этого как минимум существуют профайлеры памяти (см valgrind и intel vtune)
2) Попробовать заменить аллокатор (jemalloc, например) глобально для всей программы, включить в аллокаторе метрики (посмотреть через jeprof, изучить логи).
3) Когда выясните причину и место в архитектуре, которое дает такую проблему, какой-то код надо будет переписать. Возможно заменить алгоритмы со сложностью по памяти более низкой, чем сейчас - это уже к вашим аналитикам вопрос и архитекторам. Кроме вас вашу предметную область никто не знает.

Во всей этой схеме нет места шаманству с std::string, сам по себе он не при чем и ничего не ломает.

@КиберСталкер21 · 28.09.2023, 18:43 **[ТС]**

Сообщение от DrOffset

Если он и збивается, то не нарочно.

Ахах, я вот сейчас чаем подавился)
Нуу да ладно, просто вы возможно не совсем поняли проблему)
Как уже написал там забивает ОП прежде всего синхронизация. Она 1 раз в сутки отжирает примерно 50-100 Мб (в зависимости от того сколько данных обновилось в микросервисах и сколько таблиц в итоге пробуферилось), а работать должна годами и больше без перезапусков. На серваке 32Гб оперативы, которые ужрутся достаточно быстро в итоге(
ииии я хз, что я там ставил и какой знак равенства, но я точно описал имитацию того проблемного участка кода, который это вытворяет, и эту имитацию ускорил, чтоб не ждать месяцами.
...уфф, давай ближе к делу, господа, а так о пространственных и теоретических/теологических вещах разговаривать можно долго, где там и какие знаки кто ставит.

Алексей1153 · 28.09.2023, 18:46

Сообщение от КиберСталкер21

давай ближе к делу, господа

надо искать утечку. Но в том, что представлено в теме, её точно нет

@DrOffset · 28.09.2023, 18:46

Сообщение от КиберСталкер21

я точно описал имитацию того проблемного участка кода, который это вытворяет

Т.е. ваша рабочая программа выделяет огромный вектор строк и затем держит его в памяти?

Алексей1153 · 28.09.2023, 18:48

как временный костыль (чтобы выиграть время, ведь дедлайн был ещё вчера, а начальник злой) - можно попробовать запускать эту синхронизацию в виде отдельного процесса, а данные скидывать файлом в основной процесс. Дочерний процесс прибивается, память освобождается

@КиберСталкер21 · 28.09.2023, 18:51 **[ТС]**

Сообщение от DrOffset

А что конкретно вам советовать, если здесь нужна экспертиза вашего проекта?

Ооох ё, да при чёт тут проект то?
Почему без экспертизы нельзя всё нормально делать? Она к чему там ещё?
...блиин(
Там такой "офигенный" проект, что я там сам себе экспертиза. Откуда я тебе её выдеру?
Ooook, вот я и "наэкспертизил", что надо бы в этом месте подшаманить и что? Я не правильно "наэкспертизил"? Там проблема в другом? И в чём же она если рили вектор забивает память таким образом?
Да почему это то не проблема? Я ничего не могу понять(
По моему это вы просто убегаете от этой проблемы и хотите "перелить её в другой стакан"... не?)
Ещё раз.
Давайте по существу - вот есть вектора с string, они могу при многократных вызовах забивать ОП и swap (зафиксированно скринами) - как от этого избавиться?

@DrOffset · 28.09.2023, 18:51

Сообщение от КиберСталкер21

Как уже написал там забивает ОП прежде всего синхронизация.

Ну вот и выкиньте ее нафиг, и возьмите какое-нибудь готовое решение для организации кэша, где внутри нет тупого вектора на всю доступную память.
Опять-таки неизвестно что вам подойдет, но решения такие есть, в том числе и свободные. Вот, например: https://cachelot.io/

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .
SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .

@Aledveu 267 / 199 / 30 Регистрация: 26.11.2022 Сообщений: 866
	28.09.2023, 11:37
	КиберСталкер21, Вы путает освобождение памяти когда вы вызываете деструктор для объекта или вызываете функцию free с передачей высвободившейся памяти обратно системе. Менеджер управления памятью в вашей программе не всегда и не сразу отдаёт память обратно операционной системе. Если вы за один раз выделили большой кусок памяти а потом освободили его - то с большой вероятностью этот кусок памяти запрашивался у ОС и потом ей и вернулся. А если вы использовали много мелких кусков - то менеджер памяти продолжает хранить у себя информацию об этих кусках, хранит внутренние структуры данных о разделении памяти на эти мелкие куски и с большой вероятностью при их освобождении не отдаст их операционной системе а будет ждать пока вы снова не захотите выделить память в своей программе и тогда будет использовать эту память. 0

@КиберСталкер21 4 / 4 / 2 Регистрация: 13.11.2014 Сообщений: 108
	28.09.2023, 17:31 [ТС]
	...или мне нет доверия, что всё лезет в swap?) Вот немного скрина) Собственно, что хочу по нему отметить, таки да я немного слукавил) НО в целом прав остался, она в итоге хоть и понемногу отдавала съеденную у себя ОП, НОООО всё равно всё лезло в swap!( Т.е. во время выделения ОП система сначала выгружает что-то в swap, а только потом пытается там на что-то воздействовать и где-то подчистить... с переменным успехом надобно сказать ииии это не очень устраивает( Там на сервере и без моей программки достаточно всякого и отправлять их лишний раз в swap - это прям плохо( Вот от этого бы я точно хотел уйти. Если проблема этого кроется где-то в другом, там в системе, приоритетах процессов или чём-то ещё, то я бы очень хотел об этом узнать, чтобы далее всё корректно запускать и прочее. Миниатюры 0

Алексей1153 фрилансер 6454 / 5655 / 1129 Регистрация: 11.10.2019 Сообщений: 15,054
	28.09.2023, 17:56
	КиберСталкер21, а просто добавить ОЗУ не вариант? Хотя бы для теста, как оно будет себя вести понятно, что программу это не исправит, но, возможно, "решит проблему" 0

@DrOffset 19497 / 10102 / 2461 Регистрация: 30.01.2014 Сообщений: 17,808
	28.09.2023, 18:34
	КиберСталкер21, Естественно методы устранения проблемы для тестовой программы - это просто перстать выделять дофига памяти, и все, проблема решена. А в рабочей вашей программе что нужно сделать нам неизвестно. Но возможно, возможно, и скорее всего, что микропотимизациями вы не отделаетесь. Т.е. недостаточно просто будет где-то что-то подкрутить и хоп - все работает. Вы же именно так хотите? Я же вам говорю, что так не будет. Потому что если уж большая боевая программа полезла в своп, то все эти shrink_to_fit и clear как мертвому припарка. А что конкретно вам советовать, если здесь нужна экспертиза вашего проекта? Советы могут быть только общие 1) Выясните настоящую причину того, что программа полезла в своп. Для этого как минимум существуют профайлеры памяти (см valgrind и intel vtune) 2) Попробовать заменить аллокатор (jemalloc, например) глобально для всей программы, включить в аллокаторе метрики (посмотреть через jeprof, изучить логи). 3) Когда выясните причину и место в архитектуре, которое дает такую проблему, какой-то код надо будет переписать. Возможно заменить алгоритмы со сложностью по памяти более низкой, чем сейчас - это уже к вашим аналитикам вопрос и архитекторам. Кроме вас вашу предметную область никто не знает. Во всей этой схеме нет места шаманству с std::string, сам по себе он не при чем и ничего не ломает. 0

Алексей1153 фрилансер 6454 / 5655 / 1129 Регистрация: 11.10.2019 Сообщений: 15,054
	28.09.2023, 18:48
	как временный костыль (чтобы выиграть время, ведь дедлайн был ещё вчера, а начальник злой) - можно попробовать запускать эту синхронизацию в виде отдельного процесса, а данные скидывать файлом в основной процесс. Дочерний процесс прибивается, память освобождается 0