none
Раздутый пул приложений RRS feed

  • Pergunta

  • Подскажите пожалуйста, как бороться с раздутым пулом приложений.

    Ситуация следующая: Имеется пул приложений, который обслуживает несколько приложений. При остановке приложения пул приложений не уменьшается, и при старте нового только увеличивается. Меня уверяют, что очистка пула возможна лишь через рестарт пула приложений, так ли это или есть возможность сжать пул без его рестарта.

    segunda-feira, 20 de janeiro de 2020 11:37

Respostas

  • >Меня уверяют, что очистка пула возможна лишь через рестарт пула приложений

    Технически это не так. Пул приложений - обычный процесс .NET Framework. Когда ему нужна память, он выделяет ее, но когда память больше не нужна, он сразу ее не освобождает. Лишь когда в системе мало свободной памяти (или при кое-каких других условиях), запустится сборка мусора и ненужная память будет освобождена. Т.е. очистка памяти, конечно, возможна не только при рестарте, но вам от этого толку мало, так как вручную вы сделать эту очистку все равно не можете. Судя по вашем предыдущим 2 темам, реальная проблема в том, что на пул приложений IIS + ваши приложения ASP.NET Core (при OutOfProcess model) хостинг позволяет использовать всего 1GB?

    Я думаю ответ тут можно дать только один: в таких условиях вы не сможете заставить надежно работать приложение ASP.NET Core. Любая система с GC, по дизайну, жрет память в тех пределах, которые ей внешняя среда позволяет сожрать. При существовании дополнительного искусственного ограничения, о котором эта система не знает, она не сможет устойчиво функционировать. Хостинг просто прибьет ваши процессы до того, как они будут иметь шанс на сборку мусора. Рабочий способ ограничения доступной памяти в .NET Core - запуск (без IIS) в Docker контейнере с ограничением по памяти. CoreCLR умеет считывать это ограничение и не выделять памяти больше, чем нужно. В ваших условиях ответ - никак.

    • Marcado como Resposta Liliya Muray terça-feira, 21 de janeiro de 2020 09:32
    terça-feira, 21 de janeiro de 2020 08:32

Todas as Respostas

  • >Меня уверяют, что очистка пула возможна лишь через рестарт пула приложений

    Технически это не так. Пул приложений - обычный процесс .NET Framework. Когда ему нужна память, он выделяет ее, но когда память больше не нужна, он сразу ее не освобождает. Лишь когда в системе мало свободной памяти (или при кое-каких других условиях), запустится сборка мусора и ненужная память будет освобождена. Т.е. очистка памяти, конечно, возможна не только при рестарте, но вам от этого толку мало, так как вручную вы сделать эту очистку все равно не можете. Судя по вашем предыдущим 2 темам, реальная проблема в том, что на пул приложений IIS + ваши приложения ASP.NET Core (при OutOfProcess model) хостинг позволяет использовать всего 1GB?

    Я думаю ответ тут можно дать только один: в таких условиях вы не сможете заставить надежно работать приложение ASP.NET Core. Любая система с GC, по дизайну, жрет память в тех пределах, которые ей внешняя среда позволяет сожрать. При существовании дополнительного искусственного ограничения, о котором эта система не знает, она не сможет устойчиво функционировать. Хостинг просто прибьет ваши процессы до того, как они будут иметь шанс на сборку мусора. Рабочий способ ограничения доступной памяти в .NET Core - запуск (без IIS) в Docker контейнере с ограничением по памяти. CoreCLR умеет считывать это ограничение и не выделять памяти больше, чем нужно. В ваших условиях ответ - никак.

    • Marcado como Resposta Liliya Muray terça-feira, 21 de janeiro de 2020 09:32
    terça-feira, 21 de janeiro de 2020 08:32
  • Судя по вашем предыдущим 2 темам, реальная проблема в том, что на пул приложений IIS + ваши приложения ASP.NET Core (при OutOfProcess model) хостинг позволяет использовать всего 1GB?

    В ваших условиях ответ - никак.

    Да, вы правы 1Gb на всё...

    Думала, что можно как-то натравить ОС на процесс, чтоб та послала ему команду на сборку мусора.

    Жалко, что никак... 

    Спасибо за ответ!

    terça-feira, 21 de janeiro de 2020 09:38
  • Судя по вашем предыдущим 2 темам, реальная проблема в том, что на пул приложений IIS + ваши приложения ASP.NET Core (при OutOfProcess model) хостинг позволяет использовать всего 1GB?

    В ваших условиях ответ - никак.

    Да, вы правы 1Gb на всё...

    Думала, что можно как-то натравить ОС на процесс, чтоб та послала ему команду на сборку мусора.

    Жалко, что никак... 

    Спасибо за ответ!

    Ну почему же, можно. Перепишите ваш код чтоб он использовало меньше памяти. Это в том числе ваш код и данные лежат в пуле, он не просто так "пухнет".

    Разумеется, есть предел, если вы все еще не укладывайтесь, то придется использовать хостинг с большими возможностями (видимо платный вместо бесплатного), память не откуда не возьмется. В конце концов 1 ГБ сегодня безумно мало даже для телефона.

    Что до сборки мусора, то тут все наоборот. Языки со сборкой мусора увеличивают требование к памяти примерно в двое. Перепишите все на C++ и памяти надо будет куда меньше.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    terça-feira, 21 de janeiro de 2020 17:38
    Moderador
  • Ну почему же, можно. Перепишите ваш код чтоб он использовало меньше памяти. Это в том числе ваш код и данные лежат в пуле, он не просто так "пухнет".

    Что до сборки мусора, то тут все наоборот. Языки со сборкой мусора увеличивают требование к памяти примерно в двое. Перепишите все на C++ и памяти надо будет куда меньше.

    Переписать функцию "пул приложений" в IIS? Проблема в том, что при остановке приложения из пула, память пула не сжимается сразу, а ждет сборки мусора, которая никогда не наступает из-за маленького размера пула (где-то читала, что сборка первый раз начинается после превышения в один гиг), но из-за ограничения ниже порога сборки это событие оказывается не достижимым. Уменьшение размера моего приложения лишь отсрочит ошибку переполнения пула, но не отменит. Нужна сборка мусора в пуле...

    terça-feira, 21 de janeiro de 2020 18:25
  • Ну почему же, можно. Перепишите ваш код чтоб он использовало меньше памяти. Это в том числе ваш код и данные лежат в пуле, он не просто так "пухнет".

    Что до сборки мусора, то тут все наоборот. Языки со сборкой мусора увеличивают требование к памяти примерно в двое. Перепишите все на C++ и памяти надо будет куда меньше.

    Переписать функцию "пул приложений" в IIS? Проблема в том, что при остановке приложения из пула, память пула не сжимается сразу, а ждет сборки мусора, которая никогда не наступает из-за маленького размера пула (где-то читала, что сборка первый раз начинается после превышения в один гиг), но из-за ограничения ниже порога сборки это событие оказывается не достижимым. Уменьшение размера моего приложения лишь отсрочит ошибку переполнения пула, но не отменит. Нужна сборка мусора в пуле...

    Переписать ваш код который живет в пуле приложений. Что вы держите в памяти?

    Проблема не в остановке и не в пуле, а в том что ваш код потребляет много (против доступного) памяти. 

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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quarta-feira, 22 de janeiro de 2020 07:19
    Moderador
  • На сколько я знаю память в пуле освобождается самым обычным GC, никаких чудес там нет. GC будет проведен если памяти мало без всяких порогов.

    Вы абсолютно правы, пул очищается обычным GC, но он не вызывается пока пул не превысит некий порог, который больше 1 Gb, а у меня общий порог всех процессов 1Gb. Памяти на сервере предостаточно, так что GC по причине общей нехватки памяти в системе не вызывается...

    Скажите, сколько раз будет вызван пул, прежде чем его прибъёт ограничение? Ответ: НОЛЬ...

    quarta-feira, 22 de janeiro de 2020 08:59
  • На сколько я знаю память в пуле освобождается самым обычным GC, никаких чудес там нет. GC будет проведен если памяти мало без всяких порогов.

    Вы абсолютно правы, пул очищается обычным GC, но он не вызывается пока пул не превысит некий порог, который больше 1 Gb, а у меня общий порог всех процессов 1Gb. Памяти на сервере предостаточно, так что GC по причине общей нехватки памяти в системе не вызывается...

    Скажите, сколько раз будет вызван пул, прежде чем его прибъёт ограничение? Ответ: НОЛЬ...

    С чего вы это взяли, что он очищается якобы только при превышении порога в 1 GB? Это что, настройка конкретного сервера? Если некий "порог" реально существует, то попробуйте вызвать GC.AddMemoryPressure() с нужным размером. Но что то у меня есть сомнения по поводу "порога".

    Так же поясните вашу ситуацию: у вас ВМ с памятью 1 ГБ или кохостинг какого то типа? 

    В любом случае я рекомендую просто найти адекватный хостинг. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quarta-feira, 22 de janeiro de 2020 17:25
    Moderador
  • С чего вы это взяли, что он очищается якобы только при превышении порога в 1 GB? Это что, настройка конкретного сервера? Если некий "порог" реально существует, то попробуйте вызвать GC.AddMemoryPressure() с нужным размером. Но что то у меня есть сомнения по поводу "порога".

    Так же поясните вашу ситуацию: у вас ВМ с памятью 1 ГБ или кохостинг какого то типа? 

    В любом случае я рекомендую просто найти адекватный хостинг.

    При поиске решения данной проблемы натыкалась на вопрос, в котором автор описывал схожую проблему. Он полностью владел сервером, но когда ограничивал пул в 1 Gb, то в нем не проходила сборка мусора, а при больших размерах ограничения она выполнялась, но ответа под его вопросом не было.

    Попробую поиграть с данной функцией, если она действительно только отправляет запрос на выделение памяти, а нереально ее добавляет(((

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

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

    quarta-feira, 22 de janeiro de 2020 20:15
  • С чего вы это взяли, что он очищается якобы только при превышении порога в 1 GB? Это что, настройка конкретного сервера? Если некий "порог" реально существует, то попробуйте вызвать GC.AddMemoryPressure() с нужным размером. Но что то у меня есть сомнения по поводу "порога".

    Так же поясните вашу ситуацию: у вас ВМ с памятью 1 ГБ или кохостинг какого то типа? 

    В любом случае я рекомендую просто найти адекватный хостинг.

    При поиске решения данной проблемы натыкалась на вопрос, в котором автор описывал схожую проблему. Он полностью владел сервером, но когда ограничивал пул в 1 Gb, то в нем не проходила сборка мусора, а при больших размерах ограничения она выполнялась, но ответа под его вопросом не было.

    Попробую поиграть с данной функцией, если она действительно только отправляет запрос на выделение памяти, а нереально ее добавляет(((

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

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

    Иными словами, кто то сделал некое предположение, никто его никак его не подтвердил и не проверил, а вы его его выдаете за истину? 

    Реально шансы что это правда и GC якобы никогда не запускается если объем используемой памяти менее 1 ГБ практически нулевые. Я бы сказал что это нонсенс, вот и все. Если бы это было так, то программ на CLR с объемом памяти менее 1 ГБ просто бы не было и я знаю что это не так. 

    В вашем конкретном случае надо сделать дамп процесса и посмотреть что именно занимает память. Куда более вероятно что там нечего собирать. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quinta-feira, 23 de janeiro de 2020 06:10
    Moderador
  • Иными словами, кто то сделал некое предположение, никто его никак его не подтвердил и не проверил, а вы его его выдаете за истину? 

    Реально шансы что это правда и GC якобы никогда не запускается если объем используемой памяти менее 1 ГБ практически нулевые. Я бы сказал что это нонсенс, вот и все. Если бы это было так, то программ на CLR с объемом памяти менее 1 ГБ просто бы не было и я знаю что это не так. 

    В вашем конкретном случае надо сделать дамп процесса и посмотреть что именно занимает память. Куда более вероятно что там нечего собирать.

    Я не беру его за истину, но тесты показали, что это возможно правда. Тест был следующий: запустить приложение, остановить приложение и повторить. Результат был следующий: запуск увеличивает размер пула, остановка не влияет на размер пула, при пересечении лимита памяти, пул завершался с ошибкой. сборка мусора в пуле ни разу не производилась. Поэтому я считаю, что описанный эксперимент скорее всего правда. Я сама жуткий скептик.

    А зачем запускать сборку мусора (дорогостоящую операцию для ОС), если мелкий процесс не мешает системе. Пусть "жрет", пока ОС "лень" собирать мусор, такое отношение к мелким процессам.

    Зачем дампы? Я описала свой тест с запуском приложения, там его мертвые копии...

    quinta-feira, 23 de janeiro de 2020 06:35
  • "Реально шансы что это правда и GC якобы никогда не запускается если объем используемой памяти менее 1 ГБ практически нулевые. Я бы сказал что это нонсенс, вот и все. Если бы это было так, то программ на CLR с объемом памяти менее 1 ГБ просто бы не было и я знаю что это не так. "

    Тут тонкая разница между Workstation и Server GC. Для Workstation действительно, первый запуск GC уже при 20МБ выделенной памяти. А вот для серверного, по моим тестам, первый GC запускается только когда память заходит за 1GB. 

    quinta-feira, 23 de janeiro de 2020 06:59
  • Иными словами, кто то сделал некое предположение, никто его никак его не подтвердил и не проверил, а вы его его выдаете за истину? 

    Реально шансы что это правда и GC якобы никогда не запускается если объем используемой памяти менее 1 ГБ практически нулевые. Я бы сказал что это нонсенс, вот и все. Если бы это было так, то программ на CLR с объемом памяти менее 1 ГБ просто бы не было и я знаю что это не так. 

    В вашем конкретном случае надо сделать дамп процесса и посмотреть что именно занимает память. Куда более вероятно что там нечего собирать.

    Я не беру его за истину, но тесты показали, что это возможно правда. Тест был следующий: запустить приложение, остановить приложение и повторить. Результат был следующий: запуск увеличивает размер пула, остановка не влияет на размер пула, при пересечении лимита памяти, пул завершался с ошибкой. сборка мусора в пуле ни разу не производилась. Поэтому я считаю, что описанный эксперимент скорее всего правда. Я сама жуткий скептик.

    А зачем запускать сборку мусора (дорогостоящую операцию для ОС), если мелкий процесс не мешает системе. Пусть "жрет", пока ОС "лень" собирать мусор, такое отношение к мелким процессам.

    Зачем дампы? Я описала свой тест с запуском приложения, там его мертвые копии...

    Я не совсем понимаю в чем суть данного "теста". Что именно по вашему он проясняет (помимо того что при запуске выделяется неизвестно какая память, может управляемая, а может и нет)? И откуда вы знайте что GC ни разу не производился?


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quinta-feira, 23 de janeiro de 2020 07:22
    Moderador
  • Зачем дампы? Я описала свой тест с запуском приложения, там его мертвые копии...

    Я не совсем понимаю в чем суть данного "теста". Что именно по вашему он проясняет (помимо того что при запуске выделяется неизвестно какая память, может управляемая, а может и нет)? И откуда вы знайте что GC ни разу не производился?

    Вы кажется прикалываетесь, говоря, что не понимаете... При старте приложения в пул добавляется объект, при остановке данный объект из пула не удаляется, его должен убрать GC. При многократном добавлении (старт-стоп) объекта пул достигает ограничения и перегружается с сообщением, что превышен лимит памяти. Я утверждаю, что GC не вызывался ни разу, так как пул только равномерно рос на одно и тоже значение и ни разу не уменьшился в размере.

    Один из моих экспериментов был довести пул до критического значения 990Мб (пул+приложения), он не уменьшался в размерах более трех суток, затем была нагрузка, которая пересекла предел и пул перегрузился... Если бы была сборка мусора, то пул бы вернулся к значениям 300Мб, но за трое суток такого не случилось.

    quinta-feira, 23 de janeiro de 2020 08:37
  • Если некий "порог" реально существует, то попробуйте вызвать GC.AddMemoryPressure() с нужным размером.
    Вызывала GC.AddMemoryPressure(long.MaxValue); и GC.RemoveMemoryPressure(long.MaxValue); но эффекта для пула не было. Или там должен быть определенный танец с бубнами?
    quinta-feira, 23 de janeiro de 2020 13:09
  • Зачем дампы? Я описала свой тест с запуском приложения, там его мертвые копии...

    Я не совсем понимаю в чем суть данного "теста". Что именно по вашему он проясняет (помимо того что при запуске выделяется неизвестно какая память, может управляемая, а может и нет)? И откуда вы знайте что GC ни разу не производился?

    Вы кажется прикалываетесь, говоря, что не понимаете... При старте приложения в пул добавляется объект, при остановке данный объект из пула не удаляется, его должен убрать GC. При многократном добавлении (старт-стоп) объекта пул достигает ограничения и перегружается с сообщением, что превышен лимит памяти. Я утверждаю, что GC не вызывался ни разу, так как пул только равномерно рос на одно и тоже значение и ни разу не уменьшился в размере.

    Один из моих экспериментов был довести пул до критического значения 990Мб (пул+приложения), он не уменьшался в размерах более трех суток, затем была нагрузка, которая пересекла предел и пул перегрузился... Если бы была сборка мусора, то пул бы вернулся к значениям 300Мб, но за трое суток такого не случилось.

    Я не прикалываюсь, я совершенно не понимаю ваших доводов. Например, с чего вы взяли что "объект" который добавляется при старте может быть собран GC? Он может быть например неуправляемым, скажем загружается новый CLR хост. И даже управляемые объекты далеко не всегда могут быть собраны GC.

    Далее, какое отношение отношение старт/стоп вообще имеет к делу? На практике вы ведь не сидите у сервера и не нажимайте старт/стоп все время? Если так, то зачем нужен этот эксперимент?

    С моей точки зрения ваш эксперимент не имеет никакого практического значения, а выводы при его проведении не обоснованы. 

    Надо наверное вместо этого нагрузить сервер и смотреть что происходит с памятью в процессе его работы.

    Например, если уж проводить эксперименты для проверки "теории квантового GC", так можно например добавить API который возвращает статистику GC. Далее вызвать его через браузер и посмотреть были ли сборки или нет. Или можно на локальной машине все это сделать и посмотреть значения счетчиков производительности.

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


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quinta-feira, 23 de janeiro de 2020 17:03
    Moderador
  • Если некий "порог" реально существует, то попробуйте вызвать GC.AddMemoryPressure() с нужным размером.

    Вызывала GC.AddMemoryPressure(long.MaxValue); и GC.RemoveMemoryPressure(long.MaxValue); но эффекта для пула не было. Или там должен быть определенный танец с бубнами?
    Надо вызвать только первый API, второй вызывать не надо так как это отменит первый вызов.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    quinta-feira, 23 de janeiro de 2020 17:05
    Moderador
  • "Вызывала GC.AddMemoryPressure(long.MaxValue); и GC.RemoveMemoryPressure(long.MaxValue); но эффекта для пула не было. Или там должен быть определенный танец с бубнами?"

    Тут точно только шамана с бубном вызывать... Как GC.AddMemoryPressure тут поможет? Тем более если вызывать с таким большим значением - его CLR скорее всего просто отметет как некорректное. Увеличение бюджета неуправляемой памяти разве что поможет поскорее вызвать сборку мусора в своем процессе, но никак не в другом. На него это никак не повлияет.

    quinta-feira, 23 de janeiro de 2020 18:27
  • Я не прикалываюсь, я совершенно не понимаю ваших доводов. Например, с чего вы взяли что "объект" который добавляется при старте может быть собран GC? Он может быть например неуправляемым, скажем загружается новый CLR хост. И даже управляемые объекты далеко не всегда могут быть собраны GC.

    Далее, какое отношение отношение старт/стоп вообще имеет к делу? На практике вы ведь не сидите у сервера и не нажимайте старт/стоп все время? Если так, то зачем нужен этот эксперимент?

    С моей точки зрения ваш эксперимент не имеет никакого практического значения, а выводы при его проведении не обоснованы. 

    Надо наверное вместо этого нагрузить сервер и смотреть что происходит с памятью в процессе его работы.

    Например, если уж проводить эксперименты для проверки "теории квантового GC", так можно например добавить API который возвращает статистику GC. Далее вызвать его через браузер и посмотреть были ли сборки или нет. Или можно на локальной машине все это сделать и посмотреть значения счетчиков производительности.

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

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

    Да, я написала некий API, который мне по запросу возвращает данные с хостинга.

    Для каждого клиента свой пул приложений.

    Для приложения я могу получить различные данные, но вот для пула, мне подсказали как вычислить что процесс "w3wp" - мой, а далее уже доступные для процесса свойства по памяти.

    quinta-feira, 23 de janeiro de 2020 20:12
  • Тут точно только шамана с бубном вызывать... Как GC.AddMemoryPressure тут поможет? Тем более если вызывать с таким большим значением - его CLR скорее всего просто отметет как некорректное. Увеличение бюджета неуправляемой памяти разве что поможет поскорее вызвать сборку мусора в своем процессе, но никак не в другом. На него это никак не повлияет.

    Согласна, вряд ли это повлияет на другие системные процессы, и будет для них инициировать сборку мусора.
    quinta-feira, 23 de janeiro de 2020 20:17
  • "Вызывала GC.AddMemoryPressure(long.MaxValue); и GC.RemoveMemoryPressure(long.MaxValue); но эффекта для пула не было. Или там должен быть определенный танец с бубнами?"

    Тут точно только шамана с бубном вызывать... Как GC.AddMemoryPressure тут поможет? Тем более если вызывать с таким большим значением - его CLR скорее всего просто отметет как некорректное. Увеличение бюджета неуправляемой памяти разве что поможет поскорее вызвать сборку мусора в своем процессе, но никак не в другом. На него это никак не повлияет.

    Скорее всего никак не поможет так как в не думаю что утверждение о неком пороге GC верно. Документация таких порогов не устанавливает, а лишь говорит о том что порог динамически меняется. Что имеет смысл, так как для программ которые использует 10 МБ и 10 ГБ они будут очень разными.

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

    Конечно, вызывать надо не с long.MaxValue, а со значением предполагаемого порога. То есть 1 ГБ. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    sexta-feira, 24 de janeiro de 2020 00:18
    Moderador
  • "Скорее всего никак не поможет так как в не думаю что утверждение о неком пороге GC верно. Документация таких порогов не устанавливает, а лишь говорит о том что порог динамически меняется. Что имеет смысл, так как для программ которые использует 10 МБ и 10 ГБ они будут очень разными."

    Ну да, по сути речь не о каком-то жестком пороге, а о том, что для Server GC сборка мусора запускается значительно реже, чем для Workstation GC. Точнее, речь не о сборке мусора как таковой, а о сжатии кучи, которое потенциально отдает освобожденную память ОС. Обычная сборка, которая просто помечает участки памяти неиспользуемыми, конечно, запускается также часто и для серверного GC, но она не отдает память в ОС, и поэтому из внешнего мира незаметна. Реальный порог, когда в процессе запустится первое сжатие кучи, зависит от многих факторов. "Порог в 1 Гб" - это как гипотеза плоской Земли, работает в неких узких рамках, но в более широкой перспективе неверно. 

    sexta-feira, 24 de janeiro de 2020 04:45
  • Скорее всего никак не поможет так как в не думаю что утверждение о неком пороге GC верно.

    Огромное спасибо за зря мною потраченное время.

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

    Еще раз огромное спасибо!

    sexta-feira, 24 de janeiro de 2020 06:48