Недавно я узнал о мониторинге nodejs. Хотя у меня нет сил научиться писать простую версию мониторинга, я все еще не могу не научиться получать эти индикаторы (после изучения большого количества информации я чувствую, что что в отечественном интернете слишком мало ознакомления с этим контентом. Я также разбираю пункты знаний по серверным узлам, поэтому обобщу их в этой статье и поделюсь с вами).
С некоторыми индикаторами в этой статье могут возникнуть проблемы. Добро пожаловать на обмен. Фактически, вы можете систематизировать эти данные, записать их в библиотеку мониторинга и использовать в своих собственных малых и средних проектах. Затем у внешнего интерфейса есть такие инструменты, как bizcharts и g2, и внешний интерфейс сам рисует большой экран данных. Я думаю, что данные, собираемые Esay Monitor, не такие полные, как наши.
Узкими местами производительности серверов обычно являются следующие:
использования ЦП и загрузки ЦП, оба из которых могут в определенной степени отражать занятость машины.
Использование ЦП — это ресурсы ЦП, занятые запущенными программами, указывающие, как машина запускает программы в определенный момент времени. Чем выше уровень использования, это означает, что в это время на машине запущено много программ, и наоборот. Уровень использования напрямую связан с мощностью процессора. Давайте сначала разберемся с соответствующими API и некоторыми пояснениями к терминологии, которые помогут нам понять код для получения данных об использовании ЦП.
os.cpus()возвращает массив объектов, содержащих информацию о каждом логическом ядре ЦП.
модель: строка, определяющая модель ядра ЦП.
скорость: число, определяющее скорость ядра ЦП в МГц.
times: Объект, содержащий следующие свойства:
ПРИМЕЧАНИЕ. Значение nice предназначено только для POSIX. В операционных системах Windows значение nice всегда равно 0 для всех процессоров.
Когда вы видите пользователя и красивые поля, некоторые студенты, как и я, сбиты с толку преимуществами, поэтому я внимательно поинтересовался их значением, пожалуйста, продолжайте.
user указывает долю времени, в течение которого процессор работает в пользовательском режиме .
Выполнение процесса приложения делится на пользовательский режим и режим ядра : ЦП выполняет собственную логику кода процесса приложения в пользовательском режиме, обычно некоторые логические или числовые вычисления , ЦП выполняет системные вызовы, инициированные процессом в режиме ядра, обычно в ответ; на запрос процесса на ресурсы.
Программа пользовательского пространства — это любой процесс, не являющийся частью ядра. Оболочки, компиляторы, базы данных, веб-серверы и программы для настольных компьютеров — все это процессы в пространстве пользователя. Если процессор не простаивает, то это нормально, что большая часть времени процессора тратится на выполнение процессов в пространстве пользователя.
Nice представляет долю времени, в течение которого ЦП работает в пользовательском режиме с низким приоритетом . Низкий приоритет означает, что значение nice для процесса меньше 0.
Пользовательпредставляет собой долю времени, в течение которого ЦП работает в режиме ядра .
Вообще говоря, загрузка ЦП в режиме ядра не должна быть слишком высокой, если только процесс приложения не инициирует большое количество системных вызовов. Если оно слишком велико, это означает, что системный вызов занимает много времени, например, при частых операциях ввода-вывода.
Idle указывает долю времени, в течение которого ЦП находится в состоянии простоя, в течение которого ЦП не имеет задач для выполнения.
irq представляет собой долю времени, в течение которого ЦП обрабатывает аппаратные прерывания .
Прерывание сетевой карты является типичным примером: после того, как сетевая карта получает пакет данных, она уведомляет процессор о необходимости обработки посредством аппаратного прерывания. Если сетевой трафик системы очень велик, может наблюдаться значительное увеличение использования прерываний.
если состояние пользователя меньше 70 %, состояние ядра меньше 35 % и общее состояние меньше 70 %, это можно считать работоспособным состоянием.
Следующий пример иллюстрирует использование метода os.cpus() в Node.js:
Пример 1:
// Программа Node.js для демонстрации
//метод os.cpus()
// Выделение модуля ОС
const os = require('os');
// Печать значений os.cpus()
console.log(os.cpus()); Выход:
[ { model:'Intel(R) Core(TM) i5-7200U CPU @ 2,50 ГГц',
скорость: 2712,
раз:
{ пользователь:900000, хороший:0, sys:940265, простой:11928546, прерывание:147046 } },
{ модель: «Процессор Intel(R) Core(TM) i5-7200U @ 2,50 ГГц»,
скорость: 2712,
раз:
{пользователь: 860875, хороший: 0, sys: 507093, простой: 12400500, IRQ: 27062 } },
{ модель: «Процессор Intel(R) Core(TM) i5-7200U @ 2,50 ГГц»,
скорость: 2712,
раз:
{пользователь:1273421, nice:0, sys:618765, IDLE:11876281, IRQ:13125 } },
{ модель: «Процессор Intel(R) Core(TM) i5-7200U @ 2,50 ГГц»,
скорость: 2712,
раз:
{ user:943921, nice:0, sys:460109, IDLE:12364453, irq:12437 } } ] Ниже приведен код для получения информации об использовании процессора
const os = require('os');
const Sleep = мс => новое обещание (разрешить => setTimeout (разрешить, мс));
класс OSUtils {
конструктор() {
this.cpuUsageMSDefault = 1000 //период использования процессора по умолчанию};
/**
* Получить загрузку ЦП за определенный период времени* @param { Number } Options.ms [Период времени, по умолчанию — 1000 мс, что составляет 1 секунду]
* @param { Boolean } Options.percentage [true (возвращается в виде процента) false]
* @returns {Обещание}
*/
асинхронный getCPUUsage(options={}) {
константа, которая = это;
пусть {cpuUsageMS, процент} = параметры;
cpuUsageMS = cpuUsageMS || that.cpuUsageMSDefault;
const t1 = that._getCPUInfo(); // информация о процессоре в момент времени t1 await Sleep(cpuUsageMS);
const t2 = that._getCPUInfo(); // информация о процессоре в момент времени t2 constdle = t2.idle - t1.idle;
const total = t2.total - t1.total;
let use = 1 — простоя/всего;
if (процент) использование = (использование * 100.0).toFixed(2) + "%";
возвратное использование;
}
/**
* Получить информацию о мгновенном времени ЦП * @returns { Object } Информация о ЦП * user <число> Число миллисекунд, проведенных ЦП в пользовательском режиме.
* nice <число> Количество миллисекунд, которое процессор проводит в приятном режиме.
* sys <число> Количество миллисекунд, в течение которых процессор находился в системном режиме.
* IDLE <число> Количество миллисекунд, в течение которых ЦП находился в режиме ожидания.
* irq <число> Количество миллисекунд, в течение которых процессор находился в режиме запроса прерывания.
*/
_getCPUInfo() {
константный процессор = os.cpus();
пусть пользователь = 0, хороший = 0, sys = 0, простой = 0, irq = 0, итог = 0;
for (пусть процессор в процессоре) {
константное время = процессор[процессор].times;
пользователь += раз.пользователь;
приятно += раз.хорошо;
sys += times.sys;
простой += times.idle;
прерывание += times.irq;
}
итого += пользователь + приятно + системный + простой + прерывание;
возвращаться {
пользователь,
система,
праздный,
общий,
}
}
}
const cpuUsage = новый OSUtils().getCPUUsage({процент: true});
console.log('cpuUsage: ', cpuUsage.then(data=>console.log(data))); // Мой компьютер . Загрузка ЦП (loadavg) легко понять и относится к определенному значению. период времени Количество процессов, занимающих время ЦП, и процессов, ожидающих этого времени, представляет собой среднее значение нагрузки. Здесь процессы, ожидающие пробуждения, исключают процессы в состоянии ожидания.
Перед этим нам нужно изучить API узла.
os.loadavg()возвращает массив, содержащий среднюю нагрузку за 1, 5 и 15 минут.
Средняя нагрузка — это показатель активности системы, рассчитываемый операционной системой и выраженный в десятичном формате.
Средняя нагрузка — это концепция, специфичная для Unix. В Windows возвращаемое значение всегда равно [0, 0, 0]
Оно используется для описания текущей занятости операционной системы. Его можно просто понимать как среднее количество задач, которые процессор использует и ожидает использования. ЦП в единицу времени. Загрузка ЦП слишком высока, что указывает на слишком много процессов. В Node это может отражаться в неоднократном запуске новых процессов с использованием модуля Запретный город.
const os = require('os');
//Количество потоков ЦП const length = os.cpus().length;
//Средняя загрузка одноядерного процессора, возвращает массив, содержащий среднюю загрузку за 1, 5 и 15 минут os.loadavg().map(load => load/length Сначала объясним API
);, иначе вы не сможете его прочитать. Разберитесь с нашим кодом для получения индикаторов памяти,
Эта функция возвращает 4 параметра, их значения и различия заключаются в следующем:
Используйте следующий код, чтобы вывести использование памяти дочерним процессом. Видно, что rss примерно равен RES команды top. Кроме того, память основного процесса составляет всего 33 МБ, что меньше памяти дочернего процесса. Видно, что использование ими памяти рассчитывается независимо.
вар showMem = функция(){
вар мем = процесс.memoryUsage();
вар формат = функция (байты) {
return (байты/1024/1024).toFixed(2) + 'МБ';
};
console.log('Процесс: heapTotal' + format(mem.heapTotal) + 'heapUsed' + format(mem.heapUsed) + 'rss' + format(mem.rss) + 'external:' + format(mem.external) );
console.log('--------------------------------------------- --- ---------------');
}; В случае с Node устранить утечку памяти не так-то просто. Если наблюдается, что память только поднимается, но не падает, то должна быть проблема с утечкой памяти. Здоровое использование памяти должно увеличиваться и уменьшаться. Когда доступ большой, он увеличивается, а когда доступ падает, он уменьшается.
const os = require('os');
// Проверяем использование памяти текущим процессом Node const { rss, heapUsed, heapTotal } =process.memoryUsage();
// Получаем свободную память системы const systemFree = os.freemem();
// Получаем общий объем системной памяти const systemTotal = os.totalmem();
модуль.экспорт = {
память: () => {
возвращаться {
system: 1 - systemFree / systemTotal, // Куча использования системной памяти: heapUsed / headTotal, // Использование памяти процесса текущего узла node: rss / systemTotal, // Коэффициент использования памяти процесса текущего узла системной памяти}
}
} Мониторинг диска в основном отслеживает использование диска. Из-за частой записи журналов дисковое пространство постепенно расходуется. Если диска будет недостаточно, это вызовет различные проблемы в системе. Установите верхний предел использования диска. Если использование диска превышает значение предупреждения, администратор сервера должен организовать журналы или очистить диск.
Следующий код относится к easy Monitor 3.0.
const { execSync } = require('child_process');
const result = execSync('df -P', {coding: 'utf8'})
constlines = result.split('n');
константная метрика = {};
lines.forEach(строка => {
если (line.startsWith('/')) {
const match = line.match(/(d+)%s+(/.*$)/);
если (совпадение) {
константная скорость = parseInt(match[1] || 0);
константа смонтирована = совпадение [2];
if (!mounted.startsWith('/Volumes/') && !mounted.startsWith('/private/')) {
метрика [смонтирован] = ставка;
}
}
}
});
console.log(metric) Загрузка ввода-вывода в основном относится к дисковому вводу-выводу. Он отражает ситуацию с чтением и записью на диске. Для приложений, написанных Node и предназначенных в основном для сетевых служб, маловероятно, что нагрузка ввода-вывода будет слишком высокой. Нагрузка на ввод-вывод при многих чтениях исходит от базы данных. .
Чтобы получить индикаторы ввода-вывода, нам нужно понять команду Linux под названием iostat. Если она не установлена, вам необходимо ее установить. Давайте посмотрим, почему эта команда может отображать индикаторы ввода-вывода
iostat -dx.
Описание свойства
rrqm/s: количество операций чтения слиянием в секунду. То есть rmerge/s (количество раз в секунду объединяются запросы на чтение к устройству, и файловая система объединяет запросы на чтение одного и того же блока) wrqm/s: количество операций записи слиянием в секунду. То есть wmerge/s (количество объединений запросов на запись на устройство в секунду) r/s: количество операций чтения с устройства ввода-вывода, выполненных в секунду. Это рио/с w/s: количество операций записи на устройство ввода-вывода, выполненных в секунду. Это Wio/S rsec/s: количество секторов, считываемых в секунду. Это рект/с wsec/s: количество секторов, записываемых в секунду. то есть wsect/s rkB/s: К байт, прочитанных в секунду. Это половина rsect/s, поскольку размер каждого сектора составляет 512 байт. wkB/s: количество K байт, записываемых в секунду. Это половина wsec/s. avgrq-sz: средний размер данных (секторов) на одну операцию ввода-вывода устройства. avgqu-sz: Средняя длина очереди ввода-вывода. await: среднее время ожидания (в миллисекундах) для каждой операции ввода-вывода устройства. svctm: Среднее время обработки (в миллисекундах) каждой операции ввода-вывода устройства. %util: какой процент одной секунды используется для операций ввода-вывода, то есть процент использования процессора для ввода-вывода.
Нам нужно отслеживать только %util.
Если %util близок к 100% , это означает, что I слишком много. Генерируются запросы /O. Система ввода-вывода полностью загружена , и на этом диске может быть узкое место.
Если await намного больше, чем svctm, это означает, что очередь ввода-вывода слишком длинная и время ответа приложения становится медленнее. Если время ответа превышает допустимый для пользователя диапазон, вы можете рассмотреть возможность замены более быстрого диска. настройка алгоритма лифта ядра и оптимизация приложения или обновление процессора.
отслеживает время ответа страницы Nodejs. Решение выбрано из статьи в блоге преподавателя Ляо Сюэфэна.
Недавно я хочу следить за производительностью Nodejs. Записывать и анализировать журнал слишком хлопотно. Самый простой способ — записывать время обработки каждого HTTP-запроса и возвращать его непосредственно в заголовке HTTP-ответа.
Записать время HTTP-запроса очень просто. Это означает запись временной метки при получении запроса и запись другой временной метки при ответе на запрос. Разница между двумя временными метками — это время обработки.
Однако код res.send() разбросан по различным js-файлам, поэтому вы не можете изменить каждую функцию обработки URL-адресов.
Правильная идея — использовать для этого промежуточное программное обеспечение. Но у Nodejs нет метода перехвата res.send(), как его сломать?
Фактически, если мы немного изменим наше мышление, откажемся от традиционного метода ООП и будем рассматривать res.send() как объект функции, мы сможем сначала сохранить исходную функцию обработки res.send, а затем заменить res.send на нашу собственная функция обработки:
app.use(function (req, res, next) {
//Время начала записи:
вар exec_start_at = Date.now();
//Сохраняем исходную функцию обработки:
вар _send = res.send;
// Привязываем нашу собственную функцию-обработчик:
res.send = функция () {
//Отправить заголовок:
res.set('X-Execution-Time', String(Date.now() - exec_start_at));
// Вызов исходной функции обработки:
вернуть _send.apply(res, аргументы);
};
следующий();
}); Всего несколько строк кода позволяют установить временную метку.
Нет необходимости обрабатывать метод res.render(), поскольку res.render() внутренне вызывает res.send().
При вызове функции apply() важно передать объект res, в противном случае this исходной функции обработки указывает на неопределенное значение, что напрямую приводит к ошибке.
Измеренное время ответа домашней страницы 9 миллисекунд.
Словарь QPS:
в секунду. QPS: количество запросов в секунду означает «скорость запросов в секунду», то есть количество запросов, на которые может ответить сервер. в секунду — это показатель того, какой объем трафика обрабатывает конкретный сервер запросов за определенный период времени.
В Интернете производительность машины, служащей сервером системы доменных имен, часто измеряется скоростью запросов в секунду.
TPS: это аббревиатура TransactionsPerSecond, обозначающая количество транзакций в секунду. Это единица измерения результатов тестирования программного обеспечения. Транзакция — это процесс, в котором клиент отправляет запрос серверу, а сервер отвечает. Клиент начинает отсчет времени, когда отправляет запрос, и заканчивает, когда получает ответ сервера, для расчета затраченного времени и количества завершенных транзакций.
QPS против TPS: QPS в основном похож на TPS, но разница в том, что посещение страницы формирует TPS, но запрос страницы может генерировать несколько запросов к серверу, и сервер может считать эти запросы как «QPS». Например, при доступе к странице сервер будет запрошен дважды. При первом доступе будет сгенерирована буква «T» и две буквы «Q».
. Время ответа: общее время, необходимое для выполнения запроса от начала до конца при получении данных ответа, то есть время от клиента, инициировавшего запрос, до получения результата ответа сервера.
Время отклика RT (время отклика) — один из важнейших показателей системы. Его числовое значение напрямую отражает скорость работы системы.
Число параллелизма означает количество запросов, которые система может обрабатывать одновременно. Это также отражает грузоподъемность системы.
Пропускная способность (выдерживающая нагрузку) системы тесно связана с потреблением ЦП запросов, внешних интерфейсов, ввода-вывода и т. д. Чем выше потребление ЦП для одного запроса, тем медленнее внешний системный интерфейс и скорость ввода-вывода, а также тем ниже пропускная способность системы, и наоборот.
Несколько важных параметров пропускной способности системы: QPS (TPS), количество параллелизма и время ответа.
QPS (TPS): (запросов в секунду). Количество запросов/транзакций в секунду.
Параллельность: количество запросов/транзакций, обрабатываемых системой одновременно.
Время ответа: обычно среднее время ответа
рассчитывается после понимания смысла вышеизложенного. три элемента. Связь между ними:
Давайте разберемся с вышеизложенными концепциями на примере. Согласно правилу 80/20, если 80% ежедневных посещений приходится на 20% времени, эти 20% времени называются пиковым временем.
1, 300 Вт в день на одну машину. Сколько запросов в секунду требуется для этой машины?
(3000000 * 0,8) / (86400 * 0,2) = 139 (QPS)
2. Если QPS машины равно 58, сколько машин необходимо для ее поддержки?
139/58 = 3
На этом этапе, если вы создадите интерфейсную архитектуру для общих малых и средних проектов и развернете свои собственные службы узлов, вы будете знать, сколько машин необходимо для формирования кластера для отчета ppt. Ха-ха. вы можете рассчитать приблизительное значение с помощью PV.
Нам нужно понять стресс-тест (нам нужно полагаться на стресс-тест для получения qps. Возьмем в качестве примера команду ab:
формат команды:
ab [опции] [http://]имя хоста[:порт]/путь
Common). параметры следующие:
-n общее количество запросов Количество запросов -c concurrency Число параллелизма -t timelimit Максимальное количество секунд для теста, которое можно рассматривать как время ожидания запроса -p postfile Файл, содержащий данные, требующие POST -T content-type Информация заголовка типа контента, используемая данными POST. Копировать код.