Comments 92
0 total zombie processes.
No zombies found. Maybe all software is working correctly...

Меня несколько лет назад, тоже интересовала эта тема, думая вам стоит ознакомиться с superfech. В реальности она будет кушать ровно столько памяти, сколько доступно. Проверял на машинках с 4, 16 и 32 Гб памяти, ОС Win7 и 8.1.
В некоторых случаях, её есть смысл отключать, работает не так как хотелось бы. Например на тех же компиляциях при наличии ссд.
Я отключал… не помогает. После одного-двух уходов в сон потребление памяти снова доходит до 7+ГБ из 7,9ГБ полного объема. При этом стартует система с потреблением 4-5ГБ.
UFO landed and left these words here
0 total zombie processes.
No zombies found. Maybe all software is working correctly, but I doubt it. More likely the zombie counting process failed for some reason. Please try again.
1731 total zombie processes.
Количество постепенно растёт. Браузер закрыт. Win10, x64.
Пока писал этот коммент 5 зомбей прибавилось.
Это кошмар, ребятки.
Колоссальные усилия для поиска зомби. Ваш коллега написал утилиту, вы в ручную ставили множество других программ и нетривиально находили эти процессы.
В процессе нашли несколько багов в самой винде, так еще и утечку в более чем 10 популярных приложений.
Что-то в этом виндовс-мирке точно не так.
Что-то в этом виндовс-мирке точно не так.

Если что в юниксовых системах тоже существуют процессы-зомби.
Выходит, в юникс-мирке что-то не так тоже?
Они существуют. Но их показывает ps и поэтому очень непросто заметить приложение, которое их плодит. У на машине сейчас только pidgin таким страдает.
К сожалению Unix-мир зря гордится. Зомби в Unix-мире заметны сразу, так что 500'000 штук никто не оставит.

Но вот всякое добро внутри X сервера, оставленное там «умершими» программами или ошмётки от криво реализованного IPC (который не освобождает ресурсы, если программа забывает это делать) — приводят примерно к такому же эффекту.

Увы, но нет в мире операционок без подобных эффектов. Android к этому стремится (в частности поэтому он не поддерживает POSIX IPC), но… он тоже идеала пока не достиг…

P.S. Причём заметим, что в случае с POSIX IPC всё хуже — реализовно оно в ядре и API там такой, что избавиться от утечек в принципе нельзя. По крайней мере разработчики Windows могут гордится тем, что ядро «не теряет» память…
Справедливости ряди, это скорее к Sytem V IPC относится. В POSIX чуть лучше — объекты освобождаются как только больше не нужны ни одному процессу.

А так ещё открытые, удалённые с диска, файлы можно припомнить. Тоже в своём роде утечка места.

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

Не совсем. Нужно выполнить waitpid(childPid, &returnStatus, 0); в обработчике SIGCHILD или без него. Иначе получим такого-же зомби. Тут скорее фактор, что зомби сразу же видны в top, потому таких ошибок меньше.
Насколько я понимаю аналогичный api в unix, то там нет блока: умер процесс, родителя об этом уведомили, а если он не среагировал, это его проблемы.
Будет зомби — точно так же, как в Windows. Просто эти зомби будут в списке процессов видны, это заметят и будут чинить.

Разница не в подходе, а в средствах диагностики…

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

Нельзя просто так взять и отнять дескриптор у процесса, точнее, можно, но процессу это может не понравится. Может он действительно нужен для каких-то своих целей, даже после закрытия?
Наверняка есть причина такого поведения.
Да, конечно. Как вы будете систему сборки писать, если вы не можете узнать — завершилась команда компиляции с ошибкой или нет?

От зомби нужно, по большому счёту, две вещи:
1. Запомнить код возврата (чтобы родитель смог понять — отработал процесс-потомок успешно или нет).
2. Слот в таблице процессов (так как если этого не сделать, то, опять-таки, невозможно будет говорить о коде возврата процесса с заданным PID'ом… их ведь может быть много, если в системе нет понятия «зомби»).

Так как обычно зомби долго не живут, то оставить для них один несколько больше информации — не очень страшно, но очень сильно помогает для «посмертного анализа» (если зомби вовремя не умирают, то возможность понять — что это за процессы и как они были запущены — очень полезна).
Всё ж в Linux зомби чуть более мирные. Остаётся только лишняя запись в таблице процессов. Бывшая память зомби процесса уже свободна.
Правда в результате может быть переполнение таблицы процессов… Так что увы.
Всё ж в Linux зомби чуть более мирные. Остаётся только лишняя запись в таблице процессов.
Не только. Вроде бы ещё в ядре какое-то количество структур остаётся. 8K, если память не изменяет. Что, конечно, в 4 раза меньше, чем в Windows… но всё равно довольно много.
Теперь понятно почему хром такой прожорливый. Вот если бы у его разработчиков было не по 50 гигов, а 8 или даже 4, то они бы чаще обращали внимание на проблемы с памятью. А то запустил пару-тройку приложений на электроне + сам хром и уже 6-7 гигов как не бывало!
Им память нужна для сборки, иначе компилировать они его будут месяц.
Это понятно. Просто когда постоянно живёшь в достатке ресурсов, то проблемы «третьего мира» начинают казаться несущественными. Подозреваю что сборки тестируются в том числе на ограниченных конфигурациях, но вряд ли основная масса разаработчиков постоянно живёт в таких условиях. Из-за этого может формироваться мнение, что раз нормально работает у меня локально, то и у всех будет так же.
Такое количество памяти требуется для разработки, а не для тестирования.

Например у меня на машине 8 гигов, и если я при загрузке винды запущу любое приложение, например браузер с двумя вкладками, то докеру не хватит памяти и он не сможет запуститься. То есть в моем случае 16 гигов — это МИНИМУМ, без которого всему необходимому мне для разработке софту не хватит места для запуска.

Так что это физически невозможно, да и не нужно.
Если б они полноценно тестировались на «ограниченных конфигурациях», вряд ли браузеры подлагивали на i3 и тормозили на atom'ах.
Скорее у них другое представление о «нормальной» работе. Они запускают штук 10 окон в браузере, лениво сёрфят полдня и считают работу зачтённой, если это не крашится и не улетает в лютые тормоза. Роль бет исполнят простые юзьвери, им не привыкать, они же пусть и делают статистические и структурные анализы потребления памяти, обращений к диску, загрузки проца и сетевых запросов. Сплошная экономия, так ещё и чувство сопричастности к процессу разработки за «спасибо». :)
Компилировать — нет, для этого много памяти не нужно. А вот линкер при сборке Хрома может десятки гигабайт в одиночку выжирать…
На виртуалке с 8 ГБ и обычным HDD у меня собирается где-то пол часа.
то они бы чаще обращали внимание на проблемы с памятью.

Они обращают, и очень активно. В Chromium есть специальная Memory Team, состоящая из инженеров Google и Opera, которая занимается выяснениями «на что тратится память» (в столь большом и сложном проекте подобный вопрос тянет не на одно исследование) и оптимизациями всего этого дела. Результаты у них может и не впечатляющие, но значительные.
Плюс от разработчиков V8 периодически тоже приходят новости об успехах по этой части.
и уже 6-7 гигов как не бывало

Это нормально. Точнее сказать, так и должно быть. У Chromium сознательная политика вида «если есть память, нужно ее использовать под кэши/буферы/другие в определенной степени полезные вещи». Внутри браузере есть механизм определения так называемого 'memory pressure', и когда памяти в системе становится маловато (уровень 'moderate') или совсем мало (уровень 'critical'), компонентам браузера рассылается уведомление, что не мешало бы почиститься и ужаться.
Обычный пользователь может прикоснуться и даже немного повлиять на эту магию с помощью опций, начинающихся с --memory-pressure* в командной строке, поглядите, там разные параметры есть.
Сейчас все это дело еще перепиливается, решения об оптимизации потребления ОЗУ во время выполнения и выгрузке различных данных будут применяться также исходя из пользовательской активности и других факторов, процесс еще не завершен, но вообще будет много интересного.
Может быть и обращают.
Но по моим наблюдениям, когда памяти остаётся маловато или совсем мало, у хрома начинаются серьёзные проблемы.
Начиная с задержек отрисовки табов в заголовке окна и заканчивая сообщениями «Вкладка не отвечает» после попытки открыть новую пустую (!) вкладку.
Новая пустая вкладка вообще-то запускает целый новый процесс — со всеми вытекающими.
С другой стороны, у меня теперь сознательная политика — не использовать Chrome, не ставить его и предлагать всем его удалить.
А что в замен? Только хромопроизводные и остались. Не считать же развалины FF или Edge за браузеры.
40 конечно ещё нормальная версия, сам на производном от 55 сижу, но я про современные версии.
А этот «memory pressure» может определить, что, несмотря на работавший целый день браузер, вот именно сейчас 6гб памяти нужно только что запущенной игре?
А Вы ещё пользуетесь хромом??? Я его поставил себе, использовал несколько дней, заметил, что комп стал работать сильно медленнее, открыл диспетчер задач, увидел, что большую часть памяти и процессора жрёт именно хром. Снёс хром — с тех пор комп просто летает.
А теперь вы можете взять утилиту FindZombieHandles, запустить её на вашей машине и рассказать о своих находках.

Требует .NETFramework 4.5, увы. Впрочем, на моей XP x64 редко у какого процесса есть больше 1000 дескрипторов, и зомби процессов и памяти я там не наблюдаю.
.нет 4.5 уже не ставится на ХР или это из-за мало совместимого х64 у ХР?
Попробуйте пересобрать под более старый .NET. Там же ничего кроме P/Invoke не используется… Еще можно попробовать под Mono запустить. Или конфиг исправить, чтобы .NET 4.0 использовался, он под XP есть.
Не, бесполезно. Там все проблемы в библиотеке NtApiDotNet, не знаю, как это им удаётся, но компилироваться под 4.0 она никак не хочет, хотя казалось бы, простой враппер для функций.
Конфиг правил, не катит.
Там надо, видимо, асинхронные функции порезать. Или библиотеку с реализацией асинхронности подключить.

А что говорит Mono?
Там надо, видимо, асинхронные функции порезать. Или библиотеку с реализацией асинхронности подключить.

Да, несостыковки вылазили как раз на async с await. А какие библиотеки есть?
А что говорит Mono?

Не знаю, с какой стороны к нему подступится, но на странице загрузки есть только Supported on Windows 7, 8, 10 or later. Сейчас посмотрю старые версии, но вряд ли что выйдет.
Так, хорошо, уже запустилось, правда пришлось пару методов «зануллить». На десятке работает и показывает значения, равные оригиналу, но на XP ругается на отсутствие привилегии отладки и не может импортировать NtGetNextProcess из ntdll. Такая функция в XP должна быть, судя по WRK, но не экспортируется.
Ладно, спасибо за помощь.
4 total zombie processes.
    1 zombie held by Dropbox.exe(7120)
        1 zombie of chrome.exe
    1 zombie held by svchost.exe(1320)
        1 zombie of userinit.exe
Pass -verbose to get full zombie names.

Пожалуй помониторю пару дней. Уже не раз обращал внимание на «потери» памяти, грешил на возможные зловреды, но ни разу словить в AVZ/Gmer не удавалось. Может и правда дело в зомбях.
Десяток зомбей сожруть меньше мегабайта памяти. Чтобы беда случилась их должны быть тысячи…
Потому и говорю что помониторю, утром ОС ребуталась и уже 4 зомби, хотя я еще толком на компе ничего не делал.
Как я писал выше: появление (и исчезновение) зомби — это нормально. Ненормально — это когда они «зависают» в «полумёртвом» состоянии на часы (а то и дни).
У меня вывод handle не совпадает с кол-вом открытых дескрипторов:
image
D:\Work>handle.exe -p 4268 | wc -l
30

Интересно, почему…
Если что — это Windows 7. Также пробовал на Windows 10, там тоже на порядки отличается.
Nthandle v4.11 — Handle viewer
Copyright © 1997-2017 Mark Russinovich
Sysinternals — www.sysinternals.com

usage: handle [[-a [-l]] [-u] | [-c [-y]] | [-s]] [-p |] [name] [-nobanner]
-a Dump all handle information.
-l Just show pagefile-backed section handles.
-c Closes the specified handle (interpreted as a hexadecimal number).
You must specify the process by its PID.
WARNING: Closing handles can cause application or system instability.
-y Don't prompt for close handle confirmation.
-s Print count of each type of handle open.
-u Show the owning user name when searching for handles.
-p Dump handles belonging to process (partial name accepted).
name Search for handles to objects with (fragment accepted).
-nobanner Do not display the startup banner and copyright message.

No arguments will dump all file references.

Надо было
handle -a -nobanner -p 4268 | wc -l

или
handle -s -nobanner -p 4268
А у меня вот Reeder запускает на каждый просмотр страницы внутри себя Safari, и похоже, забывает их правильно закрывать.

В итоге, ест память больше хрома
geektimes.ru/post/107605
geektimes.ru/post/107607
geektimes.ru/post/107637
Это уже почтенного возраста статья конечно. Но как я вижу актуальности не теряет. Да и по сей день встречаются толпы людей из «тёмного царства», нуждающиеся в лучиках света.
Поток людей, творящих чёрт знает что с памятью не уменьшается со временем.

Последнее что видел буквально с месяц назад — как у клиентов вырубается виртуальная машина выполняющая роль терминала для 20 учетных записей. Ей отвели всего-навсего 384 Мб ОЗУ в VMWare (ОС WinServ2003). Один клиент съедает 804 Мб ОЗУ. Даже один клиент заставляет машину жить в жОстком свопе. Что происходит при подключении 20 клиентов… ну то что происходит, машина умирает. Хорошо когда люди включают голову, хотя бы иногда, при настройке софта и выборе нагрузок на железо!
UFO landed and left these words here
App Verifier создаёт O(n^2) лог-файлов (и об этом стоит написать отдельный пост!)

Судя по твиту — он создает ровно n файлов. А вот времени на это тратит таки O(n^2)

ой, ой.
WARNING: Can't enable debug privilege. Some zombies may not be found. Run as admin for full results.
227 total zombie processes.
185 zombies held by svchost(11768)
93 zombies of chrome.exe
17 zombies of ServiceHub.RoslynCodeAnalysisService32.exe
15 zombies of ServiceHub.IdentityHost.exe
14 zombies of Node.exe
9 zombies of ServiceHub.Host.CLR.x86.exe
8 zombies of ServiceHub.VSDetouredHost.exe
8 zombies of ServiceHub.SettingsHost.exe
6 zombies of ServiceHub.DataWarehouseHost.exe
3 zombies of Microsoft.VsHub.Server.HttpHost.exe
2 zombies of software_reporter_tool.exe
2 zombies of software_reporter_tool.exe
2 zombies of RdrCEF.exe
2 zombies of phantomjs.exe
2 zombies of conhost.exe
1 zombie of Code.exe
1 zombie of AcroRd32.exe
22 zombies held by svchost(3696)
22 zombies of RAVBg64.exe
12 zombies held by IntelCpHeciSvc(7224)
4 zombies of Video.UI.exe
4 zombies of Video.UI.exe
4 zombies of Video.UI.exe
3 zombies held by devenv.exe(28936)
2 zombies of ServiceHub.Host.Node.x86.exe
1 zombie of MSBuild.exe
1 zombie held by SynTPEnh.exe(27400)
1 zombie of SynTPEnh.exe
1 zombie held by sihost.exe(16604)
1 zombie of backgroundTaskHost.exe
1 zombie held by svchost(2232)
1 zombie of userinit.exe
Pass -verbose to get full zombie n

P.S. chrome.exe даже не запускался.
Автор, безусловно, путает процессы и хэндлы. Будь у него 506 тысяч зависших процессов — большинство PID'ов давно стало бы шести-и семизначными.
Всего лишь 202 зомби, хотя не перегружался неделю и в студии постоянно открываю тяжеловесные проекты (хотя прямо говоря — да, приходится порой студию из процессов убивать, т.к. держит файлы)
Вы бы хоть версию винды писали, можно было бы как-то статистику организовать. В конце концов, выяснить, в какой момент мелкомягкие ушли в грех.

У меня, например, на 8.1 пусто после 8-часовой работы в Qt с периодическими инкриментальными сборками студией и мингвой.
Простите далекого от этого, но вот я с гита слил репу, нахожусь в директории с «программой», но что с этим делать дальше? Можно на пальцах? Как это вообще запускается?
Зайдите в папку prebuilt — там бинарники лежат.

А вообще, для сборки проекта надо поставить Microsoft Build Tools 2017, после чего запустить из командной строки msbuild находясь в папке проекта — он соберет.
Все, теперь понял.
*Я просто из java-world, а в статье это не отражено:
А вообще, для сборки проекта надо поставить Microsoft Build Tools 2017, после чего запустить из командной строки msbuild находясь в папке проекта — он соберет.

и для «левого» человека данные моменты могут являться не очевидными.
Опять же, мне, левому человеку, это название ни о чем не говорит.
И да, я программист. Но ЯП иной и своя компоновка как директорий, так и наименований.
С моей колокольни тут будет «что-угодно», но не результат работы компилятора… скорее сорцы/компоненты, ибо стоит pre (prepared for build?!).

А так, наш диалог — наглядная иллюстрация «ожидание vs реальность».

P.S. У меня, к примеру, «выхлоп» идет в директорию target — так же абсолютно не очевидно, что туда будет собран результат компиляции… ибо ну папка с именем «цель», а чего «цель» не понятно. (тут смайлик «развожу руками»)
Не волнуйтесь, у нас тоже своя компоновка директорий. Бинарники оказываются в папке bin.

А prebuilt — это авторское изобретение в конкретном репозитории, сделанное человеком который не разобрался зачем на гитхабе придуманы релизы. Переводится как «заранее построенное».
А prebuilt — это авторское изобретение в конкретном репозитории,
Да ладно вам? А это тогда о чём?

prebuilt — это стандартное название для таких вещей. В Android мире как минимум.

сделанное человеком который не разобрался зачем на гитхабе придуманы релизы.
Нет, всё проще — это сделано человеком, который github'ом пользуется только изредка и не хочет менять своих привычек. AOSP'шный prebuilt жил тут ещё 10 лет назад (потом его на части разбили, правда).
По первой вашей ссылке нет ничего про структуру директорий в репозитории. По второй я вижу отдельный репозиторий для бинарников. Это нормальная практика, в отличии от хранения всего в одной репе вперемешку.

Что же до слова «prebuilt» — я бы вам поверил что оно существует и без ссылок :-) Под авторским изобретением я понимал элемент структуры директорий, а не слово в отрыве от нее.
По первой вашей ссылке нет ничего про структуру директорий в репозитории.
Потому что git не поддерживает прав доступа. «Структура директорий» описана тут и собирается с помощью repo.

Это нормальная практика, в отличии от хранения всего в одной репе вперемешку.
Там где нет проблем с правами доступа и проект небольшой — там всё вместе. Вот пример. Вот ещё один. Во втором случае — как раз ситуация, когда было решено, что пора на googlestorage вынести пребилды…

Под авторским изобретением я понимал элемент структуры директорий, а не слово в отрыве от нее.
Ещё раз: это не авторское изобретение. Это стандартная практика в гугловых проектах.
Почему зря? Это удобно и просто. Проблема только в том, что git не очень хорошо работает с бинарными файлами, так что для больших проектов это не годится.
Это крайне неудобно: нужно в обязательном порядке собирать проект перед каждым коммитом, иначе бинарники окажется нерелевантными. А значит — нужно сначала найти инструкции по сборке всей этой радости (а может быть — даже ОС сменить, тут не проверял).

А потом при каждом слиянии — будут лезть конфликты.
Всё гораздо проще: это делает Commit-Queue бот. И только в основную ветку.

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

P.S. Конечно если вам нужно собирать под разные платформы на разных ботах — этот метод неудобен, это да.
Отлично, значит разные файлы в одном и том же коммите могут не соответствовать друг другу…

Дело не в методе выпуска релиза, а в методе публикации. Основной репозиторий git — неподходящее место для этого.
И да, я программист. Но ЯП иной и своя компоновка как директорий, так и наименований.

Я вообще PHPшник, где сборка отсутствует как класс. Что не помешало мне потыкать по каталогам и найти бинарник, убедится в том, что он не запускается на XP, поставить студию, сменить версию дотнета, и совершить ещё множество действий при практически полном непонимании синтаксиса, компоновки и прочего.
Я из тех, кто сначала «читает ман, потом тыкает/делает».
Мана нет (Readme), названия не понятные. Пошел спрашивать.
Приставка «pre-» — значит «перед, предварительно». «built» — это «собранный». «prebuilt» — «предварительно собранный». Ну в общем, точно не сорцы.
Вопрос: если есть механизм отслеживания количества зомби процессов под виндой — то можно ведь встроить этот механизм непосредственно в ОС, собирать статистику и отправлять непосредственно разработчикам.

Так же если честно не очень понятно, как можно определить что определенный процесс является зомби, он ведь может ждать какого то определенного события, пусть даже несколько дней.
Зомби уже ничего «ждать» не может. У него завершены все потоки, он не реагирует на внешние события. Всё, что у него есть — это информация о том, какой у него был PID, когда он ещё был жив, какой он вернул код возврата при закрытии ну и ещё кое-какие метаданные. Подразумевается, что всё это нужно тому, кто его запускал, он обработает эту информацию за пару секунд после появления «зомби» и «отпустит» его. Но не всё ПО работает так корректно — об этом и статья.
собирать статистику и отправлять непосредственно разработчикам.

А потом люди жалуются на вездесущую телеметрию.
/nubmode on
Как этой зомбиловилкой пользоваться? Что скачать надо из этой кучи файлов?
Я взял каталог prebuilt — вылетает с ошибкой
/nubmode off

хмм. скачал всё одним зипом. развернул, запустил — работает. 0 зомби…
Скорее всего .exe и .dll нужны. 0 зомби — это круто. Но у большинства так и будет. Ну или будет этих зомбей 5 штук. Это некритично.

Проблемы возникают когда в системе заведётся процесс, который их не отпускает и не даёт им умереть спокойно. Тогда можно получить сотни тысяч зомбей и все радости, описанные в статье…
у меня Хром ведёт себя не лучше зомби. ну или я себя так веду, открывая стопицот вкладок с ютубом и прочим, и держа их открытыми месяцами
уже снёс его. он спустя неделю вместо ютуба стал показывать ошибку 400 и пришлось удалить его и куки
35 total zombie processes.
30 zombies held by explorer.exe(5764)
28 zombies of LogonUI.exe

Причём после каждого Win-L + разблокировки добавляется по одному зомби.
Only those users with full accounts are able to leave comments. Log in, please.