Оптимизация дисковой системы в Linux

Когда-то давно ставил себе Ubuntu. То–ли винт был слишком маленький (80ГБ), то–ли знаний каких–то не хватало, то–ли ещё что, но стоял у меня линукс на одном единственном разделе по соседству со своп–разделом. Вскоре винчестер вырос до 320ГБ, но кроме размеров корневого диска линукса ничего не изменилось. И вот, в один прекрасный день, началось…

Заинтриговал? :) На самом деле «началось» не в один прекрасный день, а постепенно: день за днём, неделя за неделей… 320–гиговый винт, разумеется, забивался всяким хламом, постоянные обновления системы, установка различного софта и последующее его удаление размазывали систему по всем трёхсот двадцати гигам. Со всеми вытекающими отсюда последствиями, выражающимися в общей «задумчивости» системы и даже глюках отдельных программ.

Ну, а в один прекрасный день я решил, что мне это всё надоело, что необходимо как–то оптимизировать данные на винте.

План оптимизации был прост, как всё гениальное: :)

  • Вынести ⁄boot в отдельный раздел для ускорения загрузки.
  • Уменьшить swap до 1ГБ, потому что место занимает много, но почти не используется. Ещё бы! При восьми гигах оперативы… :)
  • Вынести ⁄ в отдельный раздел для ускорения работы системы и софта.
  • Слить всё оставшееся место в ⁄home, чтоб зря не пропадало.
  • Форматнуть винт в ext4.

О процессе переноса данных, перебивании винта, вразумлении загрузчика и последующем раздуплении системы можно говорить много, но не в этой теме. Единственное, что скажу — результаты проделанных действий:

  • На винте стало 4 основных раздела. Ну захотелось мне так!
  • Разделы приобрели следующий вид и последовательность: ⁄boot — 100МБ, swap — 1ГБ, / — 30ГБ, ⁄home — всё остальное.

Теперь обо всём подробнее.

Почему выбрана файловая система ext4? Потому что, как утверждают знающие люди, она быстрее, чем ext3, которая была использована у меня ранее. К тому же эта система сейчас является основной в Linux, а это что–то да и значит.

Почему ⁄boot именно 100МБ? Потому что глянул я на папку ⁄boot, а она весит 100МБ. Это при том, что я не удалял старые ядра, а в последний раз они удалялись при обновлении дистрибутива полгода назад. Ну, а так как дистрибутив обновляется раз в полгода, кстати, сегодня, то больше места под ⁄boot выделять не имеет смысла. А меньше — опасно, ибо можно вовремя не удалить старые ядра и, при очередном обновлении, новому ядру некуда будет записаться, что может привести к интересным спецэффектам.

Почему swap — 1ГБ? Потому что при 8ГБ оперативной памяти, swap используется крайне редко и то на несколько мегабайт. Но совсем без подкачки нельзя, ибо также возможны различные спецеффекты. А 1ГБ — просто круглое и небольшое число.

Почему / — 30ГБ? Потому что посмотрел я в какой–то нехорошей программе, сколько же места занимает корень, и показала она мне почти 20ГБ. Дал небольшой запас на всякий случай, а потом округлил в большую сторону. :) На самом деле корень занимает меньше 8 гиг.

Почему ⁄home досталось всё остальное? Ну, а куда ж его, всё остальное, девать–то? :)

Почему разделы именно в таком порядке? ⁄boot в самом начале диска, чтобы как можно быстрее загрузить систему при запуске, когда головки диска находятся в его начале. swap в начале диска, для увеличения скорости его работы, поскольку в начале диска скорость доступа выше. swap находится после ⁄boot, поскольку подкачка практически не используется и выигрыш от размещения swap в самом начале диска будет нивелирован этим фактом. И напротив, размещение ⁄boot в начале диска, а не после swap даёт небольшой выигрыш. / находится следом за swap, поскольку его скорость так же важна, как и предыдущих разделов, но прирост производительности от размещения на 1ГБ ближе к началу диска теряется на фоне разброса данных в этом разделе на большом пространстве диска. ⁄home, как самый не значимый, из вышеперечисленных, для скорости системы, находится в конце диска.

После всего вышеописанного получился следующий результат:

  • При первой же загрузке система стартанула на 10 секунд быстрее.
  • На глаз, программы стали запускаться немного быстрее.
  • Увеличилась общая «отзывчивость» системы.

На самом деле результат получился не такой уж аховый, как на это можно было надеяться после 15–ти часов кручения гаек. Но всё же есть! Да и время уходило на совершенно не целевые, но необходимые операции. Далее по плану — оптимизация монтирования файловых систем, уменьшение корневого раздела и распараллеливание процессов во время загрузки системы.

Комментарии

Комментировать