Ускоряем браузер и попутно продляем жизнь SSD — переносим кэш браузера на RAM-диск в Linux

Перенос дискового кэша браузера на RAM-диск, иными словами, в оперативную память компьютера, может оказаться целесообразным в следующих случаях:

1. Компьютер не очень быстрый и есть желание ускорить загрузку и отображение веб-страниц в браузере;
2. В компьютере установлен SSD и хочется, так или иначе, продлить его жизненный срок.

Тема отнюдь не новая. По запросу “перенос кеша браузера” Google находит много вариантов решения этой задачи. Большинство из них относится к Windows и является по сути повторением одного и того же – какой-либо вариант сторонней программы для организации RAM-диска плюс перемещение браузерных папок и создание на них символьных ссылок. Все достаточно просто и понятно.

Неприятность лишь в том, что для создания RAM-диска в Windows придется использовать сторонние утилиты, а в их бесплатном варианте вам предложат создать RAM-диск только фиксированного размера. Динамически расширяемый по мере заполнения диск — за отдельные деньги.

В отличие от Windows, в Linux изначально присутствуют отличные возможности для организации виртуальных дисков в памяти компьютера. Причем все они будут динамическими. Это значит, что от оперативной памяти в каждый момент времени будет “откусываться” ровно столько, сколько надо для размещения содержимого RAM-диска.

Речь идет о временной файловой системе tmpfs. На текущий момент времени tmpfs является наиболее совершенной реализацией рамдиска в операционной системе Linux. С ее помощью осуществляется монтирование каталогов файловой системы с их размещением не на физическом диске, а в ОЗУ компьютера.

Если предельный размер папки в файловой системе tmpfs не указан явно, будет использовано до 50% оперативной памяти.

При этом необходимо иметь в виду, что данная файловая система изначально предназначена для размещения временных файлов и при перезагрузке компьютера, если не принять дополнительных мер, все они будут утеряны.

В данной публикации представлено готовое решение по переносу дискового кэша на RAM-диск в Linux применительно к одному из самых популярных сегодня браузеров Google Chrome и его ближайшему родственнику — Chromium.

Последнее вовсе не означает, что данное решение не может быть использовано для других браузеров. Для этого нужно лишь выяснить где ваш любимый браузер хранит кэш-файлы.

При разработке алгоритма я использовал материалы двух статей. Одна из них посвящена решению данной задачи как раз для Google Chrome, другая для FireFox.

Почему я не захотел просто реализовать описанное в этих публикациях? Дело в том, что оба представленных варианта хороши только в том случае, когда компьютером всегда пользуется только один человек. То есть, они мгновенно переводят компьютер в однопользовательский режим. По крайней мере в отношении браузера.

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

Как бы там ни было, захотелось создать некое более-менее многопользовательское решение.

Кроме того в упомянутых публикациях не слишком доходчиво были описаны способы восстановления и сохранения содержимого RAM-диска.

Вот что получилось в итоге.

Создание общего RAM-диска с помощью tmpfs

1. Создаем новую папку

Начинаем с создания новой папки, которую и будем монтировать в оперативную память компьютера. Я решил разместить ее в каталоге /home:

sudo -i
mkdir /home/.brcache

Для того, чтобы она никого не смущала впоследствии, делаем ее скрытой.

2. Задаем разрешения на запись в новой папке для всех пользователей компьютера

Для того, чтобы этой папкой могли пользоваться все существующие на компьютере юзеры, пропишем им на нее соответствующие права.

Проще всего сделать это командой chmod 777 /home/.brcache, но чтобы не возникало паранойи на почве безопасности, мы пойдем правильным путем.

Создадим новую группу пользователей. Назовем ее, например, brusers.

Включим в нее всех пользователей данного компьютера:

usermod -a -G brusers username1
usermod -a -G brusers username2
.
usermod -a -G brusers usernameN

Если других пользователей пока нет, но они предполагаются, то их можно прямо сейчас добавить командой adduser.

Меняем владельца папки /home/.brcache и даем группе brusers права на запись:

chown root:brusers /home/.brcache
chmod 774 /home/.brcache

3. Создаем новый RAM-диск в папке /home/.brcache

Отрываем в текстовом редакторе, например gedit, файл fstab:

Добавляем в конец файла такую строку:

tmpfs /home/.brcache tmpfs rw 0 0

Сохраняем файл и перезагружаем компьютер.

После перезагрузки убеждаемся в том, что RAM-диск смонтирован и к нему есть доступ.

В листинге команды mount должна присутствовать строка “tmpfs on /home/.brcache type tmpfs (rw)”.

Убедиться в том, что RAM-диск реально доступен для записи обычному пользователю можно, например, создав на нем новый тестовый файл:

echo test > test.txt

Это же можно сделать и с помощью менеджера файлов. Естественно в нем нужно включить отображение скрытых файлов.

Если все прошло успешно, удаляем test.txt и движемся дальше.

Настройка дискового кэша в браузерах Google Chrome и Chromium

Согласно описанию, дисковый кэш браузера Google Chrome находится в папке

Chromium, старший брат Google Chrome, хранит кэш в

В gui-настройках этих браузеров задать значение предельного размера и расположение дискового кэша не получится. Цивилизованно сделать это можно двумя путями: с помощью дополнительных ключей типа “—disk-cache-size”, которые придется добавить ко всем ярлыкам запуска браузера, или с помощью политик.

Первый способ представляется не слишком удобным. Помимо ярлыков запуска браузера, как такового, нужно помнить еще и о существовании web-приложений на его основе, типа Gmail.

Поэтому будем однозначно использовать политики.

Файлы с правилами для Google Chrome должны быть размещены в папке /etc/opt/chrome/policies/managed и иметь расширение .json.

4. Создаем файл политик Google Chrome

Создадим недостающие папки и файл с правилами. Назовем его, например, chrome-cache.json.

sudo -i
mkdir /etc/opt/chrome
mkdir /etc/opt/chrome/policies
mkdir /etc/opt/chrome/policies/managed
gedit /etc/opt/chrome/policies/managed/chrome-cache.json

Ограничиваем предельный суммарный объем кэш-файлов и переносим его на RAM-диск. Для этого вписываем в созданный файл следующие инструкции:

<
«DiskCacheDir»: «/home/.brcache/chromediskcache/»,
«DiskCacheSize»: 100000000,
«MediaCacheSize»: 80000000
>

Размер кэша задается в байтах. Подробнее ознакомиться с политиками Google Chrome и скачать шаблоны можно здесь.

На каком уровне его ограничивать – вопрос сложный. Зависит, в первую очередь, от объема оперативной памяти вашего компьютера, во-вторых, от того, как много вы открываете новых веб-страниц.

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

Получить информацию о текущем объеме кэша можно прямо из браузера открыв страницу: chrome://net-internals/#httpCache.

Запускаем Google Chrome, открываем любой вебсайт и убеждаемся, что на RAM-диске появилась папка /home/.brcache/chromediskcache/Cache.

! В процессе отладки и тестирования я столкнулся со странным поведение Google Chrome – после внесения изменений в файл политик браузер упорно продолжал выполнять предыдущие инструкции.

Оказалось, что Chrome при запуске с большим удовольствием “глотал” файл резервной копии chrome-cache.json

, которую создавал текстовый редактор gedit.

Для того, чтобы этого не происходило нужно или временно отключить в настройках редактора создание запасной копии файла перед сохранением, или просто удалять ее вручную всякий раз после редактирования.

Дисковый кэш браузера переехал в оперативную память и содержимое веб-страниц, особенно при их повторном открытии, отображается значительно быстрее.

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

Для того, чтобы этого не происходило займемся вопросом сохранения и восстановления содержимого RAM-диска.

Восстановление содержимого RAM-диска

Очевидно, что для того, чтобы после перезагрузки компьютера каждый раз не начинать жизнь с чистого листа, содержимое RAM-диска перед выключением нужно тем или иным способом сохранить на физическом диске, а при загрузке вновь скопировать в память.

На первый взгляд задача не представляется сложной. Создадим в папке /etc/init.d новый скрипт, который назовем, например, ramdisksaverestore.

5.Создаем скрипт для сохранения и восстановления RAM-диска

Ниже представлен готовый рабочий скрипт. Его описание и пояснения будут даны ниже при обсуждении вопросов автозапуска.

Открываем на редактирование новый файл. Назовем его ramdisksaverestore:

sudo gedit /etc/init.d/ramdisksaverestore

Вписываем или копируем в него следующий код:

#! /bin/sh
### BEGIN INIT INFO
# Provides: ramdisksaverestore
# Required-Start: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 6
# Short-Description: Google Chrome cach on RAM Disk save and restore
### END INIT INFO
filename=»/home/.brcache/homedir.txt»
case «$1» in
start)
if ! [ -f «$» ]
then
cp -rp $/.cache/google-chrome/Default /home/.brcache/chromediskcache
if [ -h $/.config/google-chrome ]
then
cp -rp $/.config/chromeconfig /home/.brcache
fi
echo $ > «$filename»
fi
;;
restart|reload|force-reload)
echo «Error: argument ‘$1’ not supported» >&2
exit 3
;;
stop)
if [ -f «$» ]
then
homedir=$(head -n 1 «$filename»)
# rsync —delete -av /home/.brcache/chromediskcache/ $/.cache/google-chrome/Default/
rm -rf $/.cache/google-chrome/Default
cp -rpf /home/.brcache/chromediskcache $/.cache/google-chrome/Default
rm -rf /home/.brcache/chromediskcache
if [ -d /home/.brcache/chromeconfig ]
then
rsync —delete -av /home/.brcache/chromeconfig/ $/.config/chromeconfig/
rm -rf /home/.brcache/chromeconfig
fi
rm -f «$filename»
fi
;;
*)
echo «Usage: $0 start|stop» >&2
exit 3
;;
esac

Делаем файл исполняемым:

sudo chmod +x /etc/init.d/ramdisksaverestore

Проверяем работу скрипта при старте. Выполняем в терминале:

Проверяем содержимое /home/.brcache. Если никаких ошибок допущено не было, то на RAM-диске должны появиться папки с кэш-файлами Google Chrome.

Аналогично можно проверить работу скрипта при остановке:

Автозапуск скрипта при входе пользователя в систему

Теперь начинается самое интересное.

Мы оформили наш скрипт как запускаемую при старте и выключении системы службу.

Самым простым способом выполнить скрипт при старте является добавление соответствующей команды в файл rc.local. Или можно воспользоваться стандартным механизмом init.d и добавить с помощью update-rc.d необходимые ярлыки в соответствующие папки rcX.d.

Если пойти таким путем, то ничего работать не будет. Дело в том, что запуск всех служб происходит до входа пользователя в систему. Соответственно, наш скрипт также будет выполнен в тот момент, когда имя пользователя, который будет работать с компьютером, еще не известно, то есть переменная $ не определена. А если нет пользователя, то не понятно чьи файлы нужно скопировать на RAM-диск.

Чтобы этого не произошло добавляем команду выполнения скрипта в файл

6. Выполнение команды запуска восстановления RAM-диска при старте

Открываем на редактирование файл /.profile

В конец файла добавляем строку запуска скрипта:

После копирования папок с кэшем браузера на рамдиск дополнительно создается файл homedir.txt в котором записан путь к домашнему каталогу текущего пользователя. Зачем это надо вскоре будет понятно.

Этот же файл используется как индикатор того, что рамдиск уже восстановлен и повторного копирования файлов не требуется.

Автозапуск скрипта при выключении и перезагрузке компьютера

7.1. Выполнение команды сохранения RAM-диска при выходе из сеанса с помощью дисплейного менеджера

Первым делом посмотрите не установлен ли в вашей системе GDM (Gnome Display Manager) или какой-либо другой графический дисплейный менеджер.

В Linux Mint можно найти MDM (Mint Display Manager).

Ищем соответствующие им одноименные папки в /etc. Дальше находим папку /PostSession/ а в ней файл Default. Открываем файл на редактирование:

sudo gedit /etc/mdm/PostSession/Default

и добавляем перед строкой “exit 0” команду запуска нашего скрипта с параметром “stop”:

Если у Вас LightDM, то команду нужно добавить в конец секции [SeatDefaults] в файле lightdm.conf.

sudo gedit /etc/lightdm/lightdm.conf

При этом выглядеть она должна так:

session-cleanup-script = /etc/init.d/ramdisksaverestore stop

Имейте в виду, что в LightDM этот способ заработает только после перезагрузки компьютера.

Это решение можно признать оптимальным. Оно даже позволяет обрабатывать ситуацию смены пользователя без перезагрузки компьютера.

Именно для этого добавлены команды удаления данных из папки рамдиска после их сохранения. После регистрации нового пользователя в системе скрипт видит чистый рамдиск и загружает нужные данные.

7.2. Запуск скрипта сохранения RAM-диска при выключении компьютера с использованием init.d

Если дисплейный менеджер не установлен, то для запуска скрипта перед выключением и перезагрузкой компьютера придется воспользоваться классическим механизмом. При этом возникает та же проблема, что и при старте — к тому моменту, когда начинают выполнятся скрипты из init.d, пользователя в системе уже нет и переменная $ вновь не определена.

В этом случае для определения пути по которому необходимо сохранить содержимое рамдиска, а это домашний каталог текущего пользователя, используется содержимое специально созданного при входе файла homedir.txt.

Определяем запуск скрипта на соответствующих уровнях:

• 0 — остановка системы;
• 6 — перезагрузка системы.

sudo update-rc.d ramdisksaverestore stop 5 0 6 .

Еще раз перезагружаем компьютер и убеждаемся в том, что все исправно работает.

Замечание по выбору алгоритма сохранения содержимого RAM-диска

Файлы кэша браузера сохраняются при выходе в их исходном местоположении, то есть в папке

Это очень удобно тогда, когда по какой-либо причине нужно вернуться к исходному состоянию. Для этого достаточно лишь удалить или переместить в другое место файл политик chrome-cache.json и отключить автозапуск скрипта ramdisksaverestore чтобы напрасно не расходовать оперативную память.

Казалось бы, оптимальным вариантом актуализации содержимого папок кэша на жестком диске является команда rsysnc. При ее использовании объем перезаписываемых данных оказывается наименьшим.

Но… совершенно неожиданно Google Chrome категорически отказался воспринимать обработанные с помощью rsysnc папки как свои. При первом запуске после восстановления рамдиска Chrome просто удалял ранее созданные папки и создавал их вновь. Все их содержимое при этом, естественно, терялось.

Причем происходило такое не всякий раз, но достаточно регулярно. Причину такого поведения определить не удалось. Пришлось заменить rsync на банальное копирование cp. Объем записываемых данных увеличился, но зато Google Chrome папки удалять прекратил.

На всякий случай я не убрал строку с командой rsync, а лишь закомментировал ее. Возможно, что это особенность моей конкретной системы или версии браузера. Попробуйте, может быть у Вас Google Chrome захочет работать с rsync без приключений.

Перемещение на RAM-диск конфигурационных файлов браузера

Я намеренно разделил описания переноса дискового кэша и пользовательской конфигурации браузера.

Во-первых, перемещение файлов конфигурации в Google Chrome не предусмотрено – нет ни соответствующих этому ключей, ни политик. Так что придется использовать символьные ссылки.

Во-вторых, конфигурационные файлы занимают больше 200 Мб и если компьютер имеет не более 1 Гб оперативной памяти, то, возможно, лучше оставить их на диске. В противном случае эффект может оказаться прямо противоположным. При нехватке оперативной памяти система начнет использовать SWAP и вместо ускорения браузера мы получим торможение всей системы.

Если основной задачей является продление срока службы SSD, то отодвинуть начало перемещения блоков памяти на SWAP-раздел (или файл) на диске в этом случае можно с помощью zRam.

Конфигурация пользователя у Google Chrome находится в папке

/.config/google-chrome, или в папке

/.config/chromium у браузера Chromium.

Переместить ее на RAM-диск не представляет никакого труда. Тем более, что созданный ранее скрипт ramdisksaverestore уже содержит соответствующие команды. Эти команды выполняются только в том случае, когда папка с конфигурацией пользователя перенесена на RAM-диск.

Переименуем папку google-chrome:

Скопируем переименованную папку на RAM-диск:

Создадим символьную ссылку на скопированную папку:

ln -s /home/.brcache/chromeconfig

Теперь можно запустить браузер и убедиться, что он отлично работает.

Для синхронизации файлов конфигурации на RAM-диске и жестком диске при выходе используется rsync. «Неудовольствия» со стороны Google Chrome в этом случае пока замечено не было.

Что нужно сделать в сеансах остальных пользователей

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

Если на RAM-диск переносится только дисковый кэш браузера, то для всех остальных пользователей компьютера достаточно добавить команду запуска скрипта ramdisksaverestore при старте в

В том случае, когда на RAM-диск перемещаются и пользовательские конфигурации, то в сеансах всех пользователей нужно выполнить три команды, описанные в предыдущем параграфе.

Желаю всем отличного интернет-серфинга с любимым браузером, который после выполнения описанных в статье мероприятий станет заметно быстрее и перестанет «убивать» SSD.

Не забудьте дополнительно переместить в tmpfs временные системные файлы, как это было описано здесь.

Источник