Как автоматически убить нехватку памяти Firefox?

Ну, на самом деле это не ответ, потому что я не полностью решил проблему сам. Мое текущее «решение» состоит в том, чтобы в основном использовать Brave, но он не может обрабатывать все веб-сайты, поэтому это не полное решение.

Другим решением может быть OOMD на Facebook или нечто подобное, которое отслеживает запущенные процессы и автоматически убивает их, если угрожает стабильности системы. Эта реализация скорее ориентирована на сервер и, вероятно, не очень подходит для настольного компьютера (или сервера терминалов)

Однако реальное решение состоит в том, чтобы загрузить исходный код и исправить его, чтобы он стал менее требовательным к памяти. Я работаю над этим, но ирония здесь в том, что процесс сборки убивает убийца OOM. Сначала это зависало, но затем я добавил RPM_BUILD_NCPUS = 1 (я делаю это на fedora), что заставило его работать почти до конца. Но LD не хочет объединять все эти файлы .o в двоичный файл и не хватает памяти.

Я думаю, что основная проблема заключается в том, что Firefox рассматривает доступную память (включая подкачку) как свободную память и использует ее для кеширования и мусора. Первое, что я постараюсь, это выяснить, где Firefox проверяет / рассчитывает доступную память, и посмотреть, смогу ли я подключить память, правильно оценив свободную память. Это может быть связано с изменением одной строки кода, если они были достаточно любезны, чтобы поместить такой код в одном месте.

На данный момент мой ответ - использовать Brave, когда он работает, и переключаться на Firefox или Chrome, когда это не так. Но НИКОГДА не используйте Firefox или Chrome, когда работает другой браузер. Особенно не вместе. Они съедают память друг друга и часто зацикливаются на освобождении и захвате памяти.

Наконец, если вы используете более 24 ГБ для каждого браузера, вы намерены запустить его, которого должно быть достаточно в соответствии с тестами, проведенными другими. Кажется, что ни Firefox, ни Chrome не используют больше этого количества.

Да, и еще одно решение - использовать 32-битную версию Firefox с ограничением в 4 ГБ на процесс. Хотя Firefox порождает много процессов в последних версиях, так что это может не решить проблему.

Я также пытался создать виртуальную машину, где я пробовал и NetBSD, и OpenBSD с различными объемами оперативной памяти. В NetBSD я без проблем запускал Firefox с 1 ГБ оперативной памяти. а в OpenBSD мне понадобилось 2 ГБ. Виртуальная машина, такая как VirtualBox и без внутреннего файла подкачки, будет физически ограничивать объем памяти, который может использовать приложение. Но вы потеряете все аппаратное ускорение графики. Я использовал VirtualBox, а не libvirt, потому что VirtualBox позволяет ограничить память и процессор для гостевой ОС. Я не пробовал это с Linux, потому что моей главной целью было опробовать * ОС BSD: es и Firefox были лишь одной из вещей, которые я в них тестировал.

Когда я вызвал тяжелую перестановку в NetBSD, интересным результатом было то, что Firefox захлебнулся и был заморожен примерно на 15 минут, но остальная часть ОС работала совершенно свободно. Мне кажется, что подкачка ограничена каким-то отдельным процессом в NetBSD. Но для этого в Linux, вероятно, потребуются серьезные изменения в ядре, и это все еще не решит проблему. Это решает проблемы для других приложений, которые вы работаете, но Firefox по-прежнему зависает. Я не пробовал это в OpenBSD, но это форк NetBSD, поэтому я подозреваю подобные результаты.

Целью здесь было бы найти решение, в котором и приложение, и операционная система работают без зависания или входа в цикл подкачки. Убийство приложения на самом деле не достигает этой цели. И не будет другого планировщика. Единственное решение - это исправить приложение. И, честно говоря, Firefox нуждается в интенсивной модульности, чтобы его создание не занимало часов и не требовало перестройки всех компонентов, включая все компоненты сторонних производителей.