@kudrbudr

Как быть при утечке памяти? Можно ли «очистить» ОЗУ скриптом?

Привет, у меня есть десятки программ одной компании, код закрытый, оптимизация так себе, и пока эти программы работают (запускает задачи, выполняет скрипты и т.д.) ОЗУ постепенно заполняется, чем больше интенсивности тем более ОЗУ занято.

Подозреваю на утечку памяти.

Попытка убить программы и возможные процессы освобождает всего 2-5 ГБ, и спустя сутки работы ОЗУ постепенно доходит до 45 ГБ (макс 64).

Вижу 35 Гб занятой ОЗУ, но не вижу что именно сожрал столько ОЗУ, после перезагрузки со всеми запущенными программами занято максимум 25 ГБ.

Я также пытался попросить chatGPT написать скрипт который очищает ОЗУ не затрагивая систему Windows, запущенных программ, но сколько бы не пытался почти всегда получаю синий экран смерти.

Вопрос:

Как бороться, избежать, очистить ОЗУ при утечке памяти? Другими словами интересует лечение симптома т.к. нет возможности устранить первопричины.

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

6679e01b006a2334759458.png
Огромное количество процессов сsc.exe и conhost.exe
  • Вопрос задан
  • 268 просмотров
Пригласить эксперта
Ответы на вопрос 3
saboteur_kiev
@saboteur_kiev Куратор тега Windows
software engineer
Вы вообще не в ту сторону шагаете.Какие тут скрипты??

Утечки памяти это не проблема операционной системы (ну разве что утечки именно в ней).

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

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

Тут нужно разбираться с вашими приложениями, с теми кто их писал.
Иначе - ну ребутать разросшиеся приложения регулярно, если этот вариант возможен.
Ответ написан
Комментировать
@res2001
Developer, ex-admin
Попытка убить программы и возможные процессы освобождает всего 2-5 ГБ

Значит вы убиваете не те программы, т.к. при закрытии процесса и память выделенная процессом освобождается.
Или другой вариант - дело не в утечках памяти. Тогда не понятно какая конкретно у вас проблема? У вас начинает тормозить комп через какое-то время или что?

Если все таки дело в утечках памяти, то объем памяти выделенной процессом можно увидеть в Task Manager.
Можно просто отсортировать список процессов по памяти и понаблюдать некоторое время. Так определите какой процесс жрет память.

Не обязательно завершать программу через taskkill, у нее же наверняка есть стандартный вариант закрытия приложения, наверное так не будут теряться данные. Чтоб например в батнике эмулировать нажатия кнопок и т.п. для закрытия программы можно использовать утилиты типа nircmd или autoit.

Вообще использовать не поддерживаемые разработчиком программы - стремное занятие. Стоит подумать о переходе на альтернативное ПО.
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Некоторые советы по вопросу. Первое.

Совет бывшего создателя - убивать приложения через taskkill конечно очень порадовал.
Было-бы неплохо чтобы создатель также помог автоматизировать процедуры восстановления
файлов и данных после такой спорадической стрельбы. Вообще не существует не-деструктивного
способа забрать выделенную память у приложения. Таковы реалии. Если программист зачем-то
выделил память - значит нужно. И фиксацию этого можно сделать только в исходном коде
приложения.


Второе. Если вы - сисадмин, который занимается развертыванием и сопровождением программных
продуктов то вам должны были дать инструкции по всему этому. Поищите в документации
секцию настройка или configuration. Там должно быть что-то вроде buffers, threads, workers, memory_pool e.t.c.
В ini files или в реестре.

По терминологии. Никакого ОЗУ уже давно не существует с точки зрения приложений. Это - старый
термин из 20-го века и его надо как-то убрать из вопроса. Современная память приложений - это
virtual memory которая представляет собой бутерброд из ОЗУ и Paging File (Swap file в разных ОС).
По факту приложения могут выделять больше памяти чем есть в ОЗУ но при этом сохранять свою
работоспособность. Но механика сброса страниц или чтения может сыграть роль performance issue,
которое надо оценить в виде метрики.

Поэтому если автор хочет понять влияние памяти на приложение - я вижу единственный вариант
- придумать метрику работы приложения (например количество отработанных транзакций в секунду
в нормальном (номинальном) режиме работы) и запомнить ее. Это будет base line или некая хорошая
горизонтальная линия на графике. Или какой-нибудь квартиль или процентиль от времени отклика.
Далее - наблюдать эти графики в Grafana или каком-то другом графическом мониторинге.

По поводу процессов сsc.exe и conhost.exe. Это - консоль и компиллятор Microsoft C#. Тут - мало информации
к расследованию. Скорее всего их наличие - это просто дизайн и архитектура. Но если автору интересно -
пускай поищет командную строку (те символы которые идут после csc.exe). Возможно будет какая-то
более ценная инфа.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы