上云无忧 > 文档中心 > 腾讯云容器服务 - 节点内存碎片化排障处理
容器服务 TKE
腾讯云容器服务 - 节点内存碎片化排障处理

文档简介:
本文档介绍如何判断 TKE 集群中存在问题是否由内存碎片化引起,并给出解决方法,请按照以下步骤进行排查并解决。
*此产品及展示信息均由腾讯云官方提供。免费试用 咨询热线:400-826-7010,为您提供专业的售前咨询,让您快速了解云产品,助您轻松上云! 微信咨询
  免费试用、价格特惠
本文档介绍如何判断 TKE 集群中存在问题是否由内存碎片化引起,并给出解决方法,请按照以下步骤进行排查并解决。

问题分析

内存页分配失败,内核日志将会出现以下报错:
		
mysqld: page allocation failure. order:4, mode:0x10c0d0
mysqld:为被分配内存的程序。
order:表示需要分配连续页的数量(2^order),本例中4则表示 2^4 = 16 个连续的页。

mode:内存分配模式的标识,在内核源码文件 include/linux/gfp.h 中定义,通常是多个标识项与运算的结果。

不同版本内核有一定区别。例如。在新版内核中 GFP_KERNEL__GFP_RECLAIM |

 __GFP_IO | __GFP_FS 的运算结果,而 __GFP_RECLAIM___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM 的运算结果。

注意
当 order 值为0时,说明系统已经完全没有可用内存。
当 order 值较大时,说明内存已碎片化,无法分配连续的大页内存。

现象描述

容器启动失败

K8S 会为每个 Pod 创建 netns 来隔离 network namespace,内核初始化 netns 时会为其创建 nf_conntrack 表的 cache,需要申请大页内存,如果此时系统内存已经碎片化,无法分配到足够的大页内存内核就会出现如下报错(v2.6.33 - v4.6):
		
runc:[1:CHILD]: page allocation failure: order:6, mode:0x10c0d0
Pod 将会一直处于 ContainerCreating 状态,dockerd 启动容器也将失败。日志报错如下:

		

Jan 23 14:15:31 dc05 dockerd: time="2019-01-23T14:15:31.288446233+08:00"

level=error msg="containerd: start container" error="oci runtime error:

container_linux.go:247: starting container process caused \"process_linux.

go:245: running exec setns process for init caused \\\"exit status 6\\\"\"\n"

id=5b9be8c5bb121264899fac8d9d36b02150269d41ce96ba6ad36d70b8640cb01c

Jan 23 14:15:31 dc05 dockerd: time="2019-01-23T14:15:31.317965799+08:00"

level=error msg="Create container failed with error: invalid header field

value \"oci runtime error: container_linux.go:247: starting container

process caused \\\"process_linux.go:245: running exec setns process for

init caused \\\\\\\"exit status 6\\\\\\\"\\\"\\n\""

Kubelet 日志报错如下:

		

Jan 23 14:15:31 dc05 kubelet: E0123 14:15:31.352386 26037 remote_runtime.

go:91] RunPodSandbox from runtime service failed: rpc error: code = 2 desc

= failed to start sandbox container for pod "matchdataserver-1255064836-t4b2w"

: Error response from daemon: {"message":"invalid header field value \"oci runtime

error: container_linux.go:247: starting container process caused \\\"process_linux.

go:245: running exec setns process for init caused \\\\\\\"exit status 6\\\\\\\"\\\"\\n\""}

Jan 23 14:15:31 dc05 kubelet: E0123 14:15:31.352496 26037 kuberuntime_sandbox.

go:54] CreatePodSandbox for pod "matchdataserver-1255064836-t4b2w_basic

(485fd485-1ed6-11e9-8661-0a587f8021ea)" failed: rpc error: code = 2 desc = failed to

start sandbox container for pod "matchdataserver-1255064836-t4b2w": Error response

from daemon: {"message":"invalid header field value \"oci runtime error: container

_linux.go:247: starting container process caused \\\"process_linux.go:245: running

exec setns process for init caused \\\\\\\"exit status 6\\\\\\\"\\\"\\n\""}

Jan 23 14:15:31 dc05 kubelet: E0123 14:15:31.352518 26037 kuberuntime_manager.

go:618] createPodSandbox for pod "matchdataserver-1255064836-t4b2w_basic

(485fd485-1ed6-11e9-8661-0a587f8021ea)" failed: rpc error: code = 2 desc = failed

to start sandbox container for pod "matchdataserver-1255064836-t4b2w": Error

response from daemon: {"message":"invalid header field value \"oci runtime error:

container_linux.go:247: starting container process caused \\\"process_linux.go:245:

running exec setns process for init caused \\\\\\\"exit status 6\\\\\\\"\\\"\\n\""}

Jan 23 14:15:31 dc05 kubelet: E0123 14:15:31.352580 26037 pod_workers.go:182]

Error syncing pod 485fd485-1ed6-11e9-8661-0a587f8021ea ("matchdataserver-1255064836

-t4b2w_basic(485fd485-1ed6-11e9-8661-0a587f8021ea)"), skipping: failed to

"CreatePodSandbox" for "matchdataserver-1255064836-t4b2w_basic(485fd485-1ed6-

11e9-8661-0a587f8021ea)" with CreatePodSandboxError: "CreatePodSandbox for pod

\"matchdataserver-1255064836-t4b2w_basic(485fd485-1ed6-11e9-8661-0a587f8021ea)\"

failed: rpc error: code = 2 desc = failed to start sandbox container for pod

\"matchdataserver-1255064836-t4b2w\": Error response from daemon: {\"message\":

\"invalid header field value \\\"oci runtime error: container_linux.go:247: starting

container process caused \\\\\\\"process_linux.go:245: running exec setns process

for init caused \\\\\\\\\\\\\\\"exit status 6\\\\\\\\\\\\\\\"\\\\\\\"\\\\n\\\"\"}"

Jan 23 14:15:31 dc05 kubelet: I0123 14:15:31.372181 26037 kubelet.go:1916] SyncLoop

(PLEG): "matchdataserver-1255064836-t4b2w_basic(485fd485-1ed6-11e9-8661-0a587f8021ea)",

event: &pleg.PodLifecycleEvent{ID:"485fd485-1ed6-11e9-8661-0a587f8021ea", Type:

"ContainerDied", Data:"5b9be8c5bb121264899fac8d9d36b02150269d41ce96ba6ad36d70b8640cb01c"}

Jan 23 14:15:31 dc05 kubelet: W0123 14:15:31.372225 26037 pod_container_deletor.go:77]

Container "5b9be8c5bb121264899fac8d9d36b02150269d41ce96ba6ad36d70b8640cb01c"

not found in pod's containers

Jan 23 14:15:31 dc05 kubelet: I0123 14:15:31.678211 26037 kuberuntime_manager.

go:383] No ready sandbox for pod "matchdataserver-1255064836-t4b2w_basic(485fd485

-1ed6-11e9-8661-0a587f8021ea)" can be found. Need to start a new one

执行命令 cat /proc/buddyinfo 查看 slab,系统不存在大块内存时返回0数量较多。如下所示:
		
$ cat /proc/buddyinfo
Node 0, zone DMA 1 0 1 0 2 1 1 0 1 1 3
Node 0, zone DMA32 2725 624 489 178 0 0 0 0 0 0 0
Node 0, zone Normal 1163 1101 932 222 0 0 0 0 0 0 0

系统 OOM

内存碎片化严重,系统缺少大页内存,即使是当前系统总内存较多的情况下,也会出现给程序分配内存失败的现象。此时系统会做出内存不够用的误判,认为需要停止一些进程来释放内存,从而导致系统 OOM。

处理步骤

1. 周期性地或者在发现大块内存不足时,先进行 drop_cache 操作。
		
echo 3 > /proc/sys/vm/drop_caches
相似文档
  • 排查思路: 1. 确保集群 DNS 正常运行 容器内解析 DNS 通过集群 DNS(通常是 CoreDNS),首先要确保集群 DNS 运行正常。kubelet 启动参数--cluster-dns可以看到 DNS 服务的 Cluster IP:
  • 在使用 TKE 集群服务的过程中,某些场景下,可能会出现服务访问不通的问题,如果确认后端 Pod 访问正常,则可能是由于 kube-proxy 组件版本较低,导致节点上的 iptables 或 ipvs 服务转发规则下发失败。本文档整理了低版本 kube-proxy 存在的若干问题,并给出相应的修复指引。若本文档无法解决您所遇到的问题,请 联系我们 来寻求帮助。
  • 开启内网访问后无法访问: 您可以直接在容器服务控制台上 开启内网访问。如果开启内网访问之后仍出现无法访问的情况,建议您对应集群类型进行如下检查: 托管集群: 参考 查看节点安全组配置 检查集群中节点的安全组是否正确放通30000-32768端口区间。
  • Service 提供公网或内网服务无法访问: 提供公网服务或者内网服务的 Service,如果出现无法访问或者 CLB 端口状态异常的情况,建议您进行如下检查: 1. 参考 查看节点安全组配置 检查集群中节点的安全组是否正确放通30000-32768端口区间。 2. 如果是公网服务,则进一步检查节点是否有公网带宽(仅针对 传统账户类型)。 3. 如果 Service 的 type 为 loadbalancer 类型,可忽略 CLB,直接检查 NodeIP + NodePort 是否可以访问。 4. 检查 Service 是否可以在集群中正常访问。
  • Kuberentes 通过声明式的方式管理资源,声明式 API 只需要声明一个期望的状态,系统就会自行调节以满足该状态。但声明式 API 也引入新的问题:无法感知资源当前状态信息,对任务的流程把握不够清晰。
官方微信
联系客服
400-826-7010
7x24小时客服热线
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部