Эта статья включена в блог GitHub Shanyuexing:shfshanyue/blog, который содержит проблемы, с которыми я столкнулся в реальной работе, размышлениях о бизнесе и обучении в направлении полного стека.
В начале зададим вопрос:
Знаете ли вы, сколько памяти обычно занимает служба Node в вашей производственной среде? Или сколько?
Когда Шаньюэ проводил собеседование с кандидатами в Node, этого вопроса было достаточно, чтобы отсеять половину самопровозглашенных специалистов в Node, но я не ответил на него и часто добавлял еще один вопрос, чтобы не пропустить кандидатов с отличным опытом беспроводной связи:
При использовании узла в качестве языка сервера в производственной среде это чрезмерно большая или кодовая проблема, которая является распространенной проблемой на сервере. В это время CPU и память контролируются, а журнал и релиз объединены. Это Легко найти проблемы.
В этой главе описывается, как отслеживать изменения в память о местной среде и производственной среде
Экземпляр приложения Node
Итак, как динамически отслеживать изменения памяти процесса Node?
Ниже приведен пример Node Server и пример с проблемой утечки памяти, а также урезанная версия проблемы, которую Ямадзуки уже давно находит в производственной среде.
В этой проблеме с утечкой памяти объем памяти в одном контейнере резко увеличился с первоначальных 400 МБ до 700 МБ, а OOM иногда возникал ниже предела ресурсов контейнера в 800 МБ, что приводило к перезапускам. Проблема не была обнаружена некоторое время (проблема была обнаружена слишком поздно, данные временных рядов полумесячной давности были поглощены, поэтому релиз не был обнаружен), поэтому лимит ресурсов был увеличен до 1000M. Позже выяснилось, что это было вызвано тем, что ctx.request смонтировал большое поле в базе данных.
const Koa = require('koa')
const app = new Koa()
function getData () {
return Array.from(Array(1000)).map(x => 10086)
}
app.use(async (ctx, next) => {
ctx.data = getData()
await next()
})
app.use(ctx => {
ctx.body = 'hello, world'
})
app.listen(3200, () => console.log('Port: 3200'))
Мониторинг памяти процесса
Некоторые проблемы необходимо вовремя устранять в локальной и тестовой среде, чтобы избежать большего влияния на производственную среду. Тогда крайне важно понять, как память контролируется локально.
pidstatдаsysstatПакет из серии инструментов отладки производительности Linux, он используется для устранения проблем с производительностью Linux, включая память, сеть, ввод-вывод, ЦП и т. д.
Это не только попытка сnode, так и для всех процессов, включаяpython,javaтак же какgo
# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p pid 1 100
при использованииpidstatПрежде всего нужно найти процессpid
Как найти pid процесса узла
существуетnodeсквозьprocess.pidнайти процессpid
> process.pid
16425
Хотя его можно найти, написав кодpid, но является инвазивным и менее практичным. Как найти его неинвазивными способамиpidШерстяная ткань? Есть два способа
- Объединение с избыточными параметрами
psнайти процесс - Объединить по номеру порта
lsofнайти процесс
$ node index.js shanyue
# 第一种方法：通过多余的参数快速定位 pid
$ ps -ef | grep shanyue
root 31796 23839 1 16:38 pts/5 00:00:00 node index.js shanyue
# 第二种方法：通过端口号定位 pid
lsof -i:3200
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 31796 root 20u IPv6 235987334 0t0 TCP *:tick-port (LISTEN)
Мониторинг памяти с помощью pidstat
Как видно из приведенного выше кода, pid службы узла31796, чтобы понаблюдать за динамическими изменениями памяти, а затем применить стресс-тест
$ ab -c 10000 -n 1000000 http://localhost:3200/
# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p 31796 1 100
Linux 3.10.0-957.21.3.el7.x86_64 (shuifeng) 2020年07月02日 _x86_64_ (2 CPU)
UID PID minflt/s majflt/s VSZ RSS %MEM Command
19时20分39秒 0 11401 0.00 0.00 566768 19800 0.12 node
19时20分40秒 0 11401 0.00 0.00 566768 19800 0.12 node
19时20分41秒 0 11401 9667.00 0.00 579024 37792 0.23 node
19时20分42秒 0 11401 11311.00 0.00 600716 59988 0.37 node
19时20分43秒 0 11401 5417.82 0.00 611420 70900 0.44 node
19时20分44秒 0 11401 3901.00 0.00 627292 85928 0.53 node
19时20分45秒 0 11401 1560.00 0.00 621660 81208 0.50 node
19时20分46秒 0 11401 2390.00 0.00 623964 83696 0.51 node
19时20分47秒 0 11401 1764.00 0.00 625500 85204 0.52 node
Значение выходных индикаторов следующее
-
RSS:Resident Set Size, набор резидентной памяти, который можно понимать как память, это индикатор памяти, который нам нужно отслеживать -
VSZ:virtual size,Виртуальная память
Как видно из вывода,Когда применяется испытание под давлением, память составляет от 19 до 85 м.
Память монитора сверху
pidstatпринадлежатьsysstatинструменты производительности Linux под , но в Mac, как найти изменения памяти?
можно использовать в это времяtop/htop
$ htop -p 31796
Мониторинг памяти производственной среды
Поскольку большинство производственных сред в настоящее время развернуты вk8s,Следовательно, мониторинг памяти определенного применения в производственной среде по существу то же самое, что и у K8S для определенного приложения.workload/deploymentмониторинг памяти, о мониторинге памятиmetricПоток данных примерно следующий:
k8s -> metric server -> prometheus -> grafana
Схема архитектуры выглядит следующим образом:
Картинка выше взята из следующей статьи
наконец вgrafanaГрафик мониторинга памяти приложения в реальном времени собирается в:
Поскольку в этой части слишком много содержания дизайна, я представлю его в следующих главах.
Это касается не только сервисов узлов, но и всего на k8s.workload
Суммировать
В этой главе представлен мониторинг локальной среды и производственной среды службы Node.
- местное использование
htop/topилиpidstatМониторинг памяти процесса - Использование производственной среды
k8s/metric-server/prometheus/grafanaМониторинг памяти узла для всего приложения
Когда в сервисе обнаружена утечка памяти, как решить проблему? Поэтому в следующей статье речь пойдет о
- Как производственная среда контролирует память всего приложения
- Как быстро определить, когда OOM происходит в производственной среде
- Пример размещения нескольких OOM в реальной производственной среде
Эта статья включена в блог GitHub Shanyuexing:shfshanyue/blog, который содержит проблемы, с которыми я столкнулся в реальной работе, размышлениях о бизнесе и обучении в направлении полного стека.
Подписывайтесь на меня
Отсканируйте код, чтобы добавить мой WeChat, сделайте пометку, чтобы войти в группу, присоединитесь к расширенной группе расширенного интерфейса
Добро пожаловать в официальный аккаунт [Дорога роста полного стека] и регулярно размещайте оригинальные статьи и статьи о развитии полного стека Node.