Автоматическая загрузка модулей ядра

После установки VirtualBox, столкнулся с проблемой запуска виртуальной машины. При запуске ВМ ругалась на незагруженный модуль ядра vboxdrv. Можно, конечно, загрузить модуль и вручную:

# modprobe vboxdrv

Но каждый раз делать так ручками, оказывается, лениво, да и модуль мониторинга температуры тоже автоматом не подключался. Поэтому встал вопрос: а как подгружать модули ядра при загрузке системы?

А нужно всего лишь отредактировать файл /etc/conf.d/modules

# nano /etc/conf.d/modules

и дописать в переменную modules требуемые модули ядра (vboxdrv и it87 в моем случае)

modules="vboxdrv it87"

Рецепт решения ошибки компиляции ядра из-за bfq

При попытке установить очередное ядро (версии 3.10.9), компиляция прервалась с ошибкой:

make[1]: *** Нет правила для сборки цели `block/bfq-iosched.o', требуемой для `block/built-in.o'.  Останов.
make: *** [block] Ошибка 2

Решение нашлось довольно быстро и оказалось довольно простым. Эти самые правила для сборки находились не там, где должны быть. Поэтому переходим в каталог с исходниками ядра:

# cd /usr/src/linux-3.10.9-calculate/

И уже оттуда копируем нужные файлы в нужное место:

# cp b/block/bfq* block/

Пробуем компилировать ядро - все в порядке, по крайней мере с bfq.

Черезмерное выделение памяти (overcommit)

Overcommit - стратегия выделения памяти, когда операционная система разрешает приложениям занимать больше виртуальной памяти, чем доступно в системе.

Сейчас в ядре два параметра, отвечающих за overcommit памяти:

vm.overcommit_memory (/proc/sys/vm/overcommit_memory) — отвечает за стратегию overcommit
vm.overcommit_ratio (/proc/sys/vm/overcommit_ratio) — отвечает за уровень в процентах overcommit

Стратегии у vm.overcommit_memory могут быть три:

OVERCOMMIT_ALWAYS (значение выставлено в 1) — ядро всегда удовлетворяет любые запросы на выделение памяти. Реально страницы памяти будут выделяться при первом обращении к ним.
OVERCOMMIT_GUESS (значение 0) — эвристический подход к распределению памяти. Используется по умолчанию, ибо подходит для большинства задач. Система будет отвергать только запросы, которые в принципе не могут быть удовлетворены, остальные — удовлетворять вне зависимости от наличия свободной памяти. На деле практически не отличим от OVERCOMMIT_ALWAYS.
OVERCOMMIT_NEVER (значение 2) — работа вообще без overcommit. Полный объём памяти, исходя из которого будут удовлетворяться или отвергаться запросы на выделение памяти, вычисляется как total_swap + total_ram * overcommit_ratio / 100. Значение параметра vm.overcommit_ratio имеет значение только при этой стратегии. Таким образом, при overcommit_ratio < 100, система всегда будет выделять память только если она подкреплена реальными страницами в ОЗУ или свопе. При overcommit_ratio > 100 мы получаем режим, схожий с OVERCOMMIT_GUESS, но с явно установленным «ограничителем».

Стоит заметить, что операционная система всегда резервирует около трех процентов памяти для процессов пользователя root.

Политики OVERCOMMIT_GUESS и OVERCOMMIT_ALWAYS приводит к ситуациям, когда суммарный размер виртуальной памяти приложений может намного превосходит реально имеющийся объем ОЗУ и свопа. В теории, когда реальная память заканчивается, в Linux срабатывает OOM Killer, убивающий лишние, самые «невыгодные» с точки зрения ядра, процессы. На практике же, OOM Killer отрабатывает далеко не всегда: система может уйти в длительный лаг или зависнуть.

Установим режим выделения памяти не больше, чем есть (OVERCOMMIT_NEVER), по умолчанию стоит выделять сколько запросит процесс (OVERCOMMIT_GUESS):

# sysctl vm.overcommit_memory=2
# sysctl vm.overcommit_ratio=80
Значение параметра vm.overcommit_ratio по-умолчанию равно 50. Чтобы изменения сохранились после перезагрузки пишем:

# echo 2 > /proc/sys/vm/overcommit_memory
# echo 80 > /proc/sys/vm/overcommit_ratio

Однако при этих параметрах появились случаи, когда браузер вдруг начинал дико свапироваться на диск, а потом обратно в память - система при этом сильно тормозила.

Удаление старых ядер

Если вы хотябы раз в неделю обновляете систему, то имеете большое количество старых версий ядра, которыми чаще всего не пользуетесь. Имеет смысл иметь в запасе возможнось загрузить предыдущую (рабочую) версию ядра, если на новом ядре что-то перестало работать. Но когда их собирается 5 - 10 штук, тогда имеет смысл подумать о том, как бы почистить ситтему от мусора. И здесь оказывается не все просто, потому что каких-то штатных средств для этого не предусмотрено. Но решение есть и оно довольно несложное - несколько команд в консоли от рута.

Первым делом нужно почистить систему от мусора, т. е. не только от старых версий ядра, но и от ненужных пакетов (которые ставились по зависимостям и остались после удаления других пакетов):

# emerge -ac

Эта команда выведет список подлежащих удалению (по мнению команды) пакетов. Если вы найдете в этом списке используемые вами программы, то просто внесите их в файл /var/lib/portage/world, чтобы emerge не пытался в будущем удалить их, после чего перезапустите команду emerge -ac и согласитесь с предложением. Например, чтобы занести в /var/lib/portage/world программу media-video/mplayer нужно выполнить команду:

# echo media-video/mplayer >> /var/lib/portage/world

Команда emerge -ac удаляет только пакеты программ, но не трогает установленные в систему ядра и их модули. Вот для этой цели и нужны дополнительные телодвижения. Нужно удалить исходники старых ядер. Например, для удаления всех ядер ветки 3.5 нужно выполнить следующее:

# rm -rf /usr/src/linux-3.5.*

а затем удалить директорию с модулями этих ядер:

# rm -rf /lib/modules/*3.5.*

Если у вас каталог /boot на отдельном разделе (обычно небольшого размера 100 - 500 MB), то большое количество старых ядер может помешать установке нового (тупо не хватет места). Это, наверное, является главной причиной для чистки старых ядер. Поэтому удаляем ненужные файлы из каталога /boot:

# rm -rf /boot/*3.5.*

Неиспользуемые версии ядер удалены, но при загрузке все они как-бы доступны. Чтобы исправить это недоразумение нужно обновить конфиг загрузчика Grub, выполнив команду:

# grub-mkconfig -o /boot/grub/grub.cfg

которая заново создаст файл /boot/grub/grub.cfg и запишет туда все существующие ядра и обнаруженные ОСи.

Гибернация в Calculate Linux

Возвращаемся к теме спящего режима под Linux. После установки дистрибутива CLD Calculate Linux я столкнулся с проблемой неработоспособности спящего и ждущего режимов. А именно: комп как-будто бы уходил в сон, но при попытке просыпания тупо зависал не реагируя ни на какие мои действия (кроме, конечно, кнопочки перезагрузки на системнике :-)).

Все эти неприятности продолжались до обновления ядра до версии 3.6.6. Методом проб и ошибок была выявлена причина - ветка ядра 3.5 как-то хреново работает с питанием. По крайней мере 4 редакции были протестированы в процессе обновлений - все корявые. Конечно же правка ядра мне пока не под силу, поэтому я сильно порадовался переходу на ветку 3.6.

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

В Calculate для управления питанием используется pm-utils - набор скриптов для взаимодействия с подсистемой управления питанием ядра. Коллекция скриптов свободно модифицируема и позвляет довльно тонко управлять как всей системы так и отдельных модулей. Но в моем случае всех этих тонкостей не понадобилось. А понадобилось найти основной умолчальный конфиг - /usr/lib/pm-utils/defaults и отредактировать его изменив (или добавив) одну строчку:

# nano /usr/lib/pm-utils/defaults

Оказалось достаточным раскоментировать одну строчку, со вполне понятным названием:

HIBERNATE_MODE="shutdown"

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

Мне кажется странным выбор умолчального местоположения конфига, тем более, что в каталоге /etc/pm/config.d/ могут быть расположены дополнительные файлы конфигурации. Но разрабам, конечно же, виднее :-)

По этой ссылке расположено чуть более подробное описание pm-utils.

Оптимизация подкачки

Работая в Linux я заметил, что раздел подкачки используется в том же объеме как и оперативная память. И это не смотря на то, что оперативной памяти еще много( приблизительно половина от имеющейся). Тогда у меня возник вопрос: как на это можно повлиять? Ну а то, что повлиять можно, я не сомневался - это же Линукс и здесь все можно настроить.

Вообще-то я не сильно заморачивался по этому поводу пока не встретил на форуме интересное замечание. Там была рекомендация выставить значение параметра vm.swappiness=10.

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

Значения параметра swappiness - это число от 0 до 100. Значение 0 означает, что своп не будет использован, пока физическая память не заполнится до предела. Значение 100 заставляет ядро агрессивно свопировать процессы на диск.

Чаще всего значение параметра по умолчанию устанавливается равным 60. Значение равное 10 представляется мне более оптимальным. А теперь о том, как это значение выставить.

Для начала узнаем каково же значение параметра выставленное по умолчанию:

# cat /proc/sys/vm/swappiness

Для того, чтобы установить значение параметра, открываем из под учетной записи root на редактирование файл /etc/sysctl.conf:

# nano /etc/sysctl.conf

и добавить в него строку:

vm.swappiness=10

После перезагрузки значение параметра изменится на указанное нами. Чтобы изменить значение до перезагрузки необходимо выполнить (под root) следующую команду:

# sysctl vm.swappiness=10

Указанные операции должны пойти на пользу повышению быстродействия среднестатистическому компьютеру.

Отключение IPv6 в ядре Debian Linux

Занимаясь настройкой шлюза на Debian машине ко мне пришло понимание, что у меня присутствует лишняя функциональность в виде поддержки протокола IPv6. Заметок в интернете по этому поводу существует довольно много, но все-таки и я решил внести свою лепту.

Итак цель - отключить поддержку IPv6 в ядре Linux. Способ подходит для владельцев ядер 2.6.31 и выше. В этих ядрах предусмотрена возможность отключить IPv6 опцией при загрузке. Однако сначала необходимо убедиться что IPv6 включен. Пишем в консоли под root'ом:

# ifconfig | grep inet6

Если указанная команда ничего не вывела на экран, значит IPv6 у вас не используется, иначе читаем далее.

Если у вас установлен загрузчик GRUB Legacy(не прогрессивный но понятный), то в конфигурационном файле /boot/grub/menu.lst в опциях загрузки ядра дописываем ipv6.disable=1.

Если же вы счастливый обладатель прогрессивного загрузчика GRUB2, тогда идем в /etc/default/grub и ищем строку с опциями загрузки ядра по умолчанию (что-то вроде "quiet splash"). Дописываем к имеющимся опцию ipv6.disable=1.
Затем запускаем от root'а:

# update-grub

Затем перезагружаем компьютер и проверяем настройки с помощью утилиты ifconfig. В выводе не должно быть IPv6 адресов. 
Еще один способ проверки:

# netstat -npl | grep -E "tcp6|udp6" | wc -l

Если в выводе команды "0", значит все в порядке и IPv6 отключен.