Grpc 服务无法在 kubernetes pod 中分配内存-解网

问：

我在 kubernetes 上部署了一个 grpc 服务，所有内存分配都通过 tcmalloc 进行。我经常在 pod 中发现内存不足问题。

Stacktrace 在这里：

terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_create
*** Aborted at 1668932192 (unix time) try "date -d @1668932192" if you are using GNU date ***
PC: @                0x0 (unknown)
*** SIGABRT (@0x1) received by PID 1 (TID 0x7f2e45bd3700) from PID 1; stack trace: ***
    @     0x7f2e4c7d63c0 (unknown)
    @     0x7f2e4c4a918b gsignal
    @     0x7f2e4c488859 abort
    @     0x7f2e4c8a1951 (unknown)
    @     0x7f2e4c8ad47c (unknown)
    @     0x7f2e4c8ad4e7 std::terminate()
    @     0x7f2e4c8ad799 __cxa_throw
    @     0x7f2e4c8a4366 std::__throw_length_error()
    @     0x7f2e4c9459fc std::__cxx11::basic_string<>::_M_create()
    @     0x561821534960 __gnu_cxx::new_allocator<>::construct<>()
    @     0x56182153390b metrics::ReadReporter::Report()
    @     0x56182125cb54 std::_Function_handler<>::_M_invoke()
    @     0x56182151f2aa std::_Function_handler<>::_M_invoke()
    @     0x56182154092e std::_Function_handler<>::_M_invoke()
    @     0x56182153f5e5 file::HttpRequest::Invoke()
    @     0x7f2e4c8d9d84 (unknown)
    @     0x7f2e4c7ca609 start_thread
    @     0x7f2e4c585293 clone
    @                0x0 (unknown)
terminate called recursively
terminate called recursively
external/com_google_tcmalloc/tcmalloc/tcmalloc_policy.h:102] Unable to allocate (new failed) 8111000728417 @ 0x561822037742 0x56182200fc67 0x561822003b0f 0x561821534960 0x56182153390b 0x56182125cb54 0x56182125d10a 0x56182151f2aa 0x56182154092e 0x56182153f5e5 0x561821545432 0x7f2e4c8d9d84
See https://github.com/google/tcmalloc/tree/master/docs/stats.md for an explanation of this page

我已为该服务注册了就绪情况和活动性探测。它只是一个线程侦听和响应 TCP。

我的困惑是：

为什么 pod 不会作为 OOM 失败（因为 SIGABRT 已被抛出，正如您在堆栈跟踪中看到的那样），并且将由 Kubernetes 重新启动？
我知道也许我可以向容器添加更多内存分配，并添加速率限制器来解决此问题，但想知道这是解决此问题的最佳实践吗？

Kubernetes gRPC tcmalloc oom

当 Pod 状态显示为 OOMKilled 时，这意味着运行 kubernetes 节点的操作系统决定终止您的进程。从日志中看，容器中的进程分配内存失败，导致其崩溃，导致重新启动计数器递增/短时间，状态为错误，然后恢复运行，或者最终在问题仍然存在时崩溃LoopBackOff。

0赞 Tinyden 11/20/2022

从 kubernetes pod 状态，我没有重新启动。在保持当前状态一天后，就没有 CrashLoopBackOffkubectl get pod

0赞 SYN 11/20/2022

那么它就是一个子进程/分支。如果这是容器的主进程，则会看到重新启动。无论哪种方式，它都没有理由显示为 OOM：从操作系统的角度来看，它不是。

0赞 Tinyden 11/21/2022

不，这是一个线程，因为我的服务在 grpc 中运行。gRPC 线程管理器管理它。

0赞 Tinyden 11/27/2022

好的，我想通了。我在 glog 中注册了信号处理程序，它杀死了主进程（PID = 1）：github.com/google/glog/blob/...但是 init 进程无法被终止，即使返回 0 表示系统调用成功。kill

答： 暂无答案

上一个：gperftools 中的 tcmalloc 使程序崩溃

下一个：gpertools-2.10 中使用哪个版本的 tcmalloc

Grpc 服务无法在 kubernetes pod 中分配内存

Grpc service fails to allocate memory within kubernetes pod

评论