Comments 12
Попытка управлять руками памятью в системах с автоматическим управлением (и кучей эвристик в этом управлении), как правило, ни к чему хорошему не приводит. В Хроме дела не «хуже», чем в Фаерфоксе, а, вероятно, оптимальнее — если нет дефицита памяти _в данный конкретный момент времени_ (никто не запрашивает), то можно и отложить тяжёлый запуск коллектора, накопив бОльший блок для освобождения. В ситуации с дефицитом памяти этот график наверняка станет другим. Вся подобная ручная возня с памятью тянется мифологией и сказаниями предков ещё из тёмных времён MS-DOS и сплетается с патологическими формами «я лучше производителей платформы знаю как должно быть». Может, и действительно лучше, но тогда стОит заняться написанием патчей для этой платформы, а не конструированием костылей на уровне выше.
Я в статье привёл два примера, когда стратегия «вся свободная память — моя память» (кстати, популярная как раз в эпоху MS-DOS) не всегда работает. Дополню.
Допустим, браузер забил всю оперативку мусором. Другое приложение тоже ориентируется на количество свободной памяти. Оно видит, что памяти нет, и выделяет для некой своей операции буфер пониженного размера, что приводит к понижению производительности. Или выделяет такой же объём, допустим гигабайт, а операционная система, чтобы удовлетворить требование, перемещает часть занятой памяти (занятой мусором) в файл подкачки. В этот момент браузер видя, что памяти маловато, наконец начинает убирать мусор, только уже поздновато…
В идеальном мире, где у людей куча свободного времени — да. В реальном, написать костыль + пнуть разработчиков в багтрекере намного быстрее.
Допустим, браузер забил всю оперативку мусором. Другое приложение тоже ориентируется на количество свободной памяти. Оно видит, что памяти нет, и выделяет для некой своей операции буфер пониженного размера, что приводит к понижению производительности. Или выделяет такой же объём, допустим гигабайт, а операционная система, чтобы удовлетворить требование, перемещает часть занятой памяти (занятой мусором) в файл подкачки. В этот момент браузер видя, что памяти маловато, наконец начинает убирать мусор, только уже поздновато…
но тогда стОит заняться написанием патчей для этой платформы, а не конструированием костылей на уровне выше.
В идеальном мире, где у людей куча свободного времени — да. В реальном, написать костыль + пнуть разработчиков в багтрекере намного быстрее.
Наверное, вам стОит изучить, как устроена виртуальная память (и когда приложение в современных операционных системах получает сообщение о невозможности выделения памяти, и как соотносятся RTL-malloc'и с системными вызовами выделения памяти). Всё сильно сложнее, чем в MS-DOS, и приложения легко могут запрашивать памяти больше, чем есть реально планок в компьютере (пока не начнут использовать эту память — тут уже включается подкачка или жёсткие эксепшны о недостатке). «Чем меньше цифры в ГУЕ менеджера памяти, тем лучше» — культ карго чистой воды, отзывчивость системы достигается не снижением этих цифр, а стабилизацией их значений (уменьшением количества изломов на гребёнке графика, если говорить грубо, но это тоже очень грубо и не должно быть единственным аспектом оптимизации).
Сейчас проверил, как Chrome 58 ведет себя в условиях нехватки памяти. Во время работы расширения запустил в фоне утиль, который в цикле выделяет, заполняет и тут же освобождает почти всю свободную оперативную память. Результат: в файл подкачки ушло примерно 400 МБ, кэш винды упал до нуля, а процесс с расширением… все также бодро лопает почти 500 МБ. Может бы и дальше продолжил расти, у меня сейчас нет времени долго тесты гонять.
Если система стоит на HDD, то в вышеприведенной ситуации об отзывчивости можно только мечтать.
культ карго чистой воды, отзывчивость системы достигается не снижением этих цифр, а стабилизацией их значений
Если система стоит на HDD, то в вышеприведенной ситуации об отзывчивости можно только мечтать.
Несколько запущенных копий расширения довольно быстро его исчерпают и приведут либо к «падению» процесса, либо к проблемам воспроизведения видео
Как минимум спорное утверждение.
Да и вообще: chrome + 15 расширений + over
Как минимум спорное утверждение.
Я привёл в статье ссылку на chromium issue 713344, в которой процесс разрастался до 3.5 ГБ. Если запустить тот пример (переместив с диска в инет) в нескольких вкладках, то процесс падает из-за недостатка памяти. Причём падает 64-битный браузер, похоже у него где-то в коде есть лимит на 4 ГБ на процесс.
Но это баг GC, который надо исправлять, а не «особенность» его стратегии.
Я заводил похожий issue 610158, сразу признали багом и кинулись чинить.
Правда, дальнейшую судьбу бага я так и не понял :) Вскоре появилась пометка Fixed, но в текущей стабильной версии 58 он проявляется всё равно. За год изменения не докатились из dev до stable?
Я заводил похожий issue 610158, сразу признали багом и кинулись чинить.
Правда, дальнейшую судьбу бага я так и не понял :) Вскоре появилась пометка Fixed, но в текущей стабильной версии 58 он проявляется всё равно. За год изменения не докатились из dev до stable?
За год изменения не докатились из dev до stable?
omahaproxy.appspot.com говорит, что коммит попал в версию 52. Если ошибка до сих пор присутствует, то наверное нужно создать новую issue. А может будет достаточно отписаться в старой.
К сожалению тут зависит от системы, а точнее от конфигурации компа и приложений. Я, помнится, оставил свой ноут (8GB, ubuntu 16.04) с запущенным в хроме вк на сообщениях (по моим наблюдениям самый активный и стабильный сжиратель памяти). Через часов 9-10 пришёл, еле переключив на tty1, запустил htop и офигел — кроме браузера я оставил ещё свою ide от JB, которая написана на java, вечном пинаемом за сожранную память. Тк вот, ide крутила девовский nodejs на 20% памяти. Ещё примерно 10% на себя забрала сама ось и её графика. Остальные 70 были безжалостно сожраны хромом…
Пришлось вырубать с кнопки.
Если в Firefox сборщик мусора достаточно неплохо справляется, то в Chrome он явно отлынивает от работыИ правильно делает!
Вы смотрите на график с точки зрения пользователя PC, который подключен к розетке и возможно страдает от нехватки RAM. В этом случае «оптимизация» GC выглядит круто!
Но с другой стороны, из-за вашего решения, пользователи смартфонов и ноутбуков начинают судорожно искать зарядное устройство и розетку, потому как вместо того, чтобы «отлынивать» браузер в панике пинает GC, чтобы тот освободил целых ~20 Мб памяти!
Не стоит забывать, что уже сейчас в вебе больше 50% — мобильные пользователи, и дальше эта цифра будет только рости. Возможно ваш плагин и работает для десктопных браузеров, но они так же запускаются на ноутбуках, которым важна автономность. Автономность 1-3 часа без розетки — это очень больно :-(
Ничто не мешает браузеру менять поведение GC в зависимости от типа питания. В моем случае питание было от розетки. И расширение предназначено для настольных компов.
Но идея интересная. Можно вызывать navigator.getBattery() и не использовать трюки если питание от аккумулятора.
Но идея интересная. Можно вызывать navigator.getBattery() и не использовать трюки если питание от аккумулятора.
GC занимается не только сборкой, но и выделением памяти и просто так взять и поменять алгоритм на лету — это не тривиальная задача.
Да, изменить частоту сборки — в теории можно, но в этом случае ноутбук будет сильнее греться и даже куллером жужжать начнет — это тоже неприятный опыт для пользователя, по-моему, даже более неприятный, чем небольшие тормоза какого-то приложения.
ps: в любом случае, прежде чем внедрять такой подход стоит лишний раз подумать, стоит ли так сильно усложнять систему (поддержку) и какой профит от этого будет?
Да, изменить частоту сборки — в теории можно, но в этом случае ноутбук будет сильнее греться и даже куллером жужжать начнет — это тоже неприятный опыт для пользователя, по-моему, даже более неприятный, чем небольшие тормоза какого-то приложения.
ps: в любом случае, прежде чем внедрять такой подход стоит лишний раз подумать, стоит ли так сильно усложнять систему (поддержку) и какой профит от этого будет?
Sign up to leave a comment.
Пытаемся управлять освобождением памяти в JavaScript