Перенос Google Chrome на RAM-диск в Linux

  • Tutorial
Опишу простой способ переноса кеша, настроек и прочих локальных данных Google Chrome на RAM-диск в Linux. Это ускорит скорость работы браузера и исключит насилие над диском (что особенно критично, если у вас SSD).

Статья не содержит ничего интересного для более-менее продвинутых пользователей Unix-like систем. Совсем ничего.



Linux предоставляет нам все средства для того, чтобы наша задача решалась за 10 минут, в лоб и правильно, как бы мы ни старались сделать всё через жопу. Я буду намеренно писать подробно.

1. Создаём RAM-диск



Никаких сторонних приложений не требуется. Linux поддерживает RAM-диски на уровне ядра. Эта штука называется tmpfs. Всё, что нам нужно, так это смонтировать tmpfs в любой удобное нам место. Создадим каталог .chrome/ramdisk в домашней директории и добавим следующую строку в /etc/fstab:

tmpfs /home/сс/.chrome/ramdisk tmpfs noatime,nodiratime,nodev,nosuid,uid=1000,gid=100,mode=0700,size=300M 0 0


заменив сс на имя вашего пользователя, uid и gid — на его идентификаторы (узнать их можно командой id), size — на желаемый размер диска. Если у вас оперативку хоть ложкой ешь, то размер можно взять и побольше. Особенностью tmpfs является то, что указанный размер не будет резервироваться в памяти — память не будет тратиться вообще, пока вы фактически не напихаете в RAM-диск данные. Командой df -h вы всегда можете посмотреть, насколько заполнен этот и другие смонтированные диски.

2. Отправляем локальные данные Хрома в наш RAM-диск



Никаких махинаций с настройками и ключами хрома делать не надо. Все юниксовые файловые системы поддерживают символические ссылки. Поэтому тупо перенаправим ~/.config/google-chrome и ~/.cache/google-chrome в наш диск:

cd ~/.chrome/ramdisk
mkdir cache config
ln -s ~/.config/google-chrome config
ln -s ~/.cache/google-chrome cache


3. Ограничиваем размеры кеша в Google Chrome



Мы опять не будет играться с ключами, а используем политики. Для этого создадим файл /etc/opt/chrome/policies/managed/cache-size.json с таким содержанием:

{
    "DiskCacheSize":    40000000,
    "MediaCacheSize":   30000000
}

где циферки — это размеры общего кеша и медиа-кеша соответственно. Можете менять на свой вкус, но следя, чтобы размер ~/.config/google-chrome + указанные размеры заполняли диск процентов на 80. Ибо размер первого каталога никак не регулируется, а DiskCacheSize и MediaCacheSize вовсе не являются жёсткими границами: Хром может их немного превысить, если будет очень нужно. У меня на момент написания статьи RAM-диск используется на 83%:

$ df -h ~/.chrome/ramdisk
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           300M  249M   52M  83% /home/cc/.chrome/ramdisk


4. Поддерживаем состояние RAM-диска между перезагрузками компьютера



Как только вы нажали кнопочку «power off», все данные из оперативки улетели в рай для битов. Мы же не хотим начинать каждый день с нового листа — нам нужно сохранять RAM-диск на жёский или твердотельный диск при выходе из системы и восстанавливать его при загрузке. Есть примерно миллион способов это сделать. Если у вас systemd, то можно создать сервис /etc/systemd/system/chrome-ramdisk.service:

[Unit]
Description=Keep Chrome's RAM disk between power-offs

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/home/сс/bin/chrome-ramdisk restore
ExecStop=/home/сс/bin/chrome-ramdisk save

[Install]
WantedBy=multi-user.target

где ~/bin/chrome-ramdisk — простенький скрипт, который сохраняет RAM-диск в tar-архив или, наоборот, извлекает этот архив в пустой RAM-диск:
#!/bin/bash

shopt -s dotglob
cd /home/cc/.chrome

if [[ "$1" == "save" ]]; then
        rm ramdisk.tar
        tar cpf ramdisk.tar ramdisk/*
elif [[ "$1" == "restore" ]]; then
        rm -rf ramdisk/*
        tar xf ramdisk.tar
fi

Сервис включается командой
$ sudo systemctl enable chrome-ramdisk.service


Если вас научили ненавидеть Леннарта П., то аналогичный эффект можно получить и в старом добром init-scripts, используя rc.local, rc.local_shutdown или тому подобные скрипты.



P. S. Google Chrome и Chromium — не совсем одно и то же. В частности, у них разные пути к каталогам настроек, кеша и политик. Статья написана для Google Chrome. Минута гугления обеспечит вам нужными путями для хромиума.

Усё.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 52
  • +4
    Мои идеи:
    1. Используем ZRAM. Кэш и текстовые данные жмутся очень хорошо, иногда и в 10 раз. Как итог наш кэш на 200 мегов может растягиваться до 2гигов.
    2. Кэшируем библиотеки и сам хром при запуске. Тут немного спорно. т.к. в системе уже есть средства для этого. При помощи aufs (не уверен) можно заставить читать данные из RAM, а в случае обновления хрома запись будет на SSD. Тоже самое с локальными данными, все профили будут висеть в оперативке и т.д., но обновление профилей будет идти на диск.
    3. Не сохранять ZRAM диск при выключении. Зачем? Там только кэш. Причем как кэш библиотек хрома, кэш профилей и просто кэш браузера. Обычно проще его очистить. Вот это экономия SSD.
    • 0
      Кешировать библиотеки и сам Хром не нужно, ибо, во-первых, этим занимается ОС, а во-вторых, если SSD, то на нём и так всё быстро. К тому же ресурс SSD вырабатывает только перезапись ячеек. Я читай сколько хошь.

      Веб-хеш нужно сохранять, ибо иначе зачем он вообще нужен? Хеш нужен для того, чтобы не качать по сети то, что уже скачано недавно и с тех пор не изменилось. Поэтому выгодно иметь большой кеш и не обнулять его каждый раз.
      • 0
        Ну в любом случае тогда ZRAM лучше оставить и записывать на диск дамп со сжатием тоже. Как итог будет и кэш раз в 10 больше и при записи будет меньше ячеек трогать.
      • –1
        Мы же хотим увеличить скорость работы, так? А ZRAM — это насилие над процессором.
        • +1
          Я в zram распологал своп и растягивал таким методом 2 гига оперативы до 5 на нетбуке с атомом. Так вот как итог получаем стабильно работающую систему. Zram как правило потребляет не более 1-10% процессора при максимальком сжатии налету. В кэше странички маленькие. Лучше иметь кэш на 2 гига и 1% нагрузки одного ядра 4х ядерного i5 или i7, чем иметь 200 мегов и постоянно подгружать еще данные.
          К слову у многих стоит шифрование на жестких дисках и SSD и сжатие тоже прямо в ФС, но никто об этом не кричит, а ведь шифрование намного больше требует в плане нагрузки. Ну и на последок — ZRAM использует прозначное сжатие на уровне ядра, разницы в производительности почти нет. Только разве что если уж ворочать гигов эдак 10 в оперативе в сжатом виде, и то сомневаюсь, что будет заметно. Да и это в любом случае будет быстрее чем из ssd или жесткого диска тянуть.
      • +16
        Но зачем, если есть wiki.archlinux.org/index.php/profile-sync-daemon?
      • +1
        Делал аналогичное только для кэша, конфиги не переносил в tmpfs.

        Директория ~/.cache обычно содержит именно кэш и этот путь используют многие приложения (Firefox, Chromium):
        $ ls -l ~/.cache
        lrwxrwxrwx 1 jightuse jightuse 11 Sep 10 21:57 /home/jightuse/.cache -> /tmp/cache/
        

        При загрузке системы создаётся директория /tmp/cache, если ещё не существует.
        Перезагружается компьютер довольно редко, поэтому об утрате кэша особенно не переживаю. У параноиков он при закрытии браузера вычищается.
        • +1
          У хрома ~/.config/google-chome — не менее (а может и более) жестокое место, чем ~/.cache/google-chome. В «конфиге» не только настройки, но и всякий специфический кеш (и его много!), favicons (!) базы данных, история (!), журналы… И пишется он постоянно. У меня сейчас там 160 МБ такого контента. Держать всё это на HDD/SDD не комильфо.
        • +3
          Согласно XDG Base Directory Specification каталог кэша $XDG_CACHE_HOME по умолчанию ~/.cache. Все нормальные браузеры (Chromium и Firefox хранят там кэш по умолчанию, а для Opera надо указать в конфиге) следуют ей.
          /home/username/.cache делаем tmpfs. Сохранение состояния приносит мало пользы тк в нормальной системе перезагрузка происходит очень редко ведь есть suspend.
            • +1
              sqlite надо переодически чистить. А favicons загружаются при первом запуске когда кэш холодный (прочитать с диска придётся в любом случае). Потом оно кэшируется в памяти и не мешает. Нагрузка с favicon и истории минимальна (Вы же не сотнями их открываете? Максимум 1-2 в минуту).

              > systemd и initscripts (да и вообще любой init) работает не из под «обычного» пользователя и, следовательно, в $HOME будет совсем не то.
              Кстати у systemd есть user-session который, к сожалению, скорее мёртв чем жив.
          • –3
            Добавлю свои две копейки — $HOME вместо /home/cc будет более универсально. Ну и вообще, есть ещё $UID и прочие переменные, которые будут подставляться для конкретного юзера.
            И если взять ramfs вместо tmpfs, то можно будет не заморачиваться по поводу размера диска.
            • +1
              systemd и initscripts (да и вообще любой init) работает не из под «обычного» пользователя и, следовательно, в $HOME будет совсем не то.
              • –2
                Если мы говорим про «однопользовательскую» систему, то сделать su в юзера не проблема. Да и для ubuntu-based upstart позволяет сделать chuid для конкретного юзера. По поводу переменной с именем пользователя врать не буду — не проверял.
              • 0
                Если взять ramfs вместо tmpfs, можно начать ловить OOM в самых неожиданных местах, когда место в памяти таки кончится. tmpfs — тот же ramfs, только умеющий уходить в своп, когда не нужен.
              • +24
                у меня SSD и меня не парит то чем он занят, он делает это быстро. Это к тому что хватит экономить на спичках.
                • –8
                  это начнет парить когда диск начнет умирать от постоянной записи
                  • +7
                    Сколько раз вы слышали о том, что SSD умер от износа ячеек памяти?) У него ресурс такой, что я бы не стал об этом париться, чего и вам советую.
                    • +7
                      ~в половине топиков, SSD-содержащих. Все слышали, но никто сам не видел. А на деле болеют в основном прошивки и сами хозяева SSD
                      • 0
                        За десять лет у меня наелся до только один стары OCZ с кривой прошивкой, зато кончилось уже два жёстких диска в десктопе и на подходе уже третий.

                        Эти мифы настолько сильно вбиты — что я даже не знаю, конспирологический гений маркетологов и картельный сговор на ум приходят, лол.
                      • 0
                        При использовании на домашнем компе этот момент наступит лет через 10-20, даже не через 5. Вы серьёзно считаете, что это может быть проблемой?

                        К тому же для корпоративного сектора, т.е. для высоких нагрузок, есть диски с большей резервной областью из коробки, к примеру Intel на 200ГБ, гарантирующий запись 2 ТБ каждый день в течении 5 лет без снижения показателей производительности.
                        • 0
                          Пользуюсь хромом на ssd два месяца примерно по 5-6 часов в день, сам хром открыт примерно по 20 часов в день. По показаниям smartctl за весь этот период на диск было записано 957ГБ данных, причем 500ГБ из них — это перенос данных со старого диска на новый. По заявлению производителя ресурса диска хватит на 1500000ГБ.

                          Экономия и правда на спичках.
                    • +8
                      что особенно критично, если у вас SSD

                      Видимо у вас очень старый SSD, так как новые можно смело использовать без лишней экономии.
                      • +1
                        Хм, а я не особо заморачивался, просто добавил в fstab:

                        tmpfs /home/<USER>/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0

                        + к этому юзаю Profile-sync-daemon
                        • 0
                          Ну я фактически это и сделал, только расписал подробнее и вместо Profile-sync-daemon использовал самодельный костыль.
                        • 0
                          Делал такое, только для кэша файрфокс, и синхронизация RAM -> HDD была с помощью atomic-rsync, по крону, а так же при выключении компа. Так же в файловой системе были файлы-флаги, чтобы понять что рам диск уже инициализирован и нечаянно не синхронизировать пустоту на винт.
                          • 0
                            Я не делал синхронизацию по таймеру, потому что у меня десктоп и выключается на ночь каждый день. Если же предполагается долгий аптайм, то, согласен, такое не совсем подходит.
                          • +6
                            Купил года полтора назад SSD, не парюсь, работает как часы, ничего никуда не переносил, swap на SSD, файл подкачки на SSD, сорцы и git на SSD, да вообще все программы и все что для них нужно на SSD. Доволен как слон. Медиа файлы да, на HDD, тут просто ГБ дешевле. Не разделяю я этой паники по поводу ресурса записи, по мне так он огромен, каждую ячейку можно перезаписывать десятки раз в сутки на протяжении всего года, каждый день. Другое дело если вы просто хотите еще более увеличить производительность, тут конечно tmpfs хороша.
                            • 0
                              Не разделяю я этой паники по поводу ресурса записи, по мне так он огромен, каждую ячейку можно перезаписывать десятки раз в сутки на протяжении всего года, каждый день.

                              Ресурс ячеки — порядка 10 000 циклов перезаписи. Если ячейка пишется 10 раз в сутки, то хватит её примерно на 3 года. Я просто воспользовался калькулятором.

                              Есть SSD с ресурсом до 100 000 циклов, но они дорогие и на рынке представлены в меньшинстве.
                              • 0
                                Смотря какого типа ячейка и по какому критерию определять ресурс оный…
                                … скажем так даже в древних микроконтроллерах, где в инструкции речь шла о 2000-5000 перезаписях, реально счёт идёт на сотни тысяч до возникновения ошибки и несколько лямов до полной смерти! Там правда 1 бит на ячейку, но увеличение разрядности влечёт за собой не только снижение надёжности чтения\записи, но и более щадящую запись, за которой следит контроллер… Ну и рассеивание данных по адресному пространству, делается не только для равномерного изнашивания, но и для снижения частоты перезаписи одной ячейки, что в разы повышает живучесть SSD больших объёмов. Ведь когда мы считаем циклы перезаписи, мы делаем это с максимально возможной скоростью, а если вставлять паузу, то время эксперимента сильно возрастает, и не только из-за паузы, а ещё и из-за увеличения числа циклов…

                                Вообще потенциал увеличения жизни ячеек очень большой, и не весь он ещё используется контроллерами, можно вообще сделать долгоживущее хранилище, специально для увеличения количества перезаписей заплатив за это размером и\или скоростью…
                                • 0
                                  Используем SSD в качестве кэширующих в ZFS-пулах на серверах с видеостримингом (нагрузка на сеть — полный гигабит) — больше 1-2 лет стоят — ничего с ними не делается… нагрузка очень приличная.
                              • +9
                                Но зачем, зачем засовывать дисковый кеш в ОЗУ, когда все браузеры умеют кеш в оперативной памяти?
                                Если хотите не иметь кеша на жёстком диске — отключите его, и увеличьте кеш в ОЗУ.

                                Если говорить о хранении настроек — ваше решение ненадёжно. При незапланированной перезагрузке вы потеряете все настройки за последнюю сессию, или, в крайнем/угловом случае, за всё время. Некоторые решения из комментариев этим не страдают.

                                Опять же, в ОС есть кеш. Кеш записи и чтения. Прогрейте кеш чтения с диска до запуска Chrome — например, скопировав его бинарние, зависимые библиотеки и все файлы из ~/.config/google-chrome в /dev/null, и Chrome запустится моментально из ОЗУ.

                                Аналогично с кешем записи. Если у вас достаточно памяти — разрешите отложенную запись на диск, и дайте ОС делать своё дело. Из минусов — проблемы при незапланированных перезагрузках, но вас это не так заботит.

                                tl;dr: Не мешайте ОС делать вам хорошо. И отключите дисковый кеш браузера, если он вас смущает.
                                • 0
                                  Не знаю на счёт SSD, но на HDD, firefox, например, тупит. Он пишет/читает sqlite базу по поводу и без, случаются лаги при сёрфинге, при скролле (если другие процессы обращаются к диску). Довольно сильно раздражает. Лечится сразу и полностью переносом профиля в RAM. Не лечится приоритетами ввода вывода.

                                  Проблема у меня воспроизводится и с WD Blue и с WD RE4 (т.е. прямо скажем не медленный hdd). При 16 Gb памяти и свободном свопе. На разных линуксах, с незапамятных времён. С другими программами проблем таких нет, кроме, пожалуй, RubyMine.
                                  • 0
                                    Занятно, а у меня на Windows не тупит, да и частых обращений к скулайту от него нет, может это баг Linux версии? Баг-трекер на предмет такого бага не проверяли?
                                    • 0
                                      Windows — это другая история. На linux вообще плохо дело обстоит с приоритетами ввода вывода для десктопа.
                                      Багтрекер — не нашёл, но и долго не искал.
                                    • +1
                                      Дело ещё в том, что стандартно Линукс не слишком агрессивно кеширует записи на диск. Он в первую очередь старается не повредить данные в случае возможной аварийной перезагрузки. Если хочется сурового кеширования записи — это делается mount-флагами и выбором ФС (говорят, btrfs довольно круто это умеет).

                                      И, да, в Firefox есть (был?) баг, из-за которого его sqlite-движок постоянно делал sync, заставляя полностью сливать кеши на диск. При использовании RAM-диска, фактически, мы обманываем его, утверждая, что по команде sync данные записаны на диск — таким образом обходя этот баг. Возможно, сейчас уже всё починили.
                                      • 0
                                        Кстати, в Arch Wiki есть хорошая статья про SSD. Там про рекомендуемые ФС и флаги монтирования тоже есть.
                                    • 0
                                      Опять же, в ОС есть кеш. Кеш записи и чтения.

                                      Есть одна разница: из-за ограниченности RAM кеш ОС постоянно обновляется — новый кеш перезаписывает старый. В случае же RAM-диска данные, которые туда запихнуты, будут всегда в оперативной памяти (своп не считаем). После возврата к браузеру после длительной работ с другими задачаи, ОС придётся перечитывать диск снова при обращении браузера к кешу и настройкам.

                                      Не мешайте ОС делать вам хорошо.

                                      После переноса кеша и конфига хрома в tmpfs Хром стал шустрее. Это заметно. Значит, ОС делает не совсем хорошо.
                                      • 0
                                        Это сколько оперативной памяти нужно, чтобы кеш файловой системы по кругу без конца вытирался? О_о

                                        Два гига или четыре?
                                    • –3
                                      ЧЯДНТ?
                                      dreamerchant@dreamerchant-1215b:~/.chrome/ramdisk$ df -h ~/.chrome/ramdisk
                                      Файловая система Размер Использовано Дост Использовано% Cмонтировано в
                                      tmpfs 400M 0 400M 0% /home/dreamerchant/.chrome/ramdisk

                                      • 0
                                        Разобрался, нужно было скопировать уже существующие файлы кэша и профиля в tmpfs, удалить каталоги и пересоздать ссылки.
                                      • +1
                                        > Если вас научили ненавидеть Леннарта П., то аналогичный эффект можно получить и в старом добром init-scripts, используя rc.local, rc.local_shutdown или тому подобные скрипты.

                                        А что делать, если меня никто не учил ненавидеть Леннарта П., но я на собственном опыте убедился, что ничего хорошего он ещё не сделал, и у systemd, судя по всему, будут те же проблемы с разработкой, что и у предыдущих его софтин? И, в отличие от предыдущих софтин, в этой проблемы ещё и с проектированием, и наглым враньём своим собственным пользователям?

                                        Обсудить не смогу из-за кармы.
                                        • +1
                                          Обсудить не смогу из-за кармы.

                                          И не надо. Уже всех достало, что при каждом упоминании «systemd» кто-нибудь опять начинает бородатый холивар.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • +5
                                            На android еще много любителей «оптимизаций».
                                            Например ставят диспетчеры задач и массово убивают все приложения в памяти, периодически.
                                            Не надо этого делать, пожалуйста!
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • 0
                                                Выше писал — на андроиде можно своп в рамдиск засунуть. Как итог увеличить в 2 раза оперативку. Но безопасно это где то 25%-50% от общей памяти. Т.е. если у вас 1 гиг. то еще 512 мегов можно создать zram swap.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              У хрома и у хромиума есть параметр --disk-cache-dir

                                              Да. Ещё есть ключ для указания размера кеша. Но в случае с ключами придётся делать переходой скрипт, а-ля
                                              #!/bin/sh
                                              exec google-chrome <keys> "$@"
                                              

                                              либо править /opt/google/chrome/google-chrome (это баш-скрипт). Последнее не комильфо, ибо после обновления хрома придётся делать всё заново. Поэтому я предпочтел вместо --disk-cache-dir использовать символические ссылки, которые поддержиавет любая нормальная файловая система, а вместо --disk-cache-size использовать политики в /etc/opt/chrome (что более правильно, ибо /etc это как раз то место, где следует хранить системные настройки).

                                              тем более про быстро-умирающие SSD диски и кол-во циклов записи с последним поколением дисков думать уже становится смешно в таких масштабах как тема топика.

                                              Возможно. У меня HDD и темой про износ SSD я глубоко не занимался. Имеются лишь общие стереотипы, что много перезаписывать нельзя. Главный же посыл переноса хрома в оперативку — ускорение его работы. Стоит попробовать, чтобы почувствовать разницу.
                                              • 0
                                                Не, смело выкидывай эти стереотипы.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.