Свопит Chromium (Chrome) — один из способов решения проблемы через overcommit memory

После обновления на одну из новых версий браузера Chromium (Google Chrome) после небольшого периода работы данные начинают писаться в своп что намертво вешает систему на некоторое время и после отвисания все равно продолжаются тормоза. Очистка свопа (swapoff -a) спасает лишь на несколько минут по прошествии которых своп опять начинает заполняться с еще большим упорством… Спасала только перезагрузка и то лишь на некоторое время…

Это для меня показалось очень странным ведь други приложения практически никогда не «цепляют» swap-раздел тем более что памяти у меня три гигабайта чего уж никак не должно быть мало для комфортной работы…

В поисках решения рыть интернет пришлось долго… В основном все утыкалось в информацию про имеющиеся в программе утечки памяти которые появляются и «зашиваются» чуть ли не в каждой новой версии браузера однако помочь в моей проблеме это никак не могло…

Однако одно из решений было найдено и оно помогло мне избавиться от использования свопа Хромиумом — по крайней мере за месяц использования после этого браузер ни разу не залез в своп хотя и не закрывался по полдня ни разу…

Собственно решение требует некоторой степени экспериментирования с конкретным компьютером — например у меня в доме два ноутбука и на обоих для оптимального результата пришлось выставлять разные значения. Однако на обоих проблема с лезущим в своп гуглобраузером была решена…

Я говорю про настройку overcommit memory

Overcommit — стратегия выделения памяти когда операционная система разрешает приложениям занимать больше виртуальной памяти чем доступно в системе.

Сейчас в ядре два параметра отвечающих за overcommit памяти:

  • vm.overcommit_memory (/proc/sys/vm/overcommit_memory) — отвечает за стратегию overcommit
  • vm.overcommit_ratio (/proc/sys/vm/overcommit_ratio) — отвечает за уровень в процентах overcommit

Собственно стратегии у vm.overcommit_memory могут быть три:

  • OVERCOMMIT_ALWAYS (значение выставлено в 1) — ядро всегда удовлетворяет любые запросы на выделение памяти. Реально страницы памяти будут выделяться при первом обращении к ним.
  • OVERCOMMIT_GUESS (значение 0) — эвристический подход к распределению памяти. Используется по умолчанию ибо подходит для большинства задач — именно он и приводит к моей проблеме. А vm.overcommit_ratio по умолчанию нвыставлен в значение 50% и будет использоватся только в случае OVERCOMMIT_NEVER. Система будет отвергать только запросы которые в принципе не могут быть удовлетворены остальные — удовлетворять вне зависимости от наличия свободной памяти. На деле практически не отличим о OVERCOMMIT_ALWAYS.
  • OVERCOMMIT_NEVER (значение 2) — работа вообще без overcommit. Полный объём памяти исходя из которого будут удовлетворяться или отвергаться запросы на выделение памяти вычисляется как total_swap + total_ram * overcommit_ratio / 100. Таким образом при overcommit_ratio 100 мы получаем режим схожий с OVERCOMMIT_GUESS но с явно установленным «ограничителем».

Хочется отметить что операционная система всегда резервирует около трех процентов памяти для процессов пользователя root…

Политика «реально выделять память только при обращении к ней» приводит к ситуациям когда суммарный размер виртуальной памяти приложений может намного превосходит реально имеющийся объем ОЗУ и свопа. В теории когда реальная память заканчивается в Linux срабатывает OOM Killer убивающий лишние самые «невыгодные» с точки зрения ядра процессы. На практике же OOM Killer отрабатывает далеко не всегда: система может уйти в длительный лаг или зависнуть.

Реально не могу подсказать какая из политик лучше подойдет для вашей машины могу лишь сказать что методом выставления разных значений и тестирования работы при них могу сообщить что для меня оказались идеальными следующие:

sudo sysctl -w "vm.overcommit_memory=1"sudo sysctl -w "vm.overcommit_ratio=75"

Собственно этими командами и выставлются необходимые значения а чтобы они работали и после перезагрузки необходимо прописать эти величины в /etc/sysctl.conf. Повторяюсь значения могут быть другими — экспериментируйте…

Таким образом в этой части для оптимизации работы прежде всего браузера Chromium мой sysctl.conf выглядит так:

vm.swappiness=30vm.vfs_cache_pressure=1000vm.overcommit_memory=1vm.overcommit_ratio=75

Оригинал статьи http://pingvinoff.net/2011/11/15/swapit-chromium-chrome-overcommit-memory/

0 комментариев

Оставить комментарий