• SMART технология внутренней оценки состояния жёсткого диска - технология внутренней оценки состояния жёсткого диска(HDD); а также механизм предсказания возможного выхода его из строя.
• RAID - мониторинг, диагностика HDD.
• Диагностика HDD (НЖМД) на работающих системах: smartmontools.
• sysctl утилита, предназначенная для управления параметрами ядра
• Load average - высокие значения показателей говорят о том, что система не справляется с нагрузкой(top, htop, atop определение загрузки ОС (Load average, LA)).
• Первые 5 минут устранения неполадок на Linux-сервере

• WAN:
  • Использование утилиты fping - расширение стандартной утилиты ping проверки целостности и качества локальной сети и Интернета
• Интерактивные просмотрщики процессов:
  • top, htop, atop определение загрузки ОС (Load average, LA) - Linux, BSD
  • htop - Linux;
  • slabtop - display kernel slab cache information in real time. Выводит информацию о состоянии внутренних буферов, кэшей Linux ядра, доступных через /proc/slabinfo. Например, для вывода заполненных кешей

    # slabtop --sort u

  • atop
  • dstat объединяет в себе возможности vmstat, iostat мониторинг использования дисковых разделов в Linux и ifstat.
• Сетевая статистика:
  • Как пользоваться командой netstat - сетевая статистика
  • Как пользоваться командой ss для анализа сокетов - сетевая статистика
  • tcpdump Linux примеры использования + графический интерфейс wireshark
  • ifstat - статистика сетевых интерфейсов
• Производительность системы:
  • vmstat - определение производительности системы.
  • free как правильно смотреть свободное ОЗУ Linux
  • Пакет sysstat состоит из следующих утилит измерения производительности системы:
    • sar - собирает и выдаёт информацию о системной активности; в реальной жизни часто бывает, что требуется посмотреть vmstat на агонизирующей системе, когда что-либо понять и исправить уже поздно, или даже уже после того, как систему перезагрузили. Это возможно. Достаточно заблаговременно установить в систему программу sar.
    • iostat мониторинг использования дисковых разделов в Linux - сообщает об использовании ЦП и статистику В/В дисков;
    • mpstat - сообщает глобальную и по-процессорную статистику;
    • pidstat - сообщает статистику по Linux задачам (процессам);
    • sadf - отображает информацию, собранную sar, в различных форматах.
    • iotop - посмотреть нагрузку на диски Disk read/write request
• Как использовать iperf для измерения пропускной способности Интернета - кроссплатформенная консольная клиент-серверная программа — генератор TCP и UDP трафика для тестирования пропускной способности сети.
• Использование Screen оконного менеджера для терминала
• slmon - простой монитор системной производительности: CPU load (SMP is supported), memory and swap load, uptime, date and time, number of logged in users, network traffic
• Использование ps для мониторинга процессов
• lshw отобразить физические параметры сервера содержит в себе lspci и Описание lsusb - определение оборудования компьютера
• Expect примеры Linux - инструмент для автоматизации интерактивных приложений таких, как telnet, ftp, passwd, fsck, rlogin, tip, Использование ssh, ssh-keygen, sshpass с примерами и других.
• Отслеживание времени выполнения команд с помощью утилиты time - измеряет время выполнения отдельной программы и затраченное на ее выполнение время ЦП.

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

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

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

• Время ответа - это время, через которое выдается ответ на отправленный запрос. Примером может служить время обработки запроса к базе данных, задержка в копировании символов на терминал или время загрузки Web- страницы.
• Эффективность работы определяется объемом работы, выполняемой за единицу времени. Другими словами, это число операций рабочей схемы, которые выполняются за единицу времени. Примером может служить число транзакций, выполняемых в минуту, объем данных, считываемых из файла или передаваемых по сети за секунду, либо число документов, найденных на Web- сервере за минуту.

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

Стандартные тесты.

Тестом называется рабочая схема, позволяющая сравнивать производительность различных систем. Все стандартные тесты тщательно изучены разработчиками систем. Операционные системы, компиляторы и, в ряде случаев, аппаратное обеспечение, могли быть спроектированы так, чтобы такие тесты выполнялись с отличными показателями. К сожалению, реальные нагрузки редко повторяют алгоритмы и требования стандартного теста. Даже те тесты, которые были созданы на основе реальных приложений, часто упрощаются и стандартизируются таким образом, чтобы они могли выполняться на различных аппаратных платформах. Среды, в которых запускаются такие тесты, имеют ряд искусственных ограничений, которые были созданы для того, чтобы измерения давали воспроизводимые результаты. Любое утверждение типа "Система A выполняет тест MegaThings на 50 процентов быстрее, чем система B, поэтому система A будет выполнять ваши программы на 50 процентов быстрее, чем система B" выглядит довольно убедительно, но на самом деле не является точным. Настолько универсального теста не существует. Единственное применение стандартных тестов производительности - это грубый отбор систем для дальнейшего тщательного тестирования. Единственным решением является составление точного описания своей рабочей схемы и оценка скорости ее выполнения в различных системах.

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

Процессор: 90% Диск: 70% Память: 60%

Работа такой системы зависит от скорости процессора. Если вам удастся настроить рабочую схему таким образом, что значение показателя использования процессора сократится с 90 до 45 процентов, то вы вправе ожидать, что производительность возрастет в два раза. Однако на деле получится, что теперь производительность системы ограничена скоростью дискового ввода-вывода, а показатели использования ресурсов станут примерно следующими:

Процессор: 45% Диск: 90% Память: 60%

Снижение нагрузки на процессор позволяет программам быстрее передавать запросы на общение к диску, в результате чего может быть достигнуто ограничение на использование диска. В результате производительность возрастет всего лишь на 30 процентов, а не на 100.

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

• Hardware.
  • Жесткие диски (HDD). (iostat мониторинг использования дисковых разделов в Linux, iotop - посмотреть нагрузку на диски Disk read/write request, vmstat, sar, Примеры использования hdparm в Linux, smartctl). При выполнении программы больше всего времени затрачивается на считывание исходного кода и данных программы с жесткого диска. Обращения к диску могут быть вызваны не только явными запросами прикладной программы. Иногда настройка системы может привести к выполнению ненужных операций дискового ввода-вывода.

Сбор информации о дисковом вводе-выводе применяется при решении следующих задач:

• Поиск наиболее интенсивно используемых файлов, файловых систем и логических томов:
  • (iostat мониторинг использования дисковых разделов в Linux). Можно ли лучше расположить или распределить интенсивно используемые файловые системы по нескольким физическим накопителям?
  • Расположены ли интенсивно используемые файлы в локальной или удаленной системе?
  • (vmstat) Не занята ли большая часть дисковой памяти пространством подкачки?
  • (vmstat) Достаточен ли размер кэша для хранения всех обновляемых процессами страниц?
  • Какую долю дискового ввода-вывода составляют синхронные операции (без кэширования)?
• Определение фрагментации файлов:
  • Насколько фрагментированы интенсивно используемые файлы?
  • (iostat мониторинг использования дисковых разделов в Linux). Поиск наиболее часто используемого физического тома: не является ли применяемый накопитель или контроллер узким местом в работе системы?

• ЦПУ (central processing unit, CPU). (vmstat). Одна программа редко способна полностью загрузить процессор (когда процессор не совсем не простаивает и не находится в состоянии ожидания) больше чем на несколько секунд. Даже в многопользовательских системах с большой нагрузкой иногда возникают периоды длительностью 10 миллисекунд, когда все нити находятся в состоянии ожидания. Если в выводе монитора указано, что процессор загружен на 100 процентов в течение длительного времени, то, скорее всего, одна из программ зациклилась. Даже если программа не содержит ошибку, а просто потребляет много процессорного времени, необходимо изменить ее алгоритм.
• ОЗУ. (vmstat, Использование ps для мониторинга процессов). Shared memory. Операционные системы стараются хранить в оперативной памяти только те инструкции и данные, которые используются в текущий момент, выгружая ненужную информацию на диск (или вообще не загружая ее в память). При обращении к странице виртуальной памяти, выгруженной на диск (или еще не загруженной в оперативную память), возникает страничная ошибка, и выполнение программы прерывается до тех пор, пока страница не будет считана с диска. Оперативная память системы почти все время заполнена. Даже если текущие выполняемые программы не занимают все пространство памяти, операционная система хранит в ней страницы программ, выполнявшихся ранее, и файлы, которые применялись этими программами. Такое хранение не требует затрат, поскольку в противном случае память все равно бы не использовалась. Вместе с тем вполне возможно, что программы или файлы понадобятся вновь, и тогда они будут обработаны значительно быстрее. WIO - процессорное время, затраченное на ожидание дискового ввода-вывода, можно просмотреть с помощью команд sar (%iowait), vmstat (wa) и iostat мониторинг использования дисковых разделов в Linux (%iowait).
• TLB Для того чтобы уменьшить время, затрачиваемое на преобразование адресов, физические адреса тех страниц виртуальной памяти, к которым обращались в последнее время, хранятся в кэше, который называется таблицей преобразования адресов (TLB). До тех пор пока программа обращается к небольшому числу страниц виртуальной памяти, полное преобразование виртуальных адресов не производится. Если программа обращается к странице, для которой в таблице TLB отсутствует запись (промах TLB), то на преобразование адреса затрачивается порядка десяти тактов процессора (время обработки промаха TLB).
• Кэш. Для минимизации задержек, связанных с обращением к оперативной памяти, в системе предусмотрен кэш для команд и данных. Если необходимые команды или данные находятся в кэше (попадание), то они будут переданы процессору уже на следующем такте (другими словами, задержки не будет). В противном случае некоторое время будет затрачено на обращение к оперативной памяти (промах кэша). В некоторых системах кэши имеют несколько уровней: L1, L2 и L3. Если необходимые данные не будут найдены в кэше L1, то система попытается найти их в кэше L2. В случае промаха в кэше L2 система переходит на уровень L3 (если он есть) или к оперативной памяти.
• Конвейер, регистры.
• Производительность сети. (ping проверки целостности и качества локальной сети и Интернета, Раздел FTP: Протокол FTP, серверы, клиенты FTP для Linux и Windows, Как пользоваться командой netstat -s, ethtool - настройка сетевых интерфейсов в Linux -S). Порты TCP. Что такое TCP / IP порт/IP, UDP, Что такое Ethernet. При настройке соединения может преследоваться одна из двух целей: повысить его пропускную способность или сократить расход памяти. Если необходимая пропускная способность всех узлов локальной сети составляет более 70 процентов от номинальной (50 процентов для Ethernet), то потребуется увеличить пропускную способность сети. Причина возникновения проблем производительности может находиться не в системе, во многих километрах от нее. Для того чтобы определить, лежит ли причина недостаточной производительности в сети, можно сравнить выполнение зависящих от сети операций с операциями, проходящими без участия сети. Если программа, выполняющая много операций удаленного чтения и записи, работает медленно, а все остальные программы выполняются нормально, возможно, причина находится в сети. Наиболее часто возникающие узкие места в сети:
  • Сетевой интерфейс клиента
  • Пропускная способность сети
  • Топология сети
  • Сетевой интерфейс сервера
  • Процессор сервера
  • Память сервера
  • Производительность сервера
  • Неэффективная настройка

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

В каких случаях нужно увеличить значения параметров очередей приема и передачи?

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

• Если CPU работает намного быстрее, чем сеть, или по одной сети передают данные несколько приложений. Обычно это характерно для больших многопроцессорных систем (SMP).
• Если для параметров tcp_sendspace и tcp_recvspace установлены большие значения. Они могут быть установлены например приложениями, которые посредством системных вызовов увеличивают объем буферов приема и передачи протокола TCP. В этом случае CPU может одновременно отправить адаптеру большое количество пакетов. Аналогичная ситуация может возникнуть при изменении параметров udp_sendspace и udp_recvspace протокола UDP.
• При резком возрастании плотности потока данных.
• При отправке небольших пакетов нагрузка на сеть выше, чем при отправке больших сообщений. Это связано с тем, что передача больших сообщений по сети занимает большее время. Соответственно, за единицу времени будет передаваться меньшее число сообщений.

• Software. Ресурсы, используемые конкретным процессом, определить довольно сложно. Это не только техническая, но также и методическая трудность. Если разные экземпляры данной программы, запущенные несколькими пользователями, совместно обращаются к одним и тем же страницам текста программы, то к какому процессу нужно относить использование этих страниц памяти? Операционная система хранит в кэш- памяти страницы файлов, использованные недавно, чтобы программы могли повторно обращаться в этим данным. Если программа несколько раз обращается к одним и тем же данным, то следует ли учитывать тот объем памяти, который использовался для хранения этих данных? Точность некоторых измерений, например, показаний системных часов, может привести к сложностям при оценке времени использования CPU последовательно запускаемыми экземплярами одной и той же программы. Существует два подхода к анализу неоднозначных данных, содержащихся в отчете об использовании ресурсов. Первый основан на том, что неопределенности игнорируются, а изменяющиеся величины исключаются из рассмотрения до тех пор, пока в результате измерений не начнут поступать согласованные данные. При втором подходе по возможности измеряются реальные параметры, а для описания результатов применяются статистические методы. Второй подход позволяет получить результаты, которые больше соответствуют реальным условиям. Случаи, когда в системе выполняется только одна программа, очень редки. Обычно в системе выполняются несколько демонов, обслуживаются активные соединения и одновременно работают несколько пользователей. При этом зависимость объема занятых ресурсов от числа выполняемых операций не линейная. Например, увеличение числа экземпляров программы может привести к использованию только нескольких новых страниц текста программы, поскольку большая часть программы уже была в памяти. В то же время, новый процесс может усилить конкуренцию за использование кэш- памяти процессора. Следовательно, он не только увеличивает конкуренцию за процессорное время, но и приводит к тому, что увеличивается время, затрачиваемое на выполнение одной команды. Это связано с возрастанием числа промахов в кэше, и в итоге приводит к снижению скорости выполнения всех процессов. В общем случае закономерность такова: чем выше уровень абстракции программы (например программа написана с использованием perl, awk и/или bash), тем сложнее гарантировать, что не возникнет никаких неожиданных проблем с производительностью.
  • Исполняемые программы
  • Обработчики прерываний. Для оповещения операционной системы о каком-либо внешнем событии применяется механизм прерываний, который позволяет приостановить выполнение текущей нити и передать управление обработчику прерываний. Перед запуском обработчика прерываний сохраняется информация о состоянии аппаратных компонентов, чтобы после обработки прерывания система могла восстановить среду выполнения нити. На работе обработчика прерываний сказываются те же задержки, связанные с перемещением по аппаратной иерархии, что и на работе обычных программ (исключение составляют страничные ошибки). Если обработчик прерываний вызывался достаточно давно (и программа не является крайне экономной по отношению к ресурсам), то маловероятно, что его код или дата сохранятся в TLB или кэш- памяти. Когда прерванная нить снова передается на выполнение, ее контекст (в частности, содержимое регистров) восстанавливается, поэтому она может продолжить свою работу. При этом содержание TLB и кэш-памяти формируется на основе последующих запросов программы. Таким образом, и в обработчике прерываний, и в прерванной программе будут возникать серьезные задержки, связанные с промахами при обращении к кэшу и TLB.
  • Ожидающие нити. Если запрос программы нельзя обработать немедленно, (например, операцию ввода-вывода нельзя выполнить из-за страничной ошибки), то до окончания обработки запроса нить переходит в состояние ожидания. Как правило, это приводит к дополнительным задержкам при работе с TLB и кэшем, не считая самого времени обработки запроса.
  • Нити, готовые к выполнению. Нить, ожидающая передачи на выполнение, фактически простаивает. Кроме того, для выполнения текущих нитей в кэше могут быть удалены данные нити, ожидающей передачи на выполнение, а из оперативной памяти могут быть выгружены ее страницы данных. Следовательно, когда нить будет передана на выполнение, возникнут дополнительные задержки при обращении к кэшу и оперативной памяти.
  • Нити, выполняемые в данный момент.
  • Инструкции, выполняемые в настоящий момент. Большинство машинных инструкций выполняются за один такт процессора, если при обращении к TLB или кэшу не возникнет промах. Однако если часто выполняется переход к различным частям программы, а данные считываются из различных областей памяти, то при обращении к TLB и кэшу возникает большое число промахов. В результате число тактов процессора, затрачиваемых на выполнение одной инструкции (CPI), может быть намного больше единицы. В этом случае говорят, что в программе ссылки расположены не компактно. Даже если программа содержит небольшое число инструкций, на их выполнение может быть затрачено довольно много тактов процессора. Это одна из причин, по которой нельзя оценить время выполнения программы, подсчитав число инструкций. Как правило, чем короче программа, тем быстрее она выполняется, однако размер программы не прямо пропорционален времени ее выполнения. Компилятор оптимизирует код программы таким образом, чтобы минимизировать число тактов процессора, необходимых на выполнение программы. Для того чтобы добиться максимальной производительности программы, нужно предоставить компилятору полную информацию, необходимую для эффективной оптимизации, а не строить предположения о том, какой способ оптимизации будет выбран компилятором.

• Сетевая плата
• OSI
• Настройка Gigabit Ethernet в ОС GNU/Linux и FreeBSD
• Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер
• Большие потоки трафика и управление прерываниями в Linux
• Что такое Ethernet
• ifconfig настройка сетевых карт
• ethtool - настройка сетевых интерфейсов в Linux
• Как пользоваться командой netstat -i
• Структура межсетевого протокола IPv4
• Порты TCP. Что такое TCP / IP порт
• UDP

• Буфер сетевой подсистемы Linux

Драйвер сетевой карты переправляет принятые пакеты в буфер сетевой подсистемы. Все передаваемые и принимаемые пакеты в сетевой подсистеме Linux хранятся и обрабатываются в специальных типовых буферах, называемых структурами буфера сокетов (struct sk_buff). Имеющиеся в памяти буферы организованы в очередь, которая управляется ОС. В случае, если нужно разместить поступивший в сетевую подсистему пакет, а существующие буфера заполнены данными, система выделяет в памяти место под новый буфер. Когда пакет обработан и надобности в нём больше нет, буфер не уничтожается, а помечается как свободный и может быть использован для размещения вновь поступившего пакета. Таким образом, обычно в системе существует некоторое количество свободных буферов, которые могут быть использованы для обмена пакетами с сетевыми интерфейсами.

Каждое ТСР- соединение требует наличия приемного и передающего буфера, тогда как для входящих UDP-соединений требуется только приёмный буфер.

• Polling режим.

Сетевые карты - устройства, управляемые прерываниями, то есть при получении пакета будет вызвано прерывание,так что драйвер знает, что есть пакет, который будет обработан. Как уже говорилось ранее, для загруженой системы, большой трафик, а соответственно и большое количество прерываний может стать проблемой. В Polling - режиме сетевая карта никогда не генерирует прерывание, а ждет, когда ОС опросит карту, накапливая тем временем информацю в буфере и надеясь, что он не переполнится. Этот Polling - драйвер обычно вызывается между двумя процессами, таким образом сокращающая время контекстного переключения. Хорошие драйвера могли бы переключать между IRQ и pollinfg режимами в случае если работа по прерываниям обнаруживает несколько раз подряд пустой буфер, и обратно, если буфер начинает переполняться.

OC: Fedora 13 (Goddard) Linux 2.6.34.9-69.fc13.x86_64.

Утилита dmesg выводит для каждого ядра процессора сообщение:

p4-clockmod: Warning: EST-capable CPU detected.
The acpi-cpufreq module offers voltage scaling in addition of frequency scaling.
You should use that instead of p4-clockmod, if possible.

Это сообщение связано с CPU Frequency Scaling - утилитами для масштабирования частоты процессора, для анализа можно использовать powertop и cpufreq-info (из пакета cpufrequtils).

Модуль ядра p4-clockmod поддерживает только performance и powersave регуляторов. Для процессоров Intel рекомендуется модуль acpi-cpufreq. Варианты модулей можно найти здесь:

# ls /lib/modules/$(uname -r)/kernel/arch/x86/kernel/cpu/cpufreq/
acpi-cpufreq.ko  p4-clockmod.ko  pcc-cpufreq.ko  powernow-k8.ko  speedstep-lib.ko

Отключим p4-clockmod и загрузим acpi-cpufreq.

# modprobe -r p4-clockmod
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.34.9-69.fc13.x86_64/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

Вывод ошибки говорит о том что у нас старый процессор и загрузка модуля acpi-cpufreq невозможно. Проверим какой процессор установлен:

# cat /proc/cpuinfo | grep "model name"
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz

Странно по информации в интернете с этими моделями процессоров работать правильно умеет только модуль acpi-cpufreq. Пробуем загрузить модуль SpeedStep

# modprobe speedstep-lib

Загрузился без ошибок.

Отключаем загрузку модуля p4-clockmod, для этого нужно создать файл как указано ниже или дописать строку в файл blacklist.conf

# nano /etc/modprobe.d/blacklist-p4-clockmod.conf
blacklist p4-clockmod