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

성능 모니터링이 필요한 이유는 무엇인가요? 이 글은 여러분에게 Node.js성능 모니터링을 안내할 것입니다. 여러분에게 도움이 되기를 바랍니다.

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

Node서버측 Javascript용 런타임으로서 Javascript의 애플리케이션 시나리오를 크게 풍부하게 합니다.

그러나 Node.js 런타임 자체는 블랙박스입니다. 우리는 런타임 상태를 인식할 수 없으며 온라인 문제를 재현하기도 어렵습니다.

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

Components

성능 모니터링은 두 부분으로 나눌 수 있습니다:

• 성능 지표 수집 및 표시

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

• 성능 데이터 캡처 및 분석

  • 힙스냅샷 : 힙 메모리 스냅샷
  • Cpuprofile: CPU 스냅샷
  • Coredump: 애플리케이션 충돌 스냅샷

솔루션 비교

위 그림에서 현재 주류인 3가지 노드의 장단점을 확인할 수 있습니다. .js 성능 모니터링 솔루션, 다음은 이 세 가지 솔루션의 구성에 대한 간략한 소개입니다.

• Prometheus

  • prom-client는 성능 지표를 수집하는 데 사용되는 prometheus의 nodejs 구현입니다.
  • grafana Prometheus 액세스를 지원하는 다양한 A 데이터 차트를 표시하는 데 사용되는 시각화 플랫폼입니다
  • 성능 지표의 수집 및 표시만 지원합니다. 폐쇄 루프를 형성하기 위해 문제를 해결하려면 다른 스냅샷 도구가 필요합니다

• AliNode

  • alinode는 공식 nodejs와 호환되는 확장 프로그램입니다. 런타임 시 몇 가지 추가 기능이 제공됩니다:

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

  • agenthub 는 성과 지표를 수집하고 보고하는 데 사용되는 상주 프로세스입니다.

    • agentx + commdx, 편리한 도구

  • 를 통합합니다. 전체 프로세스는 모니터링에서 폐쇄 루프를 형성합니다. 디스플레이, 스냅샷, 분석 등 접근이 편리하고 간편하지만 런타임 확장에는 여전히 리스크가 존재합니다

• Easy-Monitor

  • xprofiler는 실시간 런타임 상태 샘플링을 담당합니다. 및 성능 로그 출력(즉, 성능 데이터 캡처)
  • xtransit은 성능 로그 수집 및 전송을 담당합니다
  • AliNode와 가장 큰 차이점은 Node.js Addon을 사용한다는 것입니다. > 샘플러 구현Node.js Addon来实现采样器

性能指标

CPU

通过process.cpuUsage()可以获取当前进程的CPU耗时数据，返回值的单位是微秒

• user：进程执行时本身消耗的CPU时间
• system：进程执行时系统消耗的CPU时间

Memory

通过process.memoryUsage()

성능 지표
CPU
• 
• 현재 CPU 소비 데이터 process는 process.cpuUsage()를 통해 얻을 수 있습니다. 반환 값의 단위는 Microseconds

user: 실행 중 프로세스 자체가 소비한 CPU 시간

system: 프로세스가 소비한 CPU 시간입니다. 프로세스가 실행될 때의 시스템🎜🎜

🎜Memory🎜🎜🎜🎜🎜 process.memoryUsage()를 통해 현재 프로세스의 메모리 할당 데이터를 얻을 수 있습니다. 반환 값은 바이트입니다. 🎜🎜🎜rss: 상주 메모리, 노드 프로세스에서 할당한 총 메모리 크기🎜🎜heapTotal: v8🎜🎜에서 적용한 힙 메모리 크기 heapUsed: v8에서 사용하는 힙 메모리 크기 🎜🎜external: v8 🎜🎜arrayBuffers에서 관리하는 C++에서 차지하는 메모리 크기: ArrayBuffer 🎜🎜🎜🎜🎜에 할당된 메모리 크기

위 그림에서 볼 수 있듯이 rss에는 코드 세그먼트(Code Segment), 스택 메모리(Stack), 힙 메모리( 힙)rss包含代码段(Code Segment)、栈内存(Stack)、堆内存(Heap)

• Code Segment：存储代码段
• Stack：存储局部变量和管理函数调用
• Heap：存储对象、闭包、或者其他一切

Heap

通过v8.getHeapStatistics()和v8.getHeapSpaceStatistics()可以获取v8堆内存和堆空间的分析数据，下图展示了v8的堆内存组成分布：

堆内存空间先划分为空间（space），空间又划分为页（page），内存按照1MB对齐进行分页。

• New Space：新生代空间，用来存放一些生命周期比较短的对象数据，平分为两个空间（空间类型为semi space）：from space，to space

  • 晋升条件：在New space中经过两次GC依旧存活

• Old Space：老生代空间，用来存放New Space晋升的对象

• Code Space：存放v8 JIT编译后的可执行代码

• Map Space：存放Object指向的隐藏类的指针对象，隐藏类指针是v8根据运行时记录下的对象布局结构，用于快速访问对象成员

• Large Object Space：用于存放大于1MB而无法分配到页的对象

GC

v8的垃圾回收算法分为两类：

• Major GC：使用了Mark-Sweep-Compact算法，用于老生代的对象回收
• Minor GC：使用了Scavenge算法，用于新生代的对象回收

Scavenge

前提：New space分为from和to两个对象空间

触发时机：当New space空间满了

步骤：

• 在from space中，进行宽度优先遍历

• 发现存活（可达）对象

  • 已经存活过一次（经历过一次Scavange），晋升到Old space
  • 其他的复制到to space中

• 当复制结束时，to space中只有存活的对象，from space就被清空了

• 交换from space和to space，开始下一轮Scavenge

适用于回收频繁，内存不大的对象，典型的空间换时间的策略，缺点是浪费了多一倍的空间

Mark-Sweep-Compact

三个步骤：标记、清除、整理

触发时机：当Old space空间满了

步骤：

• Marking（三色标记法）

  • 白色：代表可回收对象
  • 黑色：代表不可回收对象，且其所产生的引用都已经扫描完毕
  • 灰色：代表不可回收对象，且其所产生的引用还没扫描完
  • 将V8根对象直接引用的对象放进一个marking queue（显式栈）中，并将这些对象标记为灰色
  • 从这些对象开始做深度优先遍历，每访问一个对象，将该对象从marking queue pop出来，并标记为黑色
  • 然后将该对象引用下的所有白色对象标记为灰色，push到marking queue
  • 코드 세그먼트: 코드 세그먼트를 저장
  • 스택: 지역 변수를 저장하고 함수 호출을 관리
  힙: 객체, 클로저 또는 기타 모든 것을 저장

• 힙

  V8 힙 메모리 및 힙 공간은 v8.getHeapStatistics() 및 v8.getHeapSpaceStatistics() 분석 데이터, 다음 그림은 v8의 힙 메모리 구성 분포를 보여줍니다.

  
  • 힙 메모리 공간을 먼저 공백으로 나누고, 공간을 페이지 단위로 나누어 1MB 정렬에 따라 메모리를 페이징합니다.
New Space : 상대적으로 짧은 수명주기의 일부 객체 데이터를 저장하는 데 사용되는 신세대 공간으로 두 개의 공간으로 구분됩니다. (공간 유형은 semi space) : from space, <code>to space

• Promotion 조건: New space🎜🎜🎜🎜🎜Old Space: Old Generation 공간, New Space 코드를 저장하는 데 사용됨 >Promoted object🎜🎜🎜🎜Code Space: v8 JIT🎜🎜🎜🎜로 컴파일된 실행 코드를 저장합니다. Map Space: Object가 가리키는 히든 클래스의 포인터 객체를 저장합니다. 히든 클래스 포인터는 v8에서 다음에 따라 기록한 객체입니다. 개체 구성원에 대한 빠른 액세스를 위한 런타임 레이아웃 구조🎜🎜🎜🎜대형 개체 공간: 페이지에 할당할 수 없는 1MB보다 큰 개체를 저장하는 데 사용됩니다🎜🎜🎜<h3 data-id="heading-8"><strong>GC </strong></h3>🎜v8의 가비지 수집 알고리즘은 두 가지 범주로 나뉩니다. 🎜🎜🎜Major GC: 구세대 객체 재활용을 위해 <code>Mark-Sweep-Compact 알고리즘을 사용합니다. 🎜🎜Minor GC: 새로운 세대의 객체 재활용을 위해 Scavenge 알고리즘을 사용합니다🎜🎜

  Scavenge

  🎜🎜🎜전제 조건: 새 공간는 <code>from 및 to라는 두 개의 개체 공간으로 나뉩니다.🎜🎜트리거 시간: 새 공간 공간이 가득 찼을 때🎜🎜단계: 🎜🎜🎜🎜 from space에서 너비 우선 순회🎜🎜🎜🎜를 수행하고 살아남은(연결 가능한) 개체 🎜🎜🎜가 한 번 살아남았고(Scavange를 경험함) 오래된 공간🎜🎜다른 것들은 공간으로🎜🎜🎜🎜🎜 복사가 끝나면 공간으로에 살아남은 개체들만 남게 되고, > from space가 삭제되었습니다🎜🎜🎜🎜 from space와 to space를 교환하고 다음 Scavenge🎜🎜 라운드를 시작하세요. 🎜 🎜재활용이 잦고 메모리가 작은 개체에 적합합니다. 단점은 두 배의 공간이 낭비된다는 것입니다.🎜

  Mark-Sweep-Compact

  🎜🎜🎜3단계: 표시, 지우기, 정리🎜🎜트리거 시간: 기존 공간이 가득 찼을 때🎜🎜단계: 🎜🎜🎜🎜 마킹( 3색 마킹 방식)🎜🎜🎜흰색: 재활용이 가능한 개체를 나타냅니다.🎜🎜검정색: 재활용이 불가능한 개체를 나타내며, 그에 의해 생성된 참조는 스캔되었습니다.🎜🎜회색: 재활용이 불가능한 개체를 나타내고, 참조가 생성된 참조는 다음과 같습니다. 아직 스캔되지 않았습니다. 스캔 후🎜🎜V8 루트 개체가 직접 참조하는 개체를 표시 대기열(명시적 스택)에 넣고 이러한 개체를 회색으로 표시합니다🎜🎜깊이 우선 탐색으로 시작합니다. 이러한 개체에서 개체에 액세스할 때마다 개체를 표시 대기열 pop에서 꺼내어 검은색으로 표시합니다. 🎜🎜 그런 다음 개체 참조 아래의 모든 흰색 개체를 다음으로 표시합니다. 회색, 표시 대기열에 푸시 등을 수행하여 스택의 모든 개체가 팝될 때까지 이전 세대에는 검은색(비-) 개체만 남습니다. recyclable) 및 흰색(재활용 가능). Planted🎜🎜PS: 제한된 공간에서 개체가 너무 커서 스택에 밀어넣을 수 없는 경우 v8에서는 개체를 회색으로 유지하고 건너뛰어 스택 후 전체 스택을 오버플로로 표시합니다. 지워지면 마크가 다시 탐색되므로 힙을 추가로 스캔해야 합니다🎜🎜🎜🎜🎜Sweep🎜🎜🎜흰색 개체를 지우면🎜🎜 메모리 공간이 불연속됩니다🎜🎜🎜🎜🎜Compact🎜
  • Sweep은 메모리 공간을 불연속적으로 만들기 때문에 새로운 객체가 GC에 진입하는 데 도움이 되지 않습니다.
  • 검은색(생존) 객체를 Old 공간의 한쪽 끝으로 이동하여 지워진 공간은 연속적이고 완전할 것입니다Old space的一端，这样清除出来的空间就是连续完整的
  • 虽然可以解决内存碎片问题，但是会增加停顿时间（执行速度慢）
  • 在空间不足以对新生代晋升过来的对象进行分配时才使用mark-compact

Stop-The-World

在最开始v8进行垃圾回收时，需要停止程序的运行，扫描完整个堆，回收完内存，才会重新运行程序。这种行为就叫全停顿（Stop-The-World）

虽然新生代活动对象较小，回收频繁，全停顿，影响不大，但是老生代存活对象多且大，标记、清理、整理等造成的停顿就会比较严重。

优化策略

• 增量回收（Incremental Marking）：在Marking阶段，当堆达到一定大小时，开始增量GC，每次分配了一定量的内存后，就暂停运行程序，做几毫秒到几十毫秒的marking，然后恢复程序的运行。

这个理念其实有点像React框架中的Fiber架构，只有在浏览器的空闲时间才会去遍历Fiber Tree执行对应的任务，否则延迟执行，尽可能少地影响主线程的任务，避免应用卡顿，提升应用性能。

• 并发清除（Concurrent Sweeping）：让其他线程同时来做 sweeping，而不用担心和执行程序的主线程冲突
• 并行清除（Parallel Sweeping）：让多个 Sweeping 线程同时工作，提升 sweeping 的吞吐量，缩短整个 GC 的周期

空间调整

由于v8对于新老生代的空间默认限制了大小

• New space 默认限制：64位系统为32M，32位系统为16M
• Old space 默认限制：64位系统为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-log-parser

快照工具

Heapsnapshot

对于运行程序的堆内存进行快照采样，可以用来分析内存的消耗以及变化

生成方式

生成.heapsnapshot文件有以下几种方式：

• 使用heapdump

• 使用v8的heap-profile

• 使用nodejs内置的v8模块提供的api

  • v8.getHeapSnapshot()

  

  • v8.writeHeapSnapshot(fileName)

  

• 使用v8-profiler-next

分析方法

生成的.heapsnapshot

메모리 조각화 문제를 해결할 수 있지만 일시 중지 시간이 늘어납니다(실행 속도가 느림)

새로운 세대에서 승격된 개체를 할당할 공간이 부족한 경우에만 mark-compact를 사용하세요.

🎜

Stop-The-World

🎜v8이 처음 가비지 수집을 수행할 때 중지해야 합니다. 프로그램 실행 후 전체 힙을 스캔하고 메모리를 회수하면 프로그램이 다시 실행됩니다. 이러한 동작을 완전 정지(Stop-The-World)라고 합니다🎜🎜신세대의 활성 객체는 작고 자주 재활용되지만, 완전 정지는 거의 영향을 미치지 않지만 이전 세대의 살아남은 객체는 표시, 청소, 정리 등으로 인한 일시 중지는 더 심각할 것입니다. 🎜

최적화 전략

🎜🎜증분 표시: 표시 단계에서 힙이 특정 크기에 도달하면 증분은 GC를 시작합니다. 일정량의 메모리를 할당하고 프로그램 실행을 일시 중지한 후 몇 밀리초에서 수십 밀리초 동안 표시를 한 다음 프로그램 실행을 다시 시작합니다. 🎜🎜이 개념은 실제로 React 프레임워크의 Fiber 아키텍처와 약간 비슷합니다. 브라우저의 자유 시간 동안에만 Fiber 트리를 통과하여 해당 작업을 수행합니다. 그렇지 않으면 실행이 지연되어 메인에 영향을 미칩니다. 스레드의 작업을 가능한 한 적게 수행하여 애플리케이션 지연을 방지하고 애플리케이션 성능을 향상시킵니다. 🎜🎜🎜동시 스위핑: 실행 프로그램의 메인 스레드와의 충돌을 걱정하지 않고 다른 스레드가 동시에 스위핑을 수행하도록 합니다. 🎜🎜병렬 스위핑: 여러 스위핑 스레드가 동시에 작동하여 스위핑 처리량을 향상시켜 스위핑 처리량을 단축합니다. 전체 GC 주기🎜

공간 조정

🎜v8은 기본적으로 신세대와 구세대 공간의 크기를 제한하기 때문입니다 🎜🎜 🎜새 공간 기본 제한: 64비트 시스템의 경우 32M, 32비트 시스템의 경우 16M 🎜🎜기존 공간 기본 제한: 64비트 시스템의 경우 1400M, 32비트 시스템의 경우 1400M -bit system 700M🎜🎜그래서 node는 신세대와 구세대의 공간 상한을 조정하기 위한 두 개의 매개변수를 제공합니다🎜🎜🎜--max-semi-space-size : <code>새 공간의 최대값 설정 space🎜🎜--max-old-space-size: 기존 공간의 최대값 설정 code> space🎜

GC 로그 보기

🎜node는 GC를 보는 세 가지 방법도 제공합니다. 로그: 🎜 🎜🎜--trace_gc: 로그 줄은 각 GC의 시간, 유형, 힙 크기 변경 및 원인을 간략하게 설명합니다. 🎜🎜--trace_gc_verbose: 각 GC의 결과 각 V8 힙 공간의 자세한 상태 🎜🎜--trace_gc_nvp: GC 유형, 일시 중지 시간, 메모리 변경 등을 포함한 각 GC의 자세한 키-값 쌍 정보 🎜🎜GC 로그로 인해 상대적으로 원시적이며 2차 처리가 필요합니다. v8-gc-log-parser🎜

스냅샷 도구

힙스냅샷

🎜실행 중인 프로그램의 힙 메모리에 대한 스냅샷 샘플링을 사용하여 분석할 수 있습니다. 메모리 소비 및 변경🎜

생성 방법

🎜.heapsnapshot 파일을 생성하는 방법에는 여러 가지가 있습니다. 🎜🎜 🎜🎜힙 덤프🎜🎜🎜🎜🎜🎜🎜v8 사용힙 프로필🎜🎜🎜🎜🎜🎜🎜v8에서 제공하는 API를 사용하세요 nodejs🎜🎜🎜🎜v8.getHeapSnapshot()🎜🎜🎜🎜🎜🎜🎜v8.writeHeapSnapshot(파일 이름)🎜🎜🎜🎜🎜🎜🎜 v8-profiler-next🎜🎜🎜🎜

분석 방법

🎜생성된 .heapsnapshot 파일은 Chrome 개발자 도구 도구 모음의 메모리에 업로드할 수 있으며, 결과는 다음과 같습니다. 아래와 같이 표시됩니다: 🎜🎜🎜🎜

기본 보기는 요약 보기입니다. 여기서 가장 오른쪽 두 열인 Shallow Size 및 Retained SizeSummary视图，在这里我们要关注最右边两栏：Shallow Size 和 Retained Size

• Shallow Size：表示该对象本身在v8堆内存分配的大小
• Retained Size：表示该对象所有引用对象的Shallow Size之和

当发现Retained Size特别大时，该对象内部可能存在内存泄漏，可以进一步展开去定位问题

还有Comparison视图是用于比较分析两个不同时段的堆快照，通过Delta列可以筛选出内存变化最大的对象

Cpuprofile

对于运行程序的CPU进行快照采样，可以用来分析CPU的耗时及占比

生成方式

生成.cpuprofile文件有以下几种方式：

• v8-profiler（node官方提供的工具，不过已经无法支持node v10以上的版本，并不再维护）
• v8-profiler-next（国人维护版本，支持到最新node v18，持续维护中）

这是采集5分钟的CPU Profile样例

分析方法

生成的.cpuprofile文件，可以在Chrome devtools工具栏的Javascript Profiler（不在默认tab，需要在工具栏右侧的更多中打开显示），选择上传文件后，展示结果如下图：

默认的视图是Heavy视图，在这里我们看到有两栏：Self Time和Total Time

• Self Time：代表此函数本身（不包含其他调用）的执行耗时
• Total Time：代表此函数（包含其他调用函数）的总执行耗时

当发现Total Time和Self Time偏差较大时，该函数可能存在耗时比较多的CPU密集型计算，也可以展开进一步定位排查

Codedump

当应用意外崩溃终止时，系统会自动记录下进程crash掉那一刻的内存分配信息，Program Counter以及堆栈指针等关键信息来生成core文件

生成方式

生成.core文件的三种方法：

• ulimit -c unlimited打开内核限制
• node --abort-on-uncaught-exceptionnode启动添加此参数，可以在应用出现未捕获的异常时也能生成一份core文件
• gcore <pid></pid>手动生成core文件

分析方法

获取.core文件后，可以通过mdb、gdb、lldb等工具实现解析诊断实际进程crash的原因

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

案例分析

观察

从监控可以观察到堆内存在持续上升，因此需要堆快照进行排查

分析

根据heapsnapshot可以分析排查到有一个newThing的对象一直保持着比较大的内存

排查

从代码中可以看到虽然unused方法没有调用，但是newThing对象是引用自theThing，导致其一直存在于replaceThing

• Shallow Size: v8 힙 메모리에 할당된 객체 자체의 크기를 나타냅니다.
• 보유된 크기: Shallow를 나타냅니다. 개체 Sizesum

의 모든 참조 개체 중 Retained Size가 특히 큰 것으로 확인되면 개체 내부에서 메모리 누수가 발생할 수 있습니다. 그리고 문제를 찾기 위해 더 확장할 수도 있습니다

또한비교

보기는 서로 다른 두 기간의 힙 스냅샷을 비교하고 분석하는 데 사용됩니다. 델타 열을 사용하여 필터링할 수 있습니다. 가장 큰 메모리 변화가 있는 객체를 찾아보세요

Cpuprofile

🎜🎜은 프로그램을 실행하는 🎜CPU🎜의 스냅샷 샘플링을 찍습니다. 이는 CPU 시간과 비율🎜

🎜Generation method🎜

🎜Generation.cpuprofile 파일은 다음과 같은 방법으로 사용할 수 있습니다. 🎜

• v8-profiler (노드에서 공식적으로 제공하는 도구이지만 더 이상 노드 v10을 지원하지 않습니다. 위 항목이며 더 이상 유지되지 않습니다)
• v8-profiler-next (중국어 유지 관리 버전, 최신 노드 v18 지원, 지속적인 유지 관리 중간)

🎜5분짜리 CPU 프로필 샘플입니다 🎜🎜🎜

🎜분석 방법🎜

🎜생성된 .cpuprofile파일, Chrome devtools 도구 모음의 Javascript Profiler로 이동할 수 있습니다(기본 탭이 아님, 툴바 오른쪽의 더보기에서 디스플레이를 엽니다. 파일 업로드를 선택한 후 표시 결과는 다음과 같습니다. 🎜🎜 🎜🎜기본 뷰 Heavy 뷰입니다. 여기서는 두 가지 뷰가 있음을 알 수 있습니다. 열: 자체 시간 및 총 시간🎜

• 자체 시간: 이 함수 자체의 실행 시간을 나타냅니다(다른 호출 제외). )
• 총 시간: 이 함수의 총 실행 시간을 나타냅니다(다른 호출 함수 포함)

🎜 총 시간 및 자체 시간이 크면 함수에 많은 시간이 소요되는 CPU 집약적인 계산이 있을 수 있습니다. 추가 문제 해결을 수행할 수도 있습니다🎜

🎜Codedump🎜🎜🎜어플리케이션이 충돌하여 예기치 않게 종료되면 시스템은 프로세스가 충돌한 순간의 메모리 할당 정보, 프로그램 카운터 및 스택을 자동으로 기록합니다. 코어 파일을 생성하기 위한 포인터 및 기타 주요 정보🎜🎜생성 방법🎜🎜.core 파일을 생성하는 세 가지 방법:🎜

• ulimit -c unlimited커널 제한 켜기
• node --abort-on-uncaught-Exception노드를 시작할 때 이 매개변수를 추가하세요. 애플리케이션에서 사용할 수 있습니다. 코어 파일은 다음과 같은 작업을 수행할 수 있습니다. 포착되지 않은 예외가 발생하는 경우에도 생성됩니다.
• gcore <pid></pid>코어 파일을 수동으로 생성

🎜분석 방법🎜

🎜.core 파일을 얻은 후 mdb, gdb, lldb 및 기타 도구를 사용하여 실제 프로세스 충돌 원인을 분석하고 진단할 수 있습니다🎜

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

🎜사례 분석🎜 h2>

🎜관찰🎜🎜🎜🎜🎜모니터링을 통해 힙 메모리가 계속 증가하는 것을 확인할 수 있으므로 문제 해결을 위해 힙 스냅샷이 필요합니다🎜

🎜Analytics🎜🎜 🎜🎜🎜heapsnapshot에 따르면 newThing의 개체가 항상 비교적 큰 메모리를 유지하고 있음을 분석하고 확인할 수 있습니다🎜

🎜문제 해결🎜🎜🎜🎜🎜코드를 보면 알 수 있습니다. unused 메소드가 호출되지는 않았지만 theThing에서 newThing 객체를 참조하여 replaceThing에 항상 존재하도록 함수의 실행 컨텍스트에서는 해제되지 않습니다. 이는 클로저로 인해 발생하는 일반적인 메모리 누수 사례입니다🎜🎜🎜요약🎜🎜🎜일반적인 메모리 누수에는 다음과 같은 상황이 포함됩니다. :🎜

• 전역 변수
• Closure
• Timer
• 이벤트 모니터링
• Cache

따라서 위의 상황에서는 메모리에 있는 객체가 자동으로 재활용되는지 여부를 신중하게 고려해야 합니다. 그렇다면 수동 재활용이 필요합니다. , 수동으로 객체를 null로 설정, 타이머 제거, 이벤트 리스너 바인딩 해제 등이 있습니다.

요약

지금까지 이 글에서는 전체 Node.js 성능 모니터링 시스템에 대해 자세히 소개했습니다.

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

다음으로 두 가지 주요 성능 지표와 스냅샷 도구를 자세히 소개합니다.

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

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

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

노드 관련 지식을 더 보려면 nodejs 튜토리얼을 방문하세요!

위 내용은 성능 모니터링이 필요한 이유는 무엇입니까? Node.js 성능 모니터링에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!