Параметры ядра linux что это

Углубление в параметры ядра. Часть 1: загрузочные параметры

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 способа, с помощью которых вы можете добавлять или редактировать эти параметры. Выбор одного из них будет зависеть от конкретного случая.

1. При загрузке ядра (загрузочные параметры). Эти параметры вызываются через загрузчика ОС.
2. В процессе работы ядра через псевдо-файловые системы /proc и /sys, используя “sysctl”.
3. При компиляции (или перекомпиляции) ядра и его подсистем (вроде 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 для оптимизации PostgreSQL

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

SHMMAX / SHMALL

SHMMAX — это параметр ядра, используемый для определения максимального размера одного сегмента разделяемой памяти (shared memory), который может выделить процесс Linux. До версии 9.2 PostgreSQL использовал System V (SysV), для которой требуется настройка SHMMAX. После 9.2 PostgreSQL переключился на разделяемую память POSIX. Так что теперь требуется меньше байтов разделяемой памяти System V.

До версии 9.3 SHMMAX был наиболее важным параметром ядра. Значение SHMMAX задается в байтах.

Аналогично, SHMALL — это еще один параметр ядра, используемый для определения
общесистемного объема страниц разделяемой памяти (shared memory). Чтобы просмотреть текущие значения SHMMAX, SHMALL или SHMMIN, используйте команду ipcs.

SHM* Details — Linux

SHM* Details — MacOS X

PostgreSQL использует System V IPC для выделения разделяемой памяти. Этот параметр является одним из наиболее важных параметров ядра. Всякий раз, когда вы получаете следующие сообщения об ошибках, это означает, что у вас более старая версия PostgreSQL и у вас очень низкое значение SHMMAX. Ожидается, что пользователи будут корректировать и увеличивать значение в соответствии с разделяемой памятью, которую они собираются использовать.

Возможные ошибки неправильной конфигурации

Если SHMMAX настроен неправильно, вы можете получить ошибку при попытке инициализировать кластер PostgreSQL с помощью команды initdb.

initdb Failure
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL’s request for a shared memory segment exceeded your kernel’s SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL’s shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it’s possible that it is less than your kernel’s SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

Аналогично, вы можете получить ошибку при запуске сервера PostgreSQL используя команду pg_ctl.

pg_ctl Failure
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL’s request for a shared memory segment exceeded your kernel’s SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL’s shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it’s possible that it is less than your kernel’s SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

Понимание различий в определениях

Определение параметров SHMMAX/SHMALL немного отличается в Linux и MacOS X:

• Linux: kernel.shmmax, kernel.shmall
• MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Команда sysctl может быть использована для временного изменения значения. Чтобы установить постоянные значения, добавьте запись в /etc/sysctl.conf. Подробности приведены ниже.

Изменение параметров ядра на MacOS X

Изменение параметров ядра на Linux

_{Не забудьте: чтобы сделать изменения постоянными, добавьте эти значения в /etc/sysctl.conf}

Большие страницы (Huge Pages)

В Linux по умолчанию используются страницы памяти 4 КБ, в BSD — Super Pages, а в Windows — Large Pages. Страница — это часть оперативной памяти, выделенная процессу. Процесс может иметь несколько страниц в зависимости от требований к памяти. Чем больше памяти требуется процессу, тем больше страниц ему выделено. ОС поддерживает таблицу выделения страниц для процессов. Чем меньше размер страницы, тем больше таблица, тем больше времени требуется для поиска страницы в этой таблице страниц. Поэтому большие страницы позволяют использовать большой объем памяти с уменьшенными накладными расходами; меньше просмотров страниц, меньше ошибок страниц, более быстрые операции чтения/записи через большие буферы. Как результат — улучшение производительности.

PostgreSQL поддерживает большие страницы только в Linux. По умолчанию Linux использует 4 КБ страниц памяти, поэтому в случаях, когда операций с памятью слишком много, необходимо устанавливать страницы большего размера. Наблюдается прирост производительности при использовании больших страниц размером 2 МБ и до 1 ГБ. Размер большой страницы может быть установлен во время загрузки. Вы можете легко проверить параметры большой страницы и их использование на вашем Linux-компьютере, используя команду cat /proc/meminfo | grep -i huge.

Получение информации о больших страницах (только на Linux)

В этом примере, хотя размер большой страницы установлен в 2048 (2 МБ), общее количество больших страниц имеет значение 0. Это означает, что большие страницы отключены.

Скрипт определения количества больших страниц

Это простой скрипт возвращает необходимое количество больших страниц. Запустите скрипт на вашем сервере Linux, пока работает PostgreSQL. Убедитесь, что для переменной среды $PGDATA задан каталог данных PostgreSQL.

Получение цифры требуемых больших страниц

Вывод скрипта выглядит следующим образом:

Рекомендуемое значение больших страниц — 88, поэтому вы должны установить значение 88.

Установка больших страниц

Проверьте большие страницы сейчас, вы увидите, что большие страницы не используются (HugePages_Free = HugePages_Total).

Снова информация о больших страницах (только на Linux)

Теперь задайте параметр huge_pages «on» в $PGDATA/postgresql.conf и перезапустите сервер.

И снова информация о больших страницах (только на Linux)

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

Некоторые операции с базой данных для утилизации больших страниц

Давайте посмотрим, используем ли мы сейчас больше больших страниц, чем раньше.

Еще раз информация о больших страницах (только на Linux)

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

_{Примечание: примерное значение для HugePages, используемое здесь, очень низкое, что не является нормальным значением для машины на продуктовой среде. Пожалуйста, оцените необходимое количество страниц для вашей системы и установите их соответственно в зависимости от нагрузки и ресурсов.}

vm.swappiness

vm.swappiness — это еще один параметр ядра, который может влиять на производительность базы данных. Этот параметр используется для управления поведением подкачки (swappiness) (подкачки страниц в память и из нее) в Linux. Значение варьируется от 0 до 100. Он определяет, сколько памяти будет выгружено или выгружено. Ноль означает отключение обмена, а 100 означает агрессивный обмен.

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

Установка значения 0 в более новых ядрах может привести к тому, что OOM Killer (процесс очистки памяти в Linux) убьет процесс. Таким образом, можно безопасно установить значение 1, если хотите минимизировать подкачку. Значение по умолчанию в Linux — 60. Более высокое значение заставляет MMU (блок управления памятью) использовать больше пространства подкачки, чем ОЗУ, тогда как более низкое значение сохраняет больше данных/кода в памяти.

Меньшее значение — хорошая ставка на улучшение производительности в PostgreSQL.

Источник