We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
阅读 一个平均运行一百万次才出现一次的bug,你如何调试这个bug 结合最近的语雀偶发性 Coredump 想到
堆内存的异常不同于 CPU,偶发性的异常请求导致的内存毛刺,也是需要关注的,但是由于是瞬时的内存上涨,不易排查:
另一种和前文类似的场景,异常请求造成了 OOM,正常生成了 Core 文件,存在以下场景导致无法定位
这种情况下只能通过逆工程 V8 Heap object 来进行进一步问题定位,由于在 core 文件里还原的 Heap object 丢失了 GC root 信息,所以没有办法进行 Dominator tree 的构建,人肉扫除了大字符串类,很难甄别内存泄漏点。
综上 Xprofiler 插件需要提供一个机制,在内存出现毛刺时进行自动 Dump 来辅助这类问题的定位。
int[60 * 60] Ring buffer
The text was updated successfully, but these errors were encountered:
内部同学也给了一个非常不错的解法,配合:
max old space size
应该可以处理一部分雪崩式的 OOM 问题。
具体来说,在 https://github.com/X-Profiler/xprofiler/blob/master/src/hooks/set_hooks.cc 中增加一个 OOM 的钩子即可。
Sorry, something went wrong.
继续调研 OOM Hook
hyj1991
No branches or pull requests
背景
阅读 一个平均运行一百万次才出现一次的bug,你如何调试这个bug 结合最近的语雀偶发性 Coredump 想到
堆内存的异常不同于 CPU,偶发性的异常请求导致的内存毛刺,也是需要关注的,但是由于是瞬时的内存上涨,不易排查:
另一种和前文类似的场景,异常请求造成了 OOM,正常生成了 Core 文件,存在以下场景导致无法定位
这种情况下只能通过逆工程 V8 Heap object 来进行进一步问题定位,由于在 core 文件里还原的 Heap object 丢失了 GC root 信息,所以没有办法进行 Dominator tree 的构建,人肉扫除了大字符串类,很难甄别内存泄漏点。
综上 Xprofiler 插件需要提供一个机制,在内存出现毛刺时进行自动 Dump 来辅助这类问题的定位。
具体设计
int[60 * 60] Ring buffer
存储过去 1min 内的进程 CPU / Heap 大小存在的副作用
需要处理的异常场景
监控服务端的改造
The text was updated successfully, but these errors were encountered: