Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

оптимизация Linux

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Unix
Предыдущая тема :: Следующая тема  
Автор Сообщение
Sol



Зарегистрирован: 05.12.2003
Сообщения: 427
Откуда: Томск

СообщениеДобавлено: Ср Июн 15 2005 11:29    Заголовок сообщения: оптимизация Linux Ответить с цитатой

Может будет кому полезно...

Не помню, где смотрел, поэтому "выкладываю" весь текст здесь

Linux-оверклокинг
Введение в проблему
Истина банальная, но верная: какой же русский не любит быстрой езды? И какой линуксоид - быстрой работы? Однако первое разочарование, которое может постигнуть пользователя пакетного Linux-дистрибутива (будь то Red Hat, Suse, Mandrake - исключение оставим за Slackware), - это иногда весьма задумчивый процесс загрузки системы. Да и в дальнейшем быстродействие многих приложений может оставить только пожелать лучшего - печальным примером чему послужит OpenOffice.
И тот самый начинающий Linux-юзер вправе задать себе (и остальным) вопрос: а где же тут хваленая нетребовательность к ресурсам и перерасхваленное быстродействие этой операционной системы? В меру своего понимания проблемы постараюсь дать на него ответ в настоящей заметке.
Для начала – о ресурсах. Будем откровенны: разговор о нетребовательности к оным относится исключительно к а) консольному режиму, и б) специальным применениям, типа сетевого роутера или почтового сервера. Для любого десктопа, особенно домашнего (не последняя цель которого - служить всякого рода развлечениям, немыслимым без использования оконной системы Икс) часто фигурирующие в первоисточниках цифры типа i386SX/33/4RAM/120Hard лежат далеко за областью мифов и легенд Древней Греции. Уже чисто консольный vim, собранный с feature=big (а без этого несколько затруднительно работать в кириллическом окружении - в частности, для использования команд придется постоянно переключаться на литиницу) органолептически тормозит на Celeron/400 с 96 Мбайт (ниже - пробовал очень давно, и уже забыл, как).
Если же речь идет о системе X (каковая, как неоднократно говорилось, - отнюдь не Linux) - системные требования следует наращивать в той же пропорции, что и при переходе от Windows 3.1 к Windows XP. А уж комфортная работа в современных версиях интегрированных сред типа KDE и GNOME начинается где-то с 256 Мбайт памяти (и никакие гигагерцы процессора тут лишними не покажутся). Другое дело, что Linux (вкупе с надстраивающим его Иксами) ко всем этим ресурсам относится более эффективно, обеспечивая изрядный прирост быстродействия в пересчете на каждый мегабайт RAM и мегагерц "камня".
Тем не менее, проблема "тормознутости" тяжелых приложений не снимается с ростом тестовых fps'ок "железа". Однако - проблема эта, в большинстве случаев, решается, и решается различными методами, в зависимости от того, сколько времени и сил вы готовы на нее затратить.
Разумеется, самый радикальный способ Linux-оверклокинга - собрать свой собственный Linux в соответствие с заветами великого Герарда (Бикманса) и его LFS (http://www.linuxfromscratch.org), который по определению не будет иметь в своем составе "тормознутых" компонентов, а все имеющиеся - будут заоптимизированы до посинения. Однако, проделав эту процедуру не единожды, готов под присягой подтвердить: да, это очень радикальный способ, однако абсолютно не применимый в "индустриальных", так сказать, условиях. Ибо достигаемый им результат (воистину блестящий, при благоприятном расположении звезд на небе – потому что Linux-самостройщика подстерегает много подводных камней – тех, о которые спотыкаешься, а не тех, что вставляют в сокет материнской платы) ни в коей мере не окупает для пользователя затраченных усилий (исключая, конечно, приобретенные знания и навыки – однако повторять такой эксперимент я стал бы повторять только под дулами пулеметов заградотряда). И вообще, тема Linux-самостроя столь широка и необъятна, что далеко выходит за рамки настоящей заметки.
Второй метод Linux-оверклокинга – выбор подходящего дистрибутива: ведь не секрет, что одни Linux'ы работают быстро, а другие... скажем так, не очень. На примеры отрицательные указывать пальцем не буду, а вот о положительных не упомянуть не могу - линуксоиды должны знать своих героев. Так вот, в числе максимально быстрых дистрибутивов отмечу – по нарастающей, – Slackware, Gentoo, Archlinux и, особенно, CRUX. Подчеркнем – имеется ввиду "умолчальная" установка - тот же Gentoo руками можно довести если не до третьей космической скорости, то уж до второй - точно. Впрочем, и Red Hat никто не запрещает перебрать руками до последнего пакета...
Однако и этот метод не всегда приемлем – со временем у каждого пользователя складываются сугубо личные предпочтения в отношении дистрибутивов. Так что тему настоящей заметки я сформулировал бы так: достижение максимальной производительности наличной инсталляции Linux'а, данной нам в качестве объективной реальности. Ведь свой дистрибутив мы выбирали, руководствуясь какими-то вескими соображениями, не так ли? И при этом основной нашей целью будет ускорение загрузки системы и запуска приложений – то есть аспектов, наиболее раздражающих пользователя.
Техника безопасности
Любые действия по тюнингу и твикингу любой системы... не то чтобы потенциально опасны, но при некоторых неблагоприятных условиях могут привести ко всякого рода неожиданностям и неприятностям (вплоть до невозможности загрузки). Избежать их, однако, очень легко: для этого следует только придерживаться некоторых несложных правил техники безопасности.
Первое правило – всегда иметь под рукой возможность загрузки с независимого носителя. Предлагать в качестве такового спасительную трехдюймовую дискету нынче несколько несерьезно. Ибо всегда можно разжиться каким-либо дистрибутивом LiveCD (то есть полнофункциональной Linux-системой, работающей непосредственно с компакта, без установки на винт).
Выбор здесь обширен: в этом качестве подойдет и Knoppix, известный (Upgrade #, 2003), и менее знаменитый Lonix, и загрузочный CD проекта LFS. Я, однако, посоветовал бы каким-либо образом выпросить у автора Upgrade Владимира Попова его разработку, реализуемую на базе CRUX'а. Не смотря на статус достаточно ранней бета-версии, именно с ролью большой спасательной дискеты он справляется более чем успешно (обладая множеством дополнительных достоинств). А ныне доступен и для скачивания с этого сайта.
Правило второе – backup, backup и еще раз backup, – вписано в скрижали истории гектолитрами юзерских слез по гигабайтам потерянной информации. Причем резервированию подлежат не только пользовательские данные: в обязательном порядке следует сохранять на независимых (и легко доступных) носителях весь каталог /etc, dot-файлы из каталогов $HOME и /root (а также все прочие индивидуальные настроечные файлы, если таковые имеются, например, в каталоге /opt). Это не только снизит затраты времени при нарушении системы, но и упрощает переход с системы на систему. Мои конфиги, например, годами кочуют из дистрибутива в дистрибутив, из Linux'а во FreeBSD и обратно...
Частный случай второго правила, способный, однако, резко упростить жизнь, - иметь под рукой исходники важного системного инструментария. Поясню на примере: скажем, файловая система с пользовательскими данными находятся на LVM-разделах (о которых см. соответствующий материал), а данный конкретный LiveCD таковые не поддерживает. И получается - близок локоть (сиречь данные), да не укусишь...
Правило третье – тривиально: читайте документацию, она rulez-z! Если же и это не помогает – может быть, стоит просто подумать. И вообще, руководствуясь правилом – сначала думать, а потом делать, можно избежать многих неприятностей (и не только при оверклокинге Linux'а).
Теперь, освоив принципы безопасного... оверклокинга, можно браться за дело. Процесс оверклокинга можно разбить на несколько этапов, каждый из которых знаменует очередной виток асимптотического приближения к идеалу быстродействия.
Этап первый: стартовые сервисы
Парадоксально, но факт: в большинстве случаев причиной раздражающей медлительности Linux-системы является ее банальная перегрузка. Дело в том, что красивые графические инсталляторы пакетных дистрибутивов подчас нечувствительно для пользователя устанавливают немерянное количество стартовых сервисов. Руководствуясь, видимо, принципом - "запас горба не ломит и..." (продолжение опустим, из соображений сугубо нравственных).
В результате в выводе команды типа ps aux (или при мониторинге программой top) можно обнаружить, что на нашей домашней настольной машине постоянно функционирует почтовый сервер типа sendmail'а, служба анонимного ftp-доступа, web-сервер типа apache и еще десяток столь же необходимых настольному юзеру сервисов и демонов. Я, конечно, понимаю, что иметь свой собственный post-сервер на домашней машине – круто. Однако не похоже ли это на известное упражнение по отстрелу воробьев главным калибром линкоров Королевского флота Великобритании?
Так что процесс оверклокинга начнем с элементарного избавления от всякого рода стартовых излишеств. К сожалению, это – именно та сфера, где очень трудно дать однозначные рекомендации, и не только потому, что представление об излишествах могут быть разными. Дело в том, что сфера стартовых сервисов очень дистрибутив-специфична: каждый уважающий себя майнтайнер дистрибутива считает делом чести, подвига и геройства привнести в нее что-нибудь свое, оригинальное. Тем не менее, некоторый общий порядок действий наметить можно.
Для начала вспомним, что в дистрибутивах Linux реализуются варианты одного из двух основных стилей загрузки: BSD-стиль стартовых сценариев и стартовая схема в стиле System V. Последняя распространена больше (в частности, ее придерживаются разработчики всех известных дистрибутивов типа Red Hat и его клонов, Debian и многих других). Однако начнем с BSD-стиля загрузки, как более простого (и лично мне более импонирующего).
Так вот, особенность BSD-стиля, принятого в таких дистрибутивах, как Slackware, CRUX, Archlinux, с некоторыми оговорками – Gentoo, – наличие главного конфигурационного файла, который расположен в корне каталога /etc и обычно называется, вслед за прототипом (FreeBSD и берклианскими соплеменниками) /etc/rc.conf (или неким аналогичным образом). Это – не сценарий загрузки, а простой текстовый файл, в котором перечисляются некоторые значения (раскладка клавиатуры, например, имя загружаемого шрифта, часовой пояс, и так далее), передаваемые стартовым сценариям в качестве параметров.
Здесь же можно обнаружить и список сервисов, запускаемых при старте системы - в виде построчного перечисления, как в изначальной FreeBSD, или аккумулирующей строкой, как в CRUX или Archlinux. И процесс избавления от лишнего сводится просто к удалению ненужных элементов или закрытию комментариями соответствующих строк. В частности, в CRUX'е (эталоне простоты стартовой схемы) для этого достаточно отыскать строку SERVICES=(значение1 значение2...) и стереть между скобок все, что покажется ненужным.
Несколько по иному устроена стартовая схема в стиле System V. Здесь в каталоге /etc обнаруживается подкаталог rc.d, содержащий (во вложенных подкаталогах следующего уровня - /etc/rc.d/rc.0, /etc/rc.d/rc.1 и так далее) набор файлов, представляющих собой символические ссылки на реальные сценарии запуска различных сервисов, которые активизируются на данном уровне исполнения (runlevels), соответствующем цифре в имени подкаталога. И тут избавление от лишних сервисов требует просто изъятия (стиранием или переименованием) ссылок из каталога, соответствующего уровню исполнения по умолчанию. А какой runlevel принят в данном дистрибутиве в качестве "умолчального" - всегда можно подсмотреть в файле /etc/inittab - в его строке вида
id:2:initdefault:
Где цифра во второй позиции и являет собой идентификатор уровня исполнения по умолчанию (подробности - в приложении 1).
Какие сервисы следует удалить? Очевидно, что в первую очередь - заведомо не нужные. Так, вряд ли оправдано перманентное функционирование web-сервера apache на машине, web-сервером не являющемся (а при необходимости, например, протестировать сценарий php, требующий интерпретации серверной стороной, его всегда можно запустить вручную).
Далее, я - сторонник кардинального решения проблем такого рода: а именно, по моему скромному мнению, удалить следует все сервисы, смысл которых кажется не вполне ясным. С вероятностью, близкой к 100%, они именно потому и непонятны, что необходимости в них лично вы не испытываете. И не следует бояться необратимо порушить систему: в крайнем случае у нас под рукой резервная копия каталога /etc, не так ли? И с ее помощью всегда можно вернуть систему в первозданное состояние. Зато после этого вы уже будете точно знать, для чего нужен, например, демоны ssh или ssl (скажу по секрету, кроме "безопасного" доступа к удаленным машинам, они требуются для запуска браузера links в "умолчальном" его исполнении, да и "звонилку" wvdial без них не собрать - см. материал о dial-up).
Этап второй: конфигурирование ядра
Разгрузка системы от ненужных сервисов - весьма действенный, но не самый радикальный метод Linux-оверклокинга. Следующий шаг в этом направлении - пересборка ядра. В дистрибутивах Source Based это - одно из непременных действий в ходе установки системы, и его сразу можно собрать в соответствие с собственными потребностями. В пакетных же дистрибутивах ядро устанавливается уже прекомпилированным, в некотором усредненном варианте, рассчитанном на работоспособность в типовых конфигурациях. Причем опять же в соответствие с принципом горба и запаса - то есть со множеством излишних опций. В лучшем случае предлагается выбор из нескольких прекомпилированных вариантов, из которых можно подобрать подходящий (не могу не помянуть тут добрым словом Патрика Фолькердинга - ядра Slackware всегда сопровождаются тщательно прокомментированными конфигурационными файлами).
Сама по себе тема конфигурирования ядра - предмет совершенно отдельного разговора. В контексте же нашего сегодняшнего разговора замечу только: в любом случае пересборка ядра системы повредить быстродействию не может вследствие двух факторов: а) оптимизации кода под конкретный процессор, и б) опять же разгрузки от ненужных опций.
Оптимизация под процессор достигается выбором в пункте главного меню Processor type and features собственно типа имеющегося процессора. В современных версиях ядра (и, добавлю, компилятора gcc версий от 3.1 и старше) доступен практически весь наличный на прилавках компьюторгов спектр "камней": абстрактные "трешки", "четверки" и "пятерки", все вариации на темы Pentium (вплоть до P4) и Athlon, древние AMD-K6 и ультрановые AMD64, а также экзотика типа Cyrix, Via, Elan, Winchip и Crusoe.
Сборка ядра под процессор выполняется с низким уровнем оптимизации (подозреваю, что с максимальным уровнем оптимизации, типа -O3, ядро просто не соберется). Однако, как ни странно, на некоторых видах задач (и для некоторых процессоров) она дает очень много. Так, на ядре, оптимизированном для Athlon, скорость копирования большого числа мелких файлов (а это тест отнюдь не на быстродействие дисковой подсистемы - вследствие эффективного кэширования большее влияние здесь оказывает подсистема процессор/кэш/RAM) возрастает буквально в разы (см. соответствующий материал).
Смысл разгрузки конфигурации ядра от поддержки отсутствующих устройств (типа изобилия SCSI-адаптеров и зоопарка сетевых карт) и ненужных опций (многочисленных сетевых протоколов, например) понятен: ядро становится меньше и, как следствие, не только грузится быстрее, но и быстрее выполняет свои непосредственные обязанности. И тут опять же страх собрать что-то неработоспособное столь же неуместен, как и при удалении ненужных сервисов. Худшее, что может грозить, - что ядро или не соберется (выдав соответствующие сообщения об ошибках, по которым можно диагностировать причину), или - не загрузится. На последний же случай у нас есть не только загрузочный LiveCD, но и образ старого, заведомо рабочего ядра - мы ведь не забыли сохранить его под новым именем?
Конечно, при радикальном минимализме следует не забывать как о здравом смысле, так и о конкретном знании взаимосвязей различных опций. Поясню на примере. Так, любые флэш-накопители на USB-шине (и, добавлю, многие другие накопители, не являющиеся IDE-дисками - Zip-приводы для параллельного порта, скажем) предстают перед системой в качестве дисков SCSI. Поддержка каковых и должна быть как-то (жестко или модульно) включена в ядро. ИМХО, понять этого невозможно, поэтому следует просто запомнить. А вот здравый смысл в силах подсказать нам, что для осуществления поддержки SCSI-дисков требуется как минимум общая поддержка SCSI-устройств и родового драйвера SCSI (т.н. generic scsi).
Однако тут перед пользователем встает глобальная стратегическая альтернатива: собирать ли ядро по возможности модульное, или жестко встраивать в него все необходимые опции. В чем разница?
При построении модульного ядра непосредственно в его код встраиваются только критически важные для старта системы опции - например, поддержка только того устройства и того типа файловой системы, на котором лежит корень нашего файлового древа (да и то не обязательно, с помощью должным образом сконфигурированного загрузочного ram-диска и эти штуки могут быть подгружены модульно). А устройства, несущие дополнительные файловые системы (типа /usr или /home) и собственно типы этих файловых систем подключаются в виде загружаемых модулей - автоматически, в ходе начальной загрузки системы, или вручную, при необходимости - командами типа insmod или modprobe. "Жесткая" же схема конфигурирования предполагает, что все на самом деле необходимое (все задействованные файловые системы, типы несущих их устройств и т.д.) поддерживаются непосредственно в коде ядра.
Разумеется, даже "жесткая" схема отнюдь не отвергает модульности как таковой - о здравом смысле не следует забывать и здесь. Ведь очевидно, что если раз в году требуется прочитать сформатированную в DOS дискету, не обязательно постоянно держать в памяти поддержку FAT-разделов, можно обойтись и соответствующим модулем, загружаемым вручную. Аналогично и с поддержкой символов национальных алфавитов в именах файлов: теоретически я могу себе представить ситуацию, что мне потребуется прочитать имена файлов, данных в кодировке ISO8859-5, и потому такой модуль у меня имеется. Однако практически вряд ли такая необходимость в этой жизни у меня возникнет, и поэтому встраивать это хозяйство в ядро я не буду (не смотря на всю свою приверженность к "жесткой" схеме).
Тем не менее, надеюсь, принципиальное различие между "жесткой" и модульной схемами я изложил понятно. На всякий случай повторюсь: речь идет о выборе модульной или встроенной поддержки опций, нужных именно постоянно (разумеется, если для них модульная поддержка доступна в принципе - раз, и без которых система способна стартовать - два). И возникает вопрос: а какая схема более способствует быстродействию?
Вопрос очень интересный и неоднозначный, однако строго количественных ответов на него мне не встречалось. Поэтому рискну изложить свои общие соображения.
Конечно, при максимальной модульности ядра размер этой единой и неделимой части системы уменьшается, а быстродействие, теоретически рассуждая, должно увеличиваться. А поскольку ядро - это еще и единственная часть системы, которая не может быть подвержена своппингу, опять же чисто теоретически модульное ядро приводит к экономии памяти (что также косвенно способствует скорости работы).
Однако практически все не так однозначно. Во-первых, загрузка модулей, даже выполняемая автоматически при старте системы, также требует времени. Во-вторых, управление модулями, их загрузкой и выгрузкой, перемещением в виртуальную память и прочее также требует ресурсов. В результате чего сложность системы возрастает, а скорость ее работы вполне может и снизиться. И потому для себя я всегда применяю "жесткую" схему конфигурирования ядра (с указанной выше оговоркой на счет здравого смысла). И поводов для разочарования пока не имел...
Третий этап: оптимизация приложений
Сказавши "а", логично было бы добавить "б". А именно, после пересборки ядра - выполнить оптимизацию приложений под имеющееся "железо", по крайней мере - критически важных для производительности системы в данных условиях. Тем более что современные версии компилятора gcc предоставляют к тому много возможностей.
Ясно, что для этого потребуется ручная пересборка, во-первых, самого компилятора gcc (дабы максимально ускорить процесс), во-вторых - пересборка приложений, которые принято относить к категории "тяжелых" - начиная с оконной системы Икс.
Оптимизация приложений достигается заданием соответствующих флагов - параметров компилятора gcc, определяемых при его вызове. Первый среди них - собственно уровень оптимизации, который задается флагом -O# и может варьировать от нулевого (флаг -O0, при котором никакой оптимизации не происходит) до максимального -O3. Большинство пакетных дистрибутивов, декларирующих свою оптимизированную природу, собирается, насколько мне известно, с флагом -O2 (вероятно, из соображений надежности). Так что есть резон пересобрать наиболее часто используемые программы с более высоким уровнем оптимизации.
Следующие флаги, весьма влияющие на производительность, задают конкретный процессор для целевой машины: -mcpu=значение или -march=значение. Различие между ними в том, что программа, собранная с флагом -mcpu, будучи оптимизированной под заданный в качестве значения "камень", сохраняет способность запуска на более младших моделях, тогда как флаг -march заоптимизирует программу так, что она сможет запуститься только на указанном процессоре или более старшем.
Допустимые значения флагов -mcpu и -march зависят от версии компилятора gcc. Однако в современных версиях, входящих в состав большинства дистрибутивов (gcc от 3.1 и выше) здесь могут быть заданы все используемые ныне процессоры семейства x86: pentium, pentium-mmx, pentiumpro, pentium2(а также 3 и 4), разнообразные athlon'ы (athlon просто, athlon-tbird, athlon-xp, athlon-mp), не считая всякой экзотики типа winchip etc. Детали можно посмотреть в документации на наличную версию gcc.
Следующие процессорно-специфичные флаги оптимизации позволяют задействовать специальные наборы инструкций современных "камней" - от MMX до 3DNow и SSE. Для этого сначала определяем, куда в этих случаях должен обращаться процессор - к стандартному сопроцессору или соответствующим блокам специализированных инструкций. Делается это с помощью флага -mfpmath=значение, в качестве какового могут выступать 387 (стандартный сопроцессор) или sse (блок SSE-расширений); согласно документации, можно задать оба параметра, правда смысл этого остается мне не вполне ясным.
Насколько я понимаю, при компиляции под Athlon'ы более оправданным будет флаг -mfpmath=387, учитывая максимально мощный сопроцессор этого "камушка". А вот в случае с Pentium-III и, особенно, Pentium4 резонным выбором будет скорее -mfpmath=sse. К чему следует приложить еще парочку флагов - -mmmx плюс -msse (для "пятой трешки") или -msse2 (для "пятой четверки").
Процессорно-привязанными флагами возможности оптимизации не исчерпываются. Есть еще флаги, специфическим образом обрабатывающие код для достижения максимальной производительности вне зависимости от типа процессора (вплоть до нарушений стандартов POSIX/ANSI, типа -ffast-math, благодаря чему теоретически можно собрать максимально быстрый код). Детальное их описание далеко выходит за рамки данной заметки. Тем более, что его можно найти в фундаментальном руководстве по gcc, написанном Ричардом Столлменом с соавторами (русский перевод доступен, например, на linux.yaroslavl.ru - и номером его версии, весьма древним, смущаться не след, актуальности оно ничуть не потеряло).
При использовании флагов оптимизации, особенно достаточно жестких (типа -O3 -march=значение, не говоря уже о -ffast-math), необходимо учитывать, что отнюдь не все программы гарантированно соберутся с ними. А те, что соберутся, вовсе не обязаны безукоризненно функционировать (даже, возможно, функционировать вообще - от ошибок сегментации гарантировать не может никто). Тем не менее, и этого пугаться не нужно - трус, как известно, в карты не играет, а кто не рискует, тот не обедает с коньяком (впрочем, один мой знакомый любил добавлять в таких случаях, что кто рискует - тому часто вообще не на что обедать). Так что выбор флагов оптимизации - дело сугубо личное. Могу только привести тот их набор, который долгое время использовал сам (для процессора Pentium-4):
CFLAGS="-O3 -march=pentium4 \
-fomit-frame-pointer \
-funroll-loops -pipe \
-mfpmath=sse -mmmx -msse2"
CXXFLAGS="$CFLAGS"

То есть идентичный для сборки программ на Си и Си++ (что, вообще говоря, не обязательно). И с такими флагами я собирал не только отдельные приложения, но и систему в целом.
К слову сказать, флаги оптимизации задаются различными способами:
• в командной строке при конфигурировании программы (CFLAGS="значения" ./configure);
• в виде переменных окружения в данном сеансе шелла (export CFLAGS="значения");
• или глобально, раз и навсегда, в профильном файле (например, в /etc/profile).
Что дает столь жесткая оптимизация? Компилятор gcc, пересобранный указанным образом, демонстрирует быстродействие на 10-15% выше, чем собранный по умолчанию. Учитывая, что на современных машинах ядро собирается минут за 10-15, казалось бы, немного. Однако при сборке монстров типа оконной системы Икс, интегрированной среды KDE или, скажем, OpenOffice, игра вполне стоит свеч. Да и прикладные программы, собранные с флагами оптимизации, работают существенно быстрее: Mozilla, для примера - чуть не в полтора раза, а для относительно легких Исковых программ типа Fluxbox, Nedit или Sylpheed ускорение просто не поддается измерению.
Этап четвертый: prelink
Все рассмотренные выше меры по ускорению Linux'а обеспечивают нам ощутимый выигрыш в быстродействии файловых операций, скорости загрузки Иксов или браузеров. Однако они оказываются практически бессильными, лишь только речь заходит о работе в интегрированных средах типа KDE или GNOME, самих по себе неслабого объема, да еще и опирающихся на монструозные библиотеки Qt и Gtk, соответственно. К счастью, у нас остается еще резерв верховного главнокомандовая - механизм предварительного связывания или, по простому, прелинкинга (prelinking).
Чтобы разобраться, что происходит при прелинкинге, нужно вспомнить о том, что подавляющее большинство Linux-приложений не содержит в себе весь необходимый для их работы код, а использует т.н. разделяемые библиотеки. И обычно программы при сборке связываются с такими библиотеками динамически, то есть необходимые функции вызываются из них в ходе загрузки программы. В одних случаях это происходит быстро, в других - раздражающе медленно. Печальным примером последнего является KDE - в частности, из-за громоздкости и сложности опорной библиотеки Qt, написанной на Си++. И бороться с этим перекомпиляцией и оптимизацией почти бесполезно - выигрыш в скорости не превышает нескольких процентов.
Однако операция динамического связывания программы с опорными библиотеками всегда происходит одинаково. И потому возникает предположение - а нельзя ли выполнить его раз и навсегда? Можно, и именно в этом - в сохранении библиотечных связей в исполняемом файле программы, - и заключается прелинкинг (его не следует смешивать со статической сборкой программ, о которой сказано в приложении 2).
Для операции прелинкинга необходимы:
• дистрибутив Linux с достаточно свежими версиями главной системной библиотеки glibc (версии 2.3.1 и выше) и сборочного комплекта binutils (версии 2.13 и выше); последний пакет рекомендуется в исполнении www.kernel.org, хотя я использовал и вариант с www.gnu.org - также без всяких проблем;
• библиотека libelf версии 0.7.0 или, лучше, 0.8.2; если оной не имеется - берется она здесь: http://www.stud.uni-hannover.de/~michael/software/;
• собственно программа prelink, имеющая местом своего проживания ftp://people.redhat.com/jakub/prelink.
Для начала устанавливаем libelf - обычным образом, распаковав архив и запустив последовательно ./configure, make, make install. Затем пытаемся проделать ту же процедуру с prelink - и в ходе исполнения make благополучным образом получаем сообщение об ошибке, причем, что самое обидное и парадоксальное - на стадии сборки компонентов для архитектуры PPC, нужной нам, как зайцу стоп-сигнал. Я довольно долго ломал голову, как побороть эту напасть, пока в недрах дерева портежей Gentoo не обнаружил специально предназначенный к тому патч. Он залегает в отростке portage/sys-devel/prelink/files и носит имя prelink-20030505-glibc231.patch (к сожалению, более простого способа его получения я не обнаружил - разве что самому написать). Несовпадение номеров версий патча и собственно prelink смущать тут не должно - все описанное проверено на собственной шкуре и работает.
Итак, распаковываем архив prelink, переходим в образовавшийся каталог и налагаем патч:
$ patch -Np1 -i /path/prelink-20030505-glibc231.patch

Теперь можно безбоязненно запускать ./configure, make, make install - все пройдет нормально. В результате мы получаем исполняемый файл /usr/local/sbin (если, конечно, при конфигурировании не был задан другой префикс - логичным представляется использование --prefix=/usr/sbin).
Соверменное примечание: сказанное выше имело силу более года назад. В настоящее время проблема эта, вроде бы рассосалась.
Прежде чем запускать программу связывания, необходимо выполнить некоторые конфигурационные мероприятия. А именно - скопировать из каталога doc в дереве исходников prelink файл prelink.conf:
$ cp /path_to_prelink-src/doc/prelink.conf /etc

А затем внести в него все пути к исполняемым файлам и библиотекам, которые вы собираетесь подвергнуть процедуре предварительного связывания. В результате он приобретет вид вроде следующего:
-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/X11R6/bin
...
-l /lib
-l /usr/lib
-l /usr/X11R6/lib
...

Пользователям KDE (а именно к ним, как и к пользователям GNOME, в первую голову обращен этот раздел заметки) следует проследить, чтобы в этом описании файла /etc/prelink.conf присутствовали пути к библиотекам Qt, kdelibs и исполнимым файлам kde, каковыми при ручной сборке по умолчанию являются:
...
-l /usr/local/kde/bin
-l /usr/local/qt/bin
...
-l /usr/local/qt/lib
-l /usr/local/kde/lib

иначе вся затея теряет смысл. Пользователям GNOME умолчальные пути к своим либам и бинарникам предлагается определить в виде самостоятельного упражнения...
Теперь можно, наконец, запустить процесс предварительного связывания. Делается это так:
prelink -avfmR

Смысл опций команды следующий: -a предписывает применить прелинкинг ко всем исполняемым файлам; -v - выводит подробную информацию о ходе процесса - необходимость этого я покажу парой строк ниже; -f - директива применять прелинкинг повторно, даже если эта процедура уже была выполнена (необходимость этого также будет обоснована чуть позже); -m и -R - опции, страхующие от ошибок нехватки памяти и переполнения буфера (подробности, как обычно, - на man prelink).
После этого начинается собственно предварительное связывание, – процесс во времени длящийся, хотя и не столь уж долго – моя машина управляется с ним за время, затрачиваемое на выкуривание сигареты). Однако в ходе его может начаться самый охмуреж: вывод сообщений (обеспечиваемый нам опцией -v, так что без нее не обойтись), что программа имя_рек собрана с опцией non-fPIC и потому прелинкована быть не может. У меня в дистрибутиве CRUX, установленном из прекомпилировыанных пакетов, в этот черный список попали все приложения KDE и некоторая, зато самая тяжелая, часть Иксовых. То есть именно те софтины, ради ускорения которых все и затевалось.
Выход тут, к сожалению, один, простой, но занудный: пересобрать все, что попало в список. И тут уж, разумеется, впредь не забывать, что любая программа, в выводе ./configure --help которой отмечается доступность опции --with-pic, должна конфигурироваться именно с ее участием (флаг -fPIC можно добавить в и список значений переменной CFLAGS). А после этого - повторить процедуру прелинкинга, уже - с неизменно превосходным результатом.
Да, пора поговорить о том, насколько этот результат превосходен (и стоит ли игра свеч вообще). Должен заметить, что первый мой опыт, проводившийся на базе Gentoo (и отраженный в соответствующей заметке), был несколько обескураживающим. Конечно, скорость первой загрузки приложений увеличилась - но далеко не в той степени, как было обещано на http://www.gentoo.org (а там угоджали примерно 50-процентным ускорением загрузки KDE и ее приложений). Однако повторение эксперимента (уже на базе CRUX) положение существенно выправило. Вышло так.
Саму по себе среду KDE я не использую очень давно (по ряду причин, на которых тут останавливаться невместно). Однако: а) я очень люблю некоторые KDE-приложения - в частности, konqueror, который отношу к числу лучших софтин всех времен и народов, и б) по долгу службы вынужден использовать некоторые KDE-приложения, аналогов в мире Open Sources не имеющие (например, kdem - программу визуализации данных цифровой картографии в одноименном формате). И загружаю я их из любимого оконного менеджера (а им давно и надолго стали представители семейства *box'ов). Так вот, меня всегда страшно раздражало то, как долго эти считанные приложения загружаются - ибо вслед за собой затягивают в память чуть не всю Qt с kdelibs (благо, еще не коран с шариатом, книгой тариката и всеми другими книгами).
Это было до прелинкинга. Что же стало после? На загрузку konqueror уходят неуловимые мгновения, kmail - аналогично, koffice - с OpenOffice даже смешно сравнивать, и так далее. Для пробы запустил саму KDE - время загрузки сопоставимо с оконными менеджерами средней степени тяжести (типа WindowMaker). Короче говоря, используйте прелинкинг - и будет вам счастье...
Конечно, без некоторых подводных камней и тут не обойтись. Я уже говорил, что для достижения этого счастья, очень возможно, потребуется перекомпилировать ряд программ (причем из числа самых времяемких). Далее, при обновлении (или просто пересборке) любой из библиотек, с которыми осуществлялось предварительное связывание каких-либо приложений, последние должны быть непременно также перекомпилированы (а процедура прелинкинга для них повторена - для того и нужна упоминаемая выше опция -f, принудительно форсирующая этот процесс). Однако, по моему скромному мнению, результат вполне окупает эти усилия.
Далее, на использование предварительного связывания накладываются некоторые ограничения. Так, после выполнения тотального прелинкинга могут отказаться работать программы, статически связанные с прелинкованными библиотеками. Благо, в нормальной Linux-системе таких или крайне мало, или нет вообще. И к тому же отказ их - отнюдь не обязателен. Так, я использую обычно текстовый редактор Nedit, статически слинкованный с библиотекой Lesstif. Так вот, хотя мой Lesstif перечислен в списке путей прелинкинга, никаких аномалий в работе Nedit'а не обнаруживается - он функционирует вполне справно.
Далее, предварительное связывание не может распространяться на бинарные файлы проприетарного происхождения, для которых исходники недоступны. Однако это обходится совсем просто: достаточно проследить, чтобы такие программы (а у меня в их числе - единственный RealPlayer, да и то лишь потому, что ни лучшего Алмазова, ни Алешковского не могу найти в человеческом формате) устанавливались бы в каталог /opt (что, к слову сказать, они обычно и делают). А каталог этот, понятно, не включать в описание путей в файле /etc/prelink.conf.
И, наконец, существуют программы, которые просто принципиально не желают подвергаться предварительному связывания (по крайней мере, на данном этапе софтостроения). В их числе - все, имеющие отношение к эмулятору wine. Так что ускорить выполнение "подоконных" софтин пока не удастся...
Заключительные замечания
К сожалению, я не взялся бы количественно оценивать вклад от каждого из описанных этапов Linux-оверклокинга в суммарное быстродействие системы. Однако кумулятивный эффект их всех - весьма велик. Я проводил эксперимент над дистрибутивом CRUX (повторяю, очень быстром изначально, без всяких оптимизирующих мероприятий вообще) и на двух машинах - Pentium4/1,9 и Pentium4/2,53 (прочие компоненты их были примерно одинаковыми). Так вот, субъективно на первом после полного курса тюнинга и твикинга система работала ничуть не медленее, чем на втором - до прохождения оного. Другое дело, что Pentium4/2,53 после после выполнения аналогичных мероприятий стал работать еще быстрее - но ведь излишнего быстродействия не бывает, не правда ли?
Приложения
Приложение 1. Стартовые скрипты и уровни выполнения
Runlevels - одно из тех понятий, которое достаточно сложно для понимания начинающего пользователя (эк загнул?). Дословный перевод этого термина - уровни выполнения, - способен только ввести его в заблуждение. Создавая впечатление, что система в процессе загрузки проходит некие уровни последовательно, подобно тому, как метагомы братьев Стругацких восходили от уровня к уровню (во всяком случае, у меня по началу была именно такая ассоциация). Правда, в некоторых стартовых схемах (например, в той, что принята в дистрибутиве Gentoo) так оно и есть: сначала на уровне boot загружаются все сервисы, необходимые в любом случае, затем, на уровне default - все дополнительные (при желании пользователь может опредедлить еще и дополнительные уровни выполнения для особых случаев, например, при работе с ноутбуком от сети или от аккумулятора - подробности можно посмотреть в переводной документации на www.gentoo.ru).
Однако в общем случае никакого восхождения от уровня к уровню при старте (и останове) системы не происходит. Потому что runlevels - это просто некие (более или менее фиксированные в данном дистрибутиве) наборы сценариев, исполняемых при вызове соответствующего runlevels. Не очень понятно? Надеюсь, станет яснее, после конкретного рассмотрения уровней.
Всего в Linux поддерживается 7 runlevels. Два из них - нулевой и шестой, - зарезервированы: ими описываются процессы останова (halt) и перезагрузки (reboot) системы, соответственно. Первый уровень, как правило (хотя это нигде не прописано жестко) отводится под т.н. однопользовательский режим, при котором отработки стартовых сценариев просто не происходит: грузится лишь ядро и монтируется (в режиме только для чтения) корневая файловая система. Этот уровень вызывается обычно при невозможности нормального старта системы.
А вот уровнями со 2-го по 5-й разработчики распоряжаются по собственному усмотрению. Обычно предусматриваются: нормальный многопользовательский режим, он же, но без поддержки сети, и режим авторизации в графическом режиме, то есть загрузки Иксов и какого-либо из login-менеджеров (xdm, kdm, gdm). Становится понятным, что набор сценариев для runlevel нормального многопользовательского режима должен предусматривать загрузку сетевых сервисов, а runlevel без поддержки сети обходится без них. Какие конкретно уровни выполнения задействованы в данном дистрибутиве, можно посмотреть в файле /etc/inittab.
Один из runlevel определяется (в том же файле /etc/inittab) как используемый по умолчанию (default - собственно, только с ним и имеет дело пользователь в обычной работе). Это обычно или уровень "нормального" режима, или уровень графического входа в систему (последнее характерно для user-ориентированных пакетных дистрибутивов). И вот именно набор стартовых сервисов, приписанных к "умолчальному" runlevel, и подлежит коррекции с целью освобождения от излишеств (или, напротив, дополнению необходимыми сервисами).
Приложение 2. О динамике и статике
Основа основ любой Unix-системы (в том числе и Linux) - не ядро, как можно было бы подумать, а библиотека функций языка Си (ибо большая часть любой Unix-системы на нем и написана). Библиотека - это просто набор подпрограмм для осуществления неких стандартных операций, используемых в большинстве системных и пользовательских программ (например, открытия, чтения и закрытия файла, его записи и так далее), написанных в свое время умными людьми и объединенными в единый комплекс, дабы другие умные люди не занимались изобретением велосипеда.
В Linux такой главной системной библиотекой выступает glibc (GNU Library C, хотя теоретически ее можно заменить любой аналогичной по базовым возможностям - в системах для встроенных устройств так и делается). Без ее использования практически не может функционировать ни одна программа (хотя многие из них требуют еще и библиотек дополнительных). А использование glibc возможно двоякое - статическое или динамическое.
При статическом связывании программы с библиотекой требуемые фрагменты последней просто встраиваются в код исполняемого бинарника. В результате скомпилированная программа обретает способность функционировать в системе, в которой glibc отсутствует как класс. Однако в отместку за это собранные статически программы разбухают в объеме и занимают больше места в памяти, причем используют его нерационально: ведь код для выполнения одной и той же стандартной функции (например, открытия файла), требуясь любой программе, многократно дублируется.
И потому во всех полнофункциональных дистрибутивах Linux применяется почти исключительно динамическая сборка программ. В этом случае требуемый программе код стандартной функции подгружается в память только при ее запуске. Причем, если такой код был загружен ранее другой программой - повторного его считывания из библиотеки не происходит. В результате исполнимые бинарники становятся меньше и эффективней используют память.
Материал для сравнения. Весь набор Base Linux, за исключением специальных случаев, всегда собирается динамически. А вот во FreeBSD долгое время была принята статическая сборка для тех программ из ее базы (Distributions), которые располагаются в подкаталогах /bin и /sbin корневого каталога. Делалось это для повышения надежности: в итоге корневой каталог оказывается способным существовать автономно, и, скажем, войти в систему и выполнить какие-либо спасательные действия можно даже при повреждении любых других ветвей файлового древа (в том числе и содержащих системные библиотеки). Хотя нынче )во FreeBSD 5-й верки) статически слинкованные бинарники размещаются в отдельном "аварийном" каталоге /restore, и вообще их сборка не обязательна.
Приложение 3. hdparm
Есть еще некоторые возможности для повышения производительности Linux, связанные с ее взаимодействием с железом. В частности, оптимизировать работу с дисками на физическом уровне можно с помощью утилиты hdparm. Если эту команду дать без опций и аргументов, она выведет справку по собственному использованию (которую, конечно, можно получить и из man hdparm). Легко догадаться, что использование hdparm требует минимум одного аргумента - имени файла дискового устройства (например, /dev/hda). А вот опции указывают, что именно с этим устройством надлежит сделать. В частности, опция -i выведет краткую, а опция -I - практически исчерпывающую информацию о диске (производителе, геометрии, емкости, доступных PIO- и DMA-режимах, и так далее). А с помощью опции -t можно протестировать наш диск на быстродействие (правда, только в отношении чтения). И, буде таковое покажется недостаточным, hdparm позволит принять меры по его повышению (правда, пользоваться этим надо осторожно - гарантий от повреждений данных никто не дает).
Самый очевидный шаг увеличение быстродействия диска - это включение DMA-режима командой hdparm -d 1 /dev/hda. А пользователям современных дисков современных дисков есть резон обратиться к режиму UMDA-66, что делается посредством hdparm -X66 /dev/hda. Правда, последнее, как говорят, может привести к нестабильной работе дисков - так что весь риск остается на вас.
Приложение 4. Файловые системы
Скорость обмена с диском - лишь одна составляющая быстроты исполнения файловых операций. Вторая же - это собственно файловая система, которая может быть быстрой или медленной. Опять-таки, радикальнейший способ разобраться с этим вопросом - выбрать при установке Linux самую быструю файловую систему. Вот только для этого хорошо бы знать, какая из файловых систем, поддерживаемых нынешним ядром, самая быстрая - существующие оценки вызывают противоречивые чувства. И к тому же быстродействие файловой системы существенно зависит от характера преобладающих данных.
Так, XFS, сверкающая, как метеор, при работе с файлами большого и очень большого размера, ведет себя не лучшым образом при изобилии мелких (сопоставимых с размером блока) файлов и файликов. ReiserFS же, напротив, ставит рекорды быстродействия именно на большом количестве мелких файлов, а вот с очень большими ведет себя весьма задумчиво.
Однако есть пара простых приемов ускорить работу любой из файловых систем. Простейший из них - использовать при монтировании опцию -o noatime. Давеча, выясняя вопрос о том, юзвери ли мы дрожащие, или право имеем, говорили о временных атрибутах файлов. Напоминаю, их три: ctime, или время изменения метаданных файла, mtime, или время модификации его внутреннего содержания, и atime, фиксирующее время последнего доступа к файлу. И если первые два атрибута весьма полезны, отражая некоторым образом время создания файла и его изменения, то ситуации, при которой на настольной машине потребуется знать atime, я себе представить не могу (на сервере, вероятно, этот атрибут может служить каким-нибудь целям безопасности). А времени на обновление atime для всех используемых (и юзером, и самой системой) файлов требуется немало. Так что если все файловые системы смонтировать с опцией -o noatime - быстродействия весьма прибавиться. А перманентно это можно сделать в файле /etc/fstab, заменив в соответствующем поле default на noatime.
Приложение 5. Проверка оборудования
Львиная доля времени при загрузке многих пакетных дистрибутивов, установленных по умолчанию, уходит на проверку нового оборудования. Однако если польза этого при первом запуске системы очевидна, то при последующих - весьма сомнительна. Ведь не каждый же день мы добавляем новые устройства, да и модель звуковой карты самопроизвольно, вопреки Ламарку, обычно не меняется.
Так что первый кандидат на удаление среди стартовых сервисов - это программа kudzu, именно проверкой нового "железа" и занимающаяся. К слову сказать, искоренение ее никак не повлияет на работу с устройствами горячего подключения, типа USB-драйвов или цифровых камер.
Приложение 6. Tmpfs
Некоторые часто требующиеся действия можно сильно ускорить, используя tmpfs - файловую систему в оперативной памяти. В отличие от "нормальных" (так называемых block devices based) файловый систем, она не скрывает собой никакого реального устройства, и потому не нуждается в создании. Если ядро собрано с ее поддержкой (а в большинстве пакетных дистрибутивов так оно и есть), то tmpfs готова к использованию сразу после монтирования – командой
$ mount -t tmpfs tmpfs /mount_point

В качестве штатной точки монтирования tmpfs выступает каталог /dev/shm. Однако это вызвано требования совместимости с Shared Memory стандарта POSIX, реально пока, насколько мне известно, не используемой. Так что можно подмонтировать ее ещу куда (воспользовавшись опцией -o bind команды mount, позволяющей получить доступ к одной и той же файловой системе (и даже ее ветви - сколь угодно глубоко вложенному подкаталогу) из разных точек монтирования.
И первейшим кандидатом для приложения будут каталоги типа /tmp или /var/tmp. В них можно не только разворачивать архивы исходников, но и выполнять полный цикл сборки. Время которой, по понятным причинам, весьма сократится. Для крупных пакетов, типа Иксов или KDE, выигрыш будет не столь уж значительным, а вот большое количество мелких откомпилируется просто со свистом.
Следует только помнить - все содержимое tmpfs безвозвратно исчезнет после перезагрузки. И еще: не монтируйте tmpfs в каталог /tmp при запущенных Иксах, результатом, скорее всего, будет крах X-сервера.
_________________
In My Humble Opinion
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Kristina17



Зарегистрирован: 29.01.2014
Сообщения: 2
Откуда: Москва

СообщениеДобавлено: Ср Янв 29 2014 23:27    Заголовок сообщения: Ответить с цитатой

Неплохо описано пишите еще

С уважением Кристина Задорожная
______________________________________

http://acnefine.ru/izbavlyaemsya-ot-ugrej-ispol-zuya-narodny-e-sredstva/
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Unix Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 6608306, ICQ 232284597
Пресс-релизы — pr@citforum.ru
Послать комментарий
Информация для авторов
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2006 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...