Как стать автором
Обновить

Комментарии 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ГБ.
НЛО прилетело и опубликовало эту надпись здесь
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 окон в браузере, лениво сёрфят полдня и считают работу зачтённой, если это не крашится и не улетает в лютые тормоза. Роль бет исполнят простые юзьвери, им не привыкать, они же пусть и делают статистические и структурные анализы потребления памяти, обращений к диску, загрузки проца и сетевых запросов. Сплошная экономия, так ещё и чувство сопричастности к процессу разработки за «спасибо». :)
Компилировать — нет, для этого много памяти не нужно. А вот линкер при сборке Хрома может десятки гигабайт в одиночку выжирать…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Может быть и обращают.
Но по моим наблюдениям, когда памяти остаётся маловато или совсем мало, у хрома начинаются серьёзные проблемы.
Начиная с задержек отрисовки табов в заголовке окна и заканчивая сообщениями «Вкладка не отвечает» после попытки открыть новую пустую (!) вкладку.
Новая пустая вкладка вообще-то запускает целый новый процесс — со всеми вытекающими.
С другой стороны, у меня теперь сознательная политика — не использовать Chrome, не ставить его и предлагать всем его удалить.
НЛО прилетело и опубликовало эту надпись здесь
Мой FF 40, прям возмутился отображая этот камент.
НЛО прилетело и опубликовало эту надпись здесь
А этот «memory pressure» может определить, что, несмотря на работавший целый день браузер, вот именно сейчас 6гб памяти нужно только что запущенной игре?
А Вы ещё пользуетесь хромом??? Я его поставил себе, использовал несколько дней, заметил, что комп стал работать сильно медленнее, открыл диспетчер задач, увидел, что большую часть памяти и процессора жрёт именно хром. Снёс хром — с тех пор комп просто летает.
НЛО прилетело и опубликовало эту надпись здесь
.нет 4.5 уже не ставится на ХР или это из-за мало совместимого х64 у ХР?
НЛО прилетело и опубликовало эту надпись здесь
Попробуйте пересобрать под более старый .NET. Там же ничего кроме P/Invoke не используется… Еще можно попробовать под Mono запустить. Или конфиг исправить, чтобы .NET 4.0 использовался, он под XP есть.
НЛО прилетело и опубликовало эту надпись здесь
Там надо, видимо, асинхронные функции порезать. Или библиотеку с реализацией асинхронности подключить.

А что говорит Mono?
НЛО прилетело и опубликовало эту надпись здесь
Тогда Microsoft.Bcl.Async
НЛО прилетело и опубликовало эту надпись здесь
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 клиентов… ну то что происходит, машина умирает. Хорошо когда люди включают голову, хотя бы иногда, при настройке софта и выборе нагрузок на железо!
НЛО прилетело и опубликовало эту надпись здесь
Жрут точно также, просто чуть меньше.
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'ов давно стало бы шести-и семизначными.
В ссылке на твиттер (выше): «Also my PIDs are well into the 2,000,000 range.»
Всего лишь 202 зомби, хотя не перегружался неделю и в студии постоянно открываю тяжеловесные проекты (хотя прямо говоря — да, приходится порой студию из процессов убивать, т.к. держит файлы)
Вы бы хоть версию винды писали, можно было бы как-то статистику организовать. В конце концов, выяснить, в какой момент мелкомягкие ушли в грех.

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

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

и для «левого» человека данные моменты могут являться не очевидными.
Для «левых» людей в репозитории есть папка prebuilt :-)
Опять же, мне, левому человеку, это название ни о чем не говорит.
И да, я программист. Но ЯП иной и своя компоновка как директорий, так и наименований.
С моей колокольни тут будет «что-угодно», но не результат работы компилятора… скорее сорцы/компоненты, ибо стоит 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 — неподходящее место для этого.
НЛО прилетело и опубликовало эту надпись здесь
Я из тех, кто сначала «читает ман, потом тыкает/делает».
Мана нет (Readme), названия не понятные. Пошел спрашивать.
Приставка «pre-» — значит «перед, предварительно». «built» — это «собранный». «prebuilt» — «предварительно собранный». Ну в общем, точно не сорцы.
Вопрос: если есть механизм отслеживания количества зомби процессов под виндой — то можно ведь встроить этот механизм непосредственно в ОС, собирать статистику и отправлять непосредственно разработчикам.

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

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

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

Причём после каждого Win-L + разблокировки добавляется по одному зомби.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий