[00:02] методы, которые помогут нам эффективно диагностировать и решать проблемы с производительностью в системах Leux. Прежде чем углубляться в технические детали, давайте поговорим о важнейшем первом шаге, который иногда упускают из виду даже опытные разработчики: проверка наличия
[00:14] реальной проблемы с производительностью. Когда кто-то сообщает о проблеме с производительностью, нам нужно задавать уточняющие вопросы: что заставляет нас думать, что есть проблема; работала ли система когда-либо лучше; какие недавние изменения могли
[00:27] повлиять на производительность; можем ли мы количественно оценить, что означает «медленно» в этом контексте; затрагивает ли проблема нескольких пользователей или только одного? Эти вопросы — не просто формальности, они помогают прояснить проблему, установить базовый уровень для сравнения, а
[00:42] иногда даже решить проблему без дальнейшего расследования. Позвольте мне привести быстрый пример из реальной жизни: разработчик однажды пожаловался на медленный запрос к базе данных, занимающий 5 секунд. После расследования мы обнаружили, что этот запрос
[00:55] всегда занимал 5 секунд. Проблема заключалась не в производительности, а в несоответствии ожиданиям EXP. Представьте, если бы я сразу же приступил к устранению неполадок, не задавая вопросов, я бы потратил время и ресурсы на поиск несуществующей проблемы.
[01:09] В других случаях это называется « подходом Кэннона к портам» — слепая замена портов в надежде исправить проблему. Это подчеркивает, почему...  Крайне важно подтвердить наличие реальной проблемы с производительностью, прежде чем приступать к анализу. Это сэкономит время и
[01:22] позволит нам сосредоточиться на решении реальных проблем, а не на поиске несуществующих причин. После подтверждения реальной проблемы с производительностью необходимо точно её определить. Это означает переход от расплывчатых терминов, таких как «медленно», к конкретным метрикам: например, «занимает ли веб-страница 10
[01:36] секунд» или «затягивается ли запрос к базе данных», « время ожидания». Нам нужно точно определить, когда и где возникают эти проблемы, а также понять масштаб и влияние: затрагивает ли это все серверы или только один, сколько пользователей затронуто и каковы
[01:51] последствия для бизнеса. Наконец, мы исследуем источник проблемы: связана ли низкая производительность с легитимной активностью пользователей, конкретным приложением или, возможно, запущенным процессом. Мы количественно оцениваем это в терминах запросов в секунду,
[02:05] скорости передачи данных и того, как это меняется со временем. Такой целенаправленный подход создает четкую дорожную карту для нашего исследования, гарантируя, что мы не будем тратить время на несвязанные области. Теперь давайте рассмотрим некоторые основные инструменты, которые могут помочь нам собрать эту
[02:20] информацию и точно определить первопричину наших проблем с производительностью. Начнем с времени безотказной работы. Ключевой метрикой здесь является среднее значение низкой производительности, которое показывает среднее количество процессов, которые либо запущены, либо ожидают ресурсов за
[02:33] последние 15 и 15 дней.  15 минут — это сложный показатель, на который могут влиять различные факторы. Если эти числа постоянно превышают количество ядер ЦП, это может указывать на конкуренцию процессов за ресурсы,
[02:46] но это не всегда так просто. Высокие и низкие средние значения могут быть вызваны ресурсоемкими задачами ЦП, узкими местами ввода-вывода или даже быстро появляющимися и исчезающими процессами. Помните, что низкое среднее значение само по себе не отражает всей картины, это
[03:01] скорее отправная точка, которая подсказывает нам, что нам может потребоваться дальнейшее исследование. Когда мы видим повышенные и низкие средние значения, это означает, что нужно использовать другие инструменты для более глубокого анализа. Это подводит нас к следующему инструменту: top. top предоставляет динамическое, постоянно обновляемое
[03:15] представление процессов системы и ключевых показателей. Это как панель мониторинга производительности системы. Некоторые ключевые показатели, за которыми следует следить, — это процент использования ЦП следить, — это процент использования ЦП пользовательскими и системными процессами.
[03:28] процессов. Обратите особое внимание на любые процессы, потребляющие необычно высокий процент ЦП или памяти. Это может быть причиной проблем с производительностью. Помните, что top дает нам снимок
[03:42] текущего момента. Для более полной картины нам может потребоваться отслеживать ситуацию в течение времени или использовать другие инструменты для дополнения вашего анализа. Далее — VM.  Команда `stat VM stat` отображает несколько компонентов системы одновременно, обновляясь в режиме реального времени. Ключевые области для наблюдения
[03:57] обновляясь в режиме реального времени. Ключевые области для наблюдения включают в себя скорость ЦП, активность подкачки ioe и время ожидания ввода-вывода в разделе ЦП. Для более подробного анализа вернитесь к `iio stat` — это даст нам непрерывное представление об этой активности. Ключевые показатели для наблюдения — количество
[04:11] транзакций в секунду для этой активности и процент времени, затраченного на ожидание операций ввода-вывода в разделе ЦП. Команда `iio step` разбивает операции ввода-вывода по устройствам. Это полезно, когда нам нужно определить, какой именно диск
[04:26] вызывает проблемы с производительностью. Теперь давайте изучим Net — полезный инструмент для мониторинга сетевых подключений. `net stat` имеет множество опций, мы сосредоточимся на нескольких полезных для анализа производительности. Сначала давайте перечислим все активные подключения. Эта команда
[04:42] отображает все активные подключения, как входящие, так и исходящие. Она полезна для определения открытых портов и активных служб в нашей системе. Мы можем отображать только прослушиваемые порты. Мы также можем подсчитать подключения для определенного порта. Здесь
[04:56] мы подсчитываем подключения на порту 80. Эта быстрая команда может помочь нам оценить нагрузку на определенную службу. Если мы видим необычно большое количество подключений, это может указывать на потенциальную проблему с производительностью — всплеск трафика, требующий
[05:10] расследования.  И наконец, давайте рассмотрим SAR, что означает « отчет об активности системы». Это универсальный инструмент, отлично подходящий для анализа исторических данных. Вот пример того, как он сообщает об использовании ЦП. В то время как SAR предоставляет аналогичную информацию, как и
[05:24] другие инструменты, которые мы обсуждали, его отличает способность сохранять исторические данные. Многие дистрибутивы Linux настраивают SAR на периодический сбор данных. Этот автоматизированный сбор данных может быть бесценным. Если пользователи сообщают о периодических
[05:39] замедлениях, мы можем использовать SAR для анализа предыдущих дней и выявления тенденций производительности. Это особенно полезно для сопоставления производительности системы с конкретным временем или событиями. Он может выявлять закономерности, неочевидные при
[05:52] мониторинге в реальном времени. Важно подчеркнуть, что мы здесь лишь поверхностно рассматриваем этот вопрос. подчеркнуть, что мы здесь лишь поверхностно рассматриваем этот вопрос. каждого уровня системы, от оборудования до приложений, и для
[06:05] каждой подсистемы, от файловых систем до сетевых стеков. Помните, что этот процесс итеративный. Нам может потребоваться использовать несколько инструментов и углубляться в анализ в зависимости от того, что мы обнаружим. Ключевой момент — начать с широкого спектра инструментов, таких как uptime и top, а затем сузить
[06:20] фокус на основе того, что мы обнаружили. Если вам нравятся наши видео, вам также понравится...  В нашей рассылке по системному проектированию мы освещаем важные темы в области проектирования крупномасштабных систем. Присоединяйтесь к нашему сообществу из 1 миллиона подписчиков из технологической
[06:34] of 1 million subscribers from the tech industry subscribe at blog. bio.com