Сильно разрекламированное преимущество Linux -- то, что он более продуктивен, чем Microsoft® Windows® и потому будет лучше работать на менее современном оборудовании. Такая характеристика делает Linux очень привлекательным апгрейдом для многих людей, которые сидят со своими Windows 98 и больше не имеют возможности получать обновленное и улучшенное ПО (особенно обновления, касающиеся безопасности).

Правда, однако, в том, что так как ядро Linux можно настраивать, чтобы оно было достаточно маленьким и эффективным, то, поскольку выросла мощность новых компьютеров, многие десктоповые окружения Linux (такие как KDE и GNOME) приобрели много новых возможностей. В результате инсталляция по умолчанию большинства дистрибутивов дает менее высокий уровень работы при установке на более старом оборудовании. Это же справедливо для многих современных приложений -- Web браузеры типа Firefox и офисные модули вроде OpenOffice вполне полноценны, но попытка запустить их на машине с RAM 128MB может обернуться головной болью!

Так каков же ответ? Выкиньте все ваше старое железо и сделайте апгрейд? Установите дистрибутив Linux примерно 1995-го? (Если вы решите пойти таким путем, у меня, помнится, был удачный опыт с Linux-FT.)

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

Спасибо за память

В большинстве случаев единственный важнейший фактор для функционирования настольной операционной системы -- количество доступной системной памяти. Всегда хорошо иметь быстрый процессор, но если для его использования недостаточно физической памяти, система будет тратить все свое время, перетасовывая данные между физической памятью и свопингом (состояние, называемое пробуксовка), и CPU большую часть времени будет бездействовать. Поэтому для более старых систем обычно самый легкий путь улучшения работы -- добавить еще памяти. Однако есть много причин, почему это может быть невозможно, начиная с дефицита свободных слотов и заканчивая недостаточным количеством доступной RAM для некоторых систем (особенно лэптопов или систем, основанных на RAMBUS) и понятным нежеланием тратить деньги на устаревающую систему.

Если вы не можете или не хотите обновлять RAM, следующее, что стоит сделать -- уменьшить требования к RAM в системе. Эта статья предлагает пять простых шагов к нирване памяти для вашей линуксовой машины.

Шаг 1: Выберите правильное окружение рабочего стола

Единственный наиболее важный ваш выбор -- это дистрибутив Linux и окружение рабочего стола (ОРС), которое вы собираетесь установить. Несмотря на то, что это две отдельные категории, выбор дистрибутива может повлиять на выбор ОРС. Ничто не удержит вас от установки, скажем, Fluxbox на Ubuntu, однако, вы поймете, что жить будет значительно проще, если просто использовать окружение, которое поставляется с дистрибутивом по умолчанию.

По сценарию этой статьи основная цель -- найти простой, ориентированный на десктоп, дистрибутив, который будет понятен новичкам. Я начинал с Ubuntu 6.10, который поставляется с GNOME 2.16.

В качестве основы я выбрал старую машину с процессором 800MHz и 256MB RAM. Я выполню каждый из своих экспериментов дважды -- один раз, загрузившись нормально со всеми 256MB RAM, и еще раз с mem=128M в строке ядра, что заставит его распознать только 128MB физической памяти. Это фактически позволит мне проверить две машины с 256MB и 128MB, не задействуя вторую физическую машину (или опять-таки физически не вытаскивая чипы RAM и не возвращая их затем на место). Данная опция строки ядра дает довольно близкое приближение к поведению машины с 128MB, однако заметьте, что если у вас на самом деле только 128MB, вы можете столкнуться с дополнительными сложностями -- например, для Ubuntu вам придется использовать специальный установочный диск для машин с RAM меньше 192MB.

Чтобы получить базовый уровень использования памяти, я загрузил систему, зарегистрировался в графической среде и запустил терминал (дальше в статье я буду ссылаться на эту установку, как на мой базовый уровень); затем я проверил количество свободной памяти с помощью команды free, результат вы можете видеть в Листинге 1.

 
ubuntu # free
 total used free shared buffers cached
Mem: 255988 231704 24284 0 6432 139292
-/+ buffers/cache: 85980 170008
Swap: 746980 0 746980

Первая строка означает, что из 256MB памяти используется 231MB. В следующей строке показано, что хотя задействован 231MB, только 86MB из них на самом деле заняты приложениями; остальное используется для буферов и кэша.

Самая важная часть этого листинга для оценки работы -- строка Swap; она показывает, что мы в настоящее время своп не используем, это означает, что пока проблем с памятью нет. Система в состоянии поместить все в физическую память, не прибегая к медленному пространству свопинга на диске.

Далее, чтобы понять, как будет выглядеть система при нормальном повседневном использовании, я запустил Web браузер (Firefox 2.0) и зашел на developerWorks, подключил клиента программы обмена быстрыми сообщениями (Gaim) к MSN и воспользовался файловым менеджером, чтобы найти каталог и открыть умеренного размера документ Microsoft Word в OpenOffice. (Дальше в статье я буду называть такую установку уровень слабой загруженности.)

После того как все загрузится, вывод команды free будет выглядеть как в Листинге 2.

 
ubuntu # free
 total used free shared buffers cached
Mem: 255988 252196 3792 0 21276 87500
-/+ buffers/cache: 143420 112568
Swap: 746980 18676 728304

Вы можете видеть, что с памятью все стало немного хуже. Теперь приложения используют 143MB физической памяти, а остальное занято буферами; вдобавок, системе теперь требуется 18MB свопа. В общем система кажется вполне пригодной в условиях простых офисных задач, но без особого запаса, и я бы не хотел начинать делать что-либо с более серьезными запросами, например, редактировать большие цифровые фотографии или видео, так как система сразу начнет тормозить.

Чтобы понятьб как система будет работать со 128MB, я перезагрузился и добавил в строку ядра mem=128M, как было описано выше. В том же состоянии базового уровня, показанном в Листинге 1, со 128MB RAM я получил результаты, представленные в Листинге 3.

 
ubuntu # free
 total used free shared buffers cached
Mem: 126100 121464 4636 0 1636 37000
-/+ buffers/cache: 82828 43272
Swap: 746980 17924 729056

Можно заметить, что с этими 128MB, я уже залез в своп, фактически не начав ничего делать.

Запуск моего простого набора приложений привел к результатам, показанным в Листинге 4.

 
ubuntu # free
 total used free shared buffers cached
Mem: 126100 123608 2492 0 392 51208
-/+ buffers/cache: 72008 54092
Swap: 746980 98452 648528

Как вы, наверное, можете предположить по этим числам, машина стала теперь значительно менее чуткой при нормальном использовании -- она все еще пригодна для выполнения этих простых задач, но частота обращений к диску очень велика и я, конечно, не стал бы использовать ее в качестве своей основной машины. Можете посмотреть, что полное количество необходимой приложениям памяти составляет приблизительно 170MB, но только 72MB помещается в физическую память, а 98MB отправляется в своп. Это объясняет недостаток скорости реакции системы!

Для следующей серии экспериментов я решил использовать Xubuntu, дистрибутив из проекта Ubuntu. Этот дистрибутив в точности такой же, как и Ubuntu, но вместо GNOME использует ОРС Xfce 4.4 Beta 2. В отличие от большинства известных проектов GNOME и KDE, которые концентрируются на максимуме функциональности, Xfce создан быть легковесным, поэтому он, будем надеяться, больше подойдет для устаревшего оборудования. Этот дистрибутив мы протестируем так же, как Ubuntu.

В Листинге 5 можно видеть, что базовое ОРС использует приблизительно на 25MB меньше памяти, используемой приложением, а также значительно меньше тратит на буферы и кэш (что может означать меньшую активность файлов), чем Ubuntu.

 
xubuntu # free
 total used free shared buffers cached
Mem: 
 255988 170964 85024 0 6004 104700
-/+ buffers/cache: 60260 195728
Swap: 746980 0 746980

В Листинге 6 мы снова запустили наш набор тестовых приложений (Web браузер, клиент IM и текстовый редактор). Видно, что использование памяти где-то на 20MB меньше, чем требуется Ubuntu для тех же приложений (126 физической памяти и 17 свопинга из 143 против 143 + 18 из 161).

 
xubuntu # free
 total used free shared buffers cached
Mem: 255988 252180 3808 0 1972 124008
-/+ buffers/cache: 126200 129788
Swap: 746980 16956 730024

Листинг 7 иллюстрирует базовый уровень при наличии только 128MB RAM. Моя система с ограничением памяти в этот раз гораздо счастливее -- пока что не используется своп.

 
xubuntu # free
 total used free shared buffers cached
Mem: 126100 123228 2872 0 4252 60484
-/+ buffers/cache: 58492 67608
Swap: 746980 0 746980

В Листинге 8 мы снова запускаем приложения. Системе по-прежнему гораздо лучше, чем в Ubuntu, но она все-таки использует заметное количество свопа и немного тормозит (хотя меньше, чем в той же ситуации под Ubuntu).

 
xubuntu # free
 total used free shared buffers cached
Mem: 126100 123980 2120 0 468 56276
-/+ buffers/cache: 67236 58864
Swap: 746980 64516 682464

Как можно понять из этих чисел, Xubuntu в общем использует меньше памяти во всех случаях; так что если доступно только 128MB (или меньше), это будет, возможно, хорошим выбором для вашей системы.

Один важный момент, касающийся дистрибутивов Linux -- они обычно ничего не стоят, поэтому несложно будет скачать несколько, попробовать и понять, какой вы предпочитаете, и как они все работают на вашем железе. Если у вас совсем плохо с оборудованием, вы, может быть, захотите посмотреть на дистрибутив типа Damn Small Linux, который должен работать на системах с такими низкими характеристиками, как процессор 486DX и 16MB RAM.

Поскольку у меня есть еще немного живого пространства в моей 256MB системе, и я, в общем-то, KDE-шник, я продолжил экспериментировать с другой производной Ubuntu под названием Kubuntu, которая основывается на KDE и выглядит чем-то средним между Xubuntu и Ubuntu, если говорить об использовании памяти. Чтобы вы могли сравнить, Листинг 9 иллюстрирует базовое использование Kubuntu.

 
kubuntu # free
 total used free shared buffers cached
Mem: 255988 244736 11252 0 7612 160008
-/+ buffers/cache: 77116 178872
Swap: 746980 0 746980

Шаг 2: Выберите подходящие приложения

После того как вы выбрали дистрибутив, следующее, что можно рационализировать, это набор используемых приложений. Требования к памяти могут сильно разниться у разных приложений; где-то придется идти на компромисс между размером и функциональностью, а в некоторых случаях даже одинаковые по возможностям приложения будут иметь очень разные потребности в памяти.

В этой статье для измерения использования памяти я буду применять инструмент exmap. Это более точная программа, чем ps или top, потому что она учитывает библиотеки, используемые совместно многими приложениями. Например, если два приложения используют одну и ту же разделяемую библиотеку, которая забирает 1MB памяти, ps скажет, что каждое приложение использует 1MB, а exmap более корректно покажет по 500 KB в каждом приложении. Большая точность особенно важна при оценке окружений рабочего стола, таких как KDE и GNOME, которые очень активно используют библиотеки, разделяемые между приложениями.

Для каждого из приложений, которые мы обсудим в следующих разделах, я измерил резидентное и эффективное резидентное значения, выданные программой exmap. Резидентное значение представляет из себя полное количество физической памяти занятое процессом, включая разделяемые библиотеки, которые используются, в том числе, другими процессами, и обычно именно его можно ожидать на выходе ps или top. В эффективном резидентном значении разделяемые библиотеки поделены поровну между процессами, которые их используют; это гораздо более точное представление системной памяти, потребляемой процессом.

Заметьте, что при определении полной памяти, занятой процессом, вы также должны учесть отображаемое и эффективное отображаемое значения, которые являются частями процесса, помещенного в своп. Отображаемые значения аналогичны резидентным, но скорее для страниц в свопе, нежели в физической памяти. Так что для получения картины, в которой разделяемые библиотеки не скомпенсированы, вы должны сложить резидентное и отображаемое значения; для случая, когда разделяемые библиотеки компенсируются, складывать надо эффективные резидентное и отображаемое значения. Я не записывал эти значения в приведенные дальше таблицы, потому что во всех моих тестах ни один процесс не попадал в своп, так что в выводе команды exmap были нули в соответствующих колонках.

Web браузеры

В каждом браузере из Таблицы 1 я открывал домашнюю страницу developerWorks и ждал, пока она полностью загрузится. Результаты приведены в Таблице 1.

По этой таблице видно, что разброс в используемой памяти очень велик, самый жадный до памяти браузер (Firefox) занимает примерно в 27 раз больше, чем самый скромный (Lynx). Это не вполне честное сравнение, так как Lynx на самом деле не является эквивалентом по функциональности (он даже не отображает графику, например), но оно показывает, что в зависимости от требований вы можете заметно сократить использование памяти. Даже среди первых трех браузеров, перечисленных в Таблице 1, которые более или менее равны по возможностям, Opera использует примерно две трети, а Konqueror меньше половины от количества памяти, нужной Firefox'у.

При скромных требованиях к функциональным возможностям Dillo может стать хорошим компромиссом между полностью укомплектованным браузером и аскетичным Lynx'ом. Dillo предоставляет GUI; он, однако, в известной степени ограничен в состоянии по умолчанию и даже не поддерживает SSL без дополнительного плагина!

Обратите также внимание, что когда мы сравниваем совместное использование памяти, Konqueror представляется намного лучше Firefox'а, поскольку занимает примерно на 14MB меньше памяти; однако, если мы посмотрим на полное использование, то хотя Konqueror все еще лучше, чем Firefox, но уже не настолько -- только на 5MB или около того. Это происходит из-за того, что Konqueror активно пользуется разделяемыми библиотеками KDE, которые также задействованы во многих приложениях, поскольку я работаю в среде KDE. Если бы я не запускал никаких других приложений KDE, Opera стала бы лучшим выбором, чем Konqueror. Более подробно этот вопрос мы обсудим позже.

Текстовый редактор

Для проверки текстовых процессоров я открыл тот же документ формата Microsoft Word, что и в моем первом тесте, в редакторах, перечисленных в Таблице 2.

Из этих чисел ясно видно, что OpenOffice Writer потребляет гораздо больше памяти, чем KWord или AbiWord. После OpenOffice KWord правильнее всех распознает документ, отформатированный в Microsoft Word. Хотя AbiWord смог успешно открыть документ, возникло несколько проблем с корректным его отображением, поэтому, если вам важна совместимость с Microsoft Office, то лучше держитесь редактора OpenOffice.

Клиент программы обмена быстрыми сообщениями

Для тестирования программы обмена быстрыми сообщениями (IM) я вошел со своей учетной записью в мой MSN Messenger при помощи клиентов IM, перечисленных в Таблице 3.

Здесь лучшим оказался Kmess, и это оправданно, поскольку меня интересовало подключение только к MSN. Если вам нужны другие сервисы, тогда, похоже, больше всего подойдет Kopete. Заметьте однако, что потребление памяти приложениями может возрасти, если вы используете другие протоколы IM; кроме того, Kmess встроен в KDE, поэтому если у вас не KDE, то возможно, лучшим выбором будет Gaim.

Намыльте, смойте, повторите

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

Как вы, должно быть, заметили в разделе про Web браузеры, и обычно так оно и есть на самом деле, лучшее сохранение памяти обусловлено тем, что используемое приложение намертво встроено в окружение рабочего стола. Это происходит оттого, что такие приложения активно используют разделяемые библиотеки, которые внедрены в ОРС и, вероятнее всего, уже загружены. Например, Konqueror -- это и файловый менеджер KDE, и Web браузер; в результате, в KDE он использует значительно меньше памяти, чем Firefox, потому что большая часть его функций уже загружена другими приложениями. Точно так же, если вы хотите использовать agregator RSS, хорошим выбором может стать Akregator, так как опять-таки он, вероятно, будет пользоваться теми же самыми библиотеками.

Таким образом, если вас заботит использование памяти, важно провести все эти тесты на вашей системе, поскольку обычно, просто посмотрев на исходные условия других людей, тяжело понять, какое приложение будет занимать меньше памяти в системе.

Этот факт может иметь значение для выбора ОРС. Если вы действительно хотите использовать Konqueror, например, то, наверное, целесообразно в качестве ОРС взять KDE. Аналогично, если вы пользователь GNOME, то, возможно, подумаете дважды, прежде чем выбрать это простое маленькое приложение KDE, на которое вы положили глаз, так как оно вероятно загрузит уйму нужных только ему одному библиотек.

Шаг 3: Удалите ненужные сервисы и установки

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

Хорошее место для начала -- сервисы, которые запускаются автоматически при загрузке системы -- впрочем, здесь нужно быть осторожным, чтобы не удалить что-то, что необходимо для ее работы. Вам потребуется провести некоторое исследование того, что необходимо конкретно вашему дистрибутиву и как там настроены сервисы, потому как эти вещи зависят от дистрибутива. В тех, что похуже, запускают по умолчанию кучу ненужных сервисов, таких как Web сервисы и так далее, а это съедает память.

Кроме сервисов системы вы, возможно, захотите взглянуть на то, как сконфигурировано ОРС -- здесь тоже могут запускаться ненужные сервисы.

Мой Kubuntu, похоже, не запускает слишком много лишнего, но беглый взгляд на список процессов показал несколько очевидных вещей, которые я мог удалить:

• HPLIP (4.4MB): Сервисы для принтеров и сканеров HP. Не нужны, так как к этому компьютеру такие устройства не подключены.
• cupsd (1.1MB): Демон печати. Не нужен, так как этот компьютер без принтера.
• kbluetoothd (3.2MB): Демон KDE Bluetooth. Не нужен, так как у этого компьютера нет возможности подключения Bluetooth.
• klipper (1.7MB): Утилита для работы с буфером обмена в среде KDE. Меня не заботит именно эта программа, поэтому я ее отключил.
• KMix (4.1MB): Звуковой микшер KDE. Нет необходимости, чтобы он работал все время, поскольку я настраиваю громкость посредством внешних колонок.

Всего пять минут, потраченных на настройку, сберегли около 14MB памяти -- не плохо для отправной точки около 77MB!

Стоит покопаться в настройках вашего ОРС, а также больших приложений, так как параметры некоторых из них могут повлиять на размер используемой памяти. Например, сохранить немного памяти можно, уменьшая количество виртуальных десктопов, особенно, если в качестве фона используются растровые изображения. Также может помочь отключение некоторых причудливых красивых эффектов.

Шаг 4: Имейте адекватные ожидания

Работая с устаревшим оборудованием, важно понимать ограничения машины и работать адекватно. Например, если вы хотите редактировать коллекцию фотографий, не открывайте их все одновременно. Это только неоправданно съест память. Будет гораздо легче, если открывать и закрывать их одну за другой. Точно так же, если вы пытаетесь ввести и отредактировать видео, подумайте о том, чтобы вводить отдельные сцены, а не все скопом; и если вы создаете большой документ, который будет содержать иллюстрации, не добавляйте их, пока не разберетесь с текстом.

Шаг 5: Оптимизируйте свою систему

Последний шаг -- заглянуть в глубины системы и понять, можете ли вы еще откуда-нибудь наскрести хоть немного памяти. Есть много возможностей, но начинает действовать закон сокращающихся доходов, и для многих людей количество головной боли и трудов не будет того стоить. Тем не менее, можно кое-что принять во внимание:

• Перекомпилируйте ядро только с конкретными драйверами для вашего оборудования. Большая часть распространенных дистрибутивов создается для широкого спектра аппаратных средств, поэтому часто включает в себя поддержку большого ряда устройств, которыми вы не пользуетесь. Это может быть преимуществом, хотя удобнее, когда большая часть поддержки оборудования представлена в виде модулей, которые не загружаются, если не требуется.

• Немного памяти также можно выиграть перекомпиляцией конкретных приложений или библиотек так, чтобы оптимизировать их по размеру и нацелить именно на ваш CPU. Для этого идеально подходит дистрибутив Gentoo, так как позволяет легко перекомпилировать часть или всю систему с выбранными вами для компиляции флагами. К сожалению, на старой машине это, вероятно, будет длительным процессом.

• Перекомпиляция приложений и библиотек с удалением конкретных функций также может снизить их требования к памяти. Опять-таки Gentoo -- хорошая идея, потому что он включает в себя концепцию флагов USE, которые позволяют легко собрать систему с отключенными функциями приложений. Размеры приложений можно значительно уменьшить таким образом -- приложения обычно выпускаются с поддержкой большого количества форматов файлов, кодеков и так далее, которые зачастую загнаны в библиотеки для обеспечения полной поддержки. Если вы знаете, что никогда не захотите прочитать, скажем, файл JPEG, то можете указать это в Gentoo (посредством USE="-jpeg"), и любое приложение, которое имеет дело с графикой, скомпилируется без поддержки JPEG и, скорее всего, потребует меньше памяти.

• Последние ядра 2.6 имеют параметр swappiness, который можно менять в процессе работы. Этот параметр определяет вероятность того, что приложение будет перемещено в своп вместо того, что будет уменьшен размер кэша или буферов -- мы видели в предыдущих тестах, что обычно приложения помещаются в своп, в то время как большие объемы физической памяти зарезервированы под кэш. Уменьшив стремление выгружать все в своп, можно добиться того, что кэш будет уменьшен и больше приложений, вероятно, останутся в памяти. Однако станет ли машина работать быстрее от этих перемещений или нет, во многом зависит от приложений, которыми вы пользуетесь. Может показаться, что машина быстрее реагирует, если вы постоянно переключаетесь между приложениями, потому что они, скорее всего, будут размещаться в памяти; однако, если у вас есть задача, которая много читает и записывает на диск, тогда, вероятно, компьютер затормозится. В общем, уменьшение swappiness сделает вашу систему более быстро реагирующей для диалоговых приложений, но замедлит полную пропускную способность.
  

Идеи из этой статьи могут помочь вдохнуть жизнь (и немного дополнительной безопасности) в ваши старые машины и улучшить использование Linux на стареющем оборудовании. Измерения показывают, что машина с 800-MHz/256-MB может приютить совершенно приемлемый десктоп Linux для легких офисных и домашних нужд, таких как e-mail, хождение в Интернет, редактирование текста и так далее. Немного подстройки и эксперимента и даже машина со 128MB сможет служить достаточно удобным персональным компьютером.

Хотя основной целью данной статьи было достичь функционального десктопа на довольно ограниченном оборудовании, те же принципы вы можете применить ко многим областям использования Linux. Независимо от того, сколько памяти у вашей новейшей супер-машины, вы вскоре найдете новые приложения, чтобы заполнить ее. Применяя эти методы, вы сможете выжать немного больше из своих перегруженных серверов или получите некоторое понимание, как используют память ваши собственные приложения.