Утилизация процессора что это
CPU bound — In computer science, CPU bound (or compute bound) is when the time for a computer to complete a task is determined principally by the speed of the central processor: processor utilization is high, perhaps at 100% usage for many seconds or minutes … Wikipedia
CPU cache — Cache memory redirects here. For the general use, see cache. A CPU cache is a cache used by the central processing unit of a computer to reduce the average time to access memory. The cache is a smaller, faster memory which stores copies of the… … Wikipedia
Avaya Unified Communications Management — Developer(s) Nortel (now Avaya) Operating system MS Windows, and Linux Type Unified Communications Configuration and Management Avaya Unified Communications Management in computer networking is the name of a collection o … Wikipedia
Thrash (computer science) — In computer science, thrash (verb), is the term used to describe a degenerate situation on a computer where increasing resources are used to do a decreasing amount of work. In this situation the system is said to be thrashing . Usually it refers… … Wikipedia
Tagged Command Queuing — (TCQ) is a technology built into certain ATA and SCSI hard drives. It allows the operating system to send multiple read and write requests to a hard drive. ATA TCQ is not identical in function to the more efficient Native Command Queuing (NCQ)… … Wikipedia
Rate-monotonic scheduling — In computer science, rate monotonic scheduling [citation|first1=C. L.|last1=Liu|authorlink1=Chung Laung Liu|first2=J.|last2=Layland|title=Scheduling algorithms for multiprogramming in a hard real time environment|journal=Journal of the ACM|volume … Wikipedia
Norton AntiVirus — Developer(s) Symantec Corporation Stable release … Wikipedia
Direct memory access — (DMA) is a feature of modern computers that allows certain hardware subsystems within the computer to access system memory independently of the central processing unit (CPU). Without DMA, the CPU using programmed input/output is typically fully… … Wikipedia
Peer-to-Peer Protocol (P2PP) — Application layer protocol that can be used to form and maintain an overlay among participant nodes. Provides mechanisms for nodes to join, leave, publish, or search for a resource object in the overlay. Maintaining information about nodes in… … Wikipedia
Unified Video Decoder — The Unified Video Decoder, previously called Universal Video Decoder , or UVD in short, is the video decoding unit from ATI Technologies to support hardware decode of H.264 and VC 1 video codec standards, and being a part of AVIVO HD… … Wikipedia
Привет! Меня зовут Александр Петровский, я инженер в DINS. Я работаю в команде, которая участвует в разработке сервисов облачной телефонии и видеоконференций. Каждый из них состоит из большого количества микросервисов.
Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.
Проблема
Для начала немного о том, что представляет собой наш микросервис: это in-house L3/L4 balancing router. Ядро сервиса состоит из eBPF/XDP [1] приложения, которое загружается в ядро Linux («живет» в SOFTIRQ) и решает задачи балансировки/роутинга сетевых пакетов до конечных бэкендов — это наш data plane. Cервис похож на katran [2] у Facebook, maglev [3] у Google, unimog [4] у Cloudflare и glb [5] у Github, но за небольшим исключением, что выгодно отличает нас от остальных. Серверы, на которых расположен микросервис (далее по тексту «ноды»), соединены между собой в кластер, а также соединены по BGP с L3 Juniper роутерами и получают от них сетевые пакеты с помощью ECMP. Сами кластеры располагаются в разных дата-центрах и соединены между собой, каждая нода в кластере знает состояние всех соединений во всех присоединенных кластерах. За это отвечает приложение на Erlang совместно с приложением на Golang как адаптером для работы с eBPF/XDP — это наш control plane. Таким образом, каждая нода готова балансировать/роутить пакеты в кластере, если все остальные ноды в кластере выйдут из строя. Каждый кластер в свою очередь готов балансировать/роутить пакеты других присоединенных кластеров, если они выйдут из строя.
В ходе миграции на наших stress/performance-тестах, которые генерируют высокий PPS, мы заметили рост утилизации процессора примерно на 10% на Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek по сравнению с CentOS 7 с ядром 4.19.125-1:
CentOS 7 с ядром 4.19.125-1 (the plot is stacked) на str01-t01-**r01 Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek (the plot is stacked) на str01-t01-**r02
Тут в первую очередь нам интересен рост утилизации процессора в SOFTIRQ: 13% vs. 26%. SOFTIRQ показывает время, затрачиваемое процессором при обработке некоторых soft deferred задач. Таких как обработка сетевых пакетов (rx/tx), RCU, таймеров и tasklet'ов. Следовательно, нам нужно выяснить, на что больше всего процессорного времени тратится в SOFTIRQ?
Исследование в user-space
Чтобы определить, на какой тип задач (обработка сетевых пакетов (rx/tx), RCU, таймеров и tasklet'ов) процессор тратит больше всего времени в SOFTIRQ, достаточно заглянуть в файл /proc/softirqs. Для нас интересны в первую очередь NET_TX и NET_RX. Пожалуйста, обратите внимание — файл содержит статистику по разным типам задач SOFTIRQ с начала старта системы и в данном случае, нам интересна только скорость роста этих значений:
Из листингов выше видно, значения NET_TX и NET_RX во времени растут примерно с одинаковой скоростью.
Но все-таки, кто же из них стал работать медленнее и как следствие тратить больше процессорного времени? Чтобы это определить, можно воспользоваться набором скриптов из пакета BCC. Скрипт /usr/share/bcc/tools/softirqs из этого пакета просуммирует время, затрачиваемое каждыми типом задач в SOFTIRQ в течении 10 секунд. Пожалуйста, обратите внимание, оригинальный скрипт был модифицирован для сбора статистики только на 0-м ядре процессора для большей точности и гранулярности:
После анализа листингов выше видно — основное время затрачивается при обработке входящего трафика — NET_RX. И самое странное, время в обоих случаях почти одинаково — ~266ms (str01-t01-**r01) vs. ~271ms (str01-t01-**r02). Т.е. примерно от ~266ms до ~271ms тратится на NET_RX на 0-м ядре процессора (как и на всех остальных ядрах, очевидно) в каждую секунду времени. Но! в процентном соотношении это не 13% vs. 26% как мы видели на графиках выше. It seems like we need to go deeper. :(
Исследование в kernel-space
Для дальнейшего анализа и понимания проблемы, нужно немного углубиться в то, как работает SOFTIRQ. SOFTIRQ запускается когда:
system call возвращает управление в user-space;
hardware interrupt handler возвращает управление в ядро.
Упрощённо, общий процесс работы NET_RX и обработки сетевых пакетов выглядит следующим образом: драйвер сетевого интерфейса регистрирует свой callback как NAPI poll-функцию — vmxnet3_poll_rx_only в нашем случае. При поступлении очередного пакета драйвер информирует (нотифицирует) NAPI, о том, что один из softirq callback'ов готов к работе. Ядро вызывает _do__softirq функцию, которая вызывает net_rx_action функцию, которая уже в свою очередь вызывает NAPI poll-функцию vmxnet3_poll_rx_only. Далее эта функция в течении некоторого времени вычитывает сетевые пакеты из DMA-памяти сетевого интерфейса. Время работы функции обусловлено временным бюджетом (максимум до 2ms) или количеством пакетов, которые можно вычитать (до 64 пакетов за одну итерацию). В случае, если временной бюджет еще не исчерпан, и в DMA-памяти сетевого интерфейса есть еще пакеты, которые можно вычитать, происходит очередная итерация чтения пакетов. После этого ядро вызывает net_rps_send_ipi функцию (эта функция используется RPS подсистемой). И наконец вызывается функция process_backlog для непосредственной обработки вычитанных пакетов ядром (в контексте этой функции и работает ядро нашего сервиса — eBPF/XDP приложение) [6] [7] [8].
Для дальнейшего анализа нужно собрать stacktrace (с 0-го ядра) процессора на str01-t01-**r01 в течение 10 секунд:
Для наглядности полученный stacktrace я конвертировал во FlameGraph:
FlameGraph stacktrace'a ядра CentOS 7 с ядром 4.19.125-1 на str01-t01-**r01
И то же самое на str01-t01-**r02:
Полученный stacktrace также сконвертируем во FlameGraph:
FlameGraph stacktrace'a ядра Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek на str01-t01-**r02
Используя функцию поиска — search во FlameGraph — можно найти все вызовы функции net_rx_action и время (в процентах) затраченное ей на 0-м ядре процессора. Время в обоих случаях почти одинаково — ~23.1% (str01-t01-**r01) vs. ~23.4% (str01-t01-**r02).
подобные stacktrace'ы также можно собрать с помощью скриптов из пакета BCC
Следующим шагом для получения более полной картины было проведено инструментирование функциий _do__softirq, net_rx_action, vmxnet3_poll_rx_only, net_rps_send_ipi и process_backlog в течение 60 секунд с помощью bpftrace c использованием скрипта softirqlat.bt [10]:
Обобщая результаты
Среднее время затрачиваемое в секунду на обработку трафика в NET_RX в обоих случаях почти одинаково: ~266ms vs. ~271ms;
Среднее время (в процентах) затрачиваемое в секунду на обработку трафика функцией net_rx_action в обоих случаях почти одинаково: ~23.1% vs. ~23.4%;
Среднее время затрачиваемое в секунду в функциях _do__softirq, net_rx_action, vmxnet3_poll_rx_only, net_rps_send_ipi и process_backlog в обоих случаях почти одинаково. Отклонение времени в vmxnet3_poll_rx_only на некоторых ядрах процессора зависит от количества пакетов полученных на этом ядре (если быть более точным — на rx-queue ассоциированной с соответствующим ядром процессора);
Выглядит так, что проблема где-то в SOFTIRQ аккаунтинге.
Особенности утилизации серверов
Короткий аудит позволяет выявить «кандидатов» на оптимизацию. К слову, подобная услуга полезна не только при дефиците оборудования. В нашей практике были случаи, когда такие обследования инициировали новые ИТ-директора, чтобы понять, почему основная нагрузка приходится всего на 10% имеющихся систем и зачем тогда нужны все остальные. При слияниях и поглощениях это также актуально, так как перед интеграцией систем важно понимать, что из оборудования и в каком состоянии стоит на балансе. Примечательно, что при подобном «перетряхивании» можно обнаружить массу интересного. Например, серверы-призраков, закупленные ранее под проекты, но и в итоге так и не использованные. И такие случае не единичны в нашей практике. В целом, если судить по опыту крупных компаний, при парке от 50 до 100 серверов усредненный параметр утилизации центрального процессора на всех серверах может быть равен 5 – максимум 10%. Следовательно, найти незадействованные ресурсы можно практически всегда. Но важно понимать, как правильно перебалансировать нагрузку между системами, чтобы не пострадали бизнес-сервисы.
Использовать бесплатное/общедоступное ПО?
Оптимизационный аудит можно провести самостоятельно или с привлечением подрядчика. Все работы занимают около недели. При этом применяются специальные утилиты – по большей части свободное ПО.
Для каждого типа инфраструктуры они различны. Например, для оценки утилизации виртуальных машин (CPU/RAM/Disk) мы используем RVTools, а для физических серверов — Live Optics. Затем делаем срез конфигурации, в том числе во времени. В результате собираем статистику по параметрам (время отклика, задержка и т.д.). На основе этой информации можно обнаружить неоптимальные процессы и затем их «починить». В частности, можно виртуализовать физические серверы, перераспределить ресурсы по кластерам виртуализации, устранить причины аномальных нагрузок отдельных серверов, перенести часть виртуальных машин в облако.
Какие средства вообще есть:
самописные скрипты: RVTools, Get-HyperVInventory. Эти скрипты собирают данные с хостов в средах виртуализации VMware и Hyper-V соответственно. Их функционал схож, собранные данные сохраняются в форматы .xls и .html.
средства производителей, доступные бесплатно: Live optics;
средства производителей, доступные за деньги: HPE SAF.
Проблема
Для начала немного о том, что представляет собой наш микросервис: это in-house L3/L4 balancing router. Ядро сервиса состоит из eBPF/XDP [1] приложения, которое загружается в ядро Linux («живет» в SOFTIRQ) и решает задачи балансировки/роутинга сетевых пакетов до конечных бэкендов — это наш data plane. Cервис похож на katran [2] у Facebook, maglev [3] у Google, unimog [4] у Cloudflare и glb [5] у Github, но за небольшим исключением, что выгодно отличает нас от остальных. Серверы, на которых расположен микросервис (далее по тексту «ноды»), соединены между собой в кластер, а также соединены по BGP с L3 Juniper роутерами и получают от них сетевые пакеты с помощью ECMP. Сами кластеры располагаются в разных дата-центрах и соединены между собой, каждая нода в кластере знает состояние всех соединений во всех присоединенных кластерах. За это отвечает приложение на Erlang совместно с приложением на Golang как адаптером для работы с eBPF/XDP — это наш control plane. Таким образом, каждая нода готова балансировать/роутить пакеты в кластере, если все остальные ноды в кластере выйдут из строя. Каждый кластер в свою очередь готов балансировать/роутить пакеты других присоединенных кластеров, если они выйдут из строя.
В ходе миграции на наших stress/performance-тестах, которые генерируют высокий PPS, мы заметили рост утилизации процессора примерно на 10% на Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek по сравнению с CentOS 7 с ядром 4.19.125-1:
CentOS 7 с ядром 4.19.125-1 (the plot is stacked) на str01-t01-**r01 Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek (the plot is stacked) на str01-t01-**r02
Тут в первую очередь нам интересен рост утилизации процессора в SOFTIRQ: 13% vs. 26%. SOFTIRQ показывает время, затрачиваемое процессором при обработке некоторых soft deferred задач. Таких как обработка сетевых пакетов (rx/tx), RCU, таймеров и tasklet'ов. Следовательно, нам нужно выяснить, на что больше всего процессорного времени тратится в SOFTIRQ?
Live Optics: как может быть использовано
Устанавливается на одну из централизованных машин в сети с серверами. Для его работы требуется Net.4.5. Софт работает с анализом не только серверов, но и СХД и данных, поэтому раздел для серверов — Server&Virtualization.
Как подключить сервер: добавить удаленный сервер через «Add Remote Server» и ввести запрашиваемые данные (Server URL), выбрав Connect to a Windows Server/supported Linux/UNIX Server.
Выбрать длительность сбора и нажать «Start Capture».
После окончания сбора статистики появится файл с расширением .iokit. Обычно его размер не более нескольких десятков МБ. Сбор данных увеличивает нагрузку на CPU незначительно, как правило, всего на несколько процентов.
Здесь видна статистика по серверам, включенным в обследование. Можно увидеть суммарный объем физических характеристик обследуемого объема серверов, распределение используемых ОС, пять основных серверов по выбранному параметру.
На вкладке «виртуальный» можно увидеть суммарную информацию по физическим и виртуальным ресурсам, графики распределения ресурсов и полный перечень виртуальных машин с их основными характеристиками.
Для каждой виртуальной машины доступна информация о ее статусе, имени, ОС, полном и занятом объеме дисковых ресурсов, полном и используемом объеме ОЗУ, количестве виртуальных CPU и платформе виртуализации.
На вкладке «производительность» представлены кластеры виртуализации, входящие в них гипервизоры и расположенные на них виртуальные машины. По каждому из вышеперечисленных объектов составляются графики за выбранный период сбора данных по следующим величинам:
Заключение
Теперь можно точно сказать — Oracle Linux 7 c ядром 5.4.17-2102.200.13.el7uek и включенной опцией CONFIG_IRQ_TIME_ACCOUNTING более точно производит подсчет тиков процессора и показывает более реальную статистику утилизации процессора, чем CentOS 7 с ядром 4.19.125-1 и выключенной опцией CONFIG_IRQ_TIME_ACCOUNTING.
Спасибо, что прочли до конца, я буду рад вопросам и постараюсь на них ответить в комментариях.
Метрика загруженности процессора (CPU utiliztion), которую все мы привыкли использовать, обычно понимается неправильно. Что такое загруженность процессора? То насколько процессор сейчас занят работой? Нет, это не так, и да, я говорю о метрике %CPU , которая используется всегда и везде, в каждой утилите мониторинга производительности, например в top(1) .
Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже?
Вот что это значит на самом деле:
Stalled, то есть "приостановлено" значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между "занято" и "приостановлено" (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь.
Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это "не-idle время", то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени.
Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался "DUMMY JOB" и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее).
Что же с этой метрикой не так?
В наши дни процессоры работают значительно быстрее памяти, поэтому время ожидания памяти доминирует в метрике "нагрузка на процессор". Когда вы видите большие значение %CPU в top(1) , вы, должно быть, думаете, что процессор является бутылочным горлышком, когда на самом деле проблема в DRAM.
Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.
Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:
Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии).
Это означает, что процессор может выполнить 4 операции за каждый такт, поэтому значение 0.78 для 4-wide системы означает, что процессор работает на 19,5% от своих возможностей. Новый процессор Skylake от Intel - это 5-wide процессор.
Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.
Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.
Если ваш IPC > 1.0, то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов.
Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.
Каждая такая утилита должны показывать IPC вместе с нагрузкой на процессор. Или разделять нагрузку на процессор на instruction-retired и циклы stalled циклы, то есть, %INS и %STL .
Кроме утилиты top(1) для Линукса есть утилита tiptop(1) , которая показывает IPC для каждого процесса:
Проблема со stalled-циклами может быть не только в задержках связанных с памятью:
- изменение температуры может влиять на приостановленность процессора,
- турбобуст может менять тактовую частоту процессора,
- ядро варьирует частоту процессора с определенным шагом,
- проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
- спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.
Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC < 1.0, то вероятно вы упираетесь в память, если IPC > 1.0, то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.
Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.
(14) понимаешь в процессоре живет очень много маленьких человечков, они переносят байты с одного места на другое. Количество человечков обычно пишут в маркировке процессора. Так вот, у этих человечков есть начальник, который и определяет сколько человечков работают, а сколько лоботрясничают. И процентное соотношение этих работающих и неработающих человечков и есть % использования процессора.
(19) а попробуй объясни как это выяснить сколько "использования ЦП" занимает подключение к примеру усб-устройства ?
Я утилизировал Целерон-366 путем отдавания его в пользование ребенку. Он его таскал в портфеле и показывал знакомым пацанам. Щас валяется у него на столе и используется почти в качестве брелока-игрушки. :))
з.ы. вот думаю - может ему отдать пару материнок от 286 компа? :)))
(21) Без проблем. Делаешь ps -e, находишь номер процесса, который занимается обработкой твоего usb устройства. Затем заходишь в /proc/номер процесса/ там есть файлик, в котором написано сколько "тиков" процессора использовал данный процесс. Делаешь выборку за несколько секунд и делишь колическтво потраченных "тиков" на общее число. Общее число лежит в фале в каталоге /proc/. Имя файла я точно не помню, но гугл в помощь.
(23) Хорошая идея. Поставь туда паскаль и дай пару занимательных книжек по программингу. Пусть побалуется, когда игрушки надоедят.
(26) Я уже давно его к этому делу подталкиваю. Он даже в VB6 кое-что "творил", но. Игрушки победили :((( Их тварей клепают с поражающей скоростью :(((
(27) VB - отстой. Поставь ему линукс, пусть с ним повозится, тоже очень развивает. Ну и на программирование может плавно перескочит )
(28) КУЯСЕ. Я его сам не знаю! Так что еще вопрос - куму развиваться в первую очередь придется :)))
з.ы. А мне оно точно не надь :)) Неохота. :))
(29) Да ладно тебе, он по большей части дружественный. Просто есть пара вещей, из-за которых для детей он лучше чем винда:
- Чтоб поставить игрушку, придется поразбираться )
- Чтоб настроить что-то нестандартное, придется хорошо поразбираться.
А работа мозга - штука полезная ;)
(30) Не, не будет разбираться. В 12 лет не о том они думают. По крайней мере моему пока рановато. Да и живет с "бывшей" - я в другом месте.
В одном из прошлых постов мы разбирали методологию аудита инфраструктуры. С течением времени эта тема ничуть не потеряла своей актуальности: комментаторы интересовались, можно ли на фоне полупроводникового кризиса хотя бы чуть-чуть «дожать» свою инфраструктуру, чтобы ее мощностей хватило еще на полгода-год. Иными словами, компаниям требуется апгрейд, однако оборудование приходит с большими задержками и поэтому требуется искать способы «переждать» этот период с минимальными издержками.
Мы провели ревизию и подготовили небольшой гайд, который поможет тем, кто оказался в подобной ситуации. Под катом разберем наиболее распространенные причины потери производительности и инструменты для аудита утилизации.
Чаще всего клиенты обращаются к нам за аудитом инфраструктуры в трех ситуациях:
Оборудование утилизируется не полностью «по историческим причинам».
К примеру, бизнес запрашивает у ИТ-департамента ресурсы под свои нужды: серверы, виртуальные машины, однако утилизирует их далеко не полностью, а со временем и вовсе «забывает» об их существовании. С подобной проблемой к нам обратился один крупный банк. По окончании аудита удалось «высвободить» порядка 25% неиспользуемых мощностей.
Простой, но часто встречающийся кейс: приходит пора закупать новое оборудование.
На первый взгляд ландшафт утилизирования инфраструктуры у клиента выглядит равномерно, ресурсы расходуются грамотно. Но на разных по объему платформах утилизация происходит по-разному. Иногда можно высвободить немало ресурсов за счет консолидации платформ.
Перейдем к обзору утилит, которые мы используем в рамках обследований инфраструктуры. Для удобства все средства анализа утилизации будут разбиты по направлениям их применения.
Обзор средств анализа серверной инфраструктуры
Исследование SOFTIRQ accounting'а
После чтения исходных кодов ядра Linux методом пристального вглядывания, стало понятно, что SOFTIRQ accounting производится в разных функциях, одна из них — irqtime_account_process_tick, и для нас она наиболее интересна. Комментарий в этой функции сообщает следующее:
When returning from idle, many ticks can get accounted at once, including some ticks of steal, irq, and softirq time.
Эта функция может быть включена/отключена на уровне конфига ядра с помощью опции CONFIG_IRQ_TIME_ACCOUNTING. Когда она включена, SOFTIRQ accounting производится более аккуратно, и наоборот — когда эта опция отключена, тики процессора могут быть подсчитаны неточно :(
Выглядит так, что CentOS 7 с ядром 4.19.125-1 считает тики процессора не точно, а Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek показывает более реальную статистику утилизации процессора в SOFTIRQ. Для подтверждения этой гипотезы было собрано новое ядро Oracle Linux 7 5.4.17-2102.200.13.el7uek с отключенной опцией CONFIG_IRQ_TIME_ACCOUNTING (это было сделано на str01-t01-**r03):
Левый график — нагрузка на str01-t01-**r01 с CentOS 7 с ядром 4.19.125-1 с отключенной CONFIG_IRQ_TIME_ACCOUNTING опцией;
Центральный график — нагрузка на str01-t01-**r02 с Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek с включенной CONFIG_IRQ_TIME_ACCOUNTING опцией;
Правый график — нагрузка на str01-t01-**r03 с Oracle Linux 7 с пересобранным ядром 5.4.17-2102.200.13.el7uek с отключенной CONFIG_IRQ_TIME_ACCOUNTING опцией.
Читайте также: