mayamba

4) Ваше мнение: курсы полезны или это пустая трата денег? Здесь обычно предлагают пару мнений: можно либо выкупать весь курс с нуля и становиться "разработчиком Пайтона" под ключ, а можно с книжкой изучить основу и выкупать только те курсы, которые заполняют пробелы в знаниях. В обоих случаях есть плюсы/минусы, ваше мнение?

5) И последний вопрос: как вы боретесь с профессиональным привыканием к одной области работы и расширяете свой кругозор? Имеется ввиду тот факт, что будучи, к примеру, sysdba, вы знаете много про СУБД, а про сети и прочее уже меньше. На всё вас не хватает (тупо не хватит времени), при этом на рынке труда требуется народ с возросшими скиллами и в сетях, и в ОС и пр. Думаю нет смысла спорить, что рынок труда ИТ сейчас перегрет предложениями со стороны работников. И вопрос больше в том, как совмещать работу в одной отрасли с изучением смежных, при этом и с получением опыта в этих смежных областях? Ваш опыт что подсказывает?

Список, возможно, расширю, если будет интересно.

Спасибо заранее.

• Использование/загрузка (UTILIZATION): среднее время, в течение которого ресурс был в работе или в обслуживании других систем. Обычно мы представляем использование в процентах за определенное время, например CPU, диски, и т.д.

• Насыщение (SATURATION): объем работы, который ресурс не может обслужить. Обычно мы представляем эту метрику как длину очереди.

• Ошибки (ERRORS): наличие ошибок любого рода, связанных с ресурсом и способных влиять на производительность: сбойные сектора на диске, ошибки сетевых протоколов и т.д.

Давайте определимся с понятием ресурса - это любой функциональный компонент вашей системы: сетевые соединения и процессоры, диски, память и прочее. Потенциально ресурс может быть исчерпан либо заблокирован и тем самым может быть спровоцирована ситуация "бутылочного горлышка" (bottleneck) или же вообще ошибки (error). При этом не исключается, что ресурс может быть вообще программным. Программные ресурсы мы рассматривать пока не будем, поэтому сосредоточимся на аппаратных ресурсах.

Важно помнить, что использование/загрузка и насыщение — это показатели зависящие от времени, поэтому поиск оптимального интервала наблюдения для их корректного определения может потребовать тестов и некоторого исследования с помощью некоторой системы мониторинга. Так, в ходе тестов системы мониторинга любого рода стоит предусмотреть ситуацию, когда всплеск использования либо загрузки ресурса может вызвать проблемы с насыщением и производительностью, хотя на значительном промежутке времени использование либо загрузка ресурса может быть в среднем небольшим. Сокращение же временного интервала может выявить всплески (burst) использования либо загрузки ресурса.

Начать использовать метод USE достаточно просто:

1. Создайте контрольный список ресурсов. Подумайте обо всех различных ресурсах, которые использует ваша система, и о том, как вы хотите их измерить. Некоторые ресурсы способны вызывать проблемы с производительностью более чем одним способом: например, сетевое соединение может вызывать проблемы с I/O, а также проблемы с производительностью CPU. Удостоверьтесь, что создали отдельный элемент мониторинга для каждого типа проблемы, чтобы сделать процесс идентификации более полным и быстрым.

   Метод USE лучше всего работает с ресурсами, производительность которых снижается при интенсивном использовании. Он плохо работает с ресурсами, использующими кэширование, поскольку кэширование повышает производительность ресурсов при интенсивном использовании.

   В дополнении, часто упускается из виду, что CPU, память и ввод-вывод (I/O) связаны между собой, однако проблемы производительности в этом моменте достаточно редки. С другой стороны, если это все-таки так, то у вас крупные проблемы с аппаратной либо программно-аппаратной частью системы и стоит задуматься об обновлении либо оптимизации "железа" системы. В любом случае, метод USE подскажет вам в этом случае то, что проблемы с ресурсами в иных подсистемах отсутствуют и стоит повнимательнее отнестись к производительности соединений компонентов.

2. Построение системы мониторинга. На этом этапе необходимо в выбранной системе мониторинга создать метрики, учитывая список ресурсов и типы метрик. Для каждого ресурса стоит предусмотреть надежный способ сбора метрик каждого типа (загрузка/насыщение/ошибки), их обработку и своевременное уведомление системы или пользователя об отклонениях от заданных значений. Например для системы хранения данных имеет смысл анализировать ошибки устройства (errors: hard/soft), насыщение (длина очереди ожидания, wait queue length), использование либо загрузку (device busy, %).

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

   - Использование/загрузка ресурса: максимальная загрузка ресурса обычно является признаком проблемы. Чрезмерная загрузка (например, более 70%) может стать проблемой по нескольким причинам: когда загрузка ресурса измеряется в течение относительно длительного периода времени (несколько секунд или минут), общая загрузка, скажем, 70 % может скрыть короткие всплески 100 % загрузки.

   Некоторые системные ресурсы, такие как жесткие диски, не могут быть прерваны во время операции даже для работы с более высоким приоритетом. Когда их загрузка превышает 70%, задержки в очереди могут стать более частыми и заметными. С другой стороны, CPU могут быть прерваны («разгружены») практически в любой момент.

   - Насыщенность: любая ненулевая степень насыщенности может быть проблемой. Это может быть измерено как длина очереди ожидания или время ожидания в очереди.

   - Ошибки: заслуживают изучения ненулевые счетчики ошибок, особенно если они продолжают увеличиваться при сохраняющейся низкой производительности.

4. Уже добавлю от себя: согласуйте предельные параметры с имеющимся в комании или у клиента SLA. В вашей компании может иметься действующий SLA, который может описывать доступность некоторых систем. Добавляя в систему мониторинга метрики и устанавливая предельные значения срабатывания (например предустановки триггеров в Zabbix) имеет смысл удостовериться, что вы не выходите за пределы действующего SLA и проблема не успеет развиться до такого состояния, при котором может произойти нарушение соглашения.

5. И тоже от себя: настроив систему мониторинга сразу настраивайте весь спектр требуемых оповещений и уведомлений, включая информационные панели и мнемосхемы. Рекомендую поначалу тестировать систему мониторинга и особенно уведомлений "на кошках", то есть на группе коллег, которые не будут впадать в панику при каждом оповещении об уровне загрузки CPU в 100%. Затем планомерно и вдумчиво настраивайте систему на оптимальный уровень срабатывания уведомлений и контроля данных. Цель всех действий состоит в том, чтобы выявлять проблемы на ранней стадии и решать их до того, как они повлияют на пользователей или производительность системы.

У автора метода можно найти неплохую таблицу для контроля производительности различных ОС, находится она тут: https://www.brendangregg.com/USEmethod/use-rosetta.html Отнеситесь к ней как к руководству, но не как к единственно верному способу контроля требуемых параметров.

В заключении стоит сказать, что метод USE действительно работает как базовый метод для быстрого развертывания мониторинга производительности и дает отличные результаты.

Если будут какие-либо пожелания или вопросы - добро пожаловать в комментарии.

Другой пример связан с транспортом: железнодорожный состав способен перевезти в разы больше груза, чем автомобильный транспорт. Но у последнего потенциально выше скорость. Можно сказать, что у ж/д состава выше пропускная способность, а у автомобиля - меньше задержка.

Теперь давайте подумаем, как это применимо к компьютерным системам. Если говорить про сеть, то обмен данными там идет пакетами, то есть обособленными единицами, каждая из которых имеет служебные данные (service data/protocol overhead) и полезную нагрузку (payload). Последняя как раз-таки и представляет интерес, мало кого из пользователей заботит служебная информация. Увеличить пропускную способность сети мы можем, применяя jumbo packets - увеличенные в размерах пакеты (~9000 байт и более вместо 1518 байт) - обмениваясь такими единицами, мы повышаем количество полученной информации, то есть растет параметр пропускной способности. Но при этом растут и затраты на передачу такого объема, занятость линии, загрузка аппаратной части и прочие вещи. То есть мы при этом ухудшили параметр задержки.

С другой стороны, можем сделать пакеты совсем мелкими, как в протоколе АТМ (48 байт), но теперь каждые 48 байт мы будем обязаны вставить служебную информацию. Уменьшилась задержка, уменьшилась пропускная способность.

Что лучше? Вопрос открытый. Если ваша система - трубопровод и вы качаете нефть, то, вероятно, вам будет важна пропускная способность. Для компьютерных систем, вероятно, можно привести пример систем, работающих без участия человека: хранение информации и ее передача, замкнутые системы СУБД и пр. Если же ваша система - логистика пищевых продуктов, например, доставка горячей еды, то вы заинтересованы в сокращении времени ожидания - то есть в уменьшении задержки. Для компьютерных систем происходит ровно то же самое: если в процессе обработки появляется человек, то задержка начинает играть роль. Мы начинаем замечать ее уже на уровне 100 миллисекунд, а уже при 200-300 мс она начинает нас раздражать. Телефонные линии спроектированы с учетом задержки в 100 мс.

Таким образом, производительность ОС Linux и работы по ее улучшению тесно связаны с рядом аспектов системы, первый из которых - что это за система и какова ее роль.