Комментарии 12
Когда следующая часть?
Много лет наблюдений и небольших экспериментов за Хромом показывает, что он стремится сожрать всю память в системе на всякий случай и крайне неохотно отдаёт её назад сам. Типа если вкладке уже потребовалось 1 Гб памяти разок, значит и ещё раз может потребоваться. И это не утечки того же js — gc должен был убраться давно.
У меня в хроме на линуксе вкладки группируются по процессам в оперативе.
И до тех пор пока хотя бы одна вкладка из этой группы висит открытая, все остальные почему-то остаются в оперативной памяти. А в внутреннем диспетчере задач хрома отображаются как dedicated worker
Сознательное решение разработчиков «кэшировать все, что кэшируется, буферизовать все что буферизуется», пока есть память. В Chromium есть механизм определения memory pressure, и когда с памятью становится плохо (например, она требуется другим приложениям), браузер начинает дропать кэши, и т.д. Когда памяти совсем мало (critical состояние) — останавливаются фоновые процессы, выгружаются вкладки.
На Windows и macOS оно работает довольно давно, для Linux долгое время у них этот функционал был вообще полностью выпилен после каких-то переделок и не работал в принципе (да и в старой реализации был один эпичный WTF), но летом они неожиданно очнулись и все-таки приняли мой патч, возвращающий это на место (пока что с оценкой «в лоб», без калькуляции swap faults и PSI, может быть когда-нибудь будет время доделать).
А здесь вода водная, для младших школьников, простите.
А он превращается в IE в своем худшем воплощении. Стремление охватить все что можно и нельзя ожидаемо приводит к монструозности, неповоротливости, ненадежности и остальным, сопутствующим "болячкам"…
Устройство современного веб-браузера Chrome (часть 1/4)