Оптимизация Linux под SSD 10


Твердотельные накопители становятся все доступнее и занимают все большую часть рынка. Вот и я решил заменить hdd c windows seven своего нетбука Lenovo IdeaPad S10-2 на c Ubuntu Netbook.

В этой записи я собрал нагугленные заметки по оптимизации работы на SSD для рабочей станции.

Разметка диска и файловая система

В первую очередь, нужно забыть про раздел подкачки, все прекрасно работает и без него. Для SSD лучше использовать не журналируемую файловую систему. Журнал нужен для того, чтобы, после пропадании электропитания, восстановить незавершенные транзакции — не потерять данные и оставить ФС целостной. Так как большинство SSD используются в ноутбуках/нетбуках, где присутствует батарея, пропадание электропитания практически невозможно, журнал не нужен. Я использую 100 Мб под /boot с ext2, 20 Гб как / с ext4 и все остальное под /home, так же с ext4. Файловую систему ext4 я выбрал так как она позволяет отключать журнал после создания файловой системы, делается это так:

[email protected]:~$ tune2fs -o journal_data_writeback /dev/sda1
[email protected]:~$ tune2fs -O ^has_journal /dev/sda1
[email protected]:~$ e2fsck -f /dev/sda10

Так же, для увеличения производительности, к опциям монтирования в fstab рекомендуется добавить:

relatime,nodiratime,discard,commit=60

Здесь у некоторых может возникнуть подозрение, что использование noatime эффективнее чем relatime. Это не так, relatime обновляет время доступа только при изменении файла или изменении времени доступа. Это нужно для нормальной работы некоторых программ, в том числе почтовых клиентов. Опция discard включает поддержку TRIM. Так же откладываем до раза в минуту запись изменений на накопитель commit=60.

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

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

I/O планировщик

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

elevator=noop

Параметры ядра

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

vm.laptop_mode = 5
vm.dirty_writeback_centisecs = 15000

Firefox & Chrome

Временные файлы мы перенесли в оперативную память, но браузеры хранят свой кеш в домашнем каталоге пользователя, который у нас на 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'

Кэш пакетных менеджеров

Так же может быть полезным вынести кэш менеджера пакетов в ОЗУ. Для deb-based дистрибутивов нужно добавить в fstab:

tmpfs   /var/cache/apt/archives tmpfs   defaults        	0 0

Для rpm-based дистрибутивов нужно добавить в fstab:

tmpfs   /var/cache/yum tmpfs   defaults        			0 0

UPD20130310: Обновлены обции монтирования, добавлен вынос кеша пакетных менеджеров в ОЗУ.


10 мыслей про “Оптимизация Linux под SSD

  • Андрей

    Как я ни настраивал параметры ext4 в UBUNTU, но от периодического обращения в диску на запись избавиться так и не удалось. Настройки, рекомендованные в статье не помогли.
    Но зато отличные результаты дала файловая система XFS. У нее даже заблокирована запись в суперблок, при монтировании вся информация о времени последней записи восстанавливается из inod’s! это как раз то что нужно для SSD. А тот недостаток, что обычно отмечают для XFS — возможность потери данных при неожиданном отключении
    питания здесь несущественен, если речь идет об устройствах с автономным питанием. И кроме того на ext4 Вы отключаете журналирование и потери информации при отключении становятся неизбежными, а на XFS журналирование отключать нет необходимости и возможные потери будут сведены до минимума.

    • Rascal От автора

      Не совсем. Формально для SSD лучше copy-on-write файловые системы аки zfs и btrfs.
      C точки зрения целостности данных у xfs проблема. При крахе системы или сбое питания восстановить практически не реально, для ext же существует куча утилит.
      А для нетбука xfs совсем не подходит, так как у нее значительно большее потребление ресурсов ЦПУ и памяти нежели у других.

  • Andy

    «writeback,»
    вот если рядом с этим параметром у вас стоит «discard» -отвечающий за поддержку ТРИМа — то система не сможет примонтироваться и запуститься.
    Лучше его не писать- тем более, чтодля отключения журналирования хватит манипуляций с тьюн2фс.

  • ostin

    Чувак, хотел отметить пару моментов, которые у тебя в посте не освещены (-;

    Во-первых: у SSD-дисков (надо уточнять про конкретных вендоров, разумеется, но все же) физический размер сектора, в основном, 128k. Соответственно, встает проблема с выравниваеним границ разделов. У федоры установщик (anaconda) сам размечает диск так, что первый раздел начинается с 2048 сектора (пропускает 1mb), это, разумеется, больше, чем надо выравнивать для ssd, но в общем случае тоже вполне нормально. Этот момент стоит проверить. Подробнее можно почитать, например, тут.

    Во-вторых: у некоторых моделей нетбуков 2 SSD диска, есть смысл организовать RAID 0 или LVM в режиме stripe (оно вроде так умеет?). Быстродействие от этого увеличется не очень, но некая экономия ресурса SSD будет.

    • Rascal От автора

      Насчет выравниввания таблицы разделов я не могу не согласиться, размер ячеек памяти у SSD действительно 4 Кб против 512 Б секторов НЖМД.

      А вот со второй частью не согласен категорически. RAID 0 вообще противопоказан, а в частности увеличение быстродействия зависит в данном случае от контроллера, и может быть существенно. А вот экономии ресурса, к сожалению, не будет. Более того тер. вер. говорит что надежность такой системы крайне низкая.

      • ostin

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

        • Rascal От автора

          «Чередование» записи в данном случае это абсолютно черное тело или материальная точка. Увы, идеального в природе нет. В зависимости от размера страйпа и блока файловой системы это будет с большей или меньшей степенью приближением, но лишь приближением.
          А вот математика наука более точная. Когда один из дисков выйдет из строя, за компанию похоронит и данные на втором, так как это RAID0.

          • ostin

            Математика может быть и точная наука, но раздел теории вероятностей, к которому предлагешь обратиться ты, на вопрос «когда?» точного ответа дать не может. Выйти из строя может и RAID1 и сколько бы человек с таким сдохшим массивом не говорил о том, что у него он должен был быть надежнее, чем мой RAID0 факты от этого не изменятся. Для достаточно большого количества людей вероятности будут такими, какими их указал ты — RAID 0 менее надежен, чем RAID 1. Но для меня вероятность выхода из строя моего диска такая же, как вероятность встретить динозавра на улице, т.е. 0.5 (-;

Комментарии закрыты