Низко висящие яблоки Linux

Теперь давайте посмотрим на повышение производительности операционной системы Linux, которая является достаточно интеллектуальной, чтобы распознать и адаптироваться к аппаратным проблемам, типа фирмы-изготовителя, скорости и числа центральных процессоров, количества системной памяти, а также типа, скорости и количества дисковых устройств. Тем не менее, остаются пригодными для использования многие неочевидные возможности повышения производительности. В данном случае я начну с типичной инсталляции Red Hat Linux 6.2. (Примечание: я начну работу с ядра 2.2.14-5smp, которое поставляется с Linux 6.2.)

Первым заданием после установки Linux должно быть создание монолитного ядра (то есть повторная компиляция ядра для статического включения библиотек, которые вы намереваетесь использовать и отключения динамически загружаемых модулей). Идея заключается в том, что маленькое ядро, куда включены только те опции, в которых вы нуждаетесь, превосходит “жирное” ядро, поддерживающее функции, которыми вы все равно не пользуетесь. Так что я собираюсь использовать команду cd для изменения каталога на /usr/src/Linux и издам команду очистки xconfig (загрузившись для этого в интерфейс командной строки вместо системы X-Windows).

Теперь я должен установить буквально сотни параметров. Я могу рекомендовать для использования любую из дюжины хороших книг или Web-сайтов по этой теме. Тот сайт, которым я пользовался чаще других, называется Securing and Optimizing Linux: Red Hat Edition (Обеспечение безопасности и оптимизация Linux: редакция Red Hat) Герхарда Моурани (Gerhard Mourani). (Вы можете также загрузить более старую версию книги Моурани в формате PDF (PDF version

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3.pdf ). Можно также посетить список OTN Members Booklist on Amazon (http://www.amazon.com/otn\), где можно найти другие рекомендованные книги по Linux).

К числу немногих установок параметров, которые задержались в моей памяти, относятся тип центрального процессора, поддержка симметричной многопроцессорной обработки (SMP), поддержка APIC (Advanced Peripheral Interrupt Controller – усовершенствованного программируемого контроллера прерываний), поддержка DMA (прямого доступа к памяти), активация значения по умолчанию IDE DMA и поддержка квот. Мой совет – нужно пройти их все, а если у вас возникли какие-то сомнения – читать справочный файл xconfig,.

Поскольку я знаю, что я собираюсь перекомпилировать ядро, я мог бы также исправить установки параметров взаимодействия процессов (IPC), как это записано в руководстве по установке базы данных Oracle. Для ядра 2.2, установки параметров общей памяти расположены в каталоге /usr/src/Linux/include/asm/shmparam.h. Я предлагаю установить значение параметра SHMMAX не менее 0x13000000. Параметры настройки семафора расположены в каталоге /usr/src/Linux/include/Linux/sem.h. Я рекомендую установить SEMMNI, SEMMSL и SEMOPN, равными, по крайней мере, 100, 512 и 100, соответственно.

Теперь я перекомпилирую ядро, используя команду make dep clean bzImage, скопирую карту ссылок и образ ядра в мой каталог начальной загрузки, отредактирую /etc/lilo.conf, выполню lilo и перезагружусь. Если я все сделал правильно, машина загрузится, используя мое новое (более экономное и более скромное) ядро.

Применение монолитного ядра с должным образом выставленными установками параметров IPC улучшает загрузку почти на 10 процентов, а TPS – почти на 7 процентов, как показано в Таблице 8.

Таблица 8: Результаты TPC для монолитного ядра с должным образом выставленными установками параметров IPC

Время загрузки (сек)	9,54
Транзакций/сек	11,51

<
Если простая перекомпиляция определенной версии ядра может привести к таким улучшениям, то, наверное, стоит задуматься, а не может ли обеспечить новые усовершенствования более свежая версия ядра из того же самого семейства. На Linux Interactive я нашел исходный код последней стабильной версии ядра того же самого семейства (в моем случае, 2.2.16-3smp). Но в результате я получил совершенно несерьезные усовершенствования – 1,5 процента для загрузки и фактически ничего для TPS, как показано в Таблице 9.

Таблица 9: Результаты TPC-C для более новой (младшей) версии ядра

Время загрузки (сек)	9,40
Транзакций/сек	11,52

Поскольку многие дистрибутивы Linux теперь используют в качестве основы ядро 2.4.x, следующим я попробовал именно его. Я загрузил исходный текст ядра 2.4.1smp (сегодня наиболее устойчивый выпуск – 2.4.7). Новое ядро стоило времени, потраченного на ожидание. Оно привело к усовершенствованию времени загрузки почти на 13 процентов и больше, чем на 10 процентов увеличило TPS, как показано в Таблице 10.

Таблица 10: Результаты TPC-C для новейшей главной версии ядра

Время загрузки (сек)	8,32
Транзакций/сек	12,82

Эти результаты не плохи, но настройка ОС должна обеспечить намного больший успех, типа того, что было, когда я настроил базу данных. Когда я настроил различные параметры базы данных, я выяснил, что те элементы, благодаря которым уменьшился ввод/вывод, скажем, размеры блоков и локальное управление табличными пространствами, обеспечили большие усовершенствования. Так что, моя цель состоит в том, чтобы найти методику сокращения ввода/вывода в Linux. По умолчанию Linux обновляет для любого файла атрибут last-time-read (время последнего чтения), если с ним выполняется операция чтения, и делает это же при операциях чтения. На самом деле, меня совершенно не волнует, когда база данных Oracle в последний раз читала свои файлы данных, так что я могу выключить эту опцию. Это известно как установка атрибута файла noatime (подобная установка существует для Windows NT, 2000 и XP; используйте команду regedit, чтобы установить HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate).

Если вы хотите сделать это только для файлов данных Oracle, задайте команду - chattr +A file_name. Если вы хотите сделать это для всего каталога, команда должна иметь вид - chattr-R +A directory_name. Но лучший метод состоит в том, чтобы отредактировать файл /etc/fstab, и для каждого его входа добавить к списку параметров файловой системы ключевое слово noatime (четвертый столбец). Ниже приводится пример файла /etc/fstab с этим изменением: LABEL=/ / ext2 defaults,noatime 1 1 LABEL=/boot /boot ext2 defaults,noatime 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hda2 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner 0 0

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

Таблица 11: Результаты TPC-C для атрибута файла noatime

Время загрузки (сек)	5,58
Транзакций/сек	13,884

Другая область, имеющая отношение к вводу/выводу – это подсистема виртуальной памяти Linux, которая, как и многое другое в Linux, слишком управляема. Для повышения производительности файловой системы мне достаточно отредактировать файл /ect/sysctl.cong и добавить в него следующий вход:

vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

где, согласно /usr/src/Linux/Documentation/sysctl/vm.txt:

Первый параметр полностью управляет максимальным количеством грязных буферов в буферном кэше. “Грязный” здесь означает, что содержимое буфера еще должно быть записано на диск, в противоположность “чистому” буферу, о котором вы можете уже забыть. Установка этого параметра на высокое значение означает, что Linux может задержать запись на диск на долгое время, но это также означает, что он должен будет сделать за один раз большой объем ввода/вывода, когда системе станет не хватать памяти. Низкое значение разбрасывает дисковый ввод/вывод более равномерно.

Второй параметр – 1200 ndirty, который дает максимальное количество грязных буферов, которые bdflush может записать на диск за один раз. Высокое значение означает отсроченный, пульсирующий ввод/вывод, тогда как маленькое значение может вести к нехватке памяти, когда bdflush не “просыпается” достаточно часто.

Третий параметр – 128 nrefill, который определяет количество буферов, которые bdflush добавит в список свободных буферов при вызыве refill_freelist (). Необходимо заранее распределить свободные буфера, потому что буфера часто имеют другой размер, чем страницы памяти, и какая-то “бухгалтерия” должна быть проделана заранее. Чем больше их число, тем больше памяти будет потрачено впустую, и тем реже нужно будет выполнять refill_freelist ().

Четвертый параметр – это 512 refill_freelist (). Когда оказывается, что он становится больше, чем nref_dirt грязных буферов, “пробуждается” (или, если угодно, запускается – прим. пер.) процесс bdflush.

Усовершенствования производительности – 26 процентов для времени загрузки и 7 процентов для TPS – показаны в Таблице 12.

Таблица 12: Результаты TPC-C при установке bdflush

Время загрузки (сек)	4,43
Транзакций/сек	14,99

Итак, вот каковы мои заключительные результаты – теперь требуется меньше 5 секунд, чтобы загрузить то, на что раньше требовалось 50 секунд, а вдобавок, я почти удвоил TPS. И помните, я не вел никакого мониторинга – все это были, главным образом, очевидные (как те яблоки, что низко висят) усовершенствования.

Вот полная итоговая таблица полученных мной результатов

	Время загрузки (сек)	Улуч-шение	Тран-закций/сек	Улуч-шение
Тест 1	49,41	N/A	8,15	N/A

Общий результат настройки базы данных

10,48 371,47 10,72 23,93 Результаты теста 8 9,54 9,85 11,51 6,9 Результаты теста 9 9,40 1,49 11,52 0,10 Результаты теста 10 8,32 12,98 12,82 10,09 Результаты теста 11 5,58 49,10 13,88 7,70 Результаты теста 12 4,43 25,96 14,99 7,37 Общий результат 4,43 70,97 14,99 17,09 Окончательный результат 4,43 1.015,35 14,99 45,61 Это значит: Linux + База данных Oracle8i = скорость

Содержание раздела