NodeJS CPU Шипы на 100% один процессор за раз
у меня есть прокси-сервер SOCKS5, который я написал в NodeJS.
Я использую родной net
и dgram
библиотеки для открытия сокетов TCP и UDP.
он работает нормально около 2 дней, и все процессоры составляют около 30% макс. После 2 дней без перезагрузки один процессор скачет до 100%. После этого все процессоры по очереди остаются на 100% один процессор за раз.
вот 7-дневная диаграмма процессора шипы:
Я использую кластер для создания экземпляров таких как:
for (let i = 0; i < Os.cpus().length; i++) {
Cluster.fork();
}
это выход strace в то время как процессор находится на 100%:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.76 0.294432 79 3733 epoll_pwait
0.10 0.000299 0 3724 24 futex
0.08 0.000250 0 3459 15 rt_sigreturn
0.03 0.000087 0 8699 write
0.01 0.000023 0 190 190 connect
0.01 0.000017 0 3212 38 read
0.00 0.000014 0 420 close
0.00 0.000008 0 612 180 recvmsg
0.00 0.000000 0 34 mmap
0.00 0.000000 0 16 ioctl
0.00 0.000000 0 190 socket
0.00 0.000000 0 111 sendmsg
0.00 0.000000 0 190 bind
0.00 0.000000 0 482 getsockname
0.00 0.000000 0 218 getpeername
0.00 0.000000 0 238 setsockopt
0.00 0.000000 0 432 getsockopt
0.00 0.000000 0 3259 104 epoll_ctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.295130 29219 551 total
и результат профиля узла (тяжелый вверх):
[Bottom up (heavy) profile]:
Note: percentage shows a share of a particular caller in the total
amount of its parent calls.
Callers occupying less than 1.0% are not shown.
ticks parent name
1722861 81.0% syscall
28897 1.4% UNKNOWN
поскольку я использую только собственные библиотеки, большая часть моего кода фактически работает на C++, а не JS. Поэтому любая отладка, которую я должен сделать, находится в двигателе v8. Вот сводка профилировщика узлов (для языка):
[Summary]:
ticks total nonlib name
92087 4.3% 4.5% JavaScript
1937348 91.1% 94.1% C++
15594 0.7% 0.8% GC
68976 3.2% Shared libraries
28897 1.4% Unaccounted
I подозревал, что это мог быть мусорщик, который работал. Но я увеличил размер кучи узла, и память, похоже, находится в пределах диапазона. Я действительно не знаю, как отладить его, так как каждая итерация занимает около 2 дней.
у кого-нибудь была аналогичная проблема и была успешная отладка? Мне нужна любая помощь.
2 ответов
в вашем вопросе недостаточно информации для воспроизведения вашем случае. Такие вещи, как OS, Node.причиной такого поведения может быть версия js, реализация вашего кода и т. д.
существует список лучших практик, которые могут решить или избежать такой проблемы:
- использование pm2 как супервизор для вашего узла.приложение js.
- отладку узла.применение js в продукции. Для этого:
- проверьте подключение ssh к продукту сервер
- свяжите порт отладки с localhost с помощью
ssh -N -L 9229:127.0.0.1:9229 root@your-remove-host
- начать отладку по команде
kill -SIGUSR1 <nodejs pid>
- открыть
chrome://inspect
в Chrome или использовать любой другой отладчик для узла.js
- прежде, чем идти в производство:
- стресс-тестирования
- долголетие тестирования
несколько месяцев назад мы поняли, что другая служба, которая работает на том же поле, которое отслеживает открытые сокеты, вызывает проблему. Эта служба была более старой версией, и через некоторое время она добавляла процессор при отслеживании сокетов. Обновление службы до последней версии решило проблемы с процессором.
урок усвоен: иногда это не вы, это они