Tag Archives: performance

Multitasking in System Administration

Just a quick thought on multitasking in SA (or DevOps, if you prefer). There is a common knowledge that multitasking is bad, it hurts your performance, quality, and whatnot.

Here is a nice chart to illustrate the idea:

context-swtiching

Obviously, the above is more of a rule of thumb and here is a nice summarisation. However, there was another study on the matter by Harward’s professors S.Wheelwright and K.Clark that draw slightly different picture:

6a00d8341c500653ef014e606c9737970c

What’s important here is that the percent of time on tasks or performance actually maximises at 2 concurrent tasks. This is actually much more in line with my personal observations. You can also argue that in the field of SA we often have tasks that require significant amount of “wait time” when you kick something off and then simply wait for it to complete, so the latter graph has even more sense.

Как создать файловую систему ext3, оптимизированную для работы на RAID и приложений с прямым вводом/выводом?

Система: Red Hat Enterprise Linux 3, Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 5

Решение:

RAID уровней 0, 4, 5 и 6 для записи на разные диски, разбивает данные на большие блоки — “полосы”, обычно по 64KB. Выравнивание разделов и файловых систем в соответствии с размером этих полос может повысить производительность, в частности, программ, которые используют прямой ввод/вывод.

Программа fdisk создаёт разделы, выровненные по границам цилиндров, в соответствии с исторической геометрией “цилиндр/дорожка/сектор” (cylinder/head/sector, C/H/S). Это позволяет обеспечить максимальную совместимость с другими операционными системами и утилитами. К сожалению, такая геометрия обычно не соответствует размеру полосы RAID-массива. Если доступ к RAID будет осуществляться только операционными системами и утилитами, полностью поддерживающими логическую адресацию блоков (Logical Block Addressing, LBA), то необходимость в выравнивании по геометрии C/H/S отпадает, а с помощью программы parted можно выровнять разделы под полосы RAID-массива.

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

Пример 1: выровненный по границе цилиндра раздел, созданный утилитой fdisk на диске /dev/sdb.

Parted показывает, что fdisk создал раздел, начиная с 63-сектора (32,256 байта) тома, что совместимо с геометрией C/H/S, но не оптимально для RAID. Поскольку RAID использует полосы размером 64KB, начало раздела должно быть сдвинуто на сектор 128. Начинать раздел с нулевого сектора нельзя, поскольку будет перезаписана таблица разделов. Большинство RAID-массивов используют сектора размером 512 байт, но возможны сектора и большего размера.

Примечание: По-умолчанию, parted использует в единицах размера легко читаемые сокращения системы СИ (степени числа 10). Поскольку они редко совпадают со степенями числа 2, parted нужно перевести в режим работы с секторами (unit s), перед тем как проверять или задавать выравнивание разделов по секторам.

Пример 2: удалите раздел /dev/sdb1 и создайте его заново, начиная с сектора 128.

Примечание: Команды move и resize утилиты parted пытаются сохранить содержимое файловой системы раздела. Если в разделе нет файловой системы, то эти команды откажутся работать.

Выровненная файловая система ext3 может быть создана на выровненном разделе или на логическом томе, состоящем из выровненных физических томов. LVM не влияет на выравнивание, если размер физического экстента, превосходит размер блока RAID. Обычно размер RAID блока равен 64KB, а размер физического экстента — 4MB.

Команда mke2fs принимает параметр stride, который позволяет оптимизировать размещение метаданных файловой системы для RAID-массивов. Параметр задаётся в блоках файловой системы, которые в большинстве случаев равняются 4KB. Чтобы избежать возможных неточностей и гарантировать правильность вычислений, лучше всего его задать явно.

Пример 3: создайте файловую систему ext3 на /dev/sdb1, оптимизированную для RAID с размером блока 64KB.

Как определить и настроить вероятность с которой процесс будет завершён при нехватке оперативной памяти

Ядро Red Hat Enterprise Linux 5.2 создает 2 файла для каждого процесса, которые позволяют управлять вероятностью, с которой этот процесс будет завершён, когда система будет вынуждена заврешать процессы из-за нехватки оперативной памяти (out-of-memory, OOM). Это файлы:

  • /proc/[pid]/oom_adj — используется для изменения “OOM-счёта” (OOM score), который определяет вероятность завершения процесса при нехватке оперативной памяти. Чем больше значение OOM-счёта, тем больше вероятность того, что процесс будет завершён подсистемой oomkill. Допустимые значения находятся в промежутке от -17 до 15; обратите внимание, что OOM-счёт равный -17 означает, что [pid] не будет завершён при нехватке памяти.

    Чтобы задать OOM-счёт, просто выполните команду echo значение с выводом в файл /proc/[pid]/oom_adj. Например, чтобы установить OOM-счёт равный 15 для процесса 1111, выполните:

    Учтите, что OOM-счёт наследуется процессом-потомком от родительского процесса при использовании системных вызовов семейства fork().

  • /proc/[pid]/oom_score — содержит текущий OOM-счёт для данного процесса. Используйте команду cat чтобы посмотреть текущий OOM-счёт для процесса с номером [pid]. Например, чтобы узнать текущий OOM-счёт для процесса 1111, выполните:

Прим. пер.: Значение в файле oom_score — динамически вычисляемое, оно не равняется значению, которое передаётся в файл oom_adj. Значение, передаваемое в файл oom_adj, меняет вероятность в большую или меньшую сторону, а не задаёт абсолютное значение.

Как увеличить приоритет операций ввода-вывода некоторых процессов в Red Hat Enterprise Linux 5?

Система: Red Hat Enterprise Linux 5 и новее

Введение:
Приоритет и класс ввода/вывода процесса могут быть изменены командой ionice. Linux поддерживает три класса ввода/вывода:

  • Idle: процесс, имеющий класс idle, получает возможность работать с диском только если никакая другая программа не выполняет операций ввода/вывода в течении некоторого периода времени.
  • Best effort: этот класс используется всеми процессами по-умолчанию, если не был задан определённый класс ввода/вывода.
  • Real time: процессы, работающие в классе реального времени, получают доступ к диску в перую очередь, вне зависимости от того, что еще происходит в системе.

По-умолчанию, процессы работают в классе Best Effort с приоритетом равным нулю, т.е. с наивысшим приоритетом в этом классе. Наилучший вариант применения ionice — улучшение производительности в случаях, когда нужно одновременно выполнять два класса задач: такие, которые не требуют много ввода/вывода, но чувствительны к скорости выполнения операций, и такие, которые наоборот нетребовательны к скорости отклика, но выполняют много операций ввода/вывода.

Решение:
Для повышения приоритета ввода/вывода процесса используйте следующую команду:

# ionice -c1 -n0 -p<PID>

Где:

  • -c1 указывает класс реального времени
  • -n0 задаёт наивысший приоритет
  • -p <PID> указывает идентификатор процесса

Понизить приоритет ввода/вывода процесса можно командой:

# ionice -c2 -n4 -p<PID>

Где:

  • -c2 указывает класс best-effort
  • -n4 задаёт приоритет 4

Чтобы узнать текущий приоритет ввода/вывода процесса, выполните команду:

# ionice <PID>

Например:

# ionice 9709
realtime: prio 7

За подробной информацией о ключах команды ionice, обращайтесь к руководству, которое доступно по команде man ionice.

Применения
Если текущему командному интерпретатору задать класс idle, то все команды, которые из него вызываются, будут тоже выполняться в классе idle. Чтобы это сделать, нам понадобится переменная $$ интерпретаторов bash и sh.

Например:

# echo $$
29033

Этот вывод означает, что PID вашего текущего интерпретатора равен 29033. Если вы хотите назначить назначить ему класс idle, выполните команду:

# ionice -c3 -p$$

Теперь всё, что вы делаете в этом интерпретаторе, выполняется в классе idle.

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

Примечание: приоритеты и классы ввода/вывода поддерживаются начиная с версии ядра 2.6.13, при использовании планировщика ввода/вывода CFQ. В Red Hat Enterprise Linux 5 для того, чтобы узнать какой планировщик используется в данный момент, используйте команду cat /sys/block/[sh]d[a-z]*/queue/scheduler. Текущий планировщик будет выделен квадратными скобками..

Например, следующий вывод показывает, что сейчас используется планировщик CFQ:

$ cat /sys/block/[sh]d[a-z]*/queue/scheduler
noop anticipatory deadline [cfq]