노드 서비스 CPU가 너무 높으면 어떻게 해야 합니까? 문제 해결 아이디어에 대해 이야기해 보겠습니다.-JS 튜토리얼-php.cn

node서비스 CPU가 너무 높으면 어떻게 해야 하나요? 확인하는 방법? 다음 문서에서는 노드 서비스 CPU가 너무 높은 문제를 해결하는 방법을 정리하고 공유하겠습니다. 도움이 되기를 바랍니다.

노드 서비스 CPU가 너무 높으면 어떻게 해야 합니까? 문제 해결 아이디어에 대해 이야기해 보겠습니다.

동료가 과도한 CPU 문제를 살펴보도록 도와주세요.

CPU가 증가한 후에는 다운될 수 없습니다. 마침내 동료는 특정 종속성이 주요 버전으로 업그레이드되었고 기본 공개 Redis가 있음을 발견했습니다. 구성이 오프라인 상태였지만(프로젝트가 오래되어 오랫동안 아무도 건드리지 않았습니다) 비즈니스 코드에서 Redis 서비스를 구성하고 닫아야 합니다. 비즈니스 측에서는 정보 격차가 있어서 Redis를 닫는 방법을 모릅니다. 결과적으로 온라인에 접속한 후 계속 Redis에 연결을 시도합니다(한 번 더 요청하면 한 번 더 재시도합니다)

결국 우리는 다음과 같이 문제 해결 아이디어를 요약했습니다. 추가를 환영합니다

문제 해결 아이디어

0. 인스턴스를 다시 시작하세요

일부 문제는 인스턴스를 다시 시작하면 해결될 수 있습니다.

먼저 인스턴스를 다시 시작하는 것은 서비스를 먼저 사용할 수 있도록 하기 위해 필요한 단계입니다. 후속 CPU가 여전히 너무 빠르게 급증하는 경우 먼저 코드 롤백을 고려해야 할 수 있습니다. 급증이 빠르지 않으면 롤백하지 않고 최대한 빨리 문제를 해결할 수 있습니다

1. linux shell 노드 프로세스에 의한 것인지 확인

명령 1: toptop

可以发现，主要是node进程在占用CPU。【相关教程推荐：nodejs视频教程】

[root@*** ~]# top

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                     
680 root      20   0 2290976 168176  34976 S  30.3  2.0 103:42.59 node                                                                                                                        
687 root      20   0 2290544 166920  34984 R  26.3  2.0  96:26.42 node                                                                                                                        
 52 root      20   0 1057412  23972  15188 S   1.7  0.3  11:25.97 ****                                                                                                           
185 root      20   0  130216  41432  25436 S   0.3  0.5   1:03.44 ****                                                                                                         
...

로그인 후 복사

命令二： vmstat

nodejs 동영상 튜토리얼

[root@*** ~]# vmstat 2
procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu-----
 r  b      swpd  free   buff   cache      si   so    bi    bo   in cs   us sy id wa st
 0  0      0 233481328 758304 20795516    0    0     0     1    0    0  0  0 100  0  0
 0  0      0 233480800 758304 20795520    0    0     0     0  951 1519  0  0 100  0  0
 0  0      0 233481056 758304 20795520    0    0     0     0  867 1460  0  0 100  0  0
 0  0      0 233481408 758304 20795520    0    0     0    20  910 1520  0  0 100  0  0
 0  0      0 233481680 758304 20795520    0    0     0     0  911 1491  0  0 100  0  0
 0  0      0 233481920 758304 20795520    0    0     0     0  889 1530  0  0 100  0  0

로그인 후 복사

Command 2: vmstat

먼저 2초마다 수집을 의미하는 vmstat 2 명령어를 살펴보세요

rrreee
procs
r #실행 중인 대기열(즉, 실제로 CPU에 할당된 프로세스 수)을 나타냅니다. 이 값이 CPU 수를 초과하면 CPU 병목 현상이 발생합니다. 이는 top의 부하와도 관련이 있는데, 일반적으로 부하가 3을 넘으면 상대적으로 높고, 5를 넘으면 높다고 하며, 10을 넘으면 비정상이라 서버의 상태가 매우 위험하다. . top의 로드는 초당 실행 대기열과 유사합니다. 실행 대기열이 너무 크면 CPU 사용량이 매우 많아 일반적으로 CPU 사용량이 높아진다는 의미입니다.
b #블록된 프로세스, 즉 리소스를 기다리는 프로세스를 나타냅니다. 이에 대해 많이 말하지는 않겠지만 프로세스가 차단되었다는 것은 누구나 알고 있습니다.

memory
swpd #사용된 가상 메모리의 크기가 0보다 크면 컴퓨터의 물리적 메모리가 부족하다는 의미입니다. 프로그램 메모리 누수의 원인이 아니라면 메모리를 업그레이드해야 합니다. 또는 메모리를 많이 사용하는 작업을 다른 시스템으로 마이그레이션합니다.
free # 사용 가능한 물리적 메모리의 크기
buff #Linux/Unix 시스템은 디렉토리의 내용, 권한 등을 저장하고 캐시하는 데 사용됩니다.
cache #cache는 우리가 열고 수행하는 파일을 기억하는 데 직접 사용됩니다. 파일 처리 버퍼링은 프로그램 실행 성능을 향상시키기 위해 여유 물리적 메모리의 일부를 사용하여 파일과 디렉터리를 캐시합니다.
swap
si #디스크에서 초당 읽는 가상 메모리의 크기입니다. 이 값이 0보다 크면 물리적 메모리가 부족하거나 메모리가 누수된다는 의미입니다. 처리하고 해결해 보세요. 내 컴퓨터에는 충분한 메모리가 있고 모든 것이 잘 작동합니다.
so #초당 디스크에 쓰는 가상 메모리의 크기(이 값이 0보다 큰 경우 위와 동일)
io
bi #블록 장치가 초당 수신하는 블록 수입니다. 여기서 블록 장치는 시스템의 모든 디스크 및 기타 블록 장치를 의미합니다. 기본 블록 크기는 1024byte입니다.
bo #블록 장치 초당 블록 장치에서 보낸 블록 수량(예: 파일을 읽을 때 bo는 0보다 커야 함) Bi와 bo는 일반적으로 0에 가깝습니다. 그렇지 않으면 IO가 너무 자주 발생하므로 조정이 필요합니다.
system
in # 시간 인터럽트를 포함한 초당 CPU 인터럽트 수
cs # 초당 컨텍스트 전환 수, 예를 들어 시스템 함수를 호출할 때 컨텍스트 전환, 스레드를 수행해야 합니다. 스위칭 및 프로세스 컨텍스트 스위칭, 이 값은 가능한 한 작아야 합니다. 너무 크면 스레드 또는 프로세스 수를 줄이는 것을 고려해야 합니다.

cpu
us #사용자 CPU 시간, 저는 서버에 있었습니다. 암호화 및 암호 해독을 매우 자주 수행한 것을 보면 우리가 100에 가까워질 때 r 실행 대기열이 80에 도달한 것을 볼 수 있습니다(머신이 스트레스 테스트를 수행하고 있으며 성능이 좋지 않음).
sy #시스템 CPU 시간이 너무 높다면 잦은 IO 작업 등 시스템 호출 시간이 길다는 의미입니다.
id #Idle CPU 시간, 일반적으로 말하면 id + us + sy = 100, 일반적으로 id는 유휴 CPU 사용량, us는 사용자 CPU 사용량, sy는 시스템 CPU 사용량이라고 생각합니다. 🎜🎜wt #IO CPU 시간을 기다리는 중입니다. 🎜🎜🎜🎜연습🎜
procs r: 실행 중인 프로세스가 많고 시스템이 매우 바쁩니다.
bi/bo: 디스크에 기록되는 데이터의 양이 약간 크면 기본적으로 걱정할 필요가 없습니다. 10M 미만이면 기본적으로 2M 미만이면 정상입니다.
cpu us: 서비스 피크 기간에는 50% 이상이면 허용됩니다. 오랫동안 최적화를 고려할 수 있습니다.
cpu sy: 여기서 us + sy의 기준 값은 80%입니다. us + sy가 80%보다 크면 CPU가 부족할 수 있음을 나타냅니다.
cpu wa: 열은 IO 대기에 의해 점유된 CPU 시간의 백분율을 표시합니다. 여기서 wa의 기준값은 30%입니다. wa가 30%를 초과하면 IO 대기가 심각하다는 의미입니다. 이는 디스크에 대한 랜덤 액세스가 많기 때문일 수도 있고 대역폭 병목 현상 때문일 수도 있습니다. 디스크 또는 디스크 액세스 컨트롤러(주로 블록 작업)

참조 링크: https://www.cnblogs.com/zsql/p/11643750.html

2 코드 diff

를 살펴보세요. 인스턴스를 재시작해도 문제가 해결되지 않았으며 노드 프로세스에 문제가 있는 것으로 판단됩니다. 그렇다면

온라인 커밋을 확인하고 코드 차이점을 확인하여 문제를 찾을 수 있는지 확인하세요

3. 런타임 CPU 프로파일러를 엽니다

이 작업 방법은 다른 기사와 유사합니다.SSR 서버측 메모리 누수 문제를 빠르게 찾는 방법은

노드 --inspect를 사용하여 서비스를 시작합니다.
온라인 환경을 로컬로 시뮬레이션하려면 빌드된 코드를 사용하면 직접 빌드가 작동하지 않을 수 있습니다. 환경 변수를 제어해야 하며 추악한 압축을 꺼야 합니다.
- 예를 들어 일부 환경 변수를 허용합니다. (CDN 도메인 이름 등)은 로컬을 가리킵니다. 패키지가 로컬이고 CDN에 업로드되지 않기 때문입니다
CPU 프로파일러 생성

노드 서비스 CPU가 너무 높으면 어떻게 해야 합니까? 문제 해결 아이디어에 대해 이야기해 보겠습니다.