摘要： 还有一些问题场景下下应用的内存泄漏非常严重和迅速，甚至于在我们的告警系统感知之前就已经造成应用的 OOM 了，这时我们来不及或者说根本没办法获取到堆快照，因此就没有办法借助于之前的办法来分析为什么进程会内存泄漏到溢出进而 Crash 的原因了。

在实践篇一中我们看到了两个表象都是和 CPU 相关的生产问题，它们基本也是我们在线上可能遇到的这一类问题的典型案例，而实际上这两个案例也存在一个共同点：我们可以通过 Node.js 性能平台 导出进程对应的 CPU Profile 信息来进行分析定位问题，但是实际在线上的一些极端情况下，我们遇到的故障是没有办法通过轻量的 V8...

JavaScript 发展到今天，早已脱离原本浏览器的战场，借助于 Node.js 的诞生将其触角伸到了服务端、PC 跨平台客户端方案等各个领域，但是与此同时，JS Runtime 对于绝大部分的开发者来说又一如既往的处于黑盒状态——开发者无法感知其运行状态，出现一些性能、内存问题时也没有很好的工具链进行更深入的支持。

本章前面两节生产案例分别侧重于单一的 CPU 高和单一的内存问题，我们也给大家详细展示了问题的定位排查过程，那么实际上还有一类相对更复杂的场景——它本质上是 V8 引擎的 GC 引发的问题。

前面的预备章节中我们大致了解了如何在服务器上的 Node.js 应用出现问题时，从常规的错误日志、系统/进程指标以及兜底的核心转储这些角度来排查问题。这样就引出了下一个问题：我们知道进程的 CPU/Memory 高，或者拿到了进程 Crash 后的核心转储，要如何去进行分析定位到具体的 JavaScript 代码段。

前一节中我们借助于 Chrome devtools 实现了对线上 Node.js 应用的 CPU/Memory 问题的排查定位，但是在实际生产实践中，大家会发现 Chrome devtools 更加偏向本地开发模式，因为显然 Chrome devtools 不会负责去生成分析问题所需要的 Dump 文件，这意味着开发者还得额外在线上项目中设置好 v8-profiler 和 heapdump 这样...

在本次活动上可以了解到Ruby语言最新的动态，Ruby和新语言golang在性能方面的差别。听听Matz畅谈他对云原生发展的看法，了解下他最近的动向。可以听到阿里云高级技术专家朴灵分享阿里云在开发语言上的动向，以及对于开发者的支持。

在我们想要新上线一个 Node.js 应用之前，尤其是技术栈切换的第一个 Node.js 应用，由于担心其在线上的吞吐量表现，肯定会想要进行性能压测，以便对其在当前的集群规模下能抗住多少流量有一个预估。本案例实际上正是在这样的一个场景下，我们想要上线 Node.js 技术栈来做前后端分离，那么刨开后端服务的响应 QPS，纯使用...

前面一小节我们以一个真实的压测案例来给大家讲解如何利用 Node.js 性能平台 生成的 CPU Profile 分析来进行压测时的性能调优。那么与 CPU 相关的问题相比，Node.js 应用中由于不当使用产生的内存问题是一个重灾区，而且这些问题往往都是出现在生产环境下，本地压测都难以复现，实际上这部分内存问题也成为了很多的 Node...

当前kubernetes集群中的worker节点可以支持添加多可用区中的ECS，这种部署方式的目的是可以让一个应用的多个pod（至少两个）能够分布在不同的可用区，起码不能分布在同一个可用区，已达到高可用或者同城灾备的部署。