Comments 52
Мои идеи:
1. Используем ZRAM. Кэш и текстовые данные жмутся очень хорошо, иногда и в 10 раз. Как итог наш кэш на 200 мегов может растягиваться до 2гигов.
2. Кэшируем библиотеки и сам хром при запуске. Тут немного спорно. т.к. в системе уже есть средства для этого. При помощи aufs (не уверен) можно заставить читать данные из RAM, а в случае обновления хрома запись будет на SSD. Тоже самое с локальными данными, все профили будут висеть в оперативке и т.д., но обновление профилей будет идти на диск.
3. Не сохранять ZRAM диск при выключении. Зачем? Там только кэш. Причем как кэш библиотек хрома, кэш профилей и просто кэш браузера. Обычно проще его очистить. Вот это экономия SSD.
1. Используем ZRAM. Кэш и текстовые данные жмутся очень хорошо, иногда и в 10 раз. Как итог наш кэш на 200 мегов может растягиваться до 2гигов.
2. Кэшируем библиотеки и сам хром при запуске. Тут немного спорно. т.к. в системе уже есть средства для этого. При помощи aufs (не уверен) можно заставить читать данные из RAM, а в случае обновления хрома запись будет на SSD. Тоже самое с локальными данными, все профили будут висеть в оперативке и т.д., но обновление профилей будет идти на диск.
3. Не сохранять ZRAM диск при выключении. Зачем? Там только кэш. Причем как кэш библиотек хрома, кэш профилей и просто кэш браузера. Обычно проще его очистить. Вот это экономия SSD.
Кешировать библиотеки и сам Хром не нужно, ибо, во-первых, этим занимается ОС, а во-вторых, если SSD, то на нём и так всё быстро. К тому же ресурс SSD вырабатывает только перезапись ячеек. Я читай сколько хошь.
Веб-хеш нужно сохранять, ибо иначе зачем он вообще нужен? Хеш нужен для того, чтобы не качать по сети то, что уже скачано недавно и с тех пор не изменилось. Поэтому выгодно иметь большой кеш и не обнулять его каждый раз.
Веб-хеш нужно сохранять, ибо иначе зачем он вообще нужен? Хеш нужен для того, чтобы не качать по сети то, что уже скачано недавно и с тех пор не изменилось. Поэтому выгодно иметь большой кеш и не обнулять его каждый раз.
Мы же хотим увеличить скорость работы, так? А ZRAM — это насилие над процессором.
Я в zram распологал своп и растягивал таким методом 2 гига оперативы до 5 на нетбуке с атомом. Так вот как итог получаем стабильно работающую систему. Zram как правило потребляет не более 1-10% процессора при максимальком сжатии налету. В кэше странички маленькие. Лучше иметь кэш на 2 гига и 1% нагрузки одного ядра 4х ядерного i5 или i7, чем иметь 200 мегов и постоянно подгружать еще данные.
К слову у многих стоит шифрование на жестких дисках и SSD и сжатие тоже прямо в ФС, но никто об этом не кричит, а ведь шифрование намного больше требует в плане нагрузки. Ну и на последок — ZRAM использует прозначное сжатие на уровне ядра, разницы в производительности почти нет. Только разве что если уж ворочать гигов эдак 10 в оперативе в сжатом виде, и то сомневаюсь, что будет заметно. Да и это в любом случае будет быстрее чем из ssd или жесткого диска тянуть.
К слову у многих стоит шифрование на жестких дисках и SSD и сжатие тоже прямо в ФС, но никто об этом не кричит, а ведь шифрование намного больше требует в плане нагрузки. Ну и на последок — ZRAM использует прозначное сжатие на уровне ядра, разницы в производительности почти нет. Только разве что если уж ворочать гигов эдак 10 в оперативе в сжатом виде, и то сомневаюсь, что будет заметно. Да и это в любом случае будет быстрее чем из ssd или жесткого диска тянуть.
Но зачем, если есть wiki.archlinux.org/index.php/profile-sync-daemon?
Делал аналогичное только для кэша, конфиги не переносил в tmpfs.
Директория ~/.cache обычно содержит именно кэш и этот путь используют многие приложения (Firefox, Chromium):
При загрузке системы создаётся директория /tmp/cache, если ещё не существует.
Перезагружается компьютер довольно редко, поэтому об утрате кэша особенно не переживаю. У параноиков он при закрытии браузера вычищается.
Директория ~/.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.
/home/username/.cache делаем tmpfs. Сохранение состояния приносит мало пользы тк в нормальной системе перезагрузка происходит очень редко ведь есть suspend.
sqlite надо переодически чистить. А favicons загружаются при первом запуске когда кэш холодный (прочитать с диска придётся в любом случае). Потом оно кэшируется в памяти и не мешает. Нагрузка с favicon и истории минимальна (Вы же не сотнями их открываете? Максимум 1-2 в минуту).
> systemd и initscripts (да и вообще любой init) работает не из под «обычного» пользователя и, следовательно, в $HOME будет совсем не то.
Кстати у systemd есть user-session который, к сожалению, скорее мёртв чем жив.
> systemd и initscripts (да и вообще любой init) работает не из под «обычного» пользователя и, следовательно, в $HOME будет совсем не то.
Кстати у systemd есть user-session который, к сожалению, скорее мёртв чем жив.
Добавлю свои две копейки — $HOME вместо /home/cc будет более универсально. Ну и вообще, есть ещё $UID и прочие переменные, которые будут подставляться для конкретного юзера.
И если взять ramfs вместо tmpfs, то можно будет не заморачиваться по поводу размера диска.
И если взять ramfs вместо tmpfs, то можно будет не заморачиваться по поводу размера диска.
systemd и initscripts (да и вообще любой init) работает не из под «обычного» пользователя и, следовательно, в $HOME будет совсем не то.
Если взять ramfs вместо tmpfs, можно начать ловить OOM в самых неожиданных местах, когда место в памяти таки кончится. tmpfs — тот же ramfs, только умеющий уходить в своп, когда не нужен.
у меня SSD и меня не парит то чем он занят, он делает это быстро. Это к тому что хватит экономить на спичках.
это начнет парить когда диск начнет умирать от постоянной записи
Сколько раз вы слышали о том, что SSD умер от износа ячеек памяти?) У него ресурс такой, что я бы не стал об этом париться, чего и вам советую.
~в половине топиков, SSD-содержащих. Все слышали, но никто сам не видел. А на деле болеют в основном прошивки и сами хозяева SSD
За десять лет у меня наелся до только один стары OCZ с кривой прошивкой, зато кончилось уже два жёстких диска в десктопе и на подходе уже третий.
Эти мифы настолько сильно вбиты — что я даже не знаю, конспирологический гений маркетологов и картельный сговор на ум приходят, лол.
Эти мифы настолько сильно вбиты — что я даже не знаю, конспирологический гений маркетологов и картельный сговор на ум приходят, лол.
При использовании на домашнем компе этот момент наступит лет через 10-20, даже не через 5. Вы серьёзно считаете, что это может быть проблемой?
К тому же для корпоративного сектора, т.е. для высоких нагрузок, есть диски с большей резервной областью из коробки, к примеру Intel на 200ГБ, гарантирующий запись 2 ТБ каждый день в течении 5 лет без снижения показателей производительности.
К тому же для корпоративного сектора, т.е. для высоких нагрузок, есть диски с большей резервной областью из коробки, к примеру Intel на 200ГБ, гарантирующий запись 2 ТБ каждый день в течении 5 лет без снижения показателей производительности.
Пользуюсь хромом на ssd два месяца примерно по 5-6 часов в день, сам хром открыт примерно по 20 часов в день. По показаниям smartctl за весь этот период на диск было записано 957ГБ данных, причем 500ГБ из них — это перенос данных со старого диска на новый. По заявлению производителя ресурса диска хватит на 1500000ГБ.
Экономия и правда на спичках.
Экономия и правда на спичках.
что особенно критично, если у вас SSD
Видимо у вас очень старый SSD, так как новые можно смело использовать без лишней экономии.
Хм, а я не особо заморачивался, просто добавил в fstab:
+ к этому юзаю Profile-sync-daemon
tmpfs /home/<USER>/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0+ к этому юзаю 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 больших объёмов. Ведь когда мы считаем циклы перезаписи, мы делаем это с максимально возможной скоростью, а если вставлять паузу, то время эксперимента сильно возрастает, и не только из-за паузы, а ещё и из-за увеличения числа циклов…
Вообще потенциал увеличения жизни ячеек очень большой, и не весь он ещё используется контроллерами, можно вообще сделать долгоживущее хранилище, специально для увеличения количества перезаписей заплатив за это размером и\или скоростью…
… скажем так даже в древних микроконтроллерах, где в инструкции речь шла о 2000-5000 перезаписях, реально счёт идёт на сотни тысяч до возникновения ошибки и несколько лямов до полной смерти! Там правда 1 бит на ячейку, но увеличение разрядности влечёт за собой не только снижение надёжности чтения\записи, но и более щадящую запись, за которой следит контроллер… Ну и рассеивание данных по адресному пространству, делается не только для равномерного изнашивания, но и для снижения частоты перезаписи одной ячейки, что в разы повышает живучесть SSD больших объёмов. Ведь когда мы считаем циклы перезаписи, мы делаем это с максимально возможной скоростью, а если вставлять паузу, то время эксперимента сильно возрастает, и не только из-за паузы, а ещё и из-за увеличения числа циклов…
Вообще потенциал увеличения жизни ячеек очень большой, и не весь он ещё используется контроллерами, можно вообще сделать долгоживущее хранилище, специально для увеличения количества перезаписей заплатив за это размером и\или скоростью…
Используем SSD в качестве кэширующих в ZFS-пулах на серверах с видеостримингом (нагрузка на сеть — полный гигабит) — больше 1-2 лет стоят — ничего с ними не делается… нагрузка очень приличная.
Но зачем, зачем засовывать дисковый кеш в ОЗУ, когда все браузеры умеют кеш в оперативной памяти?
Если хотите не иметь кеша на жёстком диске — отключите его, и увеличьте кеш в ОЗУ.
Если говорить о хранении настроек — ваше решение ненадёжно. При незапланированной перезагрузке вы потеряете все настройки за последнюю сессию, или, в крайнем/угловом случае, за всё время. Некоторые решения из комментариев этим не страдают.
Опять же, в ОС есть кеш. Кеш записи и чтения. Прогрейте кеш чтения с диска до запуска Chrome — например, скопировав его бинарние, зависимые библиотеки и все файлы из
Аналогично с кешем записи. Если у вас достаточно памяти — разрешите отложенную запись на диск, и дайте ОС делать своё дело. Из минусов — проблемы при незапланированных перезагрузках, но вас это не так заботит.
tl;dr: Не мешайте ОС делать вам хорошо. И отключите дисковый кеш браузера, если он вас смущает.
Если хотите не иметь кеша на жёстком диске — отключите его, и увеличьте кеш в ОЗУ.
Если говорить о хранении настроек — ваше решение ненадёжно. При незапланированной перезагрузке вы потеряете все настройки за последнюю сессию, или, в крайнем/угловом случае, за всё время. Некоторые решения из комментариев этим не страдают.
Опять же, в ОС есть кеш. Кеш записи и чтения. Прогрейте кеш чтения с диска до запуска Chrome — например, скопировав его бинарние, зависимые библиотеки и все файлы из
~/.config/google-chrome в /dev/null, и Chrome запустится моментально из ОЗУ.Аналогично с кешем записи. Если у вас достаточно памяти — разрешите отложенную запись на диск, и дайте ОС делать своё дело. Из минусов — проблемы при незапланированных перезагрузках, но вас это не так заботит.
tl;dr: Не мешайте ОС делать вам хорошо. И отключите дисковый кеш браузера, если он вас смущает.
Не знаю на счёт SSD, но на HDD, firefox, например, тупит. Он пишет/читает sqlite базу по поводу и без, случаются лаги при сёрфинге, при скролле (если другие процессы обращаются к диску). Довольно сильно раздражает. Лечится сразу и полностью переносом профиля в RAM. Не лечится приоритетами ввода вывода.
Проблема у меня воспроизводится и с WD Blue и с WD RE4 (т.е. прямо скажем не медленный hdd). При 16 Gb памяти и свободном свопе. На разных линуксах, с незапамятных времён. С другими программами проблем таких нет, кроме, пожалуй, RubyMine.
Проблема у меня воспроизводится и с WD Blue и с WD RE4 (т.е. прямо скажем не медленный hdd). При 16 Gb памяти и свободном свопе. На разных линуксах, с незапамятных времён. С другими программами проблем таких нет, кроме, пожалуй, RubyMine.
Занятно, а у меня на Windows не тупит, да и частых обращений к скулайту от него нет, может это баг Linux версии? Баг-трекер на предмет такого бага не проверяли?
Дело ещё в том, что стандартно Линукс не слишком агрессивно кеширует записи на диск. Он в первую очередь старается не повредить данные в случае возможной аварийной перезагрузки. Если хочется сурового кеширования записи — это делается mount-флагами и выбором ФС (говорят, btrfs довольно круто это умеет).
И, да, в Firefox есть (был?) баг, из-за которого его sqlite-движок постоянно делал sync, заставляя полностью сливать кеши на диск. При использовании RAM-диска, фактически, мы обманываем его, утверждая, что по команде sync данные записаны на диск — таким образом обходя этот баг. Возможно, сейчас уже всё починили.
И, да, в Firefox есть (был?) баг, из-за которого его sqlite-движок постоянно делал sync, заставляя полностью сливать кеши на диск. При использовании RAM-диска, фактически, мы обманываем его, утверждая, что по команде sync данные записаны на диск — таким образом обходя этот баг. Возможно, сейчас уже всё починили.
Опять же, в ОС есть кеш. Кеш записи и чтения.
Есть одна разница: из-за ограниченности RAM кеш ОС постоянно обновляется — новый кеш перезаписывает старый. В случае же RAM-диска данные, которые туда запихнуты, будут всегда в оперативной памяти (своп не считаем). После возврата к браузеру после длительной работ с другими задачаи, ОС придётся перечитывать диск снова при обращении браузера к кешу и настройкам.
Не мешайте ОС делать вам хорошо.
После переноса кеша и конфига хрома в tmpfs Хром стал шустрее. Это заметно. Значит, ОС делает не совсем хорошо.
ЧЯДНТ?
dreamerchant@dreamerchant-1215b:~/.chrome/ramdisk$ df -h ~/.chrome/ramdisk
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
tmpfs 400M 0 400M 0% /home/dreamerchant/.chrome/ramdisk
dreamerchant@dreamerchant-1215b:~/.chrome/ramdisk$ df -h ~/.chrome/ramdisk
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
tmpfs 400M 0 400M 0% /home/dreamerchant/.chrome/ramdisk
> Если вас научили ненавидеть Леннарта П., то аналогичный эффект можно получить и в старом добром init-scripts, используя rc.local, rc.local_shutdown или тому подобные скрипты.
А что делать, если меня никто не учил ненавидеть Леннарта П., но я на собственном опыте убедился, что ничего хорошего он ещё не сделал, и у systemd, судя по всему, будут те же проблемы с разработкой, что и у предыдущих его софтин? И, в отличие от предыдущих софтин, в этой проблемы ещё и с проектированием, и наглым враньём своим собственным пользователям?
Обсудить не смогу из-за кармы.
А что делать, если меня никто не учил ненавидеть Леннарта П., но я на собственном опыте убедился, что ничего хорошего он ещё не сделал, и у systemd, судя по всему, будут те же проблемы с разработкой, что и у предыдущих его софтин? И, в отличие от предыдущих софтин, в этой проблемы ещё и с проектированием, и наглым враньём своим собственным пользователям?
Обсудить не смогу из-за кармы.
UFO just landed and posted this here
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.
Перенос Google Chrome на RAM-диск в Linux