Pull to refresh

Comments 52

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

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

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

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

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

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

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

Экономия и правда на спичках.
Хм, а я не особо заморачивался, просто добавил в fstab:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И не надо. Уже всех достало, что при каждом упоминании «systemd» кто-нибудь опять начинает бородатый холивар.
UFO just landed and posted this here
На android еще много любителей «оптимизаций».
Например ставят диспетчеры задач и массово убивают все приложения в памяти, периодически.
Не надо этого делать, пожалуйста!
UFO just landed and posted this here
Выше писал — на андроиде можно своп в рамдиск засунуть. Как итог увеличить в 2 раза оперативку. Но безопасно это где то 25%-50% от общей памяти. Т.е. если у вас 1 гиг. то еще 512 мегов можно создать zram swap.
UFO just landed and posted this here
У хрома и у хромиума есть параметр --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 я глубоко не занимался. Имеются лишь общие стереотипы, что много перезаписывать нельзя. Главный же посыл переноса хрома в оперативку — ускорение его работы. Стоит попробовать, чтобы почувствовать разницу.
Не, смело выкидывай эти стереотипы.
Sign up to leave a comment.

Articles