LXF126:Пять ценных идей
|
|
|
- Xитрости в Linux
Содержание |
Пять советов
- Каждый линуксоид со временем накапливает собственную подборку хитростей. Александр Толстой готов поделиться с вами пятью лучшими из своей коллекции.
Как мы (и не только мы) уже неоднократно отмечали, быть просто пользователем Linux можно, но неинтересно. Статья «Ускоряем Linux» из ноябрьского номера журнала (LXF124) вызвала оживленную дискуссию как на форуме, так и в редакционной переписке, и мы решили, что тема заслуживает продолжения. Однако повышение производительности системы — одна из самых важных, но далеко не единственная задача тюнинга, поэтому сегодня мы также сконцентрируемся на трюках, которые помогут вам выполнять известные задачи с большим удобством или просто по-другому.
Ядро без команд
Несмотря на уверения, что «это несложно» и «под силу даже новичку», пересборка ядра по-прежнему подвластна лишь тем, кто сумел одолеть «кандидатский минимум» в Linux. Не то чтобы это было плохо, или иметь собственное ядро было бы насущной необходимостью – к слову, мы в Башнях LXF не испытываем таковой вот уже несколько лет – но возможность сделать эту процедуру чуточку проще никогда не помешает.
KernelCheck (http://kcheck.sf.net) – это графический интерфейс к набору сценариев на Python, берущих на себя всю «грязную» работу по перекомпиляции ядра для дистрибутивов на базе Debian. Всё верно: вы можете собрать и детально настроить свое собственное ядро Linux, не введя ни одной команды в терминале. KernelCheck предоставляет в ваше распоряжение пошаговый мастер, который готов провести пользователя по всем этапам выбора, загрузки и сборки ядра.
На первом экране следует нажать на кнопку скачивания сведений о свежей версии ядра. Данные берутся с сайта http://master.kernel.org и позволяют вам сравнить версии текущего стабильного и нестабильного ядер, узнать об актуальных наборах патчей, которые вы опять же можете применить или проигнорировать (в последнем случае получится так называемое «ванильное» ядро – по аналогии с ванильным мороженым, к которому можно добавлять различные наполнители). Сделав и подтвердив свой выбор, вы переходите далее, и KernelCheck начинает готовить для вас среду сборки: скачивает и устанавливает все необходимые пакеты разработчика. На свежеустановленной системе Ubuntu это напоминает установку пакетов из группы build-essentials, но только чуть удобнее и прозрачнее для пользователя.
Когда всё будет готово, KernelCheck запустит для вас интерфейс xconfig для настройки параметров ядра. Конфигурация поумолчанию берется из «фабричных» настроек вашего дистрибутива и копируется в файл /usr/src/linux/.config. Все сделанные вами изменения будут записаны в него же.
Сохранившись и выйдя из xconfig, вы сразу же будете перехвачены поджидающим вас скриптом из KernelCheck, который отвечает за сборку самого ядра, подгружаемых модулей и первичного образа загрузки (initrd). Теперь нужно подождать: процесс сборки ядра долог, и даже на быстрых машинах может занять около часа. Отдохнув от компьютера и дав поработать make, вы через какое-то время получите готовое ядро. KernelCheck упакует весь результат в два deb-пакета (само ядро и заголовочные файлы) и установит его обычной командой dpkg. При последующей загрузке новое ядро появится в списке Grub, и вы сможете запустить систему «с него». KernelCheck удобен и в том, что в дальнейшем вы сможете работать с установленными у вас исходными кодами ядра, обновляясь до будущих версий с помощью наборов патчей (загружать всё по новой не требуется), а также управлять версиями ядра без копания в конфигурационных файлах. KernelCheck позволяет делать чёрную работу в белых перчатках – за это его и любят продвинутые пользователи Debian-систем. Осталось дождаться версии программы для RPM!
Speed Disk для Linux
Дефрагментация в Linux? Зачем?! Почти все знают, что применяемые в Linux файловые системы, включая ext3, ext4, ReiserFS и XFS, невероятно устойчивы к фрагментации записанных данных. Так и есть, но всё же бывают и частные случаи, когда дефрагментация пригодилась бы. Скажем, у вас есть выделенный раздел для каталога /boot, и вы регулярно пересобираете ядра. Или вы создали специальный раздел для хранения часто обновляемых данных. Прошло два года – и вы замечаете, что чтение и запись на раздел сильно замедлились. Что делать?
Во-первых, размонтируйте раздел и запустите проверку диска командой fsck (если речь идет о корневом разделе, удобно воспользоваться LiveCD). Чтобы fsck проделала полную проверку даже исправного раздела, используйте параметр -f, например, так: fsck -f /dev/sda1 (вместо sda1, разумеется, подставьте требуемое имя раздела). Нас интересует доля фрагментированных файлов, которые в данном случае называются ‘non-contiguous’. Если фрагментация не превышает 15 %, то можно не волноваться; если же она больше – нужна дефрагментация. Если говорить в целом, то для Linux нет специализированных дефрагментаторов, поэтому на большинстве форумов вам посоветуют сохранить все данные на другой раздел или носитель, отформатировать исходный раздел, после чего записать все данные обратно. Это долго и неудобно; но, к счастью, есть альтернатива. Некто Кон Коливас [ConKolivas], некогда автор ветки -ck ядра Linux, создатель нового планировщика и прочая, и прочая, написал замечательный скрипт, который распределяет файлы на разделе от большого к малому, то есть сортирует их. Сценарий доступен для свободной загрузки по адресу: http://ck.kolivas.org/apps/defrag/. Особенность его в том, что он действует на всё, что находится в текущей директории, то есть позволяет дефрагментировать отдельные каталоги.
Если у вас раздел с файловой системой XFS, то дела обстоят по-другому. Вам потребуется программа xfsdump (если её нет в репозитории вашего дистрибутива, то исходный код можно скачать с сайта http://ftp.de.debian.org/debian/pool/main/x/xfsdump/xfsdump_3.0.2.tar.gz). Выполните от лица администратора команду xfs_db -r /dev/sda1, причем раздел sda1 предварительно размонтировать не нужно. Вы увидите значение параметра ‘Fragmentation factor’. Для дефрагментации используйте команду: xfs_fsr -v /dev/ sda1. Вот и всё! Кстати, если выполнить команду xfs_fsr без параметров, то она автоматически начнёт дефрагментацию всех смонтированных XFS-разделов. Если вы нетерпеливы и прервёте работу дефрагментатора, то при следующем запуске xfs_fsr возобновит работу, учитывая уже проделанные действия.
Кино в тишине
Настоящий линуксоид – тоже человек, и иногда он хочет расслабиться и посмотреть какой-нибудь хороший фильм. Чтобы просмотр кино был комфортным, нужен не только большой экран и колонки – требуется ещё, чтобы системный блок не издавал шума, что приблизило бы его к бытовой Hi-Fi-технике и сделало бы более эргономичным.
Разберёмся: в системном блоке шумят вентилятор на процессоре, винчестер, вентилятор блока питания и, в некоторых ситуациях, вентиляторы видеокарты и чипсета материнской платы. Уровень шума в каждом случае будет разный: гдето на ЦП установлен мощный вентилятор, который крутится медленно и мало шумит, у кого-то нет активного охлаждения чипсета и видеокарты. Параллельно с этим не будем забывать, что современные материнские платы автоматически регулируют скорость вращения системных вентиляторов, однако на шум это влияет мало – производители перестраховываются и не позволяют своей технике быть слишком тихой. В таких случаях как раз пригодится ручная настройка. Мы начнем с вентилятора процессора, для чего воспользуемся утилитами из состава lm-sensors.
Команда sensors позволяет выяснить, какие датчики имеются на вашей материнской плате и какой из них отвечает за управление обдувом ЦП. После этого запустим pwmconfig, который поможет откалибровать напряжение, подаваемое на вентилятор. Отвечая на вопросы программы, нужно обязательно наблюдать за вентилятором (снимите крышку системного блока!) и подтвердить его остановку и запуск при указанных напряжениях. Результат калибровки pwmconfig записывает в файл /etc/fancontrol. У меня, к примеру, он выглядит так:
FCTEMPS=hwmon1/device/pwm1=hwmon1/device/temp1_input FCFANS= hwmon1/device/pwm1=hwmon1/device/fan1_input MINTEMP=hwmon1/device/pwm1=65 MAXTEMP=hwmon1/device/pwm1=85 MINSTART=hwmon1/device/pwm1=50 MINSTOP=hwmon1/device/pwm1=65 MINPWM=hwmon1/device/pwm1=65 MAXPWM=hwmon1/device/pwm1=120
Теперь запустим собственно /sbin/fancontrol, который будет использовать значение из файла выше. Смысл этих манипуляций прост: вентилятору совсем не обязательно крутиться на полных оборотах, чтобы эффективно охлаждать ЦП. При небольших загрузках ЦП вентилятор может вообще оставаться выключенным, раскручиваясь только тогда, когда температура ЦП превысит установленный лимит.
Теперь самое интересное: как отключить винчестер? Очень просто: набрав (от имени root) hdparm -y /dev/sda. Данная команда обесточивает жесткий диск, и тот замолкает – до первого обращения к нему. Проблема в том, что при проигрывании фильма время от времени происходит считывание файла в кэш, а это значит, что жесткий диск сразу же проснётся. Но и мы не лыком шиты: весь фильм можно кэшировать в память, если у вас её достаточно. Просто откройте фильм в MPlayer из консоли следующей командой: mplayer -cache 1400000 movie.avi. Дождитесь окончания кэширования, после чего файл movie.avi в текущей директории откроется в новом окне. Данная команда позволяет поместить в ОЗУ стандартный фильм в HD-качестве размером 1,37 ГБ. Перед тем как развернуть фильм на полный экран, отключите винчестер (см. выше), откиньтесь на спинку табуретки и наслаждайтесь!
Другая файловая система
В Интернете, в местах массового скопления линуксоидов, время от времени возникают дискуссии на тему надежности файловых систем (ФС). Обсуждаются преимущества ext3/ext4 над FAT32/NTFS; файловые системы для Linux сравниваются между собой. Каждый хочет иметь одновременно и самую быструю, и самую надёжную систему, причем под надёжностью часто понимают эффективность журналирования. Сегодня мы поговорим о современной и не очень известной (пока) файловой системе NILFS, в которой реализован принцип постоянного создания контрольных точек. Другими словами, данная ФС ведет журнал всех изменений на диске в реальном времени и позволяет восстановить, к примеру, только что удаленные файлы, не прибегая к Корзине.
NILFS (http://www.nilfs.org) постоянно создаёт файлы журнала, при этом не перезаписывая ни один ранее созданный файл. Это очень здорово в тех ситуациях, когда возникает аппаратный сбой и нужно восстановить недозаписанные данные. C NILFS можно быть уверенным, что записанный секунду назад файл никуда не денется – ведь здесь нет никаких задержек между записью в журнал и обновлением файла на диске. Сведущие пользователи, наверное, сразу же укажут автору на ZFS из OpenSolaris, в которой реализован схожий функционал. Что же, и мы укажем на разницу между ZFS и NILFS: в OpenSolaris создание контрольной точки состояния файловой системы [snapshot] есть отдельная операция, во время которой никакая другая запись на диск производиться не может (надо подождать!). Напротив, в NILFS сохранение на диск и журналирование совмещены: любые изменения ФС выглядят как цепочка файлов, записываемых в конец раздела. Скорость чтения и записи у NILFS выше, чем у ZFS, а при решении некоторых задач (работа с БД SQLite) – выше в десятки раз.\
Проницательный читатель знает, что за такие показатели нужно платить, и, наверное, уже догадался, что является ценой в случае с NILFS. Всё верно: постоянная запись в конец ФС приводит к её быстрому заполнению, когда формально места на диске ещё много, но служба журнала достигла физического конца раздела. Для решения этой проблемы в NILFS предусмотрен так называемый «сборщик мусора» – функция, которая время от времени удаляет совсем старые и явно ненужные журнальные записи. На месте удаленных записей получаются «дыры», и файловая система медленно, но верно фрагментируется. Еще раз уточним, что такая ситуация возникает при длительном использовании накопителя с ограниченным объёмом. На практике это означает, что при значительной фрагментации нужно делать резервную копию всех данных, форматировать раздел и записывать все данные на него заново. К счастью, необходимость в этом возникает нечасто.
Для каких целей применима NILFS? Для любых, где нужна гарантия возврата к предыдущей версии файла. Также NILFS будет паллиативным решением для работы с дефектным носителем, где много «плохих» блоков. В NILFS можно подмонтировать контрольные точки параллельно с работой основной ФС и «вытянуть» данные при нестабильной работе дисковой подсистемы.
Перейдем к практике. NILFS входит в стандартную поставку ядра Linux, начиная с версии 2.6.30. Если у вас новое ядро, для начала работы нужно всего лишь установить комплект утилит для работы с файловой системой – nilfs-utils. Для примера возьмём подопытную карту памяти и отформатируем ее в NILFS:
/sbin/mkfs.nilfs2 -B 512 /dev/sdg1
Опция -B определяет количество блоков на сегмент. В данном случае пришлось понизить это значение до 512, так как карта памяти маленькая – всего 64 МБ. Стандартно NILFS работает с дисками размером от 128 МБ.
Подмонтируем раздел (mount -t nilfs2 /dev/sdg1 /media/sdg) и какое-то время будем сохранять на него данные. В любой момент с помощью команды lscp можно вывести список контрольных точек:
root@localhost ~]# lscp
CNO DATE TIME MODE FLG NBLKINC ICNT 1 2009‑12‑10 00:38:56 cp – 11 3 2 2009‑12‑10 00:39:39 cp – 11 4 3 2009‑12‑10 00:40:48 cp – 14 5 4 2009‑12‑10 00:41:53 cp – 14 6 5 2009‑12‑10 00:42:14 cp – 14 7 6 2009‑12‑10 00:42:24 cp – 15 8
Первый столбец содержит числовые идентификаторы контрольных точек. Чтобы подмонтировать, к примеру, точку 2, дадим такую команду:
mount -t nilfs2 -r -o cp=2 /dev/sdg1 /media/cno2
Помимо lscp, пакет nilfs-utils включает команды для создания контрольных точек, конвертации их в снимки всей ФС и удаления. Все эти команды работают в пространстве пользователя и не требуют прав администратора.
Лифт имени Линуса
Наверное, нет такого пользователя, который не хотел бы сделать бы дисковую подсистему ещё быстрее. Один из простых и эффективных способов добиться этого – грамотный выбор планировщика ввода/вывода (I/O). Если не вдаваться в подробности, то такой планировщик упорядочивает запросы на чтение/запись в очереди ядра и позволяет сократить время поиска данных на винчестере. Как это происходит и зачем это нужно? Если бы ядро Linux обращалось к диску непосредственно при каждом системном вызове, то процесс чтения/записи превратился бы в полный хаос, и головки жёсткого диска при чтении и записи данных метались бы туда-сюда. Планировщик призван упорядочить этот процесс: он группирует и распределяет вызовы на чтение и запись данных. Планировщики бывают разными, хотя в большинстве дистрибутивов поумолчанию используется CFQ. Чтобы узнать, из чего можно выбрать, дайте команду:
cat /sys/block/sda/queue/scheduler
где sda – имя интересующего вас диска. Давайте рассмотрим особенности планировщиков.
- CFQ Расшифровывается как Complete Fair Queueing – полностью честная обработка очереди. Этот тип оптимизирован на множественные запросы к диску от нескольких пользователей одновременно и хорошо справляется с многозадачностью.
- NO-OP Самый простой вариант (no operation), обеспечивающий примитивную группировку сходных запросов. Не думайте, что он бесполезен: при интенсивной работе с USB-накопителями или с SSD-дисками, где отсутствуют затраты на перемещение головки, он может оказаться полезным, а то и здорово продлить жизнь вашим устройствам.
- Anticipatory Планировщик, пытающийся «угадать» следующее действие пользователя и действующий с небольшой задержкой. Его главная цель – минимизировать движение головок. Это хорошо для винчестеров, доживающих свои последние дни, но совершенно не подходит для работы с базами данных (в этом случае Anticipatory постоянно ошибается, что снижает скорость в несколько раз).
- Deadline Этот планировщик активно использует принцип отложенной записи. Ядро не сразу сохраняет изменения на диск, а ждет «крайнего срока», используя высвобожденное время для более быстрого считывания. Этот тип планировщика идеально годится при распределённых запросах к диску – например, при работе с БД.
Какие планировщики бывают, теперь, надеюсь, понятно; осталось разобраться, как их менять. К счастью, эта операция не требует перезагрузки, и изменения вступают в силу немедленно. Например, команда
echo deadline > /sys/block/sda/queue/scheduler
набранная от имени администратора, установит тип планировщика deadline для диска /dev/sda.
Чтобы зафиксировать изменения на постоянной основе, следует поменять параметры, передаваемые ядру в настройках загрузчика (обычно это файл /boot/grub/menu.lst). В строку инициализации ядра добавьте elevator=deadline (или любой другой тип планировщика) и сохраните настройки. Оценку производительности диска лучше производить специальными тестами; простейший – команда /sbin/hdparm -tT /dev/sda.
