1.问题
k8s集群中node节点的内存使用率居高不下,使用率达到90%多。通过以下命令可以发现此虚拟机分配的内存为15g,但是用户进程使用的内存总共为7个多g,并且slab和pageTables使用的内存为191868 kB和38316 kB。那么其它内存去哪了呢?
通过free命令查看内存情况:
[root
@node158
vmware-root]# free -h
total used free shared buff/cache available
Mem: 15G 13G 325M 45M
1
.7G
1
.6G
Swap: 0B 0B 0B
|
查看所有进程耗损的内存情况:
[root
@node158
vmware-root]# ps aux | awk
'{sum+=$6} END {print sum / 1024}'
7349.84
|
查看所有进程损耗内存的详细情况:
[root
@node158
vmware-root]# ps aux --sort -rss
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root
24477
28.5
9.1
3400528
1489188
? Sl
16
:
17
11
:
15
/usr/lib/jvm/
default
-jvm/jre/bin/java -server -Dinstall4j.jvmDir=/usr/lib/jvm/
default
-jvm/jre -Dexe4j.modu
mysql
14118
1.0
4.8
2233732
786604
? Ssl
13
:
08
2
:
28
/usr/lib/jvm/
default
-jvm/jre/bin/java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=
75
-XX:+U
root
1558
4.4
3.1
1215760
512796
? Ssl
8
月
13
65
:
28
kube-apiserver --insecure-port=
0
--allow-privileged=
true
--kubelet-preferred-address-types=InternalIP,Ext
mysql
13524
0.7
3.1
1962088
510356
? Ssl
13
:
08
1
:
47
/usr/lib/jvm/
default
-jvm/jre/bin/java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=
75
-XX:+U
mysql
13567
0.6
3.0
1953412
496228
? Ssl
13
:
08
1
:
24
/usr/lib/jvm/
default
-jvm/jre/bin/java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=
75
-XX:+U
root
32057
0.1
2.5
2328428
422840
? Sl
8
月
13
1
:
39
java -Xmx700m -Djava.security.egd=file:/dev/./urandom -jar /app.jar
root
29612
0.2
1.4
3587588
231812
? Sl
09
:
20
0
:
55
java -Xmx64m -Dservice.a.url=http:
//service-a:8081/sa/info -Dservice.c.url=http://service-c:8083/sc/info -
root
27337
0.8
1.3
293024
214160
? Ssl
13
:
39
1
:
38
/usr/local/bin/mixs server --address unix:
///sock/mixer.socket --configStoreURL=k8s:// --configDefaultName
root
29237
0.1
1.3
3587592
212328
? Sl
09
:
20
0
:
53
java -Xmx64m -Dservice.b.url=http:
//service-b:8082/sb/info -Dapp.version=v1 -Djava.security.egd=file:/dev/
root
29285
0.2
1.2
3584408
205916
? Sl
09
:
20
0
:
56
java -Xmx64m -Dapp.version=v1 -Djava.security.egd=file:/dev/./urandom -jar /app.jar
root
29117
0.2
1.2
3586412
200948
? Sl
09
:
20
0
:
55
java -Xmx64m -Dapp.version=v1 -Djava.security.egd=file:/dev/./urandom -jar /app.jar
root
27327
0.4
0.9
241136
161644
? Ssl
13
:
39
0
:
59
/usr/local/bin/mixs server --address unix:
///sock/mixer.socket --configStoreURL=k8s:// --configDefaultName
root
1568
5.1
0.8
891020
144348
? Ssl
8
月
13
75
:
34
kubelet --resolv-conf=/etc/resolv.conf --allow-privileged=
true
--cluster-domain=dinfo.cn --v=
2
--cadvisor
root
1599
2.8
0.8
10642544
136372
? Ssl
8
月
13
41
:
24
/usr/local/bin/etcd --peer-client-cert-auth --client-cert-auth --initial-cluster-token=etcd-cluster-
1
--l
root
519
0.3
0.7
199032
128200
? Ss
8
月
13
4
:
33
/usr/lib/systemd/systemd-journald
root
1022
2.2
0.7
2255380
115880
? Ssl
8
月
13
33
:
08
/usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --
default
-runt
mysql
13411
0.4
0.6
1264468
106824
? Ssl
13
:
08
1
:
03
/usr/share/kibana/bin/../node/bin/node --no-warnings /usr/share/kibana/bin/../src/cli --cpu.cgroup.path.ov
root
9395
12.2
0.6
157332
98516
? Ssl
09
:
48
52
:
25
/usr/local/bin/pilot-discovery discovery
root
1026
0.0
0.4
575420
69036
? Ssl
8
月
13
1
:
02
/usr/sbin/rsyslogd -n
root
29385
0.2
0.3
290352
51328
? Sl
13
:
01
0
:
33
/usr/bin/ruby2.
3
/usr/local/bin/fluentd --no-supervisor -q
1337
14023
0.4
0.2
181992
41328
? Sl
09
:
51
1
:
59
/usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev2.json --restart-epoch
2
--drain-time-s
45
--parent-shut
1337
15190
0.4
0.2
181988
40780
? Sl
09
:
51
2
:
00
/usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev2.json --restart-epoch
2
--drain-time-s
45
--parent-shut
1337
14153
0.4
0.2
181992
40724
? Sl
09
:
51
1
:
55
/usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev2.json --restart-epoch
2
--drain-time-s
45
--parent-shut
1337
14845
0.4
0.2
181988
40576
? Sl
09
:
51
1
:
56
/usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev2.json --restart-epoch
2
--drain-time-s
45
--parent-shut
1337
12459
0.5
0.2
173596
39728
? Sl
09
:
50
2
:
11
/usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev3.json --restart-epoch
3
--drain-time-s
45
--parent-shut
root
1580
0.9
0.2
503816
34440
? Ssl
8
月
13
13
:
51
kube-scheduler --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-scheduler.yaml --leader-elect=
true
--v=
2
--a
104
18312
0.1
0.2
590056
32700
? Ssl
14
:
07
0
:
10
/usr/sbin/grafana-server --homepath=/usr/share/grafana --config=/etc/grafana/grafana.ini cfg:
default
.log.m
nfsnobo+
23768
0.0
0.1
377372
32364
? Sl
15
:
38
0
:
00
nginx: worker process
nfsnobo+
23769
0.0
0.1
377372
30484
? Sl
15
:
38
0
:
00
nginx: worker process
nfsnobo+
23770
0.0
0.1
377372
30484
? Sl
15
:
38
0
:
00
nginx: worker process
nfsnobo+
23918
0.0
0.1
377372
30484
? Sl
15
:
38
0
:
00
nginx: worker process
root
27380
0.2
0.1
50748
28708
? Ssl
13
:
39
0
:
31
/nginx-ingress-controller --
default
-backend-service=ingress-nginx/
default
-http-backend --configmap=ingress
root
28361
5.1
0.1
47392
27724
? Sl
13
:
40
10
:
00
calico-felix
root
1569
0.1
0.1
495620
27436
? Ssl
8
月
13
2
:
43
kube-proxy --v=
2
--healthz-bind-address=
0.0
.
0.0
--cluster-cidr=
10.42
.
0.0
/
16
--hostname-override=
192.168
.
1
root
27447
0.0
0.1
115096
26200
? S
13
:
39
0
:
00
nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root
1593
0.0
0.1
502244
22716
? Ssl
8
月
13
0
:
32
kube-controller-manager --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-controller-manager.yaml --enable-ho
root
10890
0.2
0.1
152020
22160
? Sl
09
:
49
0
:
56
/usr/local/bin/envoy -c /etc/istio/proxy/envoy.yaml --restart-epoch
1
--drain-time-s
2
--parent-shutdown-t
root
9494
0.1
0.1
152020
20848
? Sl
09
:
48
0
:
43
/usr/local/bin/envoy -c /etc/istio/proxy/envoy.yaml --restart-epoch
0
--drain-time-s
2
--parent-shutdown-t
root
11294
0.1
0.1
152024
20820
? Sl
09
:
49
0
:
46
/usr/local/bin/envoy -c /etc/istio/proxy/envoy.yaml --restart-epoch
1
--drain-time-s
2
--parent-shutdown-t
root
2324
0.0
0.1
791756
16580
? Ssl
8
月
13
0
:
38
agent
|
[root
@node158
vmware-root]# cat /proc/meminfo
MemTotal:
16267364
kB
MemFree:
238452
kB
MemAvailable:
1543876
kB
Buffers:
264
kB
Cached:
1552232
kB
SwapCached:
0
kB
Active:
7408296
kB
Inactive:
836604
kB
Active(anon):
6719740
kB
Inactive(anon):
19604
kB
Active(file):
688556
kB
Inactive(file):
817000
kB
Unevictable:
0
kB
Mlocked:
0
kB
SwapTotal:
0
kB
SwapFree:
0
kB
Dirty:
36204
kB
Writeback:
0
kB
AnonPages:
6692544
kB
Mapped:
340872
kB
Shmem:
46896
kB
Slab:
191868
kB
SReclaimable:
107296
kB
SUnreclaim:
84572
kB
KernelStack:
30032
kB
PageTables:
38316
kB
NFS_Unstable:
0
kB
Bounce:
0
kB
WritebackTmp:
0
kB
CommitLimit:
8133680
kB
Committed_AS:
16685588
kB
VmallocTotal:
34359738367
kB
VmallocUsed:
173828
kB
VmallocChunk:
34359339004
kB
HardwareCorrupted:
0
kB
AnonHugePages:
1619968
kB
CmaTotal:
0
kB
CmaFree:
0
kB
HugePages_Total:
0
HugePages_Free:
0
HugePages_Rsvd:
0
HugePages_Surp:
0
Hugepagesize:
2048
kB
DirectMap4k:
362432
kB
DirectMap2M:
8026112
kB
DirectMap1G:
10485760
kB
|
2.相关技术概念
2.1. memory balloon
通常来说,要改变客户机占用的宿主机内存,是要先关闭客户机,修改启动时的内存配置,然后重启客户机才能实现。而内存的ballooning(气球)技术可以在客户机运行时动态地调整它所占用的宿主机内存资源,而不需要关闭客户机。
Ballooning技术形象地在客户机占用的内存中引入气球(Balloon)的概念,气球中的内存是可以供宿主机使用的(但不能被客户机访问或使用),所以,当宿主机内存使用紧张,空余内存不多时,可以请求客户机回收利用已分配给客户机的部分内存,客户机就会释放其空闲的内存,此时若客户机空闲内存不足,可能还会回收部分使用中的内存,可能会换出部分内存到客户机的交换分区(swap)中,从而使得内存气球充气膨胀,从而让宿主机回收气球中的内存可用于其他进程(或其他客户机)。反之,当客户机中内存不足时,也可以让客户机的内存气球压缩,释放出内存气球中的部分内存,让客户机使用更多的内存。
2.2.Memory Limit
Memory Limit,顾名思义,内存上限,就是Host可以分配给此VM的pRAM数的上限。
默认情况下是选中unlimited复选框的,也就是不设上限。不设上限不意味着没有上限,隐含的上限值是分配给VM的内存值。
Q: 什么情况下要设置Memory Limit呢?(或者说Memory Limt有什么好处?)
A: 一般情况下不用设置Memory Limt。
Limit通常用来管理用户预期。开始的时候,Host上的VM数量比较少,没有资源争用,因此VM的性能完全可以保证;随后,当一台又一台VM创建出来,对于资源的争用渐渐变的频繁起来。于是VM的性能下降了,用户便会产生抱怨。因此,设置limit可以从一开始就限定VM的性能,也就是让用户一开始就觉得他的VM就应该是这样的性能,当VM数量增加的时候,也不会感觉到性能的下降。当然,Memory Limit设置在什么数值比较合理应该具体情况具体分析。
那为啥不把VM的内存(Configured Size)设小呢?这也是考虑用户心理。有用户会觉得自己的应用就是需要4GB内存,虽然我们经过分析得出的结论是只需要1GB内存就够了,但是为了考虑用户的感受,就给他设置VM的内存为4GB,于是用户看见自己的OS显示有4GB内存,就很满意,但是他不知道的是我们给他的VM设置了1GB 的Memory Limt,这样,既保证了Host的资源可以更合理的利用,又让用户感到满意。
当用户的应用越来越频繁,其对内存的需求增加的时候,这时再来调整Memory limt,以满足其对性能的要求。调整Memory Limt无需停机,而如果开始时虚拟机的内存设的小了,此时调整内存数量就要停机了。设置Memory limt的好处就在于减少了不必要的downtime。
调整memory limit的动作,其实就是通知Hypervisor将某一VM可用的pRAM放大,而无需通知GOS,所以无需GOS重启。(简单的说,就是改Hypervisor,而和GOS无关)
专用名词解释 Configured Size Configured Size可以翻译成配置内存,就是用户在创建一个VM的时候设定的内存值,也是Guest OS认为自己拥有的内存值。Configured Size在VM看来就是自己可用内存的总量,有的时候我们也称之为Guest Physical Memory。 |
3.原因
[root
@node158
vmware-root]# vmware-toolbox-cmd stat memlimit
8759
MB
|
[root
@node158
vmware-root]# vmware-toolbox-cmd stat balloon
7097
MB
|
4.解决方案
vmware 设置memory limit大小为分配给此虚拟机的大小。这样就可以避免认为用户进程占用太多的内存资源,实际上却没有使用这么多的内存资源的问题。
参考资料:
https://blog.csdn.net/xiaoxinyu316/article/details/42581785/
https://blog.csdn.net/liukuan73/article/details/47044141
所有评论(0)