Параметры загрузки ядра linux

Обновлено: 02.07.2024

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

Список аргументов

Аргументы командной строки ядра преобразуются в список строк (параметров загрузки), разделённых пробелами. Большая часть аргументов имеет вид:

где «имя» — уникальное ключевое слово, используемое для определения части ядра, которой передаются указанные значения (если есть). Обратите внимание, что ограничение в 10 значений действительно существует, так как код, используемый в данный момент, обрабатывает только 10 разделённых запятой параметров на одно ключевое слово. Тем не менее, в особых случаях вы можете указать одно ключевое слово ещё раз, с помощью 10-и дополнительных параметров (если это позволяет функция настройки).

Большая часть обработки выполняется кодом из файла ядра init/main.c. Сначала ядро проверяет, является ли аргумент одним из специальных аргументов «root=», «nfsroot=», «nfsaddrs=», «ro», «rw», «debug» или «init». Назначение этих специальных аргументов объясняется ниже.

Все параметры, указанные в виде «foo=bar» и не распознанные как обращения к функциям настройки (см. выше), считаются переменными окружения. Например, как аргумент загрузки можно указать «TERM=vt100».

Все остальные аргументы, не обработанные ядром и не считающиеся переменными окружения, затем будут переданы PID 1 (обычно, это программа init(1)). Наиболее часто встречающийся аргумент, передаваемый процессу init, — слово «single», указывающее, что система должна быть загружена в однопользовательском режиме, в котором не запускаются какие-либо службы. Более подробная информация об аргументах приведена в руководстве по установленной в системе версии init(1).

Общие аргументы загрузки, не относящиеся к настройке устройств

«init=…» Задаёт начальную команду, запускаемую ядром. Если этот параметр не задан или программа не найдена, то ядро попробует запустить /sbin/init, затем /etc/init, затем /bin/init, затем /bin/sh. Если не удалось запустить ни одну из указанных программ, то ядро переходит в режим «паники». «nfsaddrs=…» Задаёт адрес загрузки с NFS. Используется при загрузке системы по сети. «nfsroot=…» Задаёт корневую файловую систему NFS. Если эта строка не начинается с «/», «,» или цифры, то перед ним будет вставлена строка «/tftpboot/». Этот параметр используется при загрузке системы по сети. «root=…» Этот аргумент указывает ядру, какое устройство должно быть использовано в качестве корневой файловой системы. Значение по умолчанию этого параметра устанавливается при сборке ядра и, как правило, совпадает с устройством, на котором была расположена корневая файловая система во время сборки. Для использования в качестве устройства с корневой файловой системой, к примеру, второго дисковода, следует указать «root=/dev/fd1».

Корневое устройство может быть указано как в символьном, так и в числовом виде. Символьное представление имеет вид /dev/XXYN, где XX означает тип устройства (например, «hd» — для совместимых с ST-506 жёстких дисков, при этом Y принимает значения от «a» до «d»; «sd» — для совместимых со SCSI дисков, при этом Y принимает значения от «a» до «e»), Y — буква или номер устройства, а N — номер (в десятичной системе счисления) раздела на этом устройстве.

Заметим, что в данном случае речь не идёт о конкретном назначении этих устройств в файловой системе. Приставка «/dev/» — это всего лишь дань соглашениям.

Также применяется менее удобный и менее совместимый способ указания устройств с помощью чисел в формате «старший/младший номер» (например, старший номер /dev/sda3 равен 8, младший равен 3, и устройство можно указать как «root=0x803»).

'rootdelay=' В этом параметре указывается задержка (в секундах) перед попыткой смонтировать корневую файловую систему. 'rootflags=. ' В этом параметре указывается строка параметров монтирования корневой файловой системы (смотрите также fstab(5)). 'rootfstype=. ' Параметр «rootfstype» указывает ядру смонтировать корневую файловую систему, как если бы она была задаваемого типа. Это может быть полезно (как пример) при монтировании файловой системы ext3 как ext2 и затем удалении журнала в корневой файловой системе, что, фактически, превращает ext3 в ext2 и для этого не нужно загружать машину с другого носителя. «ro» и «rw» Параметр «ro» указывает ядру монтировать корневую файловую систему «только для чтения» для того, чтобы программа проверки целостности файловой системы (fsck) могла работать с не изменяющейся файловой системой. Ни один процесс не может записать данные в файл, находящийся в данной файловой системе до тех пор, пока она не будет «перемонтирована» для чтения/записи, например, командой «mount -w -n -o remount /» (см. также mount(8)).

Параметр «rw» указывает ядру монтировать корневую файловую систему в режиме для чтения/записи. Он используется по умолчанию.

'resume=. ' Указывает ядру где расположены данные suspend-to-disk, которые вы хотите использовать для возобновления работы машины при выходе из состояния сна. Обычно совпадает с расположение раздела или файла подкачки. Пример:

«reserve=…» Этот параметр используется для защиты от тестирования определённых областей ввода/вывода. Команда должна быть задана в следующем виде:

В некоторых машинах драйверы неправильно определяют аппаратное обеспечение или вызывают некорректную реакцию на тестирование определённых областей. В этих случаях может появиться необходимость предотвратить проверку (автоопределение) таких устройств.

Данный параметр загрузки служит для указания определённой области портов ввода/вывода, которую не нужно тестировать. Драйвер устройства не будет проверять указанную область, если только другой параметр явно не указывает на необходимость их проверки.

Например, загрузочная строка

предотвращает проверку адресов 0x300-0x31f всеми драйверами устройств, кроме «blah». «panic=N» По умолчанию, ядро не будет перезагружаться после паники, однако этот параметр заставит ядро перезагрузиться через N секунд (если N больше 0). Время до перезагрузки может быть также изменено командой

«reboot=[warm|cold][,[bios|hard]]» Начиная Linux 2.0.22 по умолчанию используется «холодная» (cold) перезагрузка. Возможно вернуть старое значение (warm) по умолчанию с помощью «reboot=warm» («холодная» перезагрузка может понадобиться для сброса аппаратного обеспечения, однако, она может уничтожить данные дискового кэша. «Теплая» перезагрузка может быть несколько быстрее). По умолчанию перезагрузка производится аппаратными (hard) средствами, а именно запросом контроллеру клавиатуры команды на установку низкого уровня линии сброса. Однако точно существует, по меньшей мере, один тип материнских плат, на которых этот способ не работает. При указании параметра «reboot=bios» перезагрузка будет осуществляться путем перехода в BIOS. «nosmp» и «maxcpus=N» (Только, если определён __SMP__.) Параметры загрузки «nosmp» или «maxcpus=0» полностью отключают SMP. Аргумент «maxcpus=N» ограничивает количество процессоров, активируемых в режиме SMP, значением N.

Аргументы загрузки, используемые разработчиками ядра

Необработанную информацию оценки можно прочитать из /proc/profile. Для удобства чтения можно воспользоваться какой-либо утилитой, например, readprofile.c. Запись в /proc/profile приведёт к сбросу показаний счётчиков.

Аргументы загрузки для использования ramdisk

(Только, если ядро было собрано с CONFIG_BLK_DEV_RAM) В общем, использовать ram-диск под Linux — плохая идея, так как ядро использует доступную память гораздо эффективнее. Однако при загрузке часто удобней копировать содержимое дискеты на ramдиск. Также, это позволяет получить систему, в которой загрузка отдельных модулей (для файловых систем или оборудования) производится до получения доступа к основной файловой системе.

В Linux 1.3.48 работа с ramdisk была значительно изменена. Раньше память выделялась статически и существовал параметр «ramdisk=N», определявший её размер. Также возможно было задать необходимый размер во время сборки ядра. В настоящее время под ram-диски используются буферный кэш, размер которого изменяется динамически. Дополнительную информацию по текущем настройкам ramdisk можно найти в файле исходного кода ядра Documentation/blockdev/ramdisk.txt (в старых ядрах — Documentation/ramdisk.txt).

Существует четыре параметра: два логических и два целочисленных.

«load_ramdisk=N» Если N=1, то выполнять загрузку ram-диска. Если N=0, то ramdisk не загружается (по умолчанию 0). «prompt_ramdisk=N» Если N=1, то запрашивать вставку дискеты (по умолчанию). Если N=0, то не запрашивать (таким образом, этот параметр вообще не нужен). «ramdisk_size=N» или «ramdisk=N» (устарел) Установить предельный размер ram-диска(-ов) равным N КБ. По умолчанию 4096 (4МБ). «ramdisk_start=N» Установить номер начального блока (смещение на дискете, с которого начинается ram-диск) равным N. Этот параметр не требуется, если ram-диск находится сразу за образом ядра. «noinitrd» (Только, если ядро было собрано с CONFIG_BLK_DEV_RAM и CONFIG_BLK_DEV_INITRD). В настоящее время существует возможность собрать ядро с поддержкой initrd. Если эта возможность включена, то при запуске загружается ядро и начальный ram-диск. Затем ядро преобразует initrd в «обычный» ram-диск, который монтируется в качестве корневой файловой системы на чтение-запись. Далее запускается /linuxrc. Затем монтируется «настоящая» корневая файловая система, а файловая система initrd переносится в //initrd. И, наконец, начинается обычная процедура загрузки (например, запускается /sbin/init).

Более подробно свойство initrd описано в файле исходного кода ядра Documentation/initrd.txt.

Параметр «noinitrd» указывает ядру пропускать вышеуказанные шаги, несмотря на то, что оно было собрано с поддержкой initrd. Данные initrd, тем не менее, остаются в /dev/initrd (это устройство может быть использовано только один раз: после того, как последний процесс, использующий /dev/initrd, завершится, данные освобождаются).

Параметры загрузки для SCSI-устройств

iobase — первый порт ввода/вывода, занятый хостом SCSI. Порты указываются в шестнадцатеричной системе счисления, обычно их значения находятся в диапазоне от 0x200 до 0x3ff.

irq — аппаратное прерывание, настроенное для карты. Возможные значения зависят от карты, но обычно используются 5, 7, 9, 10, 11, 12 и 15. Остальные значения, как правило, используются общей периферией, такой как: жёсткие диски IDE, дисководы, последовательные порты и т. д.

scsi-id — ID, используемый хост-адаптерами для своей идентификации на шине SCSI. Только некоторые адаптеры позволяют изменять это значение, у большинства оно фиксировано. Обычно, в качестве значения используется 7, однако, карты Seagate и Future Domain TMC-950 используют 6.

parity — указывает, ожидает ли хост-адаптер SCSI от подключенных устройств передачу значений чётности во всей передаваемой информации. Для включения проверки чётности необходимо указать единицу, для отключения — ноль. Не все адаптеры позволяют управлять чётностью с помощью параметров загрузки.

«max_scsi_luns=…» Устройство SCSI может включать в себя «подустройства». В качестве примера можно взять новые многодисковые SCSI CD-ROM-ы. Адрес каждого места под компакт-диск может быть задан «логическим номером устройства» (Logical Unit Number — LUN). Но большинство устройств, таких как, жёсткие диски, ленточные накопители и др., содержат только одно устройство, которому присваивается нулевой LUN.

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

Для указания количества проверяемых при загрузке LUN можно в качестве параметра загрузки указать «max_scsi_luns=n», где n является числом от одного до восьми. Для избежания вышеописанной проблемы можно указать, что n=1.

Hастройка ленточных накопителей SCSI С помощью приведённой ниже строки загрузочных параметров можно настроить драйвер ленточных накопителей SCSI:

Первые два числа указываются в килобайтах. По умолчанию значение buf_size равно 32КБ, а максимальный размер, который может быть указан, — 16384КБ. В write_threshold задаётся значение, при достижении которого содержимое буфера записывается на ленту (по умолчанию равно 30КБ). Максимальное количество буферов (max_bufs) зависит от количество обнаруженных накопителей. По умолчанию используется два буфера. Пример использования этого параметра:

Более подробная информация приведена в файле Documentation/scsi/st.txt (или drivers/scsi/README.st — в старых ядрах), находящемся в дереве исходного кода ядра Linux.

Жёсткие диски

Параметры драйвера IDE-диска/CD-ROM Драйвер IDE понимает довольно большое число параметров, начиная от указания геометрии диска до поддержки неисправных микросхем контроллера. Параметры, относящиеся к конкретному диску, указываются с помощью «hdX=», где X принимает значения от «a» до «h».

Общие для всех дисков параметры указываются с префиксом «hd=». Заметим, что их можно использовать и для какого-то конкретного диска, и при этом параметр будет применён именно так, как ожидалось.

Также заметим, что «hd=» может быть использован для ссылки на следующий неуказанный диск в последовательности (a, …, h) В дальнейшем, для краткости, параметры будут описаны в виде «hd=». Более подробная информация приведена в файле Documentation/ide/ide.txt (в старых ядрах — Documentation/ide.txt или в совсем старых — drivers/block/README.ide) из дерева исходного кода ядра Linux.

Параметры «hd=cyls,heads,sects[,wpcom[,irq]]» Эти параметры используются для указания физической структуры диска. Обязательными являются только первые три значения. Значения цилиндров(cyls)/головок(heads)/секторов(sects) в дальнейшем используются в программе fdisk. Значение предварительной компенсации записи (wpcom) для дисков IDE игнорируется. Значение IRQ, указанное в качестве irq, используется в контроллере интерфейса, к которому подключён диск, и, на самом деле, не относится к диску. Параметр «hd=serialize» В микросхеме двойного IDE интерфейса CMD-640 содержится ошибка, приводящая к тому, что при одновременной работе дисков первичного и вторичного интерфейсов происходит повреждение данных. Этим параметром можно указать, что драйверу никогда не следует использовать оба интерфейса одновременно. Параметр «hd=noprobe» Не определять этот диск. Например,

Если установлено два диска, то для второго диска нужно повторить вышеуказанную строку со структурой.

Устройства Ethernet

Различные драйверы используют разные параметры, но все они, как минимум, распознают IRQ, базу ввода/вывода и имя. В общей форме выглядит это примерно так:

Первый не числовой аргумент воспринимается как имя. Значения param_n (если есть) у разных карт/драйверов, обычно, имеют различный смысл. Обычно, значения param_n используются для указания адреса общей памяти, выбранного интерфейса, канала DMA и т. п.

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

Обратите внимание, что ноль в качестве значения IRQ и базы ввода/вывода указывает драйверам определять значения автоматически.

Исчерпывающей документацией по использованию нескольких карт и по специфичным для карты/драйвера значениям param_n можно считать Ethernet-HowTo. Желающие могут обратиться к соответствующему их карте разделу этого документа.

Драйвер дисковода

У драйвера дисковода есть много параметров. Все они перечислены в файле Documentation/blockdev/floppy.txt (в старых ядрах — Documentation/floppy.txt или в совсем старых ядрах — drivers/block/README.fd) из дерева исходного кода ядра Linux. Дополнительную информацию ищите в этом файле.

Драйвер звука

Драйвер звука также может учитывать параметры загрузки для замены встроенных при компиляции значений по умолчанию. Не рекомендуется заново определять значение параметров, так как это довольно сложно. Описание находится в файле Documentation/sound/oss/README.OSS (и в drivers/sound/Readme.linux у старых ядер) в дереве исходного кода ядра Linux. Параметр загрузки имеет следующий вид:

где каждое значение устройства N имеет формат 0xTaaaId, байты которого используются следующим образом:

T — тип устройства: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401

aaa — адрес ввода/вывода в шестнадцатеричном виде.

I — линия прерывания в шестнадцатеричном виде (т. е. 10=a, 11=b, …)

Как видите, результат довольно непонятен, поэтому лучше установить собственные значения при компиляции. Параметр загрузки «sound=0» полностью отключит драйвер звука.

Драйвер принтера

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

В значении перечисляется несколько названий портов. Например, при lp=none,parport0 используется первый параллельный порт для lp1 и отключается lp0. Чтобы вообще отключить драйвер принтера, укажите lp=0.

EC2 (эластичное облако вычислений) — это наиболее часто используемый AWS-сервис, поскольку он надёжен, гибок и позволяет масштабируемость. EC2 можно назвать “хребтом” AWS, т.к. прямо или косвенно он задействуется во множестве других сервисов AWS. По большей части публичные AMI, предоставляемые Amazon и другими крупными вендорами, уже прошли тщательные испытания на пригодность использования в продакшене. Тем не менее иногда возникает необходимость подстройки поведения инстансов EC2 через изменение параметров их ядер.

В текущей серии статей мы рассмотрим, что представляют собой параметры ядра (включая параметры его загрузки), а также как изменять эти параметры для Amazon Linux 1/2, RHEL 5/6/7/8, CentOS 6/7, SLES 12/15 и Ubuntu 14.04/16.04/18.04/20.04 на инстансах AWS EC2. Это будет первой частью погружения в тему параметров ядра.

Знакомство с параметрами ядра

Ядро Linux — это сложный элемент ПО, чьё поведение, как и поведение любого другого ПО, зависит от параметров по умолчанию, установленных в коде самого этого ядра. К примерам этого поведения можно отнести то, как ядро управляет диском, памятью или загрузкой системы. Эти параметры определяют поведение Linux, и в целях корректировки поведения системы могут быть изменены как в процессе работы ядра, так и при его загрузке.

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

При загрузке ядра (загрузочные параметры). Эти параметры вызываются через загрузчика ОС.
В процессе работы ядра через псевдо-файловые системы /proc и /sys, используя “sysctl”.
При компиляции (или перекомпиляции) ядра и его подсистем (вроде initrd).

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

Загрузочные параметры ядра

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

За загрузку и запуск ядра Linux отвечает загрузчик ОС, поэтому, чтобы иметь возможность передать параметры загрузки, мы используем специализированный загрузчик вроде GRUB.

Загрузочные параметры ядра определяются в виде списка строк, разделённых пробелами следующим образом:
name[=value_1][,value_2]…[,value_10].

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

К примеру, приведу конфигурацию grub для инстанса на Amazon Linux 1. В ней я изменил параметр “console”, определив для него 2 значения (допускается до 10).

Мы можем также предоставить ядру параметры загрузки, приведённые ниже. Здесь вместо определения значений “console” в виде одного параметра мы повторно использовали console для определения другого значения. При необходимости каждый параметр “console” может содержать до 10 значений, что позволяет выйти за рамки предыдущих ограничений.

Существует несколько способов изменения загрузочных параметров ядра. Кроме того, все дистрибутивы Linux (кроме Ubuntu), упомянутые ранее, используют схожие шаги для изменения этих параметров.

1. Универсальный способ—обновление загрузочных параметров через утилиту grubby

grubby— это инструмент командной строки для обновления и отображения информации о файлах конфигурации загрузчика. grubby отлично работает со всеми дистрибутивами Linux, включая Amazon Linux 1/2, RHEL 5/6/7/8, CentOS 6/7 и SLES 12/15, но при этом не дружит с Ubuntu.

PS: grubby по умолчанию установлен на все дистрибутивы Linux, кроме SLES. Инструкции по его установке вы можете найти в разделе “Добавить репозиторий и установить вручную” здесь.

Преимущества grubby

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

Обратите внимание, что это текущая версия ядра. Вы получите её же при помощи команды “uname-r” (текущая версия ядра) или через запись меню “default” в файле конфигурации. Более подробную информацию вы можете получить при помощи опции -info (аналогично использованию файла конфигурации):

Попробуйте также опцию “grubby -info ALL”.

С остальными опциями вы можете ознакомиться при помощи “grubby -help”.

В процессе загрузки загрузчик передаёт параметры ядру Linux в буфер памяти под названием kernel command line (командная строка ядра). Файл /proc/cmdline в псевдо-файловой системе /proc также содержит копию этих параметров. Проверить это мы можем при помощи следующей команды:

Работа с grubby

Чтобы добавить/изменить параметры ядра посредством grubby, нам нужно указать параметры при помощи -args=args совместно с опцией -update-kernel=default-kernel-path. Например, я добавил параметры “clocksource=tsc tsc=reliable”. Параметр “clocksource=tsc” устанавливает источник тактовой частоты как tsc (clocksource=tsc), если он ещё таковым не установлен. Параметр же “tsc=reliable” отключает все проверки стабильности TSC в процессе загрузки.

PS. Для удаления существующих параметров используйте команду -remove-arguments.

Перезагрузите систему и убедитесь, что параметры “clocksource=tsc tsc=reliable” добавлены:

Либо просто проверьте это через grubby:

В дальнейшем вы можете убедиться, что источником тактовой частоты определён tsc, при помощи следующей команды:

Это всё, что касается grubby.

2. Дистрибутивы Linux с Legacy GRUB

Amazon Linux 1 аналогично RHEL6.X, RHEL5.X и CentOS использует в качестве загрузчика GRUB (также известный как Legacy RUB). Узнать версию в подобных дистрибутивах вы можете так:

Файл конфигурации GRUB располагается в /boot/grub/grub.conf и содержит две символические ссылки на себя: /etc/grub.conf и /boot/grub/menu.lst. Нам нужно изменить эту конфигурацию grub, добавив дополнительные параметры загрузки ядра. Однако, чтобы сделать это эффективно, давайте сначала разберём основы конфигурации grub. Ниже приведён её пример из инстанса EC2 Amazon Linux 1.

Конфигурация GRUB

Здесь, как вы видите, присутствует более 1 записи меню. Запись меню наряду с параметрами содержит информацию о расположении образов ядра и initrd. Каждая запись начинается с “title…” и содержит численный порядок, начиная с 0. Значение “default” определяет текущий образ ядра, который используется для загрузки serve=. В конфигурации, приведённой выше, значение представлено как “0”. Это означает, что действует первая запись меню (4.14.181–108.257.amzn1.x86_64). Давайте взглянем на строку ядра. Вся структура name[=value_1], указанная после местоположения образа ядра (выделена жирным курсивом и разделена пробелами), представляет параметры загрузки:

kernel /boot/vmlinuz-4.14.181–108.257.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295

Важно знать её, чтобы добавлять параметры в правильную запись меню.

Работа с конфигурацией GRUB

Теперь отредактируйте файл конфигурации (/etc/grub.conf) в предпочтительном редакторе и добавьте/измените нужные вам параметры. Я добавил те же параметры “clocksource=tsc tsc=reliable”, что и ранее.

kernel /boot/vmlinuz-4.14.181–108.257.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295 clocksource=tsc tsc=reliable

Перезапустите систему, чтобы изменения вступили в силу. Проверить это мы можем тем же способом, что и в опции 1:

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

3. Дистрибутивы Linux с загрузчиком GRUB2

Amazon Linux 2, так же как RHEL7.X, CentOS7, SLES15 и SLES12, использует в качестве загрузчика GRUB2. Узнать версию такого дистрибутива вы можете следующим образом:

Для систем, по умолчанию использующих загрузчик GRUB2, конфигурация этого загрузчика размещается в /boot/grub2/grub.cfg. Управлять этим файлом должен только сам GRUB2, поскольку он генерирует его автоматически посредством grub2-mkconfig с использованием шаблонов из каталога /etc/grub.d и файла /etc/default/grub. Об этом мы поговорим чуть позже.

Понимание конфигурации GRUB2

PS. Если вы используете инстансы из семейства ARM, упомянутые здесь и здесь, то конфигурация grub должна располагаться где-то в каталоге /boot/efi/EFI. К примеру, для RHEL7, работающего на ARM, это будет /boot/efi/EFI/redhat/grub.cfg.

Загрузочные параметры ядра дистрибутивов, использующих GRUB2, определены в каталоге /etc/default/grub. Давайте взглянем на пример из инстанса на Amazon Linux 2:

“GRUB_CMDLINE_LINUX_DEFAULT” содержит загрузочные параметры (командной строки) ядра. Это строка, в которой мы редактируем конфигурацию grub для изменения загрузочных параметров.

GRUB_CMDLINE_LINUX_DEFAULT=”console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295

Работа с конфигурацией GRUB2

Отредактируйте файл конфигурации grub (/etc/default/grub.conf) с помощью предпочтительного редактора. Добавьте/измените интересующие вас параметры для строки GRUB_CMDLINE_LINUX_DEFAULT. Например, я добавил параметры systemd.log_level=debug systemd.log_target=console. Эти дополнительные параметры активируют режим отладки системы и перенаправляют в консоль. Итак, после обновления моя запись в файле /etc/default/grub будет выглядеть примерно так:

GRUB_CMDLINE_LINUX_DEFAULT=”console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0 systemd.log_level=debug systemd.log_target=console”

Теперь, чтобы автоматически сгенерировать конфигурацию grub2 на основе добавленных параметров, нам нужно запустить grub2-mkconfig, добавив путь к этой конфигурации:

Перезагрузите систему и проверьте, вступили ли изменения в силу из /proc/cmdline, как мы делали ранее.

4. Для инстансов EC2 на Ubuntu 14.04 / 16.04 / 18.04 / 20.04

GRUB2 является предустановленным загрузчиком и менеджером для Ubuntu, начиная с версии 9.10. Именно поэтому процесс изменения загрузочных параметров ядра практически такой же, как и для других дистрибутивов Linux с GRUB2, которые мы рассмотрели выше.

В данном случае местоположением файла конфигурации будет /etc/default/grub.d/50-cloudimg-settings.cfg.

Для добавления параметров откройте в редакторе /etc/default/grub.d/50-cloudimg-settings.cfg и измените нужные параметры в GRUB_CMDLINE_LINUX_DEFAULT, как мы делали ранее.

После этого выполните команду update-grub, чтобы повторно сгенерировать уже обновлённую конфигурацию grub:

PS. update-grub — это альтернатива или, так скажем, сокращённая версия команды grub-mkconfig -o /boot/grub/grub.cfg.

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

Всем привет! Вот мы и открыли очередной, четвёртый по счёт уже, поток курса «Администратор Linux», который уверенно занимают свою нишу рядом с девопсерским курсом. Больше преподавателей, больше информации и стендов. Ну и как всегда больше интересной информации, которую подобрали преподаватели.

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

Понимать процессы загрузки ядра и запуска системы Linux, важно для настройки Linux и решения проблем запуска. В этой статье представлен обзор процесса загрузки ядра с использованием GRUB2 загрузчика и запуска, выполняемого системой инициализации systemd.

На самом деле, есть два ряда событий, необходимых для приведения компьютера с Linux в рабочее состояние: загрузка ядра (boot) и запуск системы (startup). Процесс загрузки ядра начинается при включении компьютера и заканчивается с инициализацией ядра и запуском systemd. После этого начинается процесс запуска системы, и именно он доводит компьютер Linux до рабочего состояния.

В целом, процесс загрузка ядра и запуск системы Linux довольно прост. Он состоит из следующих шагов, которые будут описываться более детально в разделах ниже:

BIOS POST;
Загрузка ядра (GRUB2);
Инициализация ядра;
Запуск systemd, родителя всех процессов.

Процесс загрузки ядра

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

BIOS POST

Первый шаг процесса загрузки ядра Linux не имеет никакого отношения к Linux. Это аппаратная часть процесса, одинаковая для всех операционных систем. Когда питание подается на компьютер, в первую очередь происходит запуск POST (Power On Self Test), являющегося частью BIOS (Basic I/O System, Базовая Система Ввода-Вывода).

Когда IBM выпустила первый персональный компьютер в 1981 году, BIOS был разработан для инициализации аппаратных компонентов. POST — часть BIOS, задачей которого является обеспечение корректной работы компьютерного оборудования. Если POST заканчивается неудачно, то возможно компьютер неисправен, и процесс загрузки не продолжается.

BIOS POST проверяет базовую работоспособность железа, а затем вызывает прерывание BIOS — INT 13H, которое находит секторы загрузки ядра на всех подключенных устройствах с возможностью загрузки. Первый найденный сектор, в котором содержится валидная загрузочная запись, загружается в RAM, после чего контроль передается коду из загрузочного сектора.
Загрузочный сектор — только первый этап. В большинстве дистрибутивов Linux используется один из трех вариантов загрузчика: GRUB, GRUB2 и LILO. GRUB2 — самый новый и сейчас его используют гораздо чаще более старых вариантов.

GRUB2 расшифровывается как “GRand Unified Bootloader, version 2”, и теперь он является основным загрузчиком для большинства современных дистрибутивов Linux. GRUB2 — программа, которая делает компьютер достаточно “умным”, чтобы тот смог найти ядро операционной системы и загрузить его в память. Поскольку говорить и писать просто GRUB легче, чем GRUB2, в этой статье я возможно буду использовать термин GRUB, но подразумевать GRUB2, если не будет иного уточнения.

GRUB совместим со спецификацией мультизагрузки, что позволяет ему загружать разные версии Linux и других операционные системы; он также может запустить по цепочке загрузочную запись проприетарных операционных систем.

GRUB также позволяет пользователю выбрать загрузку ядра из нескольких возможных для любого предоставленного дистрибутива Linux. Это дает возможность загрузить предыдущую версию ядра, если обновленная не сможет загрузиться корректно или окажется несовместима с какой-то важной частью ПО. GRUB можно настроить в файл /boot/grub/grub.conf .

GRUB1 сейчас уже считается устаревшим и в большинстве современных дистрибутивов заменен на GRUB2, который является его переписанным вариантом. Дистрибутивы на основе Red Hat обновились до GRUB2 около Fedora 15 и CentOS/RHEL 7. GRUB2 имеет тот же загрузочный функционал, что и GRUB1, но в дополнении предоставляет mainframe-like, pre-OS окружение на базе команд и бОльшую гибкость на предзагрузочном этапе. Настройка GRUB2 происходит в /boot/grub2/grub.cfg .

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

Хоть официально GRUB2 не использует нумерацию этапов, ради удобства я воспользуюсь ей в этой статье.

Как уже упоминалось в разделе BIOS POST, в конце POST BIOS ищет загрузочные записи на прикрепленных дисках, обычно расположенных в Главной Загрузочной Записи (Master Boot Record, MBR), после чего он загружает первую найденную запись в память и приступает к ее исполнению. Bootstrap-код, то есть 1-ый этап GRUB2, занимает очень мало места, потому что должен влезать в первый 512-байтовый сектор на жестком диске вместе с таблицей разделов. Общее количество места, выделенного для самого bootstrap-кода в стандартной MBR — 446 байт. 446-байтовый файл для этапа 1 называется boot-img и не содержит таблицу разделов — она добавляется в загрузочную запись отдельно.

Поскольку загрузочная запись должна быть настолько маленькой, она не очень “умная” и не понимает структуру файловой системы. Поэтому единственной целью этапа 1 является обнаружение и загрузка этапа 1.5. Чтобы достичь этого, этап 1.5 GRUB должен располагаться в пространстве между самой загрузочной записью и первым разделом на диске. После загрузки этапа 1.5 GRUB в RAM, этап 1 передает контроль этапу 1.5.

Как было замечено выше, этап 1.5 GRUB должен находиться между загрузочной записью и первый разделом на диске. Исторически сложилось, что это пространство остается неиспользованным по техническим причинам. Первый раздел на жестком диске начинается в 63 секторе, а с учетом MBR в секторе 0, остается 62 512-байтовых секторов — 31744 байта — в которых можно хранить файл core.img — 1.5 этап GRUB. Файл core.img весит 25389 байт, что достаточно места для его хранения между MBR и первым разделом диска.

Поскольку для этапа 1.5 можно использовать больше кода, его может быть достаточно для содержания нескольких распространенных драйверов файловых систем, например, стандартной EXT и прочих Linux файловых систем, FAT и NTFS. core.img в GRUB2 более сложный и функциональный, чем в этапе 1.5 GRUB1. Это значит, что этап 2 GRUB2 может находиться в стандартной EXT файловой системе, но не в логическом томе. Поэтому стандартное местоположение для файлов этапа 2 — файловая система /boot , а точнее /boot/grub2 .

Обратим внимание, что директория /boot должна располагаться в файловой системе, которая поддерживается GRUB. Не все файловые системы имеют эту поддержку. Задача этапа 1.5 — начать с необходимыми драйверами файловой системы поиск файлов этапа 2 в файловой системе /boot и загрузить нужные драйверы.

Все файлы этапа 2 GRUB находятся в директории /boot/grub2 и нескольких поддиректориях. В GRUB2 нет файла образа как в этапах 1 и 2. Вместо этого он по большей части состоит из runtime модулей ядра, которые грузятся по необходимости из директории /boot/grub2/i386-pc .

Задача этапа 2 GRUB2 — обнаружить и загрузить ядро Linux в RAM и передать контроль управления компьютером ядру. Ядро и связанные с ним файлы находятся в директории /boot . Файлы ядра легко узнать, поскольку их названия начинаются с vmlinuz. Вы можете составить список содержимого директории /boot , чтобы посмотреть текущие установленные ядра в вашей системе.

GRUB2, как и GRUB1, поддерживает загрузку одного из нескольких ядер Linux. Система управления пакетами Red Hat поддерживает сохранение нескольких версий ядра, чтобы можно было загрузить старую версию ядра в случае возникновения проблем с самой новой. По умолчанию, GRUB предоставляет предварительно загруженное меню установленные ядер, включая опцию rescue, а после настройки, и опцию recovery.

Этап 2 GRUB2 загружает выбранное ядро в память и передает контроль управления компьютером ядру.

Все ядра находятся в самораспаковывающемся, сжатом формате для экономии места. Ядра расположены в директории /boot , вместе с исходным образом диска RAM и списком разделов на жестких дисках.

После того, как выбранное ядро загружено в память и начинает исполняться, в первую очередь, оно должно извлечь самого себя из сжатой версии файла, перед тем как начать выполнять полезную работу. Как только извлечение произошло, оно загружает systemd, который является заменой старой программе SysV init, и передает ему контроль.

Это конец процесса загрузки ядра. К этому моменту, ядро Linux и systemd запущены, но не могут выполнять какие-либо полезные задачи для конечного пользователя, так как выполнять еще нечего.

Процесс запуска системы

Процесс запуска системы следует за процессом загрузки ядра и приводит компьютер с Linux в рабочее состояние.

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

Сначала, systemd монтирует файловые системы, как определено в /etc/fstab , включая любые swap-файлы и разделы. К этому моменту, он может получить доступ к файлам конфигурации, расположенным в /etc , включая его собственным. Он использует собственный конфигурационный файл /etc/systemd/system/default.target , чтобы определить таргет (target), по которому нужно загрузить хост. Файл default.target — просто симлинк на настоящий target файл. Для настольной рабочей станции обычно это graphical.target, эквивалентный runlevel 5 в старом инициализаторе SystemV. Для сервера, по умолчанию скорее всего будет multi-user.target, аналогичный runlevel 3 в SystemV. emergency.target похож на однопользовательский режим.

Обратите внимание, что target’ы и сервисы являются юнитами systemd.

Ниже представлена Таблица 1, в которой идет сравнение всех таргетов systemd со старыми уровнями выполнения (runlevel) в SystemV. Псевдонимы таргета systemd предоставляются systemd для обратной совместимости. Псевдонимы таргета разрешают скриптам — и многим сисадминам, мне в том числе — использовать такие SystemV команды как init3 для изменения уровней выполнения. Конечно, команды SystemV направлены systemd для интерпретации и исполнения.

Runlevel	aliases	Description
halt.target	Приостанавливает систему без отключения питания
0	poweroff.target	runlevel0.target	Приостанавливает систему и отключает питание
S	emergency.target	Однопользовательский режим. Сервисы не запущены; файловые системы не смонтированы. Это самый базовый уровень оперирования. Для взаимодействия пользователя с системой в главной консоли запущена только аварийная оболочка.
1	rescue.target	runlevel1.target	Базовая система, включающая монтирование файловой системы с самым базовым набором сервисов и rescue оболочкой в главной консоли.
2	runlevel2.target	Многопользовательский режим, без NFS, но все сервисы, не относящиеся к GUI, запущены.
3	multi-user.target	runlevel3.target	Все сервисы запущены, но только через интерфейс командной строки (CLI).
4	runlevel4.target	Не используется.
5	graphical.target	runlevel5.target	Многопользовательский режим с GUI.
6	reboot.target	runlevel6.target	Перезагрузка.
default.target	Этот таргет всегда имеет симлинк с multi-user.target или graphical.target. systemd всегда использует default.target для запуска системы. default.target никогда не должен быть связан с halt.target, poweroff.target или reboot.target.

Таблица 1: Сравнение уровней управления SystemV с target’ами systemd и некоторые псевдонимы таргетов.

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

systemd также просматривает устаревшие директории инициализации SystemV на предмет наличия стартап файлов. Если они есть, systemd использует их в качестве файлов конфигурации для запуска сервисов описанных в файлах. Устаревший сетевой сервис — хороший пример одного из тех, что до сих пор используют стартап файлы SystemV в Fedora.

Рисунок 1, представленный ниже, напрямую скопирован с главной страницы bootup. На нем показана общая последовательность событий во время запуска systemd и базовые требования для обеспечения его успешности.

Таргеты sysinit.target and basic.target можно считать чекпоинтами в процессе запуска системы. Хоть одна из целей systemd — параллельно запускать системная сервисы, есть некоторые сервисы и функциональные таргеты, которые должны быть запущены раньше других. Эти контрольные точки не могут быть пройдены до тех пор, пока все сервисы и таргеты, необходимые для них, не будут выполнены.

Таким образом, sysinit.target достигается, когда завершены все юниты, от которых он зависит. Должны быть завершены все следующие юниты: монтирование файловых систем, настройка swap-файлов, запуск udev, настройка начального состояния генератора случайных чисел, инициализация низкоуровневых сервисов, настройка криптографических сервисов, если хотя бы одна файловая система зашифрована. В sysinit.target они могут выполняться параллельно.
sysinit.target запускает все низкоуровневые сервисы и юниты необходимые для минимальной функциональности системы, и те, что нужны для перехода к basic.target.

Рисунок 1. Карта запуска systemd

После выполнения sysinit.target, systemd запускает basic.target, начиная со всех юнитов, необходимых для его выполнения. Базовый таргет предоставляет дополнительный функционал, запуская юниты необходимые для следующего таргета, включая настройку путей до различных исполняемых директорий, коммуникационных сокетов и таймеров.

Наконец, можно начать инициализацию таргетов пользовательского уровня: multi-user.target или graphical.target. Стоит отметить, что multi-user.target должен быть достигнут до того, как будут выполнены зависимости графического таргета.

Подчеркнутые таргеты в Рисунке 1 — обычные стартап таргеты. Запуск системы завершается по достижении одного из них. Если multi-user.target является таргетом по умолчанию, то в консоли вы увидите логин в текстовом режиме. Если же по умолчанию задан graphical.target, то увидите графический логин; GUI экрана логина зависит от экранного менеджера, который вы используете.

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

Команда grub2-set-default неправильно настроила дефолтный индекс ядра в файле /etc/default/grub , поэтому желаемое альтернативное ядро не загружалось. Я вручную поменял /etc/default/grub GRUB_DEFAULT=saved на GRUB_DEFAULT=2 , где 2 — индекс установленного ядра, которое я хотел запустить. Затем, я запустил команду grub2-mkconfig > /boot/grub2/grub.cfg для создания нового конфигурационного файла grub. Эта уловка сработала, и альтернативное ядро было запущено.

Вот и всё. Ждём вопросы и комментарии тут или их можно задать напрямую на открытом уроке.

В сети довольно много статей на тему ускорения работы ГНУ систем, начиная от самого Linux ядра, заканчивая разгоном железа. Но не всем они подойдут ввиду разнообразия:

Семейств дистрибутивов;
Окружений и ПО;
Систем инициализации;
Оборудования.

Встречается настройка ядра через /etc/default/grub, операции с монтированием носителей в /etc/fstab, советы по обращению с ФП, ОЗУ, ZRAM/ZSWAP/ZCACHE, оптимизации пользовательских окружений и ПО. Писать в про всё целиком . . . можно в отдельный справочник. Но ввиду озвученных выше причин, не все пригодятся, не факт, что будут работать, а эффект от иных может быть не заметен вовсе. Поэтому тут я собрал кое-какие варианты.

ПЕРЕД ПОДОБНЫМИ ДЕЙСТВИЯМИ НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ СОЗДАТЬ ТОЧКУ ВОССТАНОВЛЕНИЯ

Возможно, не стоит применять всё сразу, чтоб была возможность выявить возможные неполадки.

Поскольку большинство систем используют systemd, для них актуальны команды

kernel — время загрузки ядра,
userspace — время на загрузку всего остального

systemd-analyze blame — посмотреть какие именно службы загружаются и сколько времени на это требуется
systemd-analyze plot >graph.svf— команда создаст svf файл с графиком, откройте его в браузере.

Далее, стоит отключить ненужные службы, список сервисов и описание можно найти в сети, как и другие команды для systemd. Чтобы это сделать нужно ввести

sudo systemctl disable <имя_службы.service>

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

Ускорение загрузки ядра Linux

Параметры загрузки ядра находятся в файле /etc/default/grub. Изменения нужно внести в значение строки GRUB_CMDLINE_LINUX_DEFAULT (значение в скобках, после знака = )

quiet - тихий вариант загрузки, выводит минимум информации

rootfstype=ext4 - в какую ФС отформатирован корень (в моём случае btrfs)

libahci.ignore_sss=1 - ускоряет загрузку жестких дисков

raid=noautodetect - отключение raid

selinux=0 - система контроля доступа, которая не нужна на домашнем ПК

plymouth.enable=0 - отключает заставку

lpj=0000000 - позволяет задать константу loops_per_jiffy, чтобы ядро её каждый раз не вычисляло. Значение индивидуально для каждого компьютера. Чтобы её узнать, нужно открыть ещё один терминал и там ввести «dmesg | grep 'lpj='». Полученное значение скопировать.

В итоге, строка будет иметь примерно такой вид:

GRUB_CMDLINE_LINUX_DEFAULT="quiet rootfstype=ext4 libahci.ignore_sss=1 raid=noautodetect selinux=0 plymouth.enable=0 lpj=12053560"

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

GRUB_DISABLE_LINUX_UUID=true

После этой операции нужно обновить конфигурацию GRUB

sudo update-grub

Установка ПО

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

sudo apt-get install preload

Можно оставить настройки по умолчанию, в файле /var/lib/preload/preload.state информация о работе preload.

cycle — как часто preload будет получать от системы данные об используемых программ и библиотек.

halflife — как часто preload будет сбрасывать старую информацию.

minsize — ограничение на размер программы или библиотеки, которую preload будет обрабатывать.

Я у себя не нашел этой утилиты. Поэтому про её работу и настройку рекомендую почитать в сети, есть материалы

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

sudo apt install prelink

В процессе работы копится всяческий мусор. Этот мусор стоит периодически чистить. Я сам постоянно использую Stacer и Bleachbit. Первая умеет много чего, а вторую программу считаю обязательной для любой ОС. Плюс использую команды для удаления зависимостей-сирот. Однако, всё же можно установить для очистки autoclean и autoremove.

sudo apt autoclean

sudo apt autoremove

Последним оставлю блок про оптимизации работ железа. Сюда стоит включить операции с SSD/HDD и ОЗУ, разгон ОЗУ/видеокарты, кастомные ядра, настройку работы ЦП и видеокарты. Для настройки работы nVidia утилита GWE и родная NVIDIA SERVER SETTING, которая устанавливается вместе с драйвером, для АМД — CoreCtrl, которая, к тому же, позволяет изменить режим работы процессора.

Для работы с SSD нужно выставить флаги в /etc/fstab

ssd, discard (Defaults - этот убираем) - для btrfs.

lazytime (Defaults, noatime - этот убираем) - для Ext4

Если вы уже выставили флаги discard в вашем Fstab, то включать TRIM по расписанию не надо!

На счет TRIM для SSD — довольно неоднозначная вещь. Встречал противоречивые мнения в сети: и что это утилита уже встроена в ядро, что она не работает по умолчанию должным образом, нужно прописывать самому в fstab. Ничего утверждать не буду. Прочитал на этот счет статью, что SSD сами справляются с уборкой мусора, надо всего-лишь держать там достаточно не размеченного пространства, порядка 10-15%. Собственно, на этом я и остановился.

Отключение защиты от уязвимостей в процессорах Intel

Spectre/Meltdown/Zombieload aka MDS (серьезно снижают производительность)

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="nopti pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

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

vm.dirty_bytes = 2097152

vm.dirty_background_bytes = 2097152

vm.vfs_cache_pressure = 50

Прошу обратить внимание на последнюю строку: этот параметр отвечает за кэширование объектов файловой системы в оперативную память. При значении 0, объекты не высвобождаются и так и остаются в оперативной памяти. Чем больше значение, тем чаще ядро будет проводить "зачистку" оперативной памяти. Поэтому если у вас оперативной памяти меньше 2 ГБ, то оставьте значение 50, дабы сократить число дисковых операций в разделе подкачки. Это также полезно в случае если у вас SSD. Но если у вас больше 2 ГБ оперативки, и обычный жёсткий диск, то выставьте значение этого параметра на 1000. Это позволит более агрессивно кэшировать дисковые операции, тем самым повысив быстродействие при достаточном количестве оперативной памяти. По умолчанию значение этого параметра равно 100.

Читайте также: