Red Hat Enterprise Linux 6 Оптимизация производительности


-o discard (или указать его в строке команды в /etc/fstab



Pdf просмотр
страница6/7
Дата04.11.2016
Размер0.66 Mb.
Просмотров1281
Скачиваний1
1   2   3   4   5   6   7
-o discard (или указать его в строке команды в /etc/fstab). Удаление будет выполняться безучастия пользователя. Блоки, переходящие из занятого состояние в свободное, будут автоматически удаляться в ext4 (начиная си в начиная сне рекомендует отключать эту функциональность, если в этом нет необходимости. Производительность приложений
Выд еление пространства
Файловые системы ext4, XFS позволяют заранее выделить пространство при помощи вызова
fallocate(2). Это поможет уменьшить фрагментацию, тем самым улучшив производительность отмечает заданный диапазон как выделенный и инициализирует его нулями. Профили производительности позволяет выбрать профиль для улучшения производительности системы.
Некоторые профили будут рассмотрены ниже.
latency-performance
Профиль для коррекции задержки ответа сервера. Отключает механизмы tuned и изменяет режим cpuspeed на performance. Для контроля дискового ввод а-вывод а используется планировщик с алгоритмом deadline. В качестве обязательного значения
cpu_dm a_latency используется Профиль для коррекции производительности обработки данных. Рекомендуется при отсутствии доступа к большому хранилищу данных. Эквивалентно latency-
perform ance за исключением:
Минимальный интервал kernel.sched_min_granularity_ns равен миллисекунд ам.
Значение kernel.sched_wakeup_granularity_ns равно 15 миллисекунд ам.
Значение vm.dirty_ratio равно Включены возможности прозрачного использования страниц большого размера.
Глава 7. Файловые системы
61
Этот профиль рекомендуется для конфигурации пространства данных для крупных серверов уровня предприятия, что включает защиту кэша за счет переключения на питание от батареи и управление кэшем над иске. Аналогичен профилю throughput-
perform ance за исключением следующих факторов:
значение readahead равно файловые системы, которые не являются корневыми и загрузочными, монтируются с параметром Зад альнейшей информацией обратитесь к справочной странице man tuned-adm и к
руководству по управлению энергопотреблением на сайте http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/
7.3. Файловые системы. Файловая система е в Red Hat Enterprise Linux 6 используется по умолчанию. Red Hat
Enterprise Linux 6 поддерживает файловые системы с максимальным размером 16 ТБ, файлы размером до ТБ и снимает ограничение на число подкаталогов (равное 32000 в ext3).
Примечание
Если размер файловой системы превышает 16 ТБ, рекомендуется выбрать другой тип,
например XFS (см. Раздел, В большинстве случаев стандартной конфигурации ext4 должно быть достаточно, но иногда может потребоваться откорректировать ее с целью повышения производ ительности.
Инициализация таблицы В файловых системах большого размера инициализация таблиц inode входе работы может занять длительное время. Параметр -E lazy_itable_init=1 может отложить его выполнение. При этом процессы ядра будут по-прежнему инициализировать файловую систему после ее монтирования. Скорость инициализации контролируется с помощью параметра -o
init_itable=n команды. Значение n по умолчанию равно Автоматическая синхронизация В некоторых случаях приложения не могут корректно выполнить синхронизацию fsync() после переименования файла, его изменения или перезаписи в таких случаях ext4 будет по умолчанию синхронизировать файлы. Операции fsync() могут занимать много времени, поэтому не рекомендуется автоматически использовать этот вид синхронизации. Параметр -o
noauto_da_alloc команды ее отключает, после чего синхронизацию надо будет выполнять вручную при помощи Приоритет ввод а-вывод ад ля журналов Hat Enterprise Linux 6 Оптимизация производительности Обычно операции обращения к журналам имеют более высокий приоритет по сравнению с обычным ввод ом-вывод ом. Параметр journal_ioprio=n команды контролирует это поведение. Допустимые значения включают отд о 7 (чем меньше значение, тем выше приоритет. По умолчанию Подробную информацию можно найти в справочных страницах mkfs.ext4(8), mount(8) ив файле документации для пакета kernel-doc.
7.3.2. XFS
XFS — высокопроизводительная разрядная файловая система, предназначенная для использования над исках большого размера. Число файлов в XFS ограничивается лишь доступным пространством включает возможности журналирования метаданных, что помогает ускорить процесс восстановления поврежденной файловой системы, допускает динамическое изменение размера и д ефрагментацию подключенных файловых систем. Red Hat Enterprise Linux 6 дополнительно поддерживает специфичные для утилиты резервного копирования и восстановления.
Особенности XFS включают предварительное и отложенное выделение места в форме экстентов. Использование экстентов облегчает отслеживание пространства и упрощает работу с большими файлами за счет уменьшения фрагментации. Отложенное выделение пространства гарантирует, что для файл будет записан последовательно, что положительно скажется на производительности. Предварительное выделение эффективно, если приложению заранее известно, сколько потребуется места для записи характеризуется высоким уровнем масштабирования благодаря индексированию данных и метаданных в структуре дерева. Число объектов увеличивается, так как операции над индексами наследуют логарифмические характеристики масштабирования их д еревьев.
Некоторые параметры оптимизации в команде изменяют ширину дерева, что может изменить характеристики масштабирования подсистем. Основы коррекции производительности Обычно стандартной конфигурации XFS должно быть достаточно, и Red Hat рекомендует ее придерживаться. В отдельных случаях можно ее изменить в соответствии с индивидуальными требованиями. Например, при наличии программного массива mkfs.xfs автоматически подберет размер сегмента чередования, но возможно, его надо будет определить вручную на аппаратных массивов.
При монтировании файловых систем большого размера рекомендуется добавить параметр
inode64 . Исключение составляют файловые системы сервера и устаревшие разрядные клиенты NFS, которым нужен доступ к файловой системе.
Д ля интенсивно меняющихся файловых систем параметру logbsize рекомендуется присвоить значение 256 КБ (максимум. По умолчанию он равен MAX (32 КБ. Дополнительные функции коррекции производительности Прежде чем приступить к изменению конфигурации XFS, необходимо точно знать, почему текущие настройки приводят к снижению производительности. Это включает понимание того, как работает приложение, и как файловая система реагирует на его д ействия.
Чаще всего производительность страдает из-за фрагментации и состязания за ресурсы.
Существуют разные способы решения подобных задач оптимизации, включая коррекцию производительности на уровне приложений.
Глава 7. Файловые системы
63
Если у вас нет опыта в этой области, рекомендуется обратиться в службу поддержки Оптимизация для большого числа файлов косвенно накладывает ограничения на число файлов в файловой системе, но этот предел настолько высокий, что практически не может быть достигнут. Если заранее известно, что стандартного размера будет недостаточно, его можно увеличить с помощью mkfs.xfs. В свою очередь, размер существующей файловой системы можно нарастить при помощи Оптимизация для большого числа файлов водном каталоге
Размер блока каталогов имеет фиксированную величину, которая определяется в строке mkfs, и не может быть изменен. Минимальный размер равен размеру блока файловой системы, который по умолчанию равен MAX (4 КБ. Обычно в его уменьшении нет необход имости.
Так как схема каталогов построена на основе дерева, изменение размера блока повлияет на размер данных о каталогах, обрабатываемых операциями ввод а-вывод а. Если размер блока остается неизменным, то с ростом каталога число необходимых запросов ввод а-вывод ад ля обработки одной операции будет увеличиваться.
Од нако при увеличении размера блока операции модификации будут использовать больше процессорных ресурсов. Увеличение размера блокад ля небольших каталогов может отрицательно сказаться на производительности, но при обращении к большим каталогам это может ускорить работу.
Станд артный размер блоков (4 КБ для файловой системы, 4 КБ для каталогов) подходит для каталогов с максимальным числом записей 1-2 миллиона с именами, длина которых составляет байт. Если число записей каталогов достигает миллионов, оптимальный размер блоков для файловой системы составляет 16 КБ, а начиная с 10 миллионов и выше — 64 КБ.
Если операции чтения каталогов выполняются намного чаще операций записи,
вышеперечисленные значения будут на порядок меньше.
Параллелизм
В отличие отд ругих файловых систем, XFS может параллельно выполнять операции выделения и освобождения экстентов и дескрипторов при условии, что они выполняются в разных линейных группах.
Число линейных групп имеет большое значение при выполнении многопоточных программ в многопроцессорных системах. При наличии лишь четырех групп степень параллелизма ограничивается этими группами. В больших файловых системах, размер которых исчисляется десятками терабайт, входе форматирования будет автоматически создано достаточное число групп.
Приложения, одновременно создающие иуд аляющие большое число файлов, должны избегать размещения файлов водном каталоге. Создаваемые каталоги помещаются в разные линейные группы, что упрощает масштабирование.
Оптимизация приложений с расширенными атрибутами может хранить некоторые атрибуты в дескрипторе. Чтение и изменение таких атрибутов осуществляется вместе с чтением дескриптора и не требует дополнительных операций, что положительно сказывается на производ ительности.
Так, стандартный дескриптор размером 256 байт может содержать примерно 100 байт Hat Enterprise Linux 6 Оптимизация производительности атрибутов.
Увеличение размера inode вовремя создания файловой системы поможет увеличить пространство атрибутов. Так, в дескрипторе размером 512 байт будет доступно приблизительно байта в дескрипторе размером 2 КБ — 1900 байт.
На размер отдельных атрибутов, которые могут размещаться внутри inode, накладываются ограничения. Так, максимальный размер атрибута и его значения составляет 254 байта. Если атрибут или его значение превышает этот размер, то он не может располагаться в Изменение метаданных Изменение метаданных со временем приводит к росту журнала, размер которого служит своего рода критерием в определении допустимой частоты их изменения. Дело в том, что ведение журналов осуществляется циклически, то есть прежде чем новые данные смогут быть добавлены в журнал, существующие данные должны быть сохранены над иск. Поиск несохраненной информации и ее запись занимает некоторое время. Исходный размер журнала зависит от размера файловой системы и обычно не нуждается в изменении.
Небольшой размер устройства журналирования означает более частую запись метаданных в силу необходимости освобождения пространства для записи обновляемых метаданных. Это может привести к снижению скорости работы.
Увеличение размера журнала сократит частоту его записи над иск, что позволит лучше организовать записываемые метаданные. Однако недостатком является то, что для отслеживания всех изменений потребуется больше памяти.
Если объем памяти компьютера ограничен, использование больших журналов не рекоменд уется.
В этом случае небольшой размер журналов может быть более предпочтителен в силу более эффективной записи данных над иск.
Д ля устройств MD и DM команда по умолчанию размещает журнал вначале сегмента чередования массива, на основе которого построена файловая система. В свою очередь, для аппаратных массивов эту информацию надо будет определить. Такое расположение журнала исключает необходимость выполнения лишних операций при записи изменений над иск.
Настройки журналов можно корректировать при помощи параметров монтирования. Так,
параметр logbsize позволяет изменить размер буфера в памяти. По умолчанию он равен MAX
(32 КБ, а максимальный размер составляет 256 КБ. В большинстве случаев большой размер помогает улучшить производительность, но при интенсивном выполнении fsync буфер меньшего размера может оказаться эффективнее.
Параметр delaylog уменьшает число операций записи в журнал, накапливая изменения и сохраняя их за один раз. Несмотря на то что этот подход требует больше памяти для хранения изменений и увеличивает риск их потери в случае сбоя, он значительно улучшает скорость изменения метаданных и облегчает масштабирование. Этот параметр не нарушает целостность метаданных при выполнении fsync, fdatasync и sync.
7.4. Кластеризация
Кластерное хранилище позволяет серверам в составе кластера обращаться к накопителям в его составе как кед иному целому. Наличие единой файловой системы упрощает администрирование, так как отпадает необходимость в установке, обновлении приложений и поддержке резервных копий в разных файловых системах.
Глава 7. Файловые системы
65
Комплект Red Hat High Availability в совокупности с Red Hat Global File System 2 предоставляет инструменты для управления кластерным хранилищем. GFS Файловая система Red Hat GFS2 (Global File System 2) напрямую взаимодействует с интерфейсом файловой системы ядра и служит для организации совместного пространства хранения данных в кластере. Настройки GFS2 определяются автоматически, но можно корректировать их вручную, что и будет рассмотрено в этой секции.
В Red Hat Enterprise Linux 6.3 одновременная запись файлов разными процессами приводила к фрагментации, что замедляло работу, особенно при обслуживании больших файлов. В Red Hat
Enterprise Linux 6.4 эта функциональность была оптимизирована.
Несмотря на то что Red Hat Enterprise Linux не предоставляет средства для д ефрагментации
GFS2, можно выполнить д ефрагментацию отдельных файлов вручную. Команда поможет определить фрагментированные файлы, которые можно скопировать во временные и переименовать, заменив исходные файлы использует глобальный механизм блокирования, требующий взаимодействия узлов в кластере. Чтобы сократить число обращений, при проектировании системы следует избегать ситуаций, приводящих к состязанию узлов за ресурсы. Для этого можно:
Заранее выделить место для файлов и каталогов при помощи Минимизировать области, которые будут использоваться совместно. Например, если несколько узлов монтируют одну и туже файловую систему, но обращаются к разным каталогам, перемещение одного каталога в другую файловую систему поможет улучшить производ ительность.
Выбрать оптимальный размер и число групп ресурсов в зависимости от среднего размера файлов и свободного пространства в системе. Это определяет вероятность одновременного обращения узлов к группе ресурсов. Но следует помнить, что слишком большое число групп может замедлить выделение блоков, в то время как недостаточное их количество приведет к конкуренции вовремя освобождения блоков. Обычно эти характеристики подбираются экспериментальным путем.
Д ругие способы повышения производительности При выборе оборудования следует принимать во внимание требования файловой системы и особенности ввод а-вывод а кластерных узлов.
Использовать д иски.
Под обрать размер файловой системы в соответствии с ожидаемым уровнем нагрузки таким образом, чтобы ее занятость не превышала 80%. Небольшие файловые системы не требуют много времени на проверку и резервное копирование, но при больших нагрузках подвергаются фрагментации.
Д ля интенсивной нагрузки рекомендуется увеличить размер журналов. Несмотря на то что журналы будут использовать больше памяти, производительность улучшится, так как запись над иск будет осуществляться реже.
Синхронизация часов на узлах GFS2 позволит избежать проблем в работе сетевых приложений. Для этой цели рекомендуется выбрать протокол Если время доступа к файлами каталогам некритично, файловая система должна быть смонтирована с параметрами noatime и nodiratime.
Red Hat Enterprise Linux 6 Оптимизация производительности
Примечание
Д ля GFS2 рекомендуется выбрать При наличии квот следует уменьшить частоту их синхронизации или предпочесть грубую синхронизацию.
Примечание
Нестрогие квоты допускают превышение заданного порога. Чтобы его минимизировать будет динамически сокращать интервал синхронизации по мере приближения к предельному значению.
За дальнейшей информацией обратитесь к руководству GFS2
по адресу Глава 7. Файловые системы
67
Глава 8. Сетевое окружение
Сетевой стек Red Hat Enterprise Linux оптимизирован для разных уровней нагрузки, поэтому в большинстве ситуаций автоматическая конфигурация обеспечивает оптимальную производ ительность.
Обычно снижение производительности сети наблюдается при сбое оборудования или нарушениях функциональности инфраструктуры. Обсуждение подобных ситуаций выходит за рамки этого документа, поэтому далее будут рассмотрены методы оптимизации рабочих окружений.
Элементы сетевой подсистемы могут включать чувствительные соединения, поэтому и Red и открытое сообщество уделяют много внимания улучшению возможностей автоматической коррекции производительности. Производительность сети

Ниже перечислены основные функции оптимизации производительности сети в Red Hat
Enterprise Linux 6.1.
RPS (Receive Packet Механизм RPS распределяет нагрузку softirq, поступающую в очередь сетевой карты,
межд у процессорами, что позволяет обслуживать запросы параллельно.
Д ля активации RPS необходимо указать имена процессоров в
/sys/class/net/ethX/queues/rx-N/rps_cpus, заменив ethX именем сетевого устройства
(например, eth1, eth2), а rx-N обозначением очереди. Пакеты, поступающие в очередь устройства ethX, будут обрабатываться назад анных процессорах. При выборе процессоров следует учитывать схему привязки кэша

RFS (Receive Flow Steering)
RFS является дополнением и позволяет контролировать выбор ресурсов на основе хэш- таблицы. Таблица заполняется автоматически при обращении к приложениям из сети и регистрирует, на каких процессорах выполняются приложения, получающие пакеты из сети.
На основе этой информации для обслуживания пакетов можно выбрать тот же процессор, на котором выполняется приложение. Параметры конфигурации RFS включают:
/proc/sys/net/core/rps_sock_flow_entries_Максимальное_число_потоков,_перенаправляемых_заданному_процессору._Это_общесистемное_значение./sys/class/net/_ethX'>/proc/sys/net/core/rps_sock_flow_entries
Максимальное число потоков, перенаправляемых заданному процессору. Это общесистемное значение.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt
Максимальное число потоков, направляемых в очередь устройства ethX. Общее число потоков не может превышать /proc/sys/net/core/rps_sock_flow_entries.
RFS допускает совместное использование процессора при получении пакетов из очереди устройства и при обслуживании пакетов из приложения, что в некоторых случаях может улучшить производительность. Однако это зависит и от множества других факторов — иерархии кэша,
нагрузки приложений и т.п.
[4]
Red Hat Enterprise Linux 6 Оптимизация производительности Поддержка тонких потоков T CP в Термин тонкий поток используется для описания обработки пакетов небольшими блоками, что приводит к тому, что механизмы повторной передачи не заполняются полностью. Такая передача используется приложениями, для которых время отклика имеет критическое значение:
онлайн-играми, управляющими системами, системами биржевой торговли.
Потеря пакетов для таких приложений недопустима, поэтому вызов getsockopt теперь поддерживает два новых флага:
TCP_THIN_DUPACK
Разрешает динамический переход в режим обработки тонких потоков после получения одного подтверждения Включает динамический таймаут для тонких потоков.
Оба параметра должны быть установлены приложением. Зад альнейшей информацией обратитесь к версия entation/networking/ip-sysctl.txt
и версия Поддержка прозрачного прокси
Яд ро разрешает подключение сокетов UDP и TCP к прозрачным прокси. Для этого надо будет настроить правила iptables и откорректировать правила маршрутизации.
Под робную информацию можно найти в версия entation/networking/tproxy.txt.
8.2. Оптимизация параметров сети
Уровень производительности иногда корректируется экспериментальным путем если изменение параметров не помогает достичь ожидаемого результата, администратор будет искать другие способы. Заточку отсчета принимается стандартная конфигурация системы и под разумевается,
что она может быть улучшена.
Как уже говорилось, сетевой стек сам оптимизирует свою работу, поэтому дальнейшие изменения требуют точного понимания его работы и требований ресурсов. Неверная конфигурация может только ухудшить производ ительность.
Например, увеличение длины очереди буфера может привести к возникновению заторов в обработке соединений. Такие соединения будут иметь слишком большие значения RTT, так как пакеты будут проводить слишком много времени в очереди. Это приведет к снижению скорости обработки.
Если возможно, рекомендуется использовать стандартные настройки и корректировать их,
только если производительность сети заметно упала. В любом случае, прежде чем приступить к изменению конфигурации, надо тщательно изучить проблему.
Ниже перечислены инструменты, которые помогут выполнить анализ производительности сети.
Под д ержка тонких потоков TCP в getsockopt
69
Утилита командной строки, возвращающая информацию осоед инениях, таблицах маршрутизации, замаскированных подключениях, многоадресных схемах и статистику интерфейсов из /proc/net/.
/proc/net/dev (информация обустройстве (информация о TCP-сокете)
/proc/net/unix (информация о сокете домена Подробную информацию можно найти на справочной странице man Утилита для отслеживания потери пакетов. Подробную информацию можно найти на справочной странице man Утилита для управления и наблюдения за устройствами, правилами маршрутизации и туннелями. Подробную информацию можно найти на справочной странице man Утилита для просмотра и изменения настроек сетевой карты. Подробную информацию можно найти на справочной странице man Содержит управляющую информацию IP, ICMP, TCP, UDP для агента snmp в формате
ASCII.
Д окумент под названием Введение в SystemTap содержит образцы сценариев для мониторинга и профилирования производительности сети. Его можно найти на странице документации по адресу После сбора и анализа статистики сети можно принять решение по оптимизации ее работы.
Например, рост числа ошибок UDP в /proc/net/snmp служит знаком переполнения очереди сокетов.
Из этого можно сделать вывод , что либо очередь обрабатывает пакеты медленно, либо объем поступающих пакетов возрос. Проверьте журналы приложений, интенсивно обращающихся к сети, — если число поступающих запросов действительно превышает длину очереди, следует откорректировать настройки приложения.
Размер буфера сокета
Размер буфера поступающих и отправляемых данных сокета изменяется динамически, поэтому обычно в его изменении нет необходимости. Если же входе анализа производительности выяснилось, что скорость освобождения очереди сокета слишком низкая, можно увеличить ее длину. Для этого надо откорректировать следующие параметры:
rmem_default
Опред еляет размер буфера, который будет использоваться по умолчанию. Чтобы его Hat Enterprise Linux 6 Оптимизация производительности изменить, выполните команду В этой команде размер буфера в байтах. Значение установленного параметра можно получить из /proc/sys/net/core/rmem_default. Стоит помнить, что стандартный размер не может быть больше rmem_max
/proc/sys/net/core/rm em _m ax). Если же он должен быть больше текущего максимума, надо изменить Параметр сокета, определяющий размер буфера поступающих данных. Подробную информацию можно найти на справочной странице

Каталог: documentation -> ru-RU -> Red Hat Enterprise Linux
Red Hat Enterprise Linux -> Руководство по установке Установка Red Hat Enterprise Linux 7 на разных платформах
Red Hat Enterprise Linux -> Red Hat Enterprise Linux 6 Примечания к выпуску
Red Hat Enterprise Linux -> Red Hat Enterprise Linux 6 Администрирование виртуального сервера
Red Hat Enterprise Linux -> Red Hat Enterprise Linux 5 Обзор Cluster Suite
Red Hat Enterprise Linux -> Руководство по установке Установка Red Hat Enterprise Linux 6 на разных платформах Редакция 0
Red Hat Enterprise Linux -> Red Hat Enterprise Linux 6 Администрирование кластера
Red Hat Enterprise Linux -> Red Hat Enterprise Linux 6 Управление энергопотреблением


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал