Форум проекта Matuntu

Поддержка => Железо => Тема начата: vita от 15 Августа 2015, 04:27:05

Название: Оптимизация SSD в Matuntu
Отправлено: vita от 15 Августа 2015, 04:27:05
Для более быстрой работы системы вместо HDD можно использовать твердотельные накопители информации SSD небольшого размера (30-64 гб).
Чтобы они дольше прослужили, необходимо провести их оптимизацию.
Для отключения записи времени обращения к файлам и папкам открываем /etc/fstab: sudo pluma /etc/fstabНужно добавить некоторые дополнительные опции: noatime, nodiratime и discard (discard - включает технологию TRIM, которая распределяет нагрузку на SSD, noatime и nodiratime - благодаря этим опциям ОС не будет записывать время последнего обращения к файлам и папкам). Получилось примерно так:
Цитировать
noatime,nodiratime,discard,errors=remount-ro 0 1
noatime,nodiratime,discard,Примечание: discard не вставлять при оптимизации флешек и карточек, если оптимизация применяется к ним.
С целью вынесения временных файлов в память в конец этого же файле надо добавить три строчки:
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
Для отключения работы с файлом подкачки открываем файл sudo pluma /etc/sysctl.confи в конце файла и прописываем следующие параметры:
vm.swappiness = 1
vm.laptop_mode = 5
vm.dirty_writeback_centisecs = 6000
Последние две строки позволяют увеличить время отложенной записи.
Перезагружаем компьютер, оптимизация завершена.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: vita от 15 Августа 2015, 04:27:54
Оптимизирую SSD по приведённой выше схеме, но имеется и другая информация об этом.
После информации об UUID применяемого SSD вписываются строки
relatime,nodiratime,discard,commit=60,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/cache/apt/archives tmpfs defaults 0 0
Также предлагается вынести кэш менеджера пакетов в ОЗУ. Для deb-based дистрибутивов нужно добавить в fstab строку:
tmpfs /var/cache/apt/archives tmpfs defaults 0 0
Для rpm-based дистрибутивов нужно добавить в fstab строку:
tmpfs /var/cache/yum tmpfs defaults 0 0Автор данной рекомендации объясняет свои действия так:
Цитировать
Может возникнуть подозрение, что использование noatime эффективнее, чем relatime. Это не так, relatime обновляет время доступа только при изменении файла или изменении времени доступа. Это нужно для нормальной работы некоторых программ, в том числе почтовых клиентов. Опция discard включает поддержку TRIM. Так же откладываем до раза в минуту запись изменений на накопитель commit=60.
Логи на рабочей станции мало кому нужны после перезагрузки, поэтому целесообразно разместить их, как и временные файлы, в оперативной памяти.
Следующие советы:
Цитировать
Планировщик cfq, используемый по умолчанию в большинстве дистрибутивов, лучше заменить на noop, который наиболее подходит для SSD (cfq изначально заточен под жесткие диски) и для этого в /etc/default/grub заменяем строчку
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
на
GRUB_CMDLINE_LINUX_DEFAULT="elevator=noop"
Далее открываем файл /etc/sysctl.conf и прописываем следующие параметры:
vm.laptop_mode = 5
vm.dirty_writeback_centisecs = 15000
Проверить, какой именно планировщик у вас включён, можно командой: cat /sys/block/sda/queue/schedulerПодставьте для проверки свой диск /dev/sd?

Последние рекомендации касаются отказа от кэширования файлов веббраузерами:
Цитировать
Временные файлы мы перенесли в оперативную память, но браузеры хранят свой кеш в домашнем каталоге пользователя, который у нас на SSD. Нужно либо переместить кеш с SSD, либо выключить его. Я выбрал последний вариант.
Для этого в адресной строке Firefox введём about​ config и изменим параметр:
browser.cache.disk.enable: false
В Chrome немного сложнее, запретить кеш раз и навсегда нельзя, вместо этого нужно каждый раз запускать браузер с параметром --disk-cache-size=0:
google-chrome --disk-cache-size=0
Или создать alias:
alias google-chrome='google-chrome --disk-cache-size=0'
Возможно найденные рекомендации для кого-нибудь окажутся полезными.
Источник (http://forums.pointlinux.org/viewtopic.php?f=30&t=208#p644)
Название: Re: Оптимизация SSD в Matuntu
Отправлено: Jury от 20 Августа 2015, 14:41:23
Добрый день. Попробовал с оптимизацией ssd , но , видимо,что-то не так сделал. Результат -загрузка зависла
 Прождал час ,на большее терпения не хватило, пришлось переустановить систему (благо , что сейчас в поиске оптимума) и установка происходит быстро. Что сделал не так уже не узнать ,буду пробовать еще и отпишусь.До ssd у меня был  гибридный диск ,но в нем  систему отдельно  было не поставить. Купил для эксперементов  KINGSTON_SV300S3 size: 60.0GB - буду с ним работать.

[вложение удалено администратором]
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ivm от 20 Августа 2015, 16:46:06
Если при редактировании /etc/fstab изменить хотя бы один символ в значении UUID, то при загрузке естественно раздел с изменённым UUID не будет найден и система не сможет загрузиться. Я однажды на такое напоролся. Удалил всего лишь один символ. Но это излечимо. В живой сессии запустите Gparted и в нём посмотрите свойства раздела, будет указан его UUID, скопировать в память и подредактировать испорченный fstab. 
Название: Re: Оптимизация SSD в Matuntu
Отправлено: vita от 20 Августа 2015, 18:19:35
Добрый день, Юрий!
У меня есть похожая на Ваш ноутбук техника и проблем с загрузкой Matuntu нет. Проприетарный драйвер видео не устанавливаю. Кроме замены HDD на SSD доустановила память (ОЗУ) по максимуму 2 ГБ. Рекомендую и Вам это сделать пока планки DDR2 не исчезли из продажи.
Попробуйте некоторое время поработать без оптимизации, чтобы сравнить прежнюю производительность ноутбука с HDD.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ivm от 08 Февраля 2016, 16:31:20
В земляной белке (16.04) в процессе оптимизации SSD приходится отказываться от вынесения временных файлов в память, т.к. с этими параметрами система не загружается.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: MindGames от 22 Февраля 2016, 13:29:32
Всем привет!
Очень хорошая статья про SSD, обязательная к ознакомлению (чтобы понимать в целом, все проблемы с такими дисками):
https://wiki.archlinux.org/index.php/Solid_State_Drives_%28%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%29 (https://wiki.archlinux.org/index.php/Solid_State_Drives_%28%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%29)
И вторая статья, описанная более простым языком:
http://vasilisc.com/ssd_ubuntu (http://vasilisc.com/ssd_ubuntu)
Желательно изучить их обе. И все вопросы отпадут.
Лично я, использую файловую систему Btrfs с параметром -o ssd в fstab. Она автоматически определяет твердотельные накопители и оптимизирует работу с ними. На Brtfs у меня установлена система и swap. Ну а Home и opt смонтированы на жесткие диски большого размера, с файловой системой ext4
Название: Re: Оптимизация SSD в Matuntu
Отправлено: vita от 22 Февраля 2016, 14:44:03
На форуме описан способ оптимизации, применяемый около пяти лет с файловой системой ext4 без swap. SSD до сих пор в великолепном состоянии, несмотря на очень активное использование, в частности, тестирование различных дистрибутивов Linux.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ivm от 22 Февраля 2016, 15:16:54
Как только человек написал о фрагментации и дефрагментации EXT 4, так доверия у меня к нему стремительно кончилось, на что бы или на кого бы он ни ссылался. 
Так же и всё остальное, что он написал не стоит ничего, ИМХО.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: MindGames от 10 Апреля 2016, 12:40:35
Как только человек написал о фрагментации и дефрагментации EXT 4, так доверия у меня к нему стремительно кончилось, на что бы или на кого бы он ни ссылался. 
Так же и всё остальное, что он написал не стоит ничего, ИМХО.
То есть, файловая система EXT4 вообще не фрагментируется? Ни как и ни когда? В интернете по этому поводу много разных мнений. А где истина?
Название: Re: Оптимизация SSD в Matuntu
Отправлено: vita от 10 Апреля 2016, 13:14:06
Более пяти лет применяю для установки системы EXT4 и ни разу эта ФС меня не подвела ни падением системы, ни потерей информации.
При этом никогда не было необходимости в дефрагментации.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: alv от 10 Апреля 2016, 13:49:59
То есть, файловая система EXT4 вообще не фрагментируется? Ни как и ни когда?
Фрагментируется. НО: в ситуациях и при совпадении таких условий, которых у десктопного применителя практически не бывает.
При этом никогда не было необходимости в дефрагментации.
Аналогично. Но опять же НО:
Как только человек написал о фрагментации и дефрагментации EXT 4...
А вот Василий (Игорь, Вы ведь про него?) с такими ситуациями имеет дело по долгу службы. Не часто, но без удовольствия :)
Так что у кого что болит... тот про то и пишет.
Например, для меня большой вопрос - шрифты и раскладки.
Для Сергея Голубева, как дальтоника - цветопередача.
Так что мы и пишем о проблемах, для нас важных. С которыми большинство применителей почти никогда не сталкивается.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ffeedd от 08 Марта 2018, 13:31:07
     Уважаемые эксперты!
Может рекомендации внесёте, может в новых темах расскаже об этом:
В свете последних установок MATUNTU (опции монтирования по умалчиванию):

X64 на HDD (внешний USB3):
~$ mount
/dev/sdb2 on / type ext4 (rw,relatime,errors=remount-ro,stripe=8191,data=ordered)
~$ cat /etc/fstab
UUID=********-****-****-****-************ /   ext4    errors=remount-ro 0       1

ручки балуются (добавляем в /etc/fstab):
commit=180
tmpfs /tmp      tmpfs defaults  0   0
tmpfs /var/tmp  tmpfs defaults  0   0
tmpfs /var/log  tmpfs defaults  0   0 Последний 0 в UUID  творчество  от руки.

B64 на флешке USB3:
~$ mount
/dev/sdd1 on / type ext2 (rw,noatime,block_validity,barrier,user_xattr,acl,errors=remount-ro,commit=180)
~$ cat /etc/fstab
UUID=********-****-****-****-************   /   ext2   noatime,commit=180,errors=remount-ro   0   1
tmpfs /tmp      tmpfs defaults  0   0
tmpfs /var/tmp  tmpfs defaults  0   0
tmpfs /var/log  tmpfs defaults  0   0

B64 на SSD:
~$ mount
/dev/sda2 on / type btrfs (rw,noatime,ssd,space_cache,commit=180,subvolid=257,subvol=/@)
~$ cat /etc/fstab
UUID=********-****-****-****-************   /   btrfs   noatime,commit=180,subvol=@   0   0
tmpfs /tmp      tmpfs defaults  0   0
tmpfs /var/tmp  tmpfs defaults  0   0
tmpfs /var/log  tmpfs defaults  0   0

Почему-то на сайте MATUNTU про это нет:
Цитировать
Кстати, если вы беспокоитесь за судьбу своего SSD - данная инструкция вам также будет полезна, ибо не будут тратиться сильно ограниченные ресурсы накопителя.
http://ubuntovod.ru/instructions/profile-sync-daemon.html (http://ubuntovod.ru/instructions/profile-sync-daemon.html)
Цитировать
Увеличиваем скорость работы браузера в ubuntu - перемещаем его полностью в оперативную память с помощью Profile Sync Daemon
http://pashich-ssd.ru/page/uvelichivaem-skorost-raboty-brauzera-v-ubuntu-peremeshhaem-ego-polnostju-v-operativnuju-pamjat-s-pomoshhju-profile-sync-daemon (http://pashich-ssd.ru/page/uvelichivaem-skorost-raboty-brauzera-v-ubuntu-peremeshhaem-ego-polnostju-v-operativnuju-pamjat-s-pomoshhju-profile-sync-daemon)
Цитировать
Profile-sync-daemon - это крошечный псевдодамон, предназначенный для управления профилями браузеров в tmpfs и периодической синхронизации с физическим диском (HDD / SSD). Это достигается за счет инновационного использования rsync для поддержки синхронизации между копией tmpfs и резервным копированием профиля (ов) браузера, связанного с медиа. Кроме того, psd имеет несколько функций восстановления после сбоя.
(Я.перевод)
https://wiki.archlinux.org/index.php/Profile-sync-daemon (https://wiki.archlinux.org/index.php/Profile-sync-daemon)

В B64 всё это есть.
#устанавливаем
~$ sudo apt update
~$ sudo apt install profile-sync-daemon
#запускаем демон
~$ systemctl --user start psd.service
#останавливаем (может и не надо)
~$ systemctl --user stop psd.service
#редактирем файл
~$ xed config/psd/psd.con
Спойлер
#

# $XDG_HOME_CONFIG/psd/psd.conf
#
# For documentation, refer to the psd man page or the wiki page
# https://wiki.archlinux.org/index.php/Profile-sync-daemon

## NOTE the following:
## To protect data from corruption, in the event that you do make an edit while
## psd is active, any changes made will be applied the next time you start psd.

# Uncomment and set to "yes" to use overlayfs instead of a full copy to reduce
# the memory costs and to improve sync/unsync operations. Note that your kernel
# MUST have this module available in order to use this mode
#
#USE_OVERLAYFS="no"
USE_OVERLAYFS="yes"

# List browsers separated by spaces to include in the sync. Useful if you do not
# wish to have all possible browser profiles sync'ed which is the default if
# this variable is left commented.
#
# Possible values:
#  chromium
#  chromium-dev
#  conkeror.mozdev.org
#  epiphany
#  firefox
#  firefox-trunk
#  google-chrome
#  google-chrome-beta
#  google-chrome-unstable
#  heftig-aurora
#  icecat
#  inox
#  luakit
#  midori
#  opera
#  opera-beta
#  opera-developer
#  opera-legacy
#  otter-browser
#  qupzilla
#  qutebrowser
#  palemoon
#  rekonq
#  seamonkey
#  surf
#  vivaldi
#  vivaldi-snapshot
#
#BROWSERS=""
BROWSERS="seamonkey"

# Uncomment and set to "no" to completely disable the crash recovery feature.
#
# The default is to create crash recovery backups if the system is ungracefully
# powered-down due to a kernel panic, hitting the reset switch, battery going
# dead, etc. Some users keep very diligent backups and don't care to have this
# feature enabled.
#BACKUP_LIMIT=5

Добавляем  следующую строку в конец файла /etc/sudoers (меняем меня *** на Вас ???) конечно без sudo не обойтись:
*** ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helperrи снова запускаем демон
~$ systemctl --user start psd.service
#ну и теперь радуемся
~$ psd p
Спойлер
Profile-sync-daemon v6.31 on Ubuntu Bionic Beaver (development branch)

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/fed/.config/psd/.psd.conf:

 browser/psname:  seamonkey/seamonkey
 owner/group id:  ***/1000
 sync target:     /home/fed/.mozilla/seamonkey/s3guo164.default
 tmpfs dir:       /run/user/1000/fed-seamonkey-s3guo164.default
 profile size:    15M
 overlayfs size:  28K
 recovery dirs:   none

Перегрузились, и щас...ссс... Не гут.
   Про автозагрузку забыли. А как сделать правильно не знаю:
Просто добавил через GUI в запускаемые приложения systemctl --user start psd.service.
Поправте пожалуйста, и не ругайте применителя...!
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ivm от 08 Марта 2018, 17:04:44
Как не раз говорил, что главным недостатком в пользовательской среде Linux является слепая вера в старые How-To.
В контексте PSD (https://wiki.archlinux.org/index.php/Profile-sync-daemon_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)) был такой вариант ускорения браузера. Но сейчас надо смотреть последние комментарии по Вашим ссылкам. Информация уже протухла.
С современными SSD старые приёмы сохранения их ресурса оказались избыточными. Можно не париться на эту тему.
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ffeedd от 09 Марта 2018, 12:45:03
Цитировать
Но сейчас надо смотреть последние комментарии по Вашим ссылкам. Информация уже протухла.
А я же Вас просил?
Цитировать
     Уважаемые эксперты!
Может рекомендации внесёте, может в новых темах расскаже об этом:
И как Ваш любимый браузер насилует Ваш SSD?
Ничего личного (просто я протух: скоро в апреле будет 62)
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ivm от 09 Марта 2018, 13:25:29
Как бы сказать проще. Я попытался понять, почему Вы так думаете.
Первоначально, с точки зрения банальной эрудиции, единственный вид памяти, который может использоваться в SSD, это какой-то особый вид флешпамяти. На этом заблуждении построена вся цепочка Ваших рассуждений. И только с этой точки зрения Ваши рассуждения верны, когда Вы считаете SSD быстрой флешкой. И так действительно было в первом поколении SSD. Но даже флешки бывают разные. Дешёвые флешки имеют ограничение по числу записей до 10 тысяч раз. Более дорогая флешка имеет ресурс на порядки больше.  И это было характерно для флешек USB 2.0. Так вот число записей флеша браузера на флешку действительно может привести к её определённому износу. Но всё равно это годы эксплуатации.
Почему Вам не приходит в голову просто отключить кэш браузера, который нужен для низкоскоростных соединений?  Почему Вы считаете, что современные SSD не оптимизированы для работы операционной системы?
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ffeedd от 09 Марта 2018, 13:58:38
Как бы сказать проще.
...
Почему Вам не приходит в голову просто отключить кэш браузера, который нужен для низкоскоростных соединений?
И только с этой точки зрения

Для меня, применителя. в свете linux 
Спаасибо Ромке (это было когда-то. почти на работе) и Я,переводу то же Спасибо.
Всё просто,
У меня так: болячка есть - её надо сковырнуть
Повтаряю вопрос;
Цитировать
Уважаемые эксперты!
Может рекомендации внесёте (не для меня):
 
Ну дайте-же, хоть ... !
Всё что можно: ставил, ломал и не только. Флешку мне  совсем совсем не жалко,
Название: Re: Оптимизация SSD в Matuntu
Отправлено: ffeedd от 26 Марта 2018, 17:45:37
Настройка Ubuntu для работы с SSD http://help.ubuntu.ru/wiki/ssd (http://help.ubuntu.ru/wiki/ssd)
Цитировать
Начиная с Ubuntu 14.04 разработчики позаботились о поддержке SSD. Система сама периодически запускает функцию TRIM на SSD, никаких discard в fstab больше не требуется. И многие другие советы, которые можно найти в интернете уже не актуальны, не создавайте себе проблем, просто пользуйтесь
Был не прав. За это не пинайте.