Начать стоит с того, что эти гигабайты у тебя есть, и ты, как десктопный пользователь, мало что потерял. Сравнивать такие процессы надо с ограничением доступной памяти и в динамике.
@ceyt > мало что потерял Потерял отзывчивость системы, потому что на дисковый кеш перестало хватать памяти, и любой вызов git … превращался в ожидания по нескольку секунд.
@minoru Стоп. Где записано, что а) дисковый кеш имеет приоритет над активным GUI-приложением; б) данные git'а надо кешировать обязательно? Вот когда ты неким образом обозначишь свои желания (хотя бы путём ограничения аппетитов Хрома кажущимся тебе логичным объёмом памяти), тогда и можно будет оценивать их выполнение тупой железякой.
@ceyt Ты всё правильно говоришь, но забываешь о том, что такие же рассуждения должны проводить и разработчики, если они хотят, чтобы их продуктом кто-то пользовался. Исходя из нынешних типичных объёмов памяти, можно сделать вывод, что в нынешнем Хромиуме на среднем компьютере можно открыть десяток вкладок. Это если на компьютере ничего, кроме Хромиума, не запущено. Это ок?
@minoru Неправильно. Если Хром без трёх из этих четырёх гигабайтов откажется работать, тогда такой вывод можно будет сделать. Ты непрозрачную систему кеширования в браузере, заточенную под его задачи, считаешь хуже непрозрачной системы кеширования в ОС, которая всем старается отвесить понемножку.
Довод про количество пользователей бьёт по тебе самому, поскольку очевидно, что у большинства пользователей компьютера только браузер на всех их гигабайтах и запущен, и им это всё как раз-таки нравится.
@ceyt > Ты непрозрачную систему кеширования в браузере […] считаешь хуже непрозрачной системы кеширования в ОС Да, потому что она по определению хуже работает в системе, где крутится ещё что-то, кроме браузера.
у большинства пользователей компьютера только браузер на всех их гигабайтах и запущен, и им это всё как раз-таки нравится
Нравится? Нравится, что сколь-нибудь большое приложение мгновенно выталкивает Chromium в своп и начинаются вселенские тормоза?
@minoru В любой системе крутится «что-то ещё», даже в ChromeOS. Надо давать конкретные определения по интересующему характеру нагрузки.
Если браузер в такой ситуации не освобождает память в пределах одного цикла очистки, а пытается её держать в свопе, проблема в мозгах разработчиков. Что-то мне подсказывает, что они не такие идиоты.
@ceyt Прости, но ты точно не идиот? Ты мне на протяжении всего треда толкаешь какую-то едва связную фигню, упорно игнорируя тот факт, что четыре гига для шести вкладок — это чересчур много. Этому нет оправдания в софте, который должен крутится на multi-purpose машине.
@j123123 Ну сорь. Я перед этим оттуда же смотрел галлереи, вообще много по сайту шлялся, может, он там внутре закешировал что-то. Правда, у меня до сих пор открыта ещё одна вкладка с этого сайта, так что хз, как это работает.
@minoru В интернете есть куча идиотов, которые не в состоянии ни объяснить, откуда берутся цифры в файрфоксовском about:memory, ни устроить тестирование на фиксированных объёмах памяти, чтобы выяснить, каковы реальные минимальные требования в целом для программы и на каждую вкладку, но горазды кричать, что браузер жрёт их память (а зачем они её тогда в компьютер вставляли? пусть на столе лежит). Что на них обращать внимание? Я рассчитываю, что на другом конце разумное существо, способное развивать мысли, и которому не надо всё разжёвывать.
Ты не понимаешь, что на свободной памяти не написано, что она кому-то потребуется в будущем. Хром имеет полное право её забрать, если на то есть причина, а причин у него полно: миллион генераций жаваскрипт-объектов для веб-говна, кеширование отрендеренной графики в полноэкранных разрешениях, кеширование страниц из истории, вся прочая хуйня, рассчитанная на то, чтобы сэкономить миллисекунды реакции на действия пользователя. Всё это динамически разбухает и сбрасывается (об этом прекрасном факте ты сам нам русским языком в посте сообщил).
DOS закончился двадцать лет назад, с тех пор все компьютеры многозадачные. Просто твои задачи — они конкретно твои, а отнюдь не всеобщие. Можно легко догадаться, что 90 процентам пользователей такое поведение браузера неудобств не причиняет, потому что ничего жирного они запускать вообще не будут. Для них тратить всю память на ускорение работы браузера — не «чересчур», а именно что самый логичный вариант. Тебе необходима мгновенная реакция на повышение требований со стороны других программ? Либо проси рычаг для сброса кешей, либо ограничивай браузер заранее.
Я тоже могу думать, что современные браузеры охуели, но это мне не мешает открыть about:memory (теперь уже в Хромиуме) и узнать, что с тремя вкладками с простыми сайтами он ест даже немного меньше, чем старая Опера, которая на них же тратит 220 МБ. А дальше вот в динамике начинаются взлёты и падения, потому что это, бля, динамика, а ты мне из одного мгновенного замера выводишь хрен знает что.
Почему джаваёбы не говорят «а сделайте так, чтобы JVM сама догадалась, что нам от неё нужно», а идут читать про сборку мусора и настройку лимитов да таймаутов?
@ceyt Ух! А как в эту твою картину мира вписывается то, что Chromium не влезает в память уже при полусотне вкладок? Тут уж явно не в кешах дело — он же, наверное, умный, и догадывается сбросить их, когда оперативки больше нет? Или в процессе оптимизации забыли добавить проверку на то, что оперативка как таковая закончилась и следующий байтик нам выдадут уже в кредит^W^Wза счёт своппинга чего-то другого?
Это не «моя картина мира», а очевидные вещи. Тебе обещали, что ты пятьдесят (кстати, было же четыре?) жирных вкладок одновременно запустить сможешь? Выкладывай под них необходимое количество памяти. При закрытии они ссохнутся.
@ceyt (Сорь, отправил, не дописав остатка коммента.)
пятьдесят (кстати, было же четыре?) жирных вкладок
Я о другой ситуации подумал просто: на компе после запусков иксов запускается только Chromium, и дальше ты просто открываешь-закрываешь вкладочки. Настанет момент, когда Chromium-у не хватит памяти, и на моём опыте этот момент наставал где-то на полусотне вкладок.
пятьдесят (кстати, было же четыре?) жирных вкладок запустить сможешь?
Обещали быстрый браузер, а на деле он тормозит (потому что не умещается в память и постоянно свопится). Кусочек моего хейтерства также направлен на пользователей этого говна, которые смеют утверждать, что FF течёт сильнее (о том, что он тормозит, если оба браузера умещаются в память, спорить не будем — это факт).
@minoru Так ведь ты не можешь бесконечно вкладки открывать, когда-нибудь этот момент настанет. С сегодняшним цирком с конями в вебе он у тебя настаёт на пятидесяти вкладках, и ничего тут странного нет. Вот когда процесс с вкладкой жирнеет по мере того, как накапливается история просмотра, но не хочет худет — это проблема.
Правда, судя по документации, основной способ освобождения памяти — убийство самой ненужной вкладки (с автоматической перезагрузкой при последующем обращении к ней пользователя), так что ты того же самого можешь добится, взяв расширение, саспендящее вкладки после какого-то лимита.
@ceyt Ну, с FF у меня уже выверенный временем подход — как только он жирнеет так, что занимает больше половины оперативки, я его перезапускаю. Т.к. он потихоньку жирнеет по мере юзания (не в последнюю очередь благодаря подгружающимся вкладкам — у меня куча окон о сотнях вкладок, которые не подгружаются после запуска FF, а ждут, когда к ним обратятся), перезапускать приходится… Хм… раз в несколько недель? Короче, я успеваю забыть о предыдущем перезапуске.
А Chromium быстрый и динамичный: никуда сам по себе не растёт, но больше десятка вкладок открывать опасно. Т.е. с ним проблема в том, что ты тупо не успеваешь среагировать на его требования к памяти — один клик, и половина программ в свопе.
Так ведь ты не можешь бесконечно вкладки открывать, когда-нибудь этот момент настанет.
Это да, но в браузере-конкуренте (Firefox, то есть) я могу заниматься этим дольше (на той же машине с тем же объёмом памяти). Ну т.е. Chromium быстрый, но во многом бесполезный.
@minoru Там небось еще и история у каждого таба жирная была. Хром к тому же хранит еще и предыдущие страницы в памяти (если ее достаточно свободной) чтобы давать тебе быструю возможность навигации по истории. Какой смысл считать потребленную память вне контекста альтернативных издержек (т.е. вне контекста когда съеденная хромом память вытеснила что-то еще) - хуй знает, разве что фетишь на свободную память.
@minoru > Исходя из нынешних типичных объёмов памяти, можно сделать вывод, что в нынешнем Хромиуме на среднем компьютере можно открыть десяток вкладок.
Экстраполяция уровня пердолика. С чего ты взял, что хром гарантированно столько же памяти будет жрать когда память начнет кончаться?
@krkm > Там небось еще и история у каждого таба жирная была. Табы были открыты с помощью Ctrl-click, дальше я их только скроллил с целью прочесть заголовок, ну и туда-сюда двигал по таббару, упорядочивая.
вне контекста когда съеденная хромом память вытеснила что-то еще
Остальные четыре гига были заняты всем остальным софтом. Chromium провоцировал свопы, когда я пытался ещё что-то в нём открыть, например, картинки из галереи на том же сайте. Достаточно контекста?
@krkm «Гарантированно столько же» — не уверен. А вот то, что эта скотина регулярно не умещается в свободные гигабайты оперативки (обычно у меня их около шести), если открыть хотя бы полсотни табов — факт. Так что экстраполяция пусть и утрированная, но не думаю, что отличается от правды более чем на порядок.
@minoru Ctrl-click дублирует историю в новый таб (попробуй сейчас и убедись, что кнопка "назад" активная").
> Chromium провоцировал свопы
Чини свой swappiness или как там. У меня 12гб, свопа нет, хром очень быстро съедает половину при небольшом количестве табов, но потом потребление памяти почти не меняется, несмотря на то что табов (и окон) становится в разы больше.
@krkm > (попробуй сейчас и убедись, что кнопка "назад" активная") Попробовал, не активная.
Чини свой swappiness или как там.
Я лучше полушаю @ceyt и начну эту скотину гонять в отдельной cgroup или ещё чём-то, что даст мне возможность задать верхнюю планку потребления памяти.
У меня 12гб, свопа нет
Я уже высказывал подозрение касательно того, что распрекрасный Chromium настолько ультрасовременный, что при всей своей оптимизированности не понимает, когда заканчивается собственно оперативка и начинается своп. И в итоге думает, что у меня не 8Гб памяти, а 16, и сжирает их все, попутно вытясняя в своп всю остальную систему. Но мне лень раскуривать архитектуру и читать релевантный код, а как проверить это всё экспериментально, я не знаю.
@minoru Он у тебя просто начнёт умирать раньше. Лучше пере-define под линукс монитор свободной памяти из ChromeOS (которая тоже линукс), как в ссылке выше, и скомпилируй.
Начать стоит с того, что эти гигабайты у тебя есть, и ты, как десктопный пользователь, мало что потерял. Сравнивать такие процессы надо с ограничением доступной памяти и в динамике.
@ceyt > мало что потерял
Потерял отзывчивость системы, потому что на дисковый кеш перестало хватать памяти, и любой вызов
git …превращался в ожидания по нескольку секунд.@minoru Стоп. Где записано, что а) дисковый кеш имеет приоритет над активным GUI-приложением; б) данные git'а надо кешировать обязательно?
Вот когда ты неким образом обозначишь свои желания (хотя бы путём ограничения аппетитов Хрома кажущимся тебе логичным объёмом памяти), тогда и можно будет оценивать их выполнение тупой железякой.
@ceyt Ты всё правильно говоришь, но забываешь о том, что такие же рассуждения должны проводить и разработчики, если они хотят, чтобы их продуктом кто-то пользовался. Исходя из нынешних типичных объёмов памяти, можно сделать вывод, что в нынешнем Хромиуме на среднем компьютере можно открыть десяток вкладок. Это если на компьютере ничего, кроме Хромиума, не запущено. Это ок?
@minoru Неправильно. Если Хром без трёх из этих четырёх гигабайтов откажется работать, тогда такой вывод можно будет сделать. Ты непрозрачную систему кеширования в браузере, заточенную под его задачи, считаешь хуже непрозрачной системы кеширования в ОС, которая всем старается отвесить понемножку.
Довод про количество пользователей бьёт по тебе самому, поскольку очевидно, что у большинства пользователей компьютера только браузер на всех их гигабайтах и запущен, и им это всё как раз-таки нравится.
@ceyt > Ты непрозрачную систему кеширования в браузере […] считаешь хуже непрозрачной системы кеширования в ОС
Да, потому что она по определению хуже работает в системе, где крутится ещё что-то, кроме браузера.
Нравится? Нравится, что сколь-нибудь большое приложение мгновенно выталкивает Chromium в своп и начинаются вселенские тормоза?
@minoru В любой системе крутится «что-то ещё», даже в ChromeOS. Надо давать конкретные определения по интересующему характеру нагрузки.
Если браузер в такой ситуации не освобождает память в пределах одного цикла очистки, а пытается её держать в свопе, проблема в мозгах разработчиков. Что-то мне подсказывает, что они не такие идиоты.
@ceyt Прости, но ты точно не идиот? Ты мне на протяжении всего треда толкаешь какую-то едва связную фигню, упорно игнорируя тот факт, что четыре гига для шести вкладок — это чересчур много. Этому нет оправдания в софте, который должен крутится на multi-purpose машине.
@j123123 http://geekandsundry.com/critical-role-grogs-soundtrack-in-the-key-of-rage/ и такие же для остальных персонажей шоу.
@j123123 Ну сорь. Я перед этим оттуда же смотрел галлереи, вообще много по сайту шлялся, может, он там внутре закешировал что-то. Правда, у меня до сих пор открыта ещё одна вкладка с этого сайта, так что хз, как это работает.
@minoru В интернете есть куча идиотов, которые не в состоянии ни объяснить, откуда берутся цифры в файрфоксовском about:memory, ни устроить тестирование на фиксированных объёмах памяти, чтобы выяснить, каковы реальные минимальные требования в целом для программы и на каждую вкладку, но горазды кричать, что браузер жрёт их память (а зачем они её тогда в компьютер вставляли? пусть на столе лежит). Что на них обращать внимание? Я рассчитываю, что на другом конце разумное существо, способное развивать мысли, и которому не надо всё разжёвывать.
Ты не понимаешь, что на свободной памяти не написано, что она кому-то потребуется в будущем. Хром имеет полное право её забрать, если на то есть причина, а причин у него полно: миллион генераций жаваскрипт-объектов для веб-говна, кеширование отрендеренной графики в полноэкранных разрешениях, кеширование страниц из истории, вся прочая хуйня, рассчитанная на то, чтобы сэкономить миллисекунды реакции на действия пользователя. Всё это динамически разбухает и сбрасывается (об этом прекрасном факте ты сам нам русским языком в посте сообщил).
DOS закончился двадцать лет назад, с тех пор все компьютеры многозадачные. Просто твои задачи — они конкретно твои, а отнюдь не всеобщие. Можно легко догадаться, что 90 процентам пользователей такое поведение браузера неудобств не причиняет, потому что ничего жирного они запускать вообще не будут. Для них тратить всю память на ускорение работы браузера — не «чересчур», а именно что самый логичный вариант. Тебе необходима мгновенная реакция на повышение требований со стороны других программ? Либо проси рычаг для сброса кешей, либо ограничивай браузер заранее.
Я тоже могу думать, что современные браузеры охуели, но это мне не мешает открыть about:memory (теперь уже в Хромиуме) и узнать, что с тремя вкладками с простыми сайтами он ест даже немного меньше, чем старая Опера, которая на них же тратит 220 МБ. А дальше вот в динамике начинаются взлёты и падения, потому что это, бля, динамика, а ты мне из одного мгновенного замера выводишь хрен знает что.
Почему джаваёбы не говорят «а сделайте так, чтобы JVM сама догадалась, что нам от неё нужно», а идут читать про сборку мусора и настройку лимитов да таймаутов?
@ceyt Ух! А как в эту твою картину мира вписывается то, что Chromium не влезает в память уже при полусотне вкладок? Тут уж явно не в кешах дело — он же, наверное, умный, и догадывается сбросить их, когда оперативки больше нет? Или в процессе оптимизации забыли добавить проверку на то, что оперативка как таковая закончилась и следующий байтик нам выдадут уже в кредит^W^Wза счёт своппинга чего-то другого?
@minoru 1. Смотришь сюда: https://chromiumcodereview.appspot.com/1250093006/
2. Смотришь сюда: https://chromium.googlesource.com/chromium/src.git/+/master/base/memory/
3. …
4. СОСЁШЬ.
5. …
6. SEND PATCHES.
Это не «моя картина мира», а очевидные вещи. Тебе обещали, что ты пятьдесят (кстати, было же четыре?) жирных вкладок одновременно запустить сможешь? Выкладывай под них необходимое количество памяти. При закрытии они ссохнутся.
@ceyt Первая ссылка отличная, фиг поймёшь — смержили, реджектнули, чо ваще произошло с тем патчсетом…
@ceyt (Сорь, отправил, не дописав остатка коммента.)
Я о другой ситуации подумал просто: на компе после запусков иксов запускается только Chromium, и дальше ты просто открываешь-закрываешь вкладочки. Настанет момент, когда Chromium-у не хватит памяти, и на моём опыте этот момент наставал где-то на полусотне вкладок.
Обещали быстрый браузер, а на деле он тормозит (потому что не умещается в память и постоянно свопится). Кусочек моего хейтерства также направлен на пользователей этого говна, которые смеют утверждать, что FF течёт сильнее (о том, что он тормозит, если оба браузера умещаются в память, спорить не будем — это факт).
@minoru Никто зелёный свет не дал. Видимо, решили целиком всё переделывать. Когда-нибудь.
@minoru Так ведь ты не можешь бесконечно вкладки открывать, когда-нибудь этот момент настанет. С сегодняшним цирком с конями в вебе он у тебя настаёт на пятидесяти вкладках, и ничего тут странного нет. Вот когда процесс с вкладкой жирнеет по мере того, как накапливается история просмотра, но не хочет худет — это проблема.
Правда, судя по документации, основной способ освобождения памяти — убийство самой ненужной вкладки (с автоматической перезагрузкой при последующем обращении к ней пользователя), так что ты того же самого можешь добится, взяв расширение, саспендящее вкладки после какого-то лимита.
@ceyt Ну, с FF у меня уже выверенный временем подход — как только он жирнеет так, что занимает больше половины оперативки, я его перезапускаю. Т.к. он потихоньку жирнеет по мере юзания (не в последнюю очередь благодаря подгружающимся вкладкам — у меня куча окон о сотнях вкладок, которые не подгружаются после запуска FF, а ждут, когда к ним обратятся), перезапускать приходится… Хм… раз в несколько недель? Короче, я успеваю забыть о предыдущем перезапуске.
А Chromium быстрый и динамичный: никуда сам по себе не растёт, но больше десятка вкладок открывать опасно. Т.е. с ним проблема в том, что ты тупо не успеваешь среагировать на его требования к памяти — один клик, и половина программ в свопе.
Это да, но в браузере-конкуренте (Firefox, то есть) я могу заниматься этим дольше (на той же машине с тем же объёмом памяти). Ну т.е. Chromium быстрый, но во многом бесполезный.
@krkm > Там небось еще и история у каждого таба жирная была.
Табы были открыты с помощью Ctrl-click, дальше я их только скроллил с целью прочесть заголовок, ну и туда-сюда двигал по таббару, упорядочивая.
Остальные четыре гига были заняты всем остальным софтом. Chromium провоцировал свопы, когда я пытался ещё что-то в нём открыть, например, картинки из галереи на том же сайте. Достаточно контекста?
@krkm «Гарантированно столько же» — не уверен. А вот то, что эта скотина регулярно не умещается в свободные гигабайты оперативки (обычно у меня их около шести), если открыть хотя бы полсотни табов — факт. Так что экстраполяция пусть и утрированная, но не думаю, что отличается от правды более чем на порядок.
@krkm > (попробуй сейчас и убедись, что кнопка "назад" активная")
Попробовал, не активная.
Я лучше полушаю @ceyt и начну эту скотину гонять в отдельной cgroup или ещё чём-то, что даст мне возможность задать верхнюю планку потребления памяти.
Я уже высказывал подозрение касательно того, что распрекрасный Chromium настолько ультрасовременный, что при всей своей оптимизированности не понимает, когда заканчивается собственно оперативка и начинается своп. И в итоге думает, что у меня не 8Гб памяти, а 16, и сжирает их все, попутно вытясняя в своп всю остальную систему. Но мне лень раскуривать архитектуру и читать релевантный код, а как проверить это всё экспериментально, я не знаю.
@minoru Он у тебя просто начнёт умирать раньше. Лучше пере-define под линукс монитор свободной памяти из ChromeOS (которая тоже линукс), как в ссылке выше, и скомпилируй.
@komar Просто ассоциация «мат — комар», сорь.