hyj1991
TA的个人档案
hyj1991个人页面-阿里云开发者社区
文章
14
问答
0
个人介绍
这个人太懒了，什么都没留下
擅长的技术
- Java
- 前端开发
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2020-01-22
逆工程 JS 对象 (一): 浅谈 V8 对象布局
本文首发于 Github，仓库地址: https://github.com/hyj1991/sourcecode_notes，里面也有更多和本文的相关其它内容，欢迎关注。 逆工程 JS 对象 (一): 浅谈 V8 对象布局 逆工程 JS 对象其实就是根据 V8 设计的对 JS 对象存储结构的描述，开发者可以实现在进程运行内存空间中或者进程崩溃后的 Core 文件还原的内存空间中来反推出当前 JS 代码运行状态和 JS 对象在堆空间的分配状况的一种技术。 这种技术可以帮助开发者分析运行中的 JS 程序，或者根据 JS 程序崩溃生成的 Core 文件来进行事后的崩溃原因分析，本文主要从 V8 对象布局的角度来和大家探讨学习下逆工程背后的一些知识。 I. 伪指针 (Tagged Pointer) 我们先来介绍认识一种特殊类型的指针: Tagged Pointer，这里虽然说是特殊，其实从存储或者占用空间大小来说并没有什么特别的地方: 32 位操作系统: 4 byte 32 bit 64 位操作系统: 8 byte 64 bit 我们可以看到，如果程序被设计为按照 4 byte 或者 8 byte 地址对齐来实现最佳的运行效率，那么指针的最后 2 位 (32 位操作系统) 或者 3 位 (64 位操作系统) 下一定都是 0，这样某种程度上对于昂贵的内存空间来说是一种浪费。 Tagged Pointer 就是利用指针最后相同的几位来实现将传统指针区分为不同数据类型的一种历史悠久的实现，具体到 V8 引擎中，它将最后一位 (bit) 通过 0 或者 1 来区分要将当前的指针解析为小整形 (Smi) 或者一个常规的指针: 最后一位为 0: 小整形 (Smi) 最后一位为 1: 指向堆对象的常规指针 (需要转换) 实际上 V8 中对 Smi Tag 的描述在 include/v8-internal.h 中: // Tag information for Smi. const int kSmiTag = 0; const int kSmiTagSize = 1; const intptr_t kSmiTagMask = (1 << kSmiTagSize) - 1; 这里和上文的描述是吻合的。 其实引擎之所以这样处理，是因为在 ECMA 规范中，JS 中所有的 Number 类型数据都是被描述要基于 IEEE-754 双精度浮点型，而我们都知道，CPU 操作浮点数的效率远低于整数，而开发者对于整数的使用又是一个非常普遍的需求: 比如循环计数控制或者数组下标索引等，因此为了程序执行效率的提升引擎需要将 一定范围 内的整数直接将原始指针进行转换后读取。 II. 小整形 (Small Integer) 上面一小节中其实也提到，Tagged Pointer 只能用来描述 一定范围 内的整数大小，那么这个范围具体是多大呢，我们可以继续来从源码中找到答案。 在 include/v8-internal.h 中，首先通过模板定义了 32 位操作系统下的 Smi Tag 信息: // Smi constants for systems where tagged pointer is a 32-bit value. template <> struct SmiTagging<4> { enum { kSmiShiftSize = 0, kSmiValueSize = 31 }; static constexpr intptr_t kSmiMinValue = static_cast<intptr_t>(kUintptrAllBitsSet << (kSmiValueSize - 1)); static constexpr intptr_t kSmiMaxValue = -(kSmiMinValue + 1); }; 这里很显然，32 位操作系统下的 Tagged Pointer，去掉最后一位的标记位，因此用来表示 Smi 值只有 32 位，所以 kSmiValueSize 为 31。 下面的部分则是计算此时能表示的最大整数: 2^(31 - 1) - 1 = 1073741823 (有符号)，所以 32 位下 Smi 的表示范围为: -1073741823 ~ 1073741823。 接着看下64 位操作系统下的 Smi Tag 信息: // Smi constants for systems where tagged pointer is a 64-bit value. template <> struct SmiTagging<8> { enum { kSmiShiftSize = 31, kSmiValueSize = 32 }; }; 同样的部分就补贴了，这里可以看到 Smi 的范围增加了一位，所以表示的范围也增加到: -2147483647 ~ 2147483647。 当然有意思的是 V8 引擎为了某些场景下需要跨平台程序完全一致性也提供了一个宏 V8_31BIT_SMIS_ON_64BIT_ARCH: #ifdef V8_31BIT_SMIS_ON_64BIT_ARCH using PlatformSmiTagging = SmiTagging<kApiInt32Size>; #else using PlatformSmiTagging = SmiTagging<kApiTaggedSize>; #endif 如果定义了这个宏的话，则在 64 位操作系统下会使用和 32 位操作系统下范围完全一致的 Smi。 有了上面的知识，还原给定的一个内存空间地址 p 对应的 Smi 值就很简单了，首先根据掩码判断 p 是否为 Smi: bool Smi::Check(int64_t p) const { return (p & kSmiTagMask) == kSmiTag; } 如果是 Smi，则将地址右移 kSmiShiftSize + kSmiTagMask 位得到记录的原始 int 值: int64_t Smi::GetValue(int64_t p) const { return p >> (kSmiShiftSize + kSmiTagMask); } 这样就完成了将一个实际保存了 Smi 的 Tagged Pointer 逆工程为其原始保存的 int 值的过程。 III. 堆对象 (Heap Object) 上一小节中实现的 Smi::Check 方法可以对给定的地址 p 来判断其最终存储 / 指向的是 Smi 还是一个 V8 对象，kSmiTag 目前在引擎中值为 0，显然当 p 的最后一位为 1 时 Check 方法返回 false，这里就意味着所有的值为奇数的地址实际都指向一个 V8 对象，我们也可以称之为 Heap Object。 如果开发同学曾经因为 JS 的内存问题在 Node.js 或者浏览器中导出过堆快照，并且在 Chrome devtools 中解析，那么就会发现所有的以 @ 符号开始对象地址都是奇数，这里也从侧面印证了这一论述。 对于这个给定的奇数地址 p，我们要将其逆工程回真正指向的 Heap Object 会复杂一些，我们来看下如何处理。 V8 基于自己的规则实现了一套对象布局方式，用 OOP 的方式来描述，所有的 JS 对象类型布局全部都继承自 Heap Object 的布局方式，其实这个也很好理解，毕竟所有 JS 对象本身就是从 Heap Object 派生出来的。 我们先来看下引擎对 Heap Object 的布局描述: // src/objects/heap-object.h // Layout description. #define HEAP_OBJECT_FIELDS(V) \ V(kMapOffset, kTaggedSize) \ /* Header size. */ \ V(kHeaderSize, 0) DEFINE_FIELD_OFFSET_CONSTANTS(Object::kHeaderSize, HEAP_OBJECT_FIELDS) #undef HEAP_OBJECT_FIELDS 其中 DEFINE_FIELD_OFFSET_CONSTANTS 宏是一个用来定义枚举类型的宏，其定义为: // src/utils/utils.h #define DEFINE_FIELD_OFFSET_CONSTANTS(StartOffset, LIST_MACRO) \ enum { \ LIST_MACRO##_StartOffset = StartOffset - 1, \ LIST_MACRO(DEFINE_ONE_FIELD_OFFSET) \ }; 里面的 DEFINE_ONE_FIELD_OFFSET 宏定义为: // src/utils/utils.h #define DEFINE_ONE_FIELD_OFFSET(Name, Size) Name, Name##End = Name + (Size)-1, 宏嵌套宏看起来比较复杂，但是其实它们的本质还是减少重复代码的编写，这里我们直接将 Heap Object 的布局定义宏全部展开: enum { HEAP_OBJECT_FIELDS_StartOffset = Object::kHeaderSize - 1, kMapOffset, kMapOffsetEnd = kMapOffset + (kTaggedSize)-1, kHeaderSize, kHeaderSizeEnd = kHeaderSize + (0) - 1, }; 这样就很清晰了，可以看到宏展开后就是一个描述布局方式的枚举，这里 Heap Object 的布局接在 Object 之后，它的核心只定义了一个指向 Map 的伪指针。 伪指针定义可以参见 Tagged Pointer，它的大小和系统的指针大小完全一致，32 位系统上为 4 byte，64 位系统上为 8 byte。 :::warning MetaMap这里的 Map 和我们在 JS 代码中使用的 Map 完全不是一个东西，它其实是包含描述指向它的 Heap Object 的结构信息的特殊 Heap Object，即经常被提到的 Hidden Class。::: IV. 元信息 (Meta Map) 既然所有的 JS 对象都继承自上一小节中提到的 Heap Object，那也意味着这些 JS 对象在 V8 引擎层面的存储对象必然会保存一个伪指针来指向用来描述这个 JS 对象结构的 Meta Map。 Layout 我们来看 V8 引擎对这样的 Meta Map 的结构描述: // Map layout: // +---------------+---------------------------------------------+ // | _ Type _ | _ Description _ | // +---------------+---------------------------------------------+ // | TaggedPointer | map - Always a pointer to the MetaMap root | // +---------------+---------------------------------------------+ // | Int | The first int field | // `---+----------+---------------------------------------------+ // | Byte | [instance_size] | // +----------+---------------------------------------------+ // | Byte | If Map for a primitive type: | // | | native context index for constructor fn | // | | If Map for an Object type: | // | | inobject properties start offset in words | // +----------+---------------------------------------------+ // | Byte | [used_or_unused_instance_size_in_words] | // | | For JSObject in fast mode this byte encodes | // | | the size of the object that includes only | // | | the used property fields or the slack size | // | | in properties backing store. | // +----------+---------------------------------------------+ // | Byte | [visitor_id] | // +----+----------+---------------------------------------------+ // | Int | The second int field | // `---+----------+---------------------------------------------+ // | Short | [instance_type] | // +----------+---------------------------------------------+ // | Byte | [bit_field] | // | | - has_non_instance_prototype (bit 0) | // | | - is_callable (bit 1) | // | | - has_named_interceptor (bit 2) | // | | - has_indexed_interceptor (bit 3) | // | | - is_undetectable (bit 4) | // | | - is_access_check_needed (bit 5) | // | | - is_constructor (bit 6) | // | | - has_prototype_slot (bit 7) | // +----------+---------------------------------------------+ // | Byte | [bit_field2] | // | | - new_target_is_base (bit 0) | // | | - is_immutable_proto (bit 1) | // | | - unused bit (bit 2) | // | | - elements_kind (bits 3..7) | // +----+----------+---------------------------------------------+ // | Int | [bit_field3] | // | | - enum_length (bit 0..9) | // | | - number_of_own_descriptors (bit 10..19) | // | | - is_prototype_map (bit 20) | // | | - is_dictionary_map (bit 21) | // | | - owns_descriptors (bit 22) | // | | - is_in_retained_map_list (bit 23) | // | | - is_deprecated (bit 24) | // | | - is_unstable (bit 25) | // | | - is_migration_target (bit 26) | // | | - is_extensible (bit 28) | // | | - may_have_interesting_symbols (bit 28) | // | | - construction_counter (bit 29..31) | // | | | // +*************************************************************+ // | Int | On systems with 64bit pointer types, there | // | | is an unused 32bits after bit_field3 | // +*************************************************************+ // | TaggedPointer | [prototype] | // +---------------+---------------------------------------------+ // | TaggedPointer | [constructor_or_backpointer] | // +---------------+---------------------------------------------+ // | TaggedPointer | [instance_descriptors] | // +*************************************************************+ // ! TaggedPointer ! [layout_descriptors] ! // ! ! Field is only present if compile-time flag ! // ! ! FLAG_unbox_double_fields is enabled ! // ! ! (basically on 64 bit architectures) ! // +*************************************************************+ // | TaggedPointer | [dependent_code] | // +---------------+---------------------------------------------+ // | TaggedPointer | [prototype_validity_cell] | // +---------------+---------------------------------------------+ // | TaggedPointer | If Map is a prototype map: | // | | [prototype_info] | // | | Else: | // | | [raw_transitions] | // +---------------+---------------------------------------------+ 这个 Meta Map 本身也是继承自 Heap Object，所以它的堆地址起始也是一个伪指针，显而易见的是这个 Tagged Pointer 不会再指向另一个用来描述自己的 Meta Map 了 (禁止套娃)。 Instance size 跟在这个 Tagged Pointer 后面的 4 个 byte (即上图中的第一个 Int) 的使用我们来看下其对应的作用: // +----------+---------------------------------------------+ // | Byte | [instance_size] | // +----------+---------------------------------------------+ // | Byte | If Map for a primitive type: | // | | native context index for constructor fn | // | | If Map for an Object type: | // | | inobject properties start offset in words | // +----------+---------------------------------------------+ // | Byte | [used_or_unused_instance_size_in_words] | // | | For JSObject in fast mode this byte encodes | // | | the size of the object that includes only | // | | the used property fields or the slack size | // | | in properties backing store. | // +----------+---------------------------------------------+ // | Byte | [visitor_id] | // +----------+---------------------------------------------+ 这里有一个比较重要的值是 instance_size，它记录了指向这个 Meta Map 的 Heap Object 的大小，换言之从 Meta Map 的首地址偏移 8 Byte 得到的新指针指向堆空间保存了原始 Heap Object 的实际占据 V8 堆空间的大小。 这样说可能还是比较抽象，所以我们来看下 Heap Object Size 是如何被设置的，可以看到在 Map 类中定义了一个 set_instance_size_in_words 的成员方法: // src/objects/map-inl.h void Map::set_instance_size_in_words(int value) { RELAXED_WRITE_BYTE_FIELD(*this, kInstanceSizeInWordsOffset, static_cast<byte>(value)); } 将宏 RELAXED_WRITE_BYTE_FIELD 展开最终得到: // src/objects/map-inl.h void Map::set_instance_size_in_words(int value) { base::Relaxed_Store( reinterpret_cast<base::Atomic8*>( ((*this).ptr() + kInstanceSizeInWordsOffset - kHeapObjectTag)), static_cast<base::Atomic8>(static_cast<byte>(value))); } 其中 base::Relaxed_Store 的定义如下: // src/base/atomicops_internals_portable.h inline void Relaxed_Store(volatile Atomic8* ptr, Atomic8 value) { __atomic_store_n(ptr, value, __ATOMIC_RELAXED); } __atomic_store_n 是 gcc 定义的多线程下比信号量锁性能更好的原子存储操作操作，引用下 gcc 官方文档 里的说法: This built-in function implements an atomic store operation. It writes val into *ptr. 其实就是把 value 写入 *ptr 指向的堆空间，__ATOMIC_RELAXED 表示不会对执行写入操作的线程设定优先级: __ATOMIC_RELAXED: Implies no inter-thread ordering constraints. 回到 set_instance_size_in_words 展开后的方法，它的作用描述下就是: 取 Meta Map 自己的伪指针（首地址 加上 kInstanceSizeInWordsOffset 偏移量（这里是 8byte） 转换成真实地址（伪指针最后一位伪 1） 将 instance size 写入上面得到的真实地址指向的堆空间内 值得注意的是，指针的加减运算和指针类型有关，所以上面代码中计算 instance 偏移量的时候首先将 Meta Map 的指针强转为 base::Atomic8 类型的指针，而 Atomic8 的实际上就是 char 的别名: // src/base/atomicops.h using Atomic8 = char; Instance type 因为每一个不同的 JS 对象类型布局除了头部的指向 Meta Map 的伪指针外都不一样，所以获取原始的 Heap Object 的类型就比较重要。 这部分信息保存在第二个 Int (4 byte) 长度的区域里: // +----------+---------------------------------------------+ // | Short | [instance_type] | // +----------+---------------------------------------------+ // | Byte | [bit_field] | // | | - has_non_instance_prototype (bit 0) | // | | - is_callable (bit 1) | // | | - has_named_interceptor (bit 2) | // | | - has_indexed_interceptor (bit 3) | // | | - is_undetectable (bit 4) | // | | - is_access_check_needed (bit 5) | // | | - is_constructor (bit 6) | // | | - has_prototype_slot (bit 7) | // +----------+---------------------------------------------+ // | Byte | [bit_field2] | // | | - new_target_is_base (bit 0) | // | | - is_immutable_proto (bit 1) | // | | - unused bit (bit 2) | // | | - elements_kind (bits 3..7) | // +----------+---------------------------------------------+ 可以看到这里用了一个 short (2 byte) 的长度来保存原始 Heap Object 的类型信息，换言之从 Meta Map 的首地址偏移 12 Byte 得到新地址转换为 uint16_t 类型的地址后指向的堆空间得到的无符号整数即标识了原始 Heap Object 的类型。 这里还是通过原始 Heap Object 的类型是如何被设置的来理解下这部分内容，Map 类中同样定义了一个 set_instance_type 的成员方法: void Map::set_instance_type(InstanceType value) { WriteField<uint16_t>(kInstanceTypeOffset, value); } InstanceType 是一个枚举类型，它定义了完整的 Heap Object 可能的类型: // src/objects/instance-type.h enum InstanceType : uint16_t { // .... }; 可以看到 InstanceType 继承自 uint16_t，正好是 2 byte，也和 Meta Map 中分配给实例类型一个 short 的长度来表示相吻合。 接着我们看下 WriteField 函数究竟做了些什么: template <class T, typename std::enable_if<std::is_arithmetic<T>::value, int>::type = 0> inline void WriteField(size_t offset, T value) const { // Pointer compression causes types larger than kTaggedSize to be unaligned. #ifdef V8_COMPRESS_POINTERS constexpr bool v8_pointer_compression_unaligned = sizeof(T) > kTaggedSize; #else constexpr bool v8_pointer_compression_unaligned = false; #endif if (std::is_same<T, double>::value || v8_pointer_compression_unaligned) { // Bug(v8:8875) Double fields may be unaligned. base::WriteUnalignedValue<T>(field_address(offset), value); } else { base::Memory<T>(field_address(offset)) = value; } } 展开 field_address 得到: inline Address field_address(size_t offset) const { return ptr() + offset - kHeapObjectTag; } 它的作用就是通过指针偏移量来计算出真实的堆空间地址。 最后看下 base::Memory 做了些什么: template <class T> inline T& Memory(Address addr) { DCHECK(IsAligned(addr, alignof(T))); return *reinterpret_cast<T*>(addr); } template <class T> inline T& Memory(byte* addr) { return Memory<T>(reinterpret_cast<Address>(addr)); } 有了以上的信息，我们进行下简单转换下可以得到可读性比较好的代码: inline void WriteField(size_t offset, uint16_t value) const { *reinterpret_cast<uint16_t *>(ptr() + offset - kHeapObjectTag) = value } 这样看就比较明确了，创建 Heap Object 的时候通过调用 set_instance_type 方法确实将一个类型为 uint16_t 的类型值存储到了 Meta Map 起始地址偏移 kInstanceTypeOffset 的堆空间内。 V. 还原 V8 对象 了解了上述的这些内容，我们对于一个给定的地址 p，判断其为堆对象后可以: 根据 kMapOffset 来获取其指向的 Meta Map 根据 Meta Map 和 kInstanceSizeInWordsOffset 获取原始堆对象在 V8 堆上的大小 根据 Meta Map 和 kInstanceTypeOffset 获取原始堆对象类型 根据原始对象类型的布局来还原其各个属性 值得一提的是，按照引擎的定义， Meta Map 的起始伪指针指向一个 Meta Map root (作为 GC root 方便 GC)，换言之所有的 JS 对象指向的 Meta Map 都指向了同一个 Meta Map root: // +---------------+---------------------------------------------+ // | TaggedPointer | map - Always a pointer to the MetaMap root | // +---------------+---------------------------------------------+ 这一点同样从导出的 HeapSnapshot 堆快照的分析中可以得到证实，这部分内容后面会在解析堆快照的文章中详细说明。 Meta Map 的定义里已经包含了逆工程 V8 对象的几乎绝大部分内容，下面一篇文章中我们会以一个例子来看下如何借助于 Meta Map 还原 JS Object 的原始信息。 VI. 参考资料 解读 V8 GC Log（一）: Node.js 应用背景与 GC 基础知识 Bringing JavaScript Back to Life Built-in Functions for Memory Model Aware Atomic Operations LLNode - An lldb plugin for Node.js and V8
-
发表了文章 2019-04-22
Node.js 应用故障排查手册 —— 雪崩型内存泄漏问题
楔子 实践篇一中我们也看到了一个比较典型的由于开发者不当使用第三方库，而且在配置信息中携带了三方库本身使用不到的信息，导致了内存泄漏的案例，实际上类似这种相对缓慢的 Node.js 应用内存泄漏问题我们总是可以在合适的机会抓取堆快照进行分析，而且堆快照一般来说确实是分析内存泄漏问题的最佳手段。 但是还有一些问题场景下下应用的内存泄漏非常严重和迅速，甚至于在我们的告警系统感知之前就已经造成应用的 OOM 了，这时我们来不及或者说根本没办法获取到堆快照，因此就没有办法借助于之前的办法来分析为什么进程会内存泄漏到溢出进而 Crash 的原因了。这种问题场景实际上属于线上 Node.js 应用内存问题的一个极端状况，本节将同样从源自真实生产的一个案例来来给大家讲解下如何处理这类极端内存异常。 本书首发在 Github，仓库地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云栖社区会同步更新。 最小化复现代码 同样我们因为例子的特殊性，我们需要首先给出到大家生产案例的最小化复现代码，建议读者自行运行一番此代码，这样结合起来看下面的排查分析过程会更有收获。最小复现代码还是基于 Egg.js，如下所示： 'use strict'; const Controller = require('egg').Controller; const fs = require('fs'); const path = require('path'); const util = require('util'); const readFile = util.promisify(fs.readFile); class DatabaseError extends Error { constructor(message, stack, sql) { super(); this.name = 'SequelizeDatabaseError'; this.message = message; this.stack = stack; this.sql = sql; } } class MemoryController extends Controller { async oom() { const { ctx } = this; let bigErrorMessage = await readFile(path.join(__dirname, 'resource/error.txt')); bigErrorMessage = bigErrorMessage.toString(); const error = new DatabaseError(bigErrorMessage, bigErrorMessage, bigErrorMessage); ctx.logger.error(error); ctx.body = { ok: false }; } } module.exports = MemoryController; 这里我们还需要在 app/controller/ 目录下创建一个 resource 文件夹，并且在这个文件夹中添加一个 error.txt，这个 TXT 内容随意，只要是一个能超过 100M 的很大的字符串即可。 值得注意的是，其实这里的问题已经在 egg-logger >= 1.7.1 的版本中修复了，所以要复现当时的状况，你还需要在 Demo 的根目录执行以下的三条命令以恢复当时的版本状况： rm -rf package-lock.json rm -rf node_modules/egg/egg-logger npm install egg-logger@1.7.0 最后使用 npm run dev 启动这个问题最小化复现的 Demo。 感知进程出现问题 这个案例下，实际上我们的线上 Node.js 应用几乎是触发了这个 Bug 后瞬间内存溢出然后 Crash 的，而平台预设的内存阈值告警，实际上是由一个定时上报的逻辑构成，因此存在延时，也导致了这个案例下我们无法像 冗余配置传递引发的内存溢出 问题那样获取到 Node.js 进程级别的内存超过预设阈值的告警。 那么我们如何来感知到这里的错误的呢？这里我们的服务器配置过了 ulimit -c unlimited ，因此 Node.js 应用 Crash 的时候内核会自动生成核心转储文件，而且性能平台目前也支持核心转储文件的生成预警，这一条规则目前也被放入了预设的快速添加告警规则中，可以参考工具篇中 Node.js 性能平台使用指南 - 配置合适的告警 一节，详细的规则内容如下所示： 这里需要注意的是，核心转储文件告警需要我们在服务器上安装的 Agenthub/Agentx 依赖的 Commandx 模块的版本在 1.5.2 之上（包含），这一块更详细的信息也可以看官方文档 核心转储分析能力 一节。 问题排查过程 I. 分析栈信息 依靠上面提到的平台提供的核心转储文件生成时给出的告警，我们在收到报警短信时登录控制台，可以看到 Coredump 文件列表出现了新生成的核心转储文件，继续参照工具篇中 Node.js 性能平台使用指南 - 核心转储分析 中给出的转储和 AliNode 定制分析的过程，我们可以看到如下的分析结果展示信息： 同样我们直接展开 JavaScript 栈信息查看应用 Crash 那一刻的栈信息： 截图中忽略掉了 Native C/C++ 代码的栈信息，这里其实仅仅看 JavaScript 栈信息就能得到结论了，通过翻阅比对出问题的 egg-logger@1.7.0 中 lib/utils.js 的代码内容： function formatError(err) { // ... // 这里对 Error 对象的 key 和 value 调用 inspect 方法进行序列化 const errProperties = Object.keys(err).map(key => inspect(key, err[key])).join('\n'); // ... } // inspect 方法实际上是调用 require('util').inspect 来对错误对象的 value 进行序列化 function inspect(key, value) { return `${key}: ${util.inspect(value, { breakLength: Infinity })}`; } 这样我们就知道了线上 Node.js 应用在 Crash 的那一刻正在使用 require('util').inspect 对某个字符串进行序列化操作。 II. 可疑字符串 那么这个序列化的动作究竟是不是造成进程 Crash 的元凶呢？我们接着来点击 inspect 函数的参数来展开查看这个可疑的字符串的详细信息，如下图所示： 点击红框中的参数，得到字符串的详情页面链接，如下图所示： 再次点击这里的 detail 链接，既可在弹出的新页面中看到这个可疑字符串的全部信息： 这里可以看到，这个正在被 util.inspect 的字符串大小高达 186.94 兆，显然正是在序列化这么大的字符串的时候，造成了线上 Node.js 应用的堆内存雪崩，几乎在瞬间就内存溢出导致 Crash。 值得一提的是，我们还可以点击上图中的 + 号来在当前页面展示更多的问题字符串内容： 也可以在页面上点击 一键导出 按钮下载问题完整的字符串： 毕竟对于这样的问题来说，如果能抓到产生问题的元凶参数，起码能更方便地进行本地复现。 III. 修复问题 那么知道了原因，其实修复此问题就比较简单了，Egg-logger 官方是使用 circular-json 来替换掉原生的 util.inspect 序列化动作，并且增加序列化后的字符串最大只保留 10000 个字符的限制，这样就解决这种包含大字符串的错误对象在 Egg-logger 模块中的序列化问题。 结尾 本节的给大家展现了对于线上 Node.js 应用出现瞬间 Crash 问题时的排查思路，而在最小化复现 Demo 对应的那个真实线上故障中，实际上是拼接的 SQL 语句非常大，大小约为 120M，因此首先导致数据库操作失败，接着数据库操作失败后输出的 DatabaseError 对象实例上则原封不动地将问题 SQL 语句设置到属性上，从而导致了 ctx.logger.error(error) 时堆内存的雪崩。在 Node.js 性能平台 提供的 核心转储告警 + 在线分析能力 的帮助下，此类无法获取到常规 CPU Profile 和堆快照等信息的进程无故崩溃问题也变得有迹可循了，实际上它作为一种兜底分析手段，在很大程度上提升了开发者真正将 Node.js 运用到服务端生产环境中的信心。
-
发表了文章 2019-04-13
Node.js 应用故障排查手册 —— 类死循环导致进程阻塞
楔子 在实践篇一中我们看到了两个表象都是和 CPU 相关的生产问题，它们基本也是我们在线上可能遇到的这一类问题的典型案例，而实际上这两个案例也存在一个共同点：我们可以通过 Node.js 性能平台 导出进程对应的 CPU Profile 信息来进行分析定位问题，但是实际在线上的一些极端情况下，我们遇到的故障是没有办法通过轻量的 V8 引擎暴露的 CPU Profile 接口（仅部分定制的 AliNode runtime 版本支持，详见下文）来获取足够的进程状态信息进行分析的，此时我们又回到了束手无策的状态。 本章节将从一个生产环境下 Node.js 应用出现进程级别阻塞导致的不再提供服务的问题场景来给大家展示下如何处理这类相对极端的应用故障。 本书首发在 Github，仓库地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云栖社区会同步更新。 最小化复现代码 这个例子稍微有些特殊，我们首先给出生产案例的最小化复现代码，有兴趣的同学可以亲自运行一番，这样结合下文的此类问题的排查过程，能更加清晰的看到我们面对这样的问题时的排查思路，问题最小代码如下，基于 Egg.js ： 'use strict'; const Controller = require('egg').Controller; class RegexpController extends Controller { async long() { const { ctx } = this; // str 模拟用户输入的问题字符串 let str = '<br/> ' + ' 早餐后自由活动，于指定时间集合自行办理退房手续。'; str += '<br/> <br/>' + ' <br/> ' + ' <br/>'; str += ' <br/>' + ' ' + ' ' + ' <br/>'; str += ' <br/> <br/>'; str += ' ' + ' ' + ' 根据船班时间，自行前往暹粒机场，返回中国。<br/>'; str += '如需送机服务，需增加280/每单。<br/>'; const r = str.replace(/(^(\s*?<br[\s\/]*?>\*?)+|(\s*?<br[\s\/]*?>\s*?)+?$)/igm, ''); ctx.body = r; } } module.exports = RegexpController; 问题应用状态 其实这个例子对应的问题场景可能很多 Node.js 开发者都遇到过，它非常有意思，我们首先来看下出现这类故障时我们的 Node.js 应用的状态。当我们收到在平台配置的 CPU 告警信息后，登录性能平台进入对应的告警应用找到出问题的 CPU 非常高的进程：然后点击 数据趋势 按钮查看此进程当前的状态信息： 可以看到进程的 CPU 使用率曲线一直处于近乎 100% 的状态，此时进程不再响应其余的请求，而且我们通过跳板机进入生产环境又可以看到进程其实是存活的，并没有挂掉，此时基本上可以判断：此 Node.js 进程因为在执行某个同步函数处于阻塞状态，且一直卡在此同步函数的执行上。 Node.js 的设计运行模式就是单主线程，并发靠的是底层实现的一整套异步 I/O 和事件循环的调度。简单的说，具体到事件循环中的某一次，如果我们在执行需要很长时间的同步函数（比如需要循环执行很久才能跳出的 while 循环），那么整个事件循环都会阻塞在这里等待其结束后才能进入下一次，这就是不推荐大家在非初始化的逻辑中使用诸如 fs.readFileSync 等同步方法的原因。 排查方法 这样的问题其实非常难以排查，原因在于我们没办法知道什么样的用户输入造成了这样的阻塞，所以本地几乎无法复现问题。幸运的是，性能平台目前有不止一种解决办法处理这种类死循环的问题，我们来详细看下。 I. CPU Profile 这个分析方法可以说是我们的老朋友了，因为类死循环的问题本质上也是 CPU 高的问题，因此我们只要对问题进程抓取 CPU Profile，就能看到当前卡在哪个函数了。需要注意的是，进程假死状态下是无法直接使用 V8 引擎提供的抓取 CPU Profile 文件的接口，因此工具篇章节的 正确打开 Chrome devtools 一节中提到的 v8-profiler 这样的第三方模块是无法正常工作的。 不过定制过的 AliNode runtime 采用了一定的方法规避了这个问题，然而遗憾的是依旧并不是所有的 AliNode runtime 版本都支持在类死循环状态下抓取 CPU Profile，这里实际上对大家使用的 Runtime 版本有要求： AliNode V3 版本需要 >= v3.11.4 AliNode V4 版本需要 >= v4.2.1 AliNode V1 和 V2 版本不支持 如果你的线上 AliNode runtime 版本恰好符合需求，那么可以按照前面 Node.js 性能平台使用指南 提到的那样，对问题进程抓取 3 分钟的 CPU Profile，并且使用 AliNode 定制的火焰图分析： 这里可以看到，抓取到的问题进程 3 分钟的 CPU 全部耗费在 long 函数里面的 replace 方法上，这和我们提供的最小化复现代码一致，因此可以判断 long 函数内的正则存在问题进行修复。 II. 诊断报告 诊断报告也是 AliNode 定制的一项导出更多更详细的 Node.js 进程当前状态的能力，导出的信息也包含当前的 JavaScript 代码执行栈以及一些其它进程与系统信息。它与 CPU Profile 的区别主要在两个地方： 诊断报告主要针对此刻进程状态的导出，CPU Profile 则是一段时间内的 JavaScript 代码执行状态 诊断报告除了此刻 JavaScript 调用栈信息，还包含了 Native C/C++ 栈信息、Libuv 句柄和部分操作系统信息 当我们的进程处于假死状态时，显然不管是一段时间内还是此时此刻的 JavaScript 执行状况，必然都是卡在我们代码中的某个函数上，因此我们可以使用诊断报告来处理这样的问题，当然诊断报告功能同样也对 AliNode runtime 版本有所要求： AliNode V2 版本需要 >= v2.5.2 AliNode V3 版本需要 >= v3.11.8 AliNode V4 版本需要 >= v4.3.0 AliNode V1 版本不支持 且要求：Agenthub/Egg-alinode 依赖的 Commandx 版本 >= v1.5.3 如果你使用的 AliNode runtime 版本符合要求，即可进入平台应用对应的实例信息页面，选中问题进程： 然后点击 诊断报告 即可生成此刻问题进程的状态信息报告： 诊断报告虽然包含了很多的进程和系统信息，但是其本身是一个相对轻量的操作，故而很快就会结束，此时继续点击 转储 按钮将生成的诊断报告上传至云端以供在线分析展示： 继续点击 分析 按钮查看 AliNode 定制的分析功能，展示结果如下： 结果页面上面的概览信息比较简单，我们来看下 JavaScript 栈 页面的内容，这里显然也告诉我们当前的 JS 函数卡在 long 方法里面，并且比 CPU Profile 更加详细的是还带上了具体阻塞在 long 方法的哪一行，对比我们提供给大家的最小复现代码其实就是执行 str.replace 这一行，也就是问题的正则匹配操作所在的地方。 III. 核心转储分析 其实很多朋友看到这里会有疑惑：既然 CPU Profile 分析和诊断报告已经能够找到问题所在了，为什么我们还要继续介绍相对比较重的核心转储分析功能呢？ 其实道理也很简单，不管是类死循环状态下的 CPU Profile 抓取还是诊断报告功能的使用，都对问题进程的 AliNode runtime 版本有所要求，而且更重要的是，这两种方法我们都只能获取到问题正则的代码位置，但是我们无法知道什么样的用户输入在执行这样的正则时会触发进程阻塞的问题，这会给我们分析和给出针对性的处理造成困扰。因此，这里最后给大家介绍对 AliNode runtime 版本没有任何要求，且能拿到更精准信息的核心转储分析功能。 首先按照预备章节的核心转储一节中提到的 手动生成 Core dump 文件的方法，我们对问题进程进行 sudo gcore <pid> 的方式获取到核心转储文件，然后在平台的详情页面，将鼠标移动到左边 Tab 栏目的 文件 按钮上，可以看到 Coredump 文件 的按钮：点击后可以进入 Core dump 文件列表页，然后点击上方的 上传 按钮进行核心转储文件的上传操作：这里需要注意的是，请将 Core dump 文件以 .core 结尾重命名，而对应的 Node 可执行文件以 .node 结尾重命名，推荐的命名方式为 <os info>-<alinode/node>-<version>.node，方便以后回顾，比如 centos7-alinode-v4.7.2.node 这种。最后 Core dump 文件和 Node 可执行文件之间必须是 一一对应 的关系。这里一一对应指的是：这份 Core dump 文件必须是由这个 Node 可执行文件启动的进程生成的，如果这两者没有一一对应，分析结果往往是无效信息。因为 Core dump 文件一般来说都比较大，所以上传会比较慢，耐心等待至上传完毕后，我们就可以使用 AliNode 定制的核心转储文件分析功能进行分析了，点击 分析 按钮即可： 此时我们在新打开的分析结果页面可以看到如下的分析结果展示信息： 这个页面的各项含义在工具篇的 Node.js 性能平台使用指南的 [最佳实践——核心转储分析]() 一节已经解释过，这里不再赘述，这里直接展开 JavaScript 栈信息： 这里可以看到得到的结论和前面的 CPU Profile 分析以及诊断报告分析一致，都能定位到提供的最小复现代码中的 long 方法中的异常正则匹配，但是核心转储文件分析比前面两者多了导致当前 Node.js 进程产生问题的异常字符串： "<br/> 早餐后自由活动，于指定时间集合自行办理退房手续。<br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> 根据船班时间，自行前往暹粒机场，返回中国。<br/>如需送机服务，需增加280/每单。<br/>" ，有了这个触发正则执行异常的问题字符串，我们无论是构造本地复现样例还是进一步分析都有了重要的信息依靠。 分析问题 上一节中我们采用了 Node.js 性能平台提供的三种不同的方式分析定位到了线上应用处于假死状态的原因，这里来简单的解释下为什么字符串的正则匹配会造成类死循环的状态，它实际上异常的用户输入触发了 正则表达式灾难性的回溯，会导致执行时间要耗费几年甚至几十年，显然不管是那种情况，单主工作线程的模型会导致我们的 Node.js 应用处于假死状态，即进程依旧存活，但是却不再处理新的请求。 关于正则回溯的原因有兴趣的同学可以参见 小心别落入正则回溯陷阱 一文。 结尾 其实这类正则回溯引发的进程级别阻塞问题，本质上都是由于不可控的用户输入引发的，而 Node.js 应用又往往作为 Web 应用直接面向一线客户，无时不刻地处理千奇百怪的用户请求，因此更容易触发这样的问题。 相似的问题其实还有一些代码逻辑中诸如 while 循环的跳出条件在一些情况下失效，导致 Node.js 应用阻塞在循环中。之前我们就算知道是进程阻塞也难以方便的定位到具体的问题代码以及产生问题的输入，现在借助于 Node.js 性能平台 提供的核心转储分析能力，相信大家可以比较容易地来解决这样的问题。
-
发表了文章 2019-04-08
Node.js 应用故障排查手册 —— 综合性 GC 问题和优化
楔子 本章前面两节生产案例分别侧重于单一的 CPU 高和单一的内存问题，我们也给大家详细展示了问题的定位排查过程，那么实际上还有一类相对更复杂的场景——它本质上是 V8 引擎的 GC 引发的问题。 简单的给大家介绍下什么是 GC，GC 实际上是语言引擎实现的一种自动垃圾回收机制，它会在设定的条件触发时（比如堆内存达到一定值）时查看当前堆上哪些对象已经不再使用，并且将这些没有再使用到的对象所占据的空间释放出来。许多的现代高级语言都实现了这一机制，来减轻程序员的心智负担。 本书首发在 Github，仓库地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云栖社区会同步更新。 GC 带来的问题 虽然上面介绍中现代语言的 GC 机制解放了程序员间接提升了开发效率，但是万事万物都存在利弊，底层的引擎引入 GC 后程序员无需再关注对象何时释放的问题，那么相对来说程序员也就没办法实现对自己编写的程序的精准控制，它带来两大问题： 代码编写问题引发的内存泄漏 程序执行的性能降低 内存泄漏问题我们已经在上一节的生产案例中体验了一下，那么后者是怎么回事呢？ 其实理解起来也很简单：原本一个程序全部的工作都是执行业务逻辑，但是存在了 GC 机制后，程序总会在一定的条件下耗费时间在扫描堆空间找出不再使用的对象上，这样就变相降低了程序执行业务逻辑的时间，从而造成了性能的下降，而且降低的性能和耗费在 GC 上的时间，换言之即 GC 的次数 * 每次 GC 耗费的时间成正比。 问题现象与原始分析 现在大家应该对 GC 有了一个比较整体的了解，这里我们可以看下 GC 引发的问题在生产中的表现是什么样的。在这个案例中，表象首先是 Node.js 性能平台 上监控到进程的 CPU 达到 100%，但是此时服务器负载其实并不大，QPS 只有 100 上下，我们按照前面提到的处理 CPU 问题的步骤抓取 CPU Profile 进行分析可以看到： 这次的问题显然是 Garbage Collector 耗费的 CPU 太多了，也就是 GC 的问题。实际上绝大部分的 GC 机制引发的问题往往表象都是反映在 Node.js 进程的 CPU 上，而本质上这类问题可以认为是引擎的 GC 引起的问题，也可以理解为内存问题，我们看下这类问题的产生流程： 堆内存不断达到触发 GC 动作的预设条件 进程不断触发 GC 操作 进程 CPU 飙高 而且 GC 问题不像之前的 ejs 模板渲染引发的问题，就算我们在 CPU Profile 中可以看到这部分的耗费，但是想要优化解决这个问题基本是无从下手的，幸运的是 Node.js 提供了（其实是 V8 引擎提供的）一系列的启动 Flag 能够输出进程触发 GC 动作时的相关日志以供开发者进行分析： --trace_gc: 一行日志简要描述每次 GC 时的时间、类型、堆大小变化和产生原因 --trace_gc_verbose: 结合 --trace_gc 一起开启的话会展示每次 GC 后每个 V8 堆空间的详细状况 --trace_gc_nvp: 每一次 GC 的一些详细键值对信息，包含 GC 类型，暂停时间，内存变化等信息 加粗的 Flag 意味着我们需要在启动应用前加上才能在运行时生效，这部分的日志实际上是一个文本格式，可惜的是 Chrome devtools 原生并不支持 GC 日志的解析和结果展示，因此需要大家获取到以后进行对应的按行解析处理，当然我们也可以使用社区提供 v8-gc-log-parser 这个模块直接进行解析处理，对这一块有兴趣的同学可以看 @joyeeCheung 在 JS Interactive 的分享: Are Your V8 Garbage Collection Logs Speaking To You?，这里不详细展开。 更好的 GC 日志展示 虽然 Chrome devtools 并不能直接帮助我们解析展示 GC 日志的结果，但是 Node.js 性能平台 其实给大家提供了更方便的动态获取线上运行进程的 GC 状态信息以及对应的结果展示，换言之，开发者无需在运行你的 Node.js 应用前开启上面提到的那些 Flag 而仍然可以在想要获取到 GC 信息时通过控制台拿到 3 分钟内的 GC 数据。 对应在这个案例中，我们可以进入平台的应用实例详情页面，找到 GC 耗费特别大的进程，然后点击 GC Trace 抓取 GC 数据： 这里默认会抓取 3 分钟的对应进程的 GC 日志信息，等到结束后生成的文件会显示在 文件 页面： 此时点击 转储 即可上传到云端以供在线分析展示了，如下图所示： 最后点击这里的 分析 按钮，即可看到 AliNode 定制后的 GC 信息分析结果的展现： 结果展示中，可以比较方便的看到问题进程的 GC 具体次数，GC 类型以及每次 GC 的耗费时间等信息，方便我们进一步的分析定位。比如这次问题的 GC Trace 结果分析图中，我们可以看到红圈起来的几个重要信息： GC 总暂停时间高达 47.8s，大头是 Scavenge 3min 的 GC 追踪日志里面，总共进行了 988 次的 Scavenge 回收 每次 Scavenge 耗时均值在 50 ~ 60ms 之间 从这些解困中我们可以看到此次 GC 案例的问题点集中在 Scavenge 回收阶段，即新生代的内存回收。那么通过翻阅 V8 的 Scavenge 回收逻辑可以知道，这个阶段触发回收的条件是：Semi space allocation failed。 这样就可以推测，我们的应用在压测期间应该是在新生代频繁生成了大量的小对象，导致默认的 Semi space 总是处于很快被填满从而触发 Flip 的状态，这才会出现在 GC 追踪期间这么多的 Scavenge 回收和对应的 CPU 耗费，这样这个问题就变为如何去优化新生代的 GC 来提升应用性能。 优化新生代 GC 通过平台提供的 GC 数据抓取和结果分析，我们知道可以去尝试优化新生代的 GC 来达到提升应用性能的目的，而新生代的空间触发 GC 的条件又是其空间被占满，那么新生代的空间大小由 Flag --max-semi-space-size 控制，默认为 16MB，因此我们自然可以想到要可以通过调整默认的 Semi space 的值来进行优化。 这里需要注意的是，控制新生代空间的 Flag 在不同的 Node.js 版本下并不是一样的，大家具体可以查看当前的版本来进行确认使用。 在这个案例中，显然是默认的 16M 相对当前的应用来说显得比较小，导致 Scavenge 过于频繁，我们首先尝试通过启动时增加 --max-semi-space-size=64 这个 Flag 来将默认的新生代使用到的空间大小从 16M 的值增大为 64M，并且在流量比较大而且进程 CPU 很高时抓取 CPU Profile 观察效果： 调整后可以看到 Garbage collector 阶段 CPU 耗费占比下降到 7% 左右，再抓取 GC Trace 并观察其展示结果确认是不是 Scavenge 阶段的耗费下降了： 显然，Semi space 调大为 64M 后，Scavenge 次数从近 1000 次降低到 294 次，但是这种状况下每次的 Scavenge 回收耗时没有明显增加，还是在 50 ~ 60ms 之间波动，因此 3 分钟的 GC 追踪总的停顿时间从 48s 下降到 12s，相对应的，业务的 QPS 提升了约 10% 左右。那么如果我们通过 --max-semi-space-size 这个 Flag 来继续调大新生代使用到的空间，是不是可以进一步优化这个应用的性能呢？此时尝试 --max-semi-space-size=128 来从 64M 调大到 128M，在进程 CPU 很高时继续抓取 CPU Profile 来查看效果： 此时 Garbage collector 耗费下降相比上面的设置为 64M 并不是很明显，GC 耗费下降占比不到 1%，同样我们来抓取并观察下 GC Trace 的结果来查看具体的原因： 很明显，造成相比设置为 64M 时 GC 占比提升不大的原因是：虽然此时进一步调大了 Semi space 至 128M，并且 Scavenge 回收的次数确实从 294 次下降到 145 次，但是每次算法回收耗时近乎翻倍了，因此总收益并不明显。 按照这个思路，我们再使用 --max-semi-space-size=256 来将新生代使用的空间进一步增大到 256M 再来进行最后一次的观察： 这里和调整为 128M 时是类似的情况： 3 分钟内 Scavenge 次数从 294 次下降到 72 次，但是相对的每次算法回收耗时波动到了 150ms 左右，因此整体性能并没有显著提升。 借助于性能平台的 GC 数据抓取和结果展示，通过以上的几次尝试改进 Semi space 的值后，我们可以看到从默认的 16M 设置到 64M 时，Node 应用的整体 GC 性能是有显著提升的，并且反映到压测 QPS 上大约提升了 10%；但是进一步将 Semi space 增大到 128M 和 256M 时，收益确并不明显，而且 Semi space 本身也是作用于新生代对象快速内存分配，本身不宜设置的过大，因此这次优化最终选取对此项目 最优的运行时 Semi space 的值为 64M。 结尾 在本生产案例中，我们首先可以看到，项目使用的三方库其实也并不总是在所有场景下都不会有 Bug 的（实际上这是不可能的），因此在遇到三方库的问题时我们要敢于去从源码的层面来对问题进行深入的分析。最后实际上在生产环境下通过 GC 方面的运行时调优来提升我们的项目性能是一种大家不那么常用的方式，这也有很大一部分原因是应用运行时 GC 状态本身不直接暴露给开发者。通过上面这个客户案例，我们可以看到借助于 Node.js 性能平台，实时感知 Node 应用 GC 状态以及进行对应的优化，使得不改一行代码提升项目性能变成了一件非常容易的事情。
-
发表了文章 2019-03-30
Node.js 应用故障排查手册 —— 冗余配置传递引发的内存溢出
楔子 前面一小节我们以一个真实的压测案例来给大家讲解如何利用 Node.js 性能平台 生成的 CPU Profile 分析来进行压测时的性能调优。那么与 CPU 相关的问题相比，Node.js 应用中由于不当使用产生的内存问题是一个重灾区，而且这些问题往往都是出现在生产环境下，本地压测都难以复现，实际上这部分内存问题也成为了很多的 Node.js 开发者不敢去将 Node.js 这门技术栈深入运用到后端的一大阻碍。 本节将以一个开发者容易忽略的生产内存溢出案例，来展示如何借助于性能平台实现对线上应用 Node.js 应用出现内存泄漏时的发现、分析、定位问题代码以及修复的过程，希望能对大家有所启发。 本书首发在 Github，仓库地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云栖社区会同步更新。 最小化复现代码 因为内存问题相对 CPU 高的问题来说比较特殊，我们直接从问题排查的描述可能不如结合问题代码来看比较直观，因此在这里我们首先给出了最小化的复现代码，大家运行后结合下面的分析过程应该能更有收获，样例基于 Egg.js：如下所示： 'use strict'; const Controller = require('egg').Controller; const DEFAULT_OPTIONS = { logger: console }; class SomeClient { constructor(options) { this.options = options; } async fetchSomething() { return this.options.key; } } const clients = {}; function getClient(options) { if (!clients[options.key]) { clients[options.key] = new SomeClient(Object.assign({}, DEFAULT_OPTIONS, options)); } return clients[options.key]; } class MemoryController extends Controller { async index() { const { ctx } = this; const options = { ctx, key: Math.random().toString(16).slice(2) }; const data = await getClient(options).fetchSomething(); ctx.body = data; } } module.exports = MemoryController; 然后在 app/router.js 中增加一个 Post 请求路由： router.post('/memory', controller.memory.index); 造成问题的 Post 请求 Demo 这里也给出来，如下所示： 'use strict'; const fs = require('fs'); const http = require('http'); const postData = JSON.stringify({ // 这里的 body.txt 可以放一个比较大 2M 左右的字符串 data: fs.readFileSync('./body.txt').toString() }); function post() { const req = http.request({ method: 'POST', host: 'localhost', port: '7001', path: '/memory', headers: { 'Content-Type': 'application/json', 'Content-Length': Buffer.byteLength(postData) } }); req.write(postData); req.end(); req.on('error', function (err) { console.log(12333, err); }); } setInterval(post, 1000); 最后我们在启动完成最小化复现的 Demo 服务器后，再运行这个 Post 请求的客户端，1s 发起一个 Post 请求，在平台控制台可以看到堆内存在一直增加，如果我们按照本书工具篇中的 Node.js 性能平台使用指南 - 配置合适的告警 一节中配置了 Node.js 进程堆内存告警的话，过一会就会收到平台的 短信/邮件 提醒。 问题排查过程 收到性能平台的进程内存告警后，我们登录到控制台并且进入应用首页，找到告警对应实例上的问题进程，然后参照工具篇中的 Node.js 性能平台使用指南 - 内存泄漏 中的方法抓取堆快照，并且点击 分析 按钮查看 AliNode 定制后的分解结果展示： 这里默认的报表页面顶部的信息含义已经提到过了，这里不再重复，我们重点来看下这里的可疑点信息：提示有 18 个对象占据了 96.38% 的堆空间，显然这里就是我们需要进一步查看的点。我们可以点击 对象名称 来看到这18 个 system/Context 对象的详细内容： 这里进入的是分别以这 18 个 system/Context 为根节点起始的支配树视图，因此展开后可以看到各个对象的实际内存占用情况，上图中显然问题集中在第一个对象上，我们继续展开查看： 很显然，这里真正吃掉堆空间的是 451 个 SomeClient 实例，面对这样的问题我们需要从两个方面来判断这是否真的是内存异常的问题： 当前的 Node.js 应用在正常的逻辑下，是否单个进程需要 451 个 SomeClient 实例 如果确实需要这么多 SomeClient 实例，那么每个实例占据 1.98MB 的空间是否合理 对于第一个判断，在对应的实际生产面临的问题中，经过代码逻辑的重新确认，我们的应用确实需要这么多的 Client 实例，显然此时排查重点集中在每个实例的 1.98MB 的空间占用是否合理上，假如进一步判断还是合理的，这意味着 Node.js 默认单进程 1.4G 的堆上限在这个场景下是不适用的，需要我们来通过启动 Flag 调大堆上限。 正是基于以上的判断需求，我们继续点开这些 SomeClient 实例进行查看： 这里可以很清晰的看到，这个 SomeClient 本身只有 1.97MB 的大小，但是下面的 options 属性对应的 Object@428973 对象一个就占掉了 1.98M，进一步展开这个可疑的 Object@428973 对象可以看到，其 ctx 属性对应的 Object@428919 对象正是 SomeClient 实例占据掉如此大的对空间的根本原因所在！ 我们可以点击其它的 SomeClient 实例，可以看到每一个实例均是如此，此时我们需要结合代码，判断这里的 options.ctx 属性挂载到 SomeClient 实例上是否也是合理的，点击此问题 Object 的地址： 进入到这个 Object 的关系图中： Search 展示的视图不同于 Dom 结果图，它实际上展示的是从堆快中解析出来的原始对象关系图，所以边信息是一定会存在的，靠边名称和对象名称，我们比较容易判断对象在代码中的位置。 但是在这个例子中，仅仅依靠以 Object@428973 为起始点的内存原始关系图，看不到很明确的代码位置，毕竟不管是 Object.ctx 还是 Object.key 都是相当常见的 JavaScript 代码关系，因此我们继续点击 Retainer 视图： 得到如下信息： 这里的 Retainer 信息和 Chrome Devtools 中的 Retainer 含义是一样的，它代表了节点在堆内存中的原始父引用关系，正如本文的内存问题案例中，仅靠可疑点本身以及其展开无法可靠地定位到问题代码的情况下，那么展开此对象的 Retainer 视图，可以看到它的父节点链路可以比较方便的定位到问题代码。 这里我们显然可以通过在 Retainer 视图下的问题对象父引用链路，很方便地找到代码中创建此对象的代码： function getClient(options) { if (!clients[options.key]) { clients[options.key] = new SomeClient(Object.assign({}, DEFAULT_OPTIONS, options)); } return clients[options.key]; } 结合看 SomeClient 的使用，看到用于初始化的 options 参数中实际上只是用到了其 key 属性，其余的属于冗余的配置信息，无需传入。 代码修复与确认 知道了原因后修改起来就比较简单了，单独生成一个 SomeClient 使用的 options 参数，并且仅将需要的数据从传入的 options 参数上取过来以保证没有冗余信息即可： function getClient(options) { const someClientOptions = Object.assign({ key: options.key }, DEFAULT_OPTIONS); if (!clients[options.key]) { clients[options.key] = new SomeClient(someClientOptions); } return clients[options.key]; } 重新发布后运行，可以到堆内存下降至只有几十兆，至此 Node.js 应用的内存异常的问题完美解决。 结尾 本节中也比较全面地给大家展示了如何使用 Node.js 性能平台 来排查定位线上应用内存泄漏问题，其实严格来说本次问题并不是真正意义上的内存泄漏，像这种配置传递时开发者图省事直接全量 Assign 的场景我们在写代码时或多或少时都会遇到，这个问题带给我们的启示还是：当我们去编写一个公共组件模块时，永远不要去相信使用者的传入参数，任何时候都应当只保留我们需要使用到的参数继续往下传递，这样可以避免掉很多问题。
滑动查看更多
暂无更多信息
-
发表了文章
2020-01-22
逆工程 JS 对象 (一): 浅谈 V8 对象布局
-
发表了文章
2019-04-22
Node.js 应用故障排查手册 —— 雪崩型内存泄漏问题
-
发表了文章
2019-04-13
Node.js 应用故障排查手册 —— 类死循环导致进程阻塞
-
发表了文章
2019-04-08
Node.js 应用故障排查手册 —— 综合性 GC 问题和优化
-
发表了文章
2019-03-30
Node.js 应用故障排查手册 —— 冗余配置传递引发的内存溢出
-
发表了文章
2019-03-25
Node.js 应用故障排查手册 —— 利用 CPU 分析调优吞吐量
-
发表了文章
2019-03-23
Node.js 应用故障排查手册 —— Node.js 性能平台使用指南
-
发表了文章
2019-03-23
Node.js 应用故障排查手册 —— 正确打开 Chrome devtools
-
发表了文章
2019-03-23
Node.js 应用故障排查手册 —— 大纲与常规问题指标简介
-
发表了文章
2018-10-19
如何进行 GC 调优提升 Node 应用性能
-
发表了文章
2018-08-03
Node 案发现场揭秘 —— Core dump 还原线上应用异常
-
发表了文章
2018-05-02
快速定位线上 Node.js 内存泄漏问题
-
发表了文章
2018-04-02
Co、递归调用引发的内存泄漏
-
发表了文章
2018-03-28
Node.js 性能平台新功能——模块仓库
滑动查看更多
暂无更多信息