성능 모니터링이 필요한 이유는 무엇입니까? Node.js 성능 모니터링에 대해 이야기해 보겠습니다.

성능 모니터링이 필요한 이유

Node는 서버측 Javascript의 런타임으로서 Javascript의 애플리케이션 시나리오를 크게 강화합니다.

하지만 Node.js 런타임 자체는 블랙박스이므로 런타임 상태를 인지할 수 없으며 온라인 문제를 재현하기 어렵습니다 .

따라서 성능 모니터링 은 Node.js 애플리케이션의 "정상 작동"의 초석입니다. 다양한 런타임 표시기를 언제든지 모니터링할 수 있을 뿐만 아니라 비정상적인 시나리오 문제를 해결하는 데도 도움이 될 수 있습니다.

구성 요소

성능 모니터링은 성능 지표 수집 및 표시의 두 부분으로 나눌 수 있습니다

• .

  • 프로세스 수준 데이터: CPU, 메모리, 힙, GC 및 기타
  • 시스템 수준 데이터: 디스크 점유, I/O 로드, TCP/UDP 연결 상태, 등
  • 애플리케이션 계층 데이터:
• QPS, 느린 HTTP, 비즈니스 처리 링크 로그 등

  성능 데이터 캡처 및 분석

  • Heapsnapshot: 힙 메모리 스냅샷
  • Cpuprofile: CPU 스냅샷
  • Coredump:

애플리케이션 충돌 스냅샷 솔루션 비교

위 그림에서 현재 주류를 이루는 세 가지 Node.js 성능 모니터링 솔루션의 장단점을 확인할 수 있습니다. 다음은 이 세 가지 솔루션의 구성에 대해 간략하게 소개합니다.

• Prometheus

  • prom-client는 prometheus의 nodejs 구현입니다. 성능 지표를 수집하는 데 사용됩니다.
  • Grafana는 다양한 데이터 차트를 표시하는 데 사용되는 시각화 플랫폼입니다. Prometheus에 대한 액세스는
  • 성능 지표의 수집 및 표시만 지원하며 폐쇄 루프

• AliNode를 형성하기 위해 다른 스냅샷 도구가 필요합니다.

  • Alinode는 공식 nodejs와 호환되는 확장 런타임으로 몇 가지 추가 기능을 제공합니다:

    • v8의 런타임 메모리 상태 모니터링
    • libuv의 런타임 상태 모니터링
    • 온라인 오류 진단 기능: 힙 스냅샷, CPU 프로필, GC 추적 등.

  • Agenthub는 성능 지표를 수집하는 데 사용되는 상주 프로세스입니다.

통합

• 된

  • 에이전트
• • • x + commdx의 편리한 도구

    는

  • 모니터링, 표시, 스냅샷 및 분석에서 폐쇄 루프를 형성합니다. 액세스는 편리하고 간단하지만 런타임을 확장할 때 여전히 위험이 있습니다.

• • 실시간 런타임 상태 샘플링 및 출력 성능 로그(즉, 성능 데이터 가져오기)
  • xtransit은 성능 로그 수집 및 전송을 담당합니다.
  • AliNode와 가장 큰 차이점은 Node.js Addon 사용하여 샘플러

성능 표시

CPU를

현재 프로세스의 CPU 시간 소모 데이터는 process.cpuUsage() 반환 값의 단위는 마이크로초이다.

• 사용자: 프로세스가 실행될 때 프로세스 자체가 소모한 CPU 시간
• 시스템: 프로세스가 소모한 CPU 시간 프로세스가 실행될 때의 시스템

메모리

현재 프로세스의 메모리 할당 데이터는 process.memoryUsage() 를 통해 얻을 수 있습니다. 반환 값의 단위는 바이트입니다.

• rss: 상주 메모리, 노드 프로세스에서 할당한 전체 메모리 크기
• heapTotal: v8에서 적용되는 힙 메모리 크기
• heapUsed: v8에서 사용하는 힙 Memory
• sizeexternal: v8에서 관리하는 C++에서 차지하는 메모리 크기
• arrayBuffers: ArrayBuffer에 할당된 메모리 크기

위 그림에서 볼 수 있듯이 rss 에는 코드 세그먼트( Code Segment ), 스택 메모리( Stack ) 및 힙 메모리( Heap )가 포함됩니다.

• 코드 세그먼트: 코드 세그먼트를 저장
• 하고
힙(
• Heap
)을 관리합니다.
• 객체, 클로저 또는 기타 모든

힙은

v8.getHeapStatistics() 및 v8.getHeapSpaceStatistics() 다음 그림은 v8의 힙 메모리 구성 분포를 보여줍니다.

힙 메모리 공간은 먼저 공간으로 나누어지고, 메모리는 1MB 정렬에 따라 페이징됩니다.

• 뉴 스페이스(New Space): 상대적으로 짧은 수명 주기로 일부 객체 데이터를 저장하는 데 사용되는 신세대 공간으로 두 개의 공간으로 구분됨(공간 유형은 semi space ): from space to space

  • 프로모션 조건: 뉴 공간에서 두 번의 GC 후에도 여전히 생존합니다.

• 올드 스페이스(Old Space) : New Space 에서 승격된 객체를 저장하는 데 사용되는 Old Generation 공간

• Code Space: v8 JIT로 컴파일된 실행 코드를 저장합니다.

• Map Space: Object가 가리키는 히든 클래스의 포인터 객체를 저장합니다. 런타임에 따른 객체 레이아웃 구조는 객체 멤버에 빠르게 액세스하는 데 사용됩니다.

• 대형 객체 공간: 페이지에 할당할 수 없는 1MB보다 큰 객체를 저장하는 데 사용됩니다.

GC

의 가비지 수집 알고리즘은

• 가지

• GC: 구세대의 객체 재활용을 위해 Mark-Sweep-Compact 알고리즘을 사용합니다.
• Scavenge

Scavenge

• • 은

  두

• from space

공간

New space from to

New space

• • Scavenge를 경험했으며, Old space 으로 승격되고
  • 다른 to space 으로

• 복사가 완료되면 to space 에서 살아남은 개체만 있으며 from space

• from space 에서 to space 교환되고 다음 라운드 Scavenge 시작됩니다.

Mark-Sweep-Compact

보다 두 배의 공간을 낭비한다는 단점이 있습니다

3단계: 표시, 지우기, 정리

트리거 타이밍: Old space 가득 찬 경우

단계:

• 표시(3색 표시 방법)

  흰색
  • : 재활용이 불가능한 개체
  • 를 나타냅니다.
  • 회색
  • : 재활용할 수 없는 객체를 나타내며 해당 객체에 의해 생성된 참조는 아직 스캔되지 않았습니다.
  • V8 루트 객체가 직접 참조하는 객체를 marking queue (명시적 스택)에 넣고 해당 객체를 회색으로 표시합니다.
  • 이 객체에서 깊이를 시작합니다. 객체에 액세스할 때마다 객체를 marking queue 에서 pop 검은색으로 표시합니다.
  • 그런 다음 객체가 참조하는 모든 흰색 객체를 회색으로 표시하고 marking queue 로 push
  • . 스택의 모든 객체는 삭제됩니다. Old Generation에는 검은색(재활용 불가능)과 흰색(재활용 가능)의 두 가지 유형만 있습니다.
  • PS: 객체가 너무 커서 재활용할 수 없는 경우
  .
  • 공간이 제한된 스택에 푸시되면 v8은 개체를 회색으로 유지하고 건너뜁니다. 전체 스택을 오버플로(overflowed)로 표시하고 스택이 지워질 때까지 기다린 다음 표시를 다시 순회하므로 추가 스캔이 필요합니다.
• • 흰색 객체를 지우기
  • 위한

  스윕은

  메모리 공간을 불연속적으로 만듭니다
• • .

• 컴팩트

  스윕은 새 객체가 GC에 들어가고
  • 검정색(생존) 객체를 하나로 이동하는 데
  • 도움이 됩니다.
  • Old space 이 연속적이고 완전해지도록 하기 위해
  • 메모리 조각화 문제를 해결할 수는 있지만 일시정지 시간(실행 속도가 느려짐)이 늘어나고
  • 신입생을 위한 공간이 부족합니다. 승격된 개체를 할당할 때만 사용됩니다

Stop-The-World

v8은 처음에 가비지 수집을 수행할 때 프로그램을 다시 실행하기 전에 프로그램을 중지하고 전체 힙을 검색한 후 메모리를 회수해야 합니다. 이 동작을 전체 일시 중지( Stop-The-World )라고 합니다.

새로운 세대의 활성 개체는 작고 자주 재활용되지만, 전체 중지는 거의 영향을 미치지 않습니다. 그러나 이전 세대의 살아남은 개체는 많고 큽니다. 마킹, 청소, 분류 등으로 인한 일시정지 등은 더욱 심각할 것입니다.

최적화 전략

• 증분 재활용(Incremental Marking): Marking 단계에서는 힙이 특정 크기에 도달하면 증분 GC가 시작됩니다. 일정량의 메모리가 할당될 때마다 실행 중인 프로그램이 일시 중지되고 몇 밀리초 동안 마킹이 수행됩니다. 수십 밀리초로 설정한 다음 프로그램을 다시 시작합니다.

이 개념은 실제로 React 프레임워크의 Fiber 아키텍처와 약간 비슷합니다. 브라우저의 자유 시간 동안에만 Fiber 트리를 통과하여 해당 작업을 수행합니다. 그렇지 않으면 실행이 지연되어 메인 스레드의 작업에 최소한의 영향을 미칩니다. , 애플리케이션 지연을 방지하고 애플리케이션 성능을 향상시킵니다.

• 동시 스위핑(Concurrent Sweeping): 실행 프로그램의 메인 스레드와의 충돌을 걱정하지 않고 다른 스레드가 동시에 스위핑을 수행하도록 합니다.
• 병렬 스위핑(Parallel Sweeping): 여러 스위핑 스레드가 동시에 작동하도록 하여 스위핑 처리량을 향상하고 전체 GC 주기적을 단축합니다.

공간 조정

v8에는

• New space 기본 제한이 있으므로 64비트 시스템의 경우 32M, 32비트 시스템의 경우 16M,
• Old space 비트 시스템의 경우 1400M입니다
.
• 32비트 시스템의 경우 700M

이므로 node 신세대와 구세대의 공간 상한을 조정하기 위해 두 개의 매개변수가 제공됩니다

• --max-semi-space-size : New Space 공간의 최대값을 설정합니다.
• --max-old-space-size : Old Space 공간 보기의 최대값을 설정합니다.

GC 로그

node GC 로그를 보는 세 가지 방법도 제공합니다.

• --trace_gc : 로그 줄은 각 GC의 시간, 유형, 힙 크기 변경 및 원인을 간략하게 설명합니다
• --trace_gc_verbose : 각 GC 이후 각 V8 힙을 표시합니다. 공간의 세부 상태
• --trace_gc_nvp : GC 유형, 일시 중지 시간, 메모리 변경 등을 포함한 각 GC의 세부 키-값 쌍 정보입니다.

GC 로그는 상대적으로 원시적이고 필요하므로 보조 처리를 수행하려면 AliNode 팀에서 개발한 v8-gc를 사용할 수 있습니다. 로그 파서

스냅샷 도구인

Heapsnapshot은

실행 중인 프로그램의 힙 메모리 스냅샷을 찍고 메모리 소비를 분석하고

생성 방법을

.heapsnapshot 다음과 같은 방법으로 생성됩니다.

• heapdump 사용

• v8의 힙 프로필 사용

• nodejs의 내장 v8 모듈에서 제공하는

  api

  • v8.getHeapSnapshot()

  사용하세요.

  

  • v8.writeHeapSnapshot(fileName)

  

• v8-profiler-next 사용

분석 방법

Chrome devtools 툴바의 Memory에 업로드 .heapsnapshot , 결과는 아래와 같이 표시됩니다.

기본 보기는 Summary 보기입니다. 여기서 가장 오른쪽 두 열인 Shallow Size 와 Retained Size

Shallow
• Retained Size
• Shallow Size v8 힙 메모리에 할당된 개체 자체의 크기를 나타냅니다.
• 개체의 모든 참조 개체에 대한 Shallow Size

Retained Size 가 특히 큰 것으로 확인되면 개체 내부에 메모리 누수가 있을 수 있습니다.

Comparison 보기를 사용하여 문제를 비교할

서로 다른 두 기간의 힙 스냅샷을 분석합니다. Delta 열은 가장 큰 메모리 변경 사항이 있는 개체를 필터링하는 데 사용할 수 있습니다.

Cpuprofile은

프로그램을 실행하는 CPU의 스냅샷 샘플링을 수행하며, 이는 CPU 시간과 비율을 분석하는 데 사용할 수 있습니다.

.cpuprofile 파일을 생성하는 방법에는 여러 가지가 있습니다:

v8

• -profiler(노드에서 공식적으로 제공하는 도구이지만 더 이상 사용할 수 없음) node v10 이상 지원) 버전, 더 이상 유지 관리되지 않음)
• v8-profiler-next (중국 유지 관리 버전, 최신 노드 v18 지원, 지속적인 유지 관리 중)

5분 분량의 CPU 프로필 샘플 모음입니다.

분석 방법

Javascript Profiler 생성된 .cpuprofile 파일은

기본 보기는 Heavy 보기입니다. 여기에는 Self Time 과 Total Time

• Self Time : 이 함수 자체의 실행 시간을 나타냅니다(다른 호출 제외).
• Total Time : 다른 호출을 포함하여 이 함수의 실행 시간을 나타냅니다. 함수 호출) 총 시간과 자체 시간이 크게 벗어나는 경우 해당 함수에

많은 시간이 소요되는 CPU 집약적인 계산이 Self Time Total Time .

응용 프로그램이 예기치 않게 충돌하고 종료되는 경우

을

시스템은 이를 자동으로 기록합니다. 프로세스는 해당 순간에 메모리 할당 정보, 프로그램 카운터 및 스택 포인터 및 기타 주요 정보를 충돌시켜 코어 파일

생성 방법을

.core

• ulimit -c unlimited 커널 제한을 엽니다

• node --abort-on-uncaught-exception 노드 시작 시 이 매개변수를 추가하면 애플리케이션에서 포착되지 않은 예외가 발생할 때 코어 파일을 생성할 수 있습니다.
• gcore <pid> 코어 파일

분석 방법을

.core mdb, gdb, lldb 등의 도구를 통해 진단 가능 프로세스 충돌의 실제 원인

• llnode `which node` -c /path/to/core/dump

사례 분석

관찰

힙 메모리가 계속해서 증가하는 것을 모니터링을 통해 관찰할 수 있으므로 문제 해결

및 분석을 위해 힙 스냅샷이 필요합니다.

heapsnapshot 상대적으로 큰 메모리를 항상 유지하고 있는 newThing 객체가 있다는 것을 분석하여 알아낼 수 있습니다

.

보면

unused theThing newThing

클로저로 인한 replaceThing 사례

일반적인 메모리 누수

에는

• 전역 변수,
• 클로저,
• 타이머,
• 이벤트 청취
• 캐시 등이 포함됩니다.

자동으로 재활용되지 않으면 수동으로 객체를 null 로 설정, 타이머 제거, 이벤트 리스너 바인딩 해제 등과 같은 수동 재활용이 필요합니다.

으로

이 기사는 전체 Node.js 성능 모니터링 시스템에 대한 자세한 소개를 제공했습니다.

먼저, 성능 모니터링을 통해 해결되는 문제점과 그 구성요소를 소개하고, 주류 솔루션의 장단점을 비교한다.

그런 다음 성능 지표의 두 가지 주요 부분과 스냅샷 도구를 자세히 소개합니다.

• 성능 지표는 주로 CPU, 메모리, 힙 공간 및 GC 지표에 중점을 두고 동시에 v8의 GC 전략과 GC 최적화 계획을 소개합니다.
• 스냅샷 도구에는 주로 힙 스냅샷, CPU 스냅샷, 충돌 시 코어 덤프가 포함됩니다
• .

마지막으로 관찰, 분석 및 문제 해결을 통해 간단한 메모리 누수 사례를 재현하고 일반적인 메모리 누수 상황과 해결 방법을 요약합니다.

이 글이 모든 사람이 전체 Node.js 성능 모니터링 시스템을 이해하는 데 도움이 되기를 바랍니다.