что такое нагрузка memctrl

Немного истории

реклама

Перечитав кучу статей вижу, что карты достаются только майнерам, так что выход найден: самому.

Стать майнером

$300 по текущим курсам. Перевожу на BTC и Ether кошельки, но в реальные деньги выводить пока не пробовал. Считаю, что моя 3080 уже стала немного дешевле.

Но вернемся к теме.

Перегрев памяти

реклама

Поиграл с настройками, направил вентилятор на бекплейт (что мало помогло).

реклама

И пришел вот к каким выводам:

Итого

Вот что у меня получилось после установки вентилятора на 73% и снижении разгона памяти до +800 мегагерц.

Частота и напряжение на GPU заданы через кривую в MSI afterburner на 1400Mhz и 0.743v, так что потребление не выходит за 70% (

220W). Температура памяти остановилась на 96 градусах, что намного лучше 100+ при вентиляторах в режиме авто.

Карты после майнинга

реклама

Старый вопрос опять станет актуальным, когда пройдет и этот бум. Покупать 3080 после майнинга или нет?

Мои старые карты десятой серии тоже «после майнинга» от завязавших майнеров 2017, но я брал с остаточной гарантией и на пломбах.

Стоит ли брать карты без пломб с «замененной термопастой«?

Однозначно, не стоит гнать память на картах после майнинга. Для игр прирост небольшой, а риски возрастают.

Майнить можно и на одной карте. Делать это можно не ради выгоды, а для получения минимальных знаний о криптовалютах.

Следите за температурами и не перегревайтесь!

Источник

Индуктивная нагрузка при массовом отключении/включении ригов

@ndrei

Бывалый

Предположим есть у вас помещение в далеке от вашего места проживания.
Подведено туда 10 квадратов 220Вольт тоесть 50А тоесть 11квт мощности.
Стоят там много ригов и майнят.

Внезапно отключается свет, риги встают, конденсаторы на БП разряжаются, потом включается свет и БП еще до включения ригов начинают массово жрать электричество в свои электролиты.
Это называется индуктивной нагрузкой, она может по мощности превышать во много раз обычную нагрузку.
Что произойдет с автоматами я надеюсь вы понимаете. Их вырубит.
Придется ехать и включать вырубленные автоматы.

Как защититься от индуктивной нагрузки? Легко, надо поставить автоматы характеристики D, риск выключиться уже будет меньше.
Но я боюсь это тоже может не помочь, тк вы представьте что 15 БП 750Вт одновременно включили в сеть, ну для любого автомата это будет КЗ, к гадалке не ходи, электромагнитный расцепитель подумает что это КЗ и будет прав.

@ndrei

Бывалый

Реальный пример, 3 БП Zalman 650W, включенные одновременно в сеть, вырубили 32А автоматический выключатель характеристики C. При последовательном подключении не вырубают.

В голове уже где то витает идея (контакторы/таймеры) но это же колхоз, должен быть другой выход.

Источник

CPU Load: когда начинать волноваться?

Аналогия транспортного потока

Так Вы говорите, 1.00 — идеальное значание load average?

Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!

У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.

Многоядерность vs. многопроцессорность

Сведем все вместе

Давайте посмотрим на средние значения загрузки с помощью команды uptime :

Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.

Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?

Количество ядер важно для правильно понимания load average. Как мне его узнать?

Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :

Примечания переводчика

Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.

Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.

Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂

Источник

7 простых оптимизаций, уменьшивших нагрузку на CPU с 80% до 27%

У нас есть ресурс, на котором мы полгода назад выложили образ для тестирования, доступный всем под соответствующей лицензией, список поставщиков оборудования, с которыми у нас проведены IOT-ы, пакет документов по продукту и несколько статей на английском о нашем опыте разработки (про Lua-based движок, например, или разнообразное тестирование).

Прежде всего хочется сказать, что большинство оптимизаций касалось взаимодействия базы данных и логики приложения. Более продуманное использование запросов и кеширование информации – это, пожалуй, главное, что мы сделали. Для анализа времени работы запросов на БД, нам пришлось сделать свою утилиту. Дело в том, что изначально в приложении использовалась база Oracle TimesTen, которая не имеет встроенных развитых средств мониторинга. А после внедрения PostgreSQL, мы решили, что использовать одно средство для сравнения двух баз, это правильно, так что оставили свою утилиту. Кроме того, наша утилита позволяет не собирать данные постоянно, а включать/выключать ее по мере надобности, например, в коммерческой сети с небольшим ростом загрузки CPU, но зато с возможность проанализовать сразу на продакшене, какой запрос вызывает проблемы в данный момент.
Утилита называет tt_perf_info и просто замеряет время, потраченное на разные этапы исполнения запроса: fetch, непосредственно исполнение, количество вызовов в секунду, процент, занимаемый от общего времени. Время выводится в микросекундах. Топ 15 запросов на версии 3.5.2 и 3.6.1 можно увидеть в таблицах по ссылкам:
3.5.2 top 15
3.6.1 top 15 (пустые клетки соответствуют значению 0 в этой версии)

Оптимизация 1: уменьшение коммитов

Если внимательно посмотреть на результат вывода tt_perf_info на разных версиях, то можно заметить, что количество вызовов pcrf.commit было уменьшено с 12006 раз в секунду до 1199, то есть в 10 раз! Вполне очевидное решение, пришедшее нам в голову, заключалось в том, чтобы проверять, действительно ли произошли какие-то изменения в базе, и только в случае положительного ответа производить коммит. Например, для UPDATE запроса в PCRF делается проверка количества изменившихся записей. Если оно равно 0, то коммит не производится. Аналогично с DELETE.

Оптимизация 2: удаление MERGE запроса

На базе Oracle TimesTen было замечено, что MERGE запрос устанавливает лок на всю таблицу. Что в условиях постоянно конкурирующих за таблицы процессов, приводило к очевидным проблемам. Так что мы просто заменили все MERGE запросы на комбинацию из GET-UPDATE-INSERT. Если запись есть, она обновляется, если нет – добавляется новая. Мы даже не стали оборачивать все это в транзакцию, а рекурсивно вызвали функцию в случае неудачи. На псевдокоде это выглядит примерно так:

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

Оптимизация 3: кеширование конфигурации для подсчета объемов потребляемого абонентами трафика

Алгоритм подсчета объема потребляемого трафика по 3GPP спецификации имеет довольно сложную структуру. В версии 3.5.2 вся конфигурация хранилась в базе и представляла из себя таблицы мониторинг ключей и аккумуляторов с отношением многие-ко-многим. Также система поддерживала суммирование аккумуляторов трафика от разных внешних систем в одно значение на PCRF и эта настройка хранилась в БД. Как следствие, при приходе очередных данных о накопленном объеме, происходила сложная выборка по базе.
В 3.6.1 большая часть конфигурации была вынесена в xml файл с нотификацией процессов об изменении данного файла и подсчетом контрольной суммы по конфигурационной информации. Также, текущая информация о подписке на мониторинг траффика хранится в блобе, привязанном к каждой пользовательской сессии. Вычитывание и запись блоба – операция несомненно более быстрая и менее ресурсоемкая, чем огромная выборка из таблиц с отношением многие-ко-многим.

Оптимизация 4: уменьшение количества вывозов Lua движка

Lua движок вызывается на каждый запрос типа CCR-I, CCR-U and RAR, обрабатывающийся в PCRF, и исполняет Lua скрипт, описывающий алгоритм выбора политики, так как вероятно изменение политики абонента при обработке данных запросов. Но идея чек-суммы нашла свое применение и здесь. В 3.6.1 версии мы сохранили всю информацию, от которой может зависеть реальное изменение политики, в отдельную структуру и стали считать контрольную сумму по ней. Соответственно, движок стал дергаться только в случае реальных изменений.

Оптимизация 5: вынос сетевой конфигурации из БД

Сетевая конфигурация также хранится в Базе Данных с самых ранних версий PCRF. В релизе 3.5.2 логика приложения и сетевая часть довольно сильно пересекались по таблицам с настройками сети, так как логический модуль регулярно читал параметры соединений из БД, а сетевая часть пользовалась БД, как хранилищем всей сетевой информации. В версии 3.6.1 информация для сетевой части была перенесена в разделяемую память, а в основную логику добавлены периодические процессы, обновляющие ее при изменениях в базе. Тем самым были уменьшены локи по общим таблицам в базе.

Оптимизация 6: выборочный разбор команд Diameter

PCRF общается со внешними системами по протоколу Diameter, анализируя и разбирая множество команд в единицу времени. Эти команды, как правило, содержат множество полей (avp) внутри себя, но далеко не каждой компоненте нужны все поля. Часто используется только несколько полей из первой (заголовочной) части команды, такие как Destination/Origin Host/Realm, или поля, позволяющие идентифицировать абонента или сессию, то есть id (которые тоже зачастую расположены в начале). И только один-два основных процесса используют все поля сообщения. Поэтому в версии 3.6.1 были введены маски, описывающие, какие поля необходимо вычитывать для данной компоненты. А также убраны почти все операции копирования памяти. Фактически в памяти осталось только исходное сообщение, а все процессы используют структуры с указателями на необходимые части, данные копируются внутри процессов уже по строгой необходимости.

Оптимизация 7: кеширование времени

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

Источник

Мониторинг использования CPU на сервере Linux

Объем памяти, размер кеша, скорость чтения и записи на диск, скорость и доступность вычислительной мощности – это ключевые элементы, влияющие на производительность любой инфраструктуры.

Данное руководство ознакомит с базовыми понятиями мониторинга CPU. Вы узнаете, как использовать утилиты uptime и top, чтобы узнать о нагрузке и использовании ЦП.

Требования

Основные понятия

Прежде чем приступить к работе с утилитами, нужно понять, как измеряется использование ЦП и к каким результатам нужно стремиться.

Загрузка и использование ЦП

Загрузка (CPU Load) и использование процессора (CPU Utilization) – два разных способа взглянуть на использование вычислительной мощности компьютера.

Чтобы оценить основное различие между ними, попробуйте представить, что процессоры – это кассиры в продуктовом магазине, а задачи – это клиенты, которых нужно обслужить. Загрузка процессора – это, по сути, одна очередь, в которой клиенты ждут, пока освободиться один из кассиров. Нагрузка – это в данном случае количество клиентов в очереди, включая тех, что уже на кассе. Чем длиннее очередь, тем дольше ждать.

Использование ЦП оценивает исключительно занятость кассиров и не знает, сколько клиентов в очереди.

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

Загрузка ЦП – это длина очереди запланированных задач, включая те, что находятся в обработке. Задачи могут переключаться в пределах миллисекунд, поэтому один снапшот загрузки не так полезен, как среднее значение из нескольких снапшотов, взятых за определенный период времени. Потому загрузка ЦП часто представляется как среднее значение.

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

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

Ненормированные и нормированные значения

В одной процессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная емкость всех процессоров рассчитывается как 100% независимо от количества процессоров, такое значение считается нормированным. Другой вариант предлагает считать каждый процессор как единицу, так что 2-процессорная система в полном объеме имеет емкость 200%, 4-процессорная система в полном объеме имеет мощность 400% и т. д.

Чтобы правильно интерпретировать загрузку или использование CPU, нужно знать количество процессоров на сервере.

Отображение информации о ЦП

Чтобы узнать количество процессоров, можно использовать команду nproc с опцией –all. Без этого флага команда отобразит количество обрабатывающих блоков, доступных для текущего процесса, что будет меньше общего количества процессоров.

В большинстве современных дистрибутивов Linux также можно использовать команду lscpu, которая отображает не только количество процессоров, но и архитектуру, имя модели, скорость и многое другое:

lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping: 2
CPU MHz: 1797.917
BogoMIPS: 3595.83
Virtualization: VT-x
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 30720K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

Знание точного количества процессоров важно для интерпретации результатов тех или иных утилит.

Оптимальные значения загрузки и использования ЦП

Оптимальное значение использования ЦП зависит от того, какую работу должен выполнять сервер. Стабильно высокое использование процессора негативно влияет на отзывчивость системы. Часто приложениям и пакетным заданиям с интенсивными вычислениями необходим весь или почти весь объем ЦП. Однако, если система должна обслуживать веб-страницы или поддерживать интерактивные сеансы сервисов (например, SSH), тогда может понадобиться свободная вычислительная мощность.

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

Мониторинг ЦП

Существует множество инструментов для получения данных о состоянии ЦП системы. Мы рассмотрим две команды: uptime и top. Обе утилиты являются частью стандартной установки большинства популярных дистрибутивов Linux и обычно используются для исследования загрузки и использования ЦП.

Примечание: Следующие примеры выполнены на 2-ядерном сервере.

Утилита uptime

Команда uptime позволяет отследить загрузку процессора. Она может быть полезна, если система медленно реагирует на интерактивные запросы (вероятно, ей не хватает системных ресурсов).

Утилита uptime сообщает следующие данные:

uptime
14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63

В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. При запуске uptime подключились два пользователя. Этот сервер имеет 2 процессора. За минуту до запуска команды средняя загрузка процессора была 2,00, что означает, что в течение этой минуты процессоры использовали в среднем две задачи, а ожидающих задач не было. Среднее значение загрузки з а5 минут указывает на то, что в течение некоторого интервала времени один из процессоров бездействовал около 60% времени. Среднее за 15 минут значение указывает на то, что было доступно больше времени обработки. Вместе эти три значения показывают увеличение загрузки за последние пятнадцать минут.

Утилита uptime сообщает полезные средние значения загрузки ЦП, но для того, чтобы получить более подробную информацию, нужно использовать top.

Утилита top

Как и uptime, утилита top доступна как в Linux, так и в Unix-системах, но помимо отображения средних значений нагрузки для заданных временных интервалов она предоставляет информацию о потреблении ЦП в реальном времени, а также другие полезные показатели производительности. Если uptime запускается и сразу завершает работу, top работает на переднем плане и регулярно обновляется.

Заглавный блок

Первые пять строк содержат сводную информацию о процессах на сервере:

Первая строка почти идентична выводу утилиты uptime. Здесь показаны средние значения за одну, пять и пятнадцать минут. Эта строка отличается от вывода uptime только тем, что вначале указывается утилита top и время последнего обновления данных.

Вторая строка предоставляет краткий обзор состояния задач: общее количество процессов, количество запущенных, спящих, остановленных и зависших процессов.

Третья строка говорит об использовании ЦП. Эти цифры нормируются и отображаются в процентах (без символа %), так что все значения в этой строке должны составлять до 100% независимо от количества процессоров.

Четвертая и пятая строки сообщают об использовании памяти и swap соответственно.

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

Давайте рассмотрим подробнее все компоненты строки CPU.

Таблица процессов

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

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

Примечание: Если вы предпочитаете работать с нормированными значениями, вы можете нажать SHIFT + I, и отображение переключится с режима Irix в режим Solaris. Этот режим выводит ту же информацию, которая усредняется по всему количеству процессоров, так что используемая сумма не будет превышать 100%. Перейдя к режиму Solaris, вы получите краткое сообщение о том, что режим Irix выключен.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10081 8host 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress
10082 8host 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress
1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd
1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd

Заключение

Теперь вы умеете работать с утилитами uptime и top и интерпретировать их вывод.

Источник