[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":16},"topics",[35],"user",{"_20":21,"_13":14,"_22":23,"_24":14,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34},"loginname","qimenxiaozi","page",1,"limit",20,"total","id","17348","avatar_url","https://avatars0.githubusercontent.com/u/12589725?v=4","githubUsername","create_at","2015-06-03 02:49:13.316","score",460,"topic_count",4,"reply_count",88,"is_star",false,{"_20":36,"_37":38,"_39":-5,"_40":41,"_42":43,"_44":45,"_46":47,"_48":34,"_31":49,"_50":51,"_25":52,"_53":54},"41","author_id","135","tab","content"," 在Node 中，Buffer 是一个广泛用到的类，本文将从以下层次来分析其内存策略：\r\n\r\n* User 层面，即Node lib/*.js 或用户自己的Js 文件调用 new Buffer\r\n* Socekt read/write\r\n* File read/write\r\n\r\n## User Buffer\r\n\r\n在 lib/buffer.js 模块中，有个模块私有变量 pool，它指向当前的一个8K 的slab ：\r\n\r\n```js\r\nBuffer.poolSize = 8 * 1024;\r\nvar pool;\r\n\r\nfunction allocPool() {\r\n pool = new SlowBuffer(Buffer.poolSize);\r\n pool.used = 0;\r\n}\r\n```\r\n\r\nSlowBuffer 为 src/node_buffer.cc 导出，当用户调用new Buffer时，如果你要申请的空间大于8K，Ｎode 会直接调用SlowBuffer ，如果小于8K ，新的Buffer 会建立在当前slab 之上：\r\n\r\n\r\n* 新创建的Buffer的 parent成员变量会指向这个slab ，\r\n* offset 变量指向在这个slab 中的偏移：\r\n\r\n```\r\nif (!pool || pool.length - pool.used < this.length) allocPool();\r\nthis.parent = pool;\r\nthis.offset = pool.used;\r\npool.used += this.length;\r\n```\r\n\r\n比如当你需要2K 的空间时： new Buffer（2*1024），它会检查这个slab 的剩余空间，如果有剩余，则分配给你这段可用空间，并把当前 slab 的已用空间 used += 2*1024\r\n比如当我们连续两次调用new Buffer（2*1024）时：\r\n\r\n $\"\"$ \r\n\r\n当我们再次申请一个5K 的空间时，当前的pool 仅有4K 可用，所以这时node会再次申请一个8K 的slab ，并把当前的pool 指向它，注意此时原先的slab 会有4K空间被浪费：\r\n\r\n $\"\"$ \r\n\r\n此时原先的slab 被两个2K 的 Buffer 所引用，所以当这两个Buffer 引用都变为null 后，V8 认为可以销毁这个slab。\r\n\r\n注意，假如我们的某一个slab被一个1Byte 的Buffer 所引用，那么，即使其他所有的引用都已经变为null ，这块8K 的slab 也不会被回收:\r\n\r\n $\"\"$ \r\n\r\n## Socket 读写\r\n\r\n首先让我们看stream read 的情况：\r\n在stream_wrap 当中，此时的策略与用户层的 new Buffer 相似，只是slab 的 size 变为 1MB ，此时我们需要考虑socket “读操作” 缓冲区大小问题，设想以下，假如我们数据长度为30K，而我们的缓冲区大小仅为2K，这意味着我们至少调用15次socket read操作，要触发15次 on(“data”) 事件，每次都需要把这个事件及数据从libuv 层次传递到用户js 层次，这是极其低效的，所以我们需要设置一个较大的缓冲区，在libuv 的 unix/stream.c ，当绑定socket 的 watcher read 事件被触发时，会调用uv__read 函数，其固化了buffer 大小为64*1024 ：\r\n\r\n```\r\n...\r\nbuf = stream->alloc_cb((uv_handle_t*)stream, 64 * 1024);\r\n...\r\n```\r\n\r\nalloc_cb 定义在 stream_wrap.cc 中\r\n\r\n```\r\nuv_buf_t StreamWrap::OnAlloc(uv_handle_t* handle, size_t suggested_size)\r\n```\r\n\r\n $\"\"$ \r\n\r\n但事实上我们知道，我们socket read 一般很少会有64K 大小，比如假如nread 仅为 2k，此时我们为了避免浪费，可以重设slab_used :\r\n\r\n```\r\nif (handle_that_last_alloced == handle) {\r\nslab_used -= (buf.len - nread);\r\n}\r\n```\r\n\r\n $\"\"$ \r\n\r\n敬请注意，我们之所以能够这么做，是因为当检测到socket 上read事件时才分配缓冲区， alloc_cb →socket read → read callback 这一过程是顺序进行的，没有外来的干扰！（我不明白为何node 还要加上一次判断 if (handle_that_last_alloced == handle) ，深究的可以告诉我）\r\n\r\n我们看到，在socket read 的情况下,缓冲区的管理在stream_wrap 中控制，uv steram.c 执行读操作，返回的回调函数也是在stream_wrap 中定义，然后把读取到的Buffe 层层传递给user 的js当中，即我们的on(“data”) 事件，这个过程中没有额外的内存拷贝，还是相当高效的, 不过有个问题：假使你持久引用了一个有stream.read 上浮的Buffer ，你将导致其所引用的那个1M 的slab 得不到释放！\r\n\r\n我们在来看 Socket.prototype.write ，当你传入一个 string 时，node 会自动生成一个Buffer ，如果你本身就是Buffer ，那就省了这一步（注意调用的是user 层面的 new Buffer）：\r\n\r\n```\r\n// Change strings to buffers. SLOW\r\nif (typeof data == 'string') {\r\ndata = new Buffer(data, encoding);\r\n}\r\n```\r\n\r\n然后这个Buffer 对应的指针会层层传递，直至 uv 的stream.c 的相应的 write 函数，这个过程也不会再有额外的拷贝操作，尤其要注意的是：当你直接传入一个Buffer 时，直至socket.write 回调返回表示结束，此过程中你不应该再修改它，因为底层正在或将要操作它！\r\n\r\n \r\n\r\n## 文件读写\r\n\r\nregular file 的write 和 socket 比较类似，没什么亮点，我们重点来看 file read。\r\n\r\n关于IO 操作时bufsize 大小的重要性，上文已有介绍，记得APUE 中 steven 老先生也有专门的测试结果，此处不再赘述，\r\n\r\n在 fs.ReadStream 时，我们可以传入一些参数：\r\n\r\n```\r\n{\r\n flags: 'r',\r\n encoding: null,\r\n fd: null,\r\n mode: 0666,\r\n bufferSize: 64 * 1024\r\n}\r\n```\r\n\r\n默认bufsize 为 64K ，但在 lib/fs.js 中，还有一个poolSize 控制变量：\r\n\r\n```\r\nvar kPoolSize = 40 * 1024;\r\n```\r\n\r\n当node 最终实际调用fs.read 时：\r\n\r\n```\r\nvar thisPool = pool;\r\nvar toRead = Math.min(pool.length - pool.used, this.bufferSize);\r\nvar start = pool.used;\r\n```\r\n\r\nNode 会对用户传入的bufsize 与当前pool 的剩余空间作比较，取其小者而用之，所以默认的64*1024 大小其实是永远不会生效的。\r\n\r\n好吧，40K 大小也可以接受，但如果你要读取的文件比较小，比如1K ，2K 级别的比较多，这时我们预留40K 的buf ,当读返回时，其实只用到了1K 或 2K ，这时候，Node 不会再像socket.read 那样，再把 pool.used 减去 39K 或 38K ，因为我们实际的fs.read 操作是在另一独立线程中执行的，即 buf alloc → fs read → read cb 这一个过程不是顺序的，我们不能再像socket.read 那样重新设置pool used ！这种情况下内存的浪费相当严重！\r\n\r\n所以当你想缓存大量小文件时，如静态服务器，我的建议是：自己分配大块Buffer ，然后把从fs.readStream 上浮的Buffer 拷贝到我们自己的大块Buffer 中，然后在这个大块Buffer 上做 slice生成相应的小Buffer ，这样我们就没有引用readStream 上浮的Buffer ，使其可以被V8 回收，当然如果你内存足够你挥霍，当我啥都没说...\r\n\r\n## 内存池\r\n\r\n再来看底层的node_buffer :\r\n\r\n```\r\nvoid Buffer::Replace(char *data, size_t length, free_callback callback, void *hint)\r\n```\r\n\r\n这个函数的内存操作很单纯：\r\n\r\n```\r\n….\r\n\r\ndelete [] data_;\r\n\r\n….\r\n\r\ndata_ = new char[length_];\r\n```\r\n\r\n其实通过上面分析可知，一个繁忙的网络服务器，很可能会频繁的new/delete 8K / 1M 的内存块，如果是静态文件服务，可能还会有频繁的40K 内存块的操作，所以我试着对node 添加了 8K 内存块的内存池控制，服务繁忙时命中率无限接近100%，可惜总体性能提升没有达到预期，在此就不现拙了，有兴趣的同学可以自己hack 玩玩，有成果了可以知会我一声(http://weibo.com/windyrobin)...\r\n\r\n## 小节：\r\n由以上分析，我们可知\r\n\r\n* 不要轻易持久引用由 socket.readStream 或 fs.readStream 上浮的Buffe\r\n* 当你调用stream.write 并直接传递Buffer 进去时，在此操作返回之前，你不应该再修改它\r\n* 当调用fs.readStream 时，如果你对文件大小有估值，尽量传入较接近的bufsize\r\n* 当你持久引用一个Buffer 时，哪怕它只有一个字节，也可能导致其依赖的slab （可能是8K /1M...）得不到释放\r\n\r\n附：以上分析基于node 0.6 系列，就这方面的问题，我已提交了几个Issue 给 Node 官方，开发人员正在对以上暴露的问题就行改进：\r\n\r\n----\r\n\r\nbnoordhuis commented November 14, 2011\r\n[@igorzi](/user/igorzi): I'm assigning this to you as part of the slab allocator redesign.\r\n","title","Node Buffer/Stream 内存策略分析","last_reply_at","2015-12-08 09:26:17.86","good",true,"top",7,"visit_count",23233,"2011-11-21 11:11:39","author",{"_13":55,"_22":56},"windyrobin","http://www.gravatar.com/avatar/e9e2e24aa3ed291923d223924ec694ba?s=48"]