tomcat（1）
说起对tomcat内存的限制，对于一个不熟悉的童鞋来说肯定是先google、百度，国内的文章都比较千篇一律。我来说说我在项目中的配置。
一、最常见的配置修改catalina.sh或catalina.bat
这或许是百度、google搜索到的最多的。下图是开源中国的tomcat配置：
当我们打开catalina.sh或catalina.bat瞬间蒙了，几百行不熟悉的脚本，下面我推荐另一种优雅的方式
二、使用setenv.sh火setenv.bat配置tomcat内存
如果你查看过catalina.sh或catalina.bat里面的代码你会发现这段说明
我们将开源中国的配置的那两行添加到tomcat/bin目录下，命名为setenv.sh、serenv.bat即可。
再也不用蛋疼的看那么多代码了,是不是感觉优雅了很多！
三、在docker中控制tomcat内存大小
首先，docker可以控制容器的内存大小，但是tomcat的内存依然是又必要限制的，避免引起内存泄露。
之前看到有的是在Dockerfile中构建image的时候写死了一个setenv.sh到tomcat的bin目录下，这样的话就限制死了我们的镜像，不够通用。
我们在项目中则是直接以docker env的形式在实例启动的时候限制，这样更加灵活。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：10047次
排名：千里之外
转载：10篇
译文：17篇
(1)(2)(1)(4)(11)(11)(5)Docker容器的资源限制 | 开源小站Docker 容器内存监控原理及应用
作者：XuXinkun
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Docker 容器内存监控原理及应用的相关资料,需要的朋友可以参考下
Docker 容器内存监控
linux内存监控
要明白docker容器内存是如何计算的，首先要明白linux中内存的相关概念。
使用free命令可以查看当前内存使用情况。
[root@localhost ~]$ free
-/+ buffers/cache:
这里有几个概念:
mem: 物理内存
swap: 虚拟内存。即可以把数据存放在硬盘上的数据
shared: 共享内存。存在在物理内存中。
buffers: 用于存放要输出到disk（块设备）的数据的
cached: 存放从disk上读出的数据
可以参考这里。
为方便说明，我对free的结果做了一个对应。
[root@localhost ~]$ free
shared_mem
-/+ buffers/cache: real_used
total_swap used_swap
物理内存总量
已使用的物理内存量
空闲的物理内存量
shared_mem
共享内存量
buffer所占内存量
cache所占内存量
实际使用的内存量
实际空闲的内存量
total_swap
已使用的swap
空闲的swap
一般认为，buffer和cache是还可以再进行利用的内存，所以在计算空闲内存时，会将其剔除。
因此这里有几个等式:
real_used = used_mem - buffer - cache
real_free = free_mem + buffer + cache
total_mem = used_mem + free_mem
了解了这些，我们再来看free的数据源。其实其数据源是来自于/proc/memeinfo文件。
[root@localhost ~]$ cat /proc/meminfo
2095356 kB
SwapCached:
Active(anon):
Inactive(anon): 4455076 kB
Active(file):
Inactive(file):
Unevictable:
SwapTotal:
Writeback:
AnonPages:
8374496 kB
SReclaimable:
8163096 kB
SUnreclaim:
KernelStack:
PageTables:
NFS_Unstable:
WritebackTmp:
CommitLimit:
Committed_AS:
VmallocTotal:
VmallocUsed:
VmallocChunk:
HardwareCorrupted:
AnonHugePages:
HugePages_Total:
HugePages_Free:
HugePages_Rsvd:
HugePages_Surp:
Hugepagesize:
DirectMap4k:
DirectMap2M:
2015232 kB
DirectMap1G:
说完linux的内存，我们再来看下docker的内存监控。docker自身提供了一种内存监控的方式，即可以通过docker stats对容器内存进行监控。
该方式实际是通过对cgroup中相关数据进行取值从而计算得到。
cgroup中的memory子系统为hierarchy提供了如下文件。
[root@localhost ~]$ ll /cgroup/memory/docker/53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f/
--w--w--w- 1 root root 0 2月 22 12:51 cgroup.event_control
-rw-r--r-- 1 root root 0 5月 25 17:07 cgroup.procs
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.failcnt
--w------- 1 root root 0 2月 22 12:51 memory.force_empty
-rw-r--r-- 1 root root 0 3月 30 17:06 memory.limit_in_bytes
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.max_usage_in_bytes
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.memsw.failcnt
-rw-r--r-- 1 root root 0 3月 30 17:06 memory.memsw.limit_in_bytes
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 root root 0 2月 22 12:51 memory.memsw.usage_in_bytes
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.move_charge_at_immigrate
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.oom_control
-rw-r--r-- 1 root root 0 3月 30 17:06 memory.soft_limit_in_bytes
-r--r--r-- 1 root root 0 2月 22 12:51 memory.stat
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.swappiness
-r--r--r-- 1 root root 0 2月 22 12:51 memory.usage_in_bytes
-rw-r--r-- 1 root root 0 2月 22 12:51 memory.use_hierarchy
-rw-r--r-- 1 root root 0 2月 22 12:51 notify_on_release
-rw-r--r-- 1 root root 0 2月 22 12:51 tasks
这些文件的具体含义可以查看相关资料cgroup memory。
这里主要介绍几个与docker监控相关的。
memory.usage_in_bytes
已使用的内存量(包含cache和buffer)(字节)，相当于linux的used_meme
memory.limit_in_bytes
限制的内存总量(字节)，相当于linux的total_mem
memory.failcnt
申请内存失败次数计数
memory.memsw.usage_in_bytes
已使用的内存和swap(字节)
memory.memsw.limit_in_bytes
限制的内存和swap容量(字节)
memory.memsw.failcnt
申请内存和swap失败次数计数
memory.stat
内存相关状态
以下为一个容器的样例。
[root@localhost 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.usage_in_bytes
[root@localhost 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.memsw.usage_in_bytes
[root@localhost 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.stat
mapped_file
inactive_anon 4218880
active_anon
inactive_file
active_file
unevictable 0
hierarchical_memory_limit
hierarchical_memsw_limit
total_cache
total_mapped_file
total_pgpgin
total_pgpgout
total_swap
total_inactive_anon 4218880
total_active_anon
total_inactive_file
total_active_file
total_unevictable 0
memory.stat
memory.stat包含有最丰富的
页缓存，包括 tmpfs（shmem），单位为字节
匿名和 swap 缓存，不包括 tmpfs（shmem），单位为字节
mapped_file
memory-mapped 映射的文件大小，包括 tmpfs（shmem），单位为字节
存入内存中的页数
从内存中读出的页数
swap 用量，单位为字节
active_anon
在活跃的最近最少使用（least-recently-used，LRU）列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节
inactive_anon
不活跃的 LRU 列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节
active_file
活跃 LRU 列表中的 file-backed 内存，以字节为单位
inactive_file
不活跃 LRU 列表中的 file-backed 内存，以字节为单位
unevictable
无法再生的内存，以字节为单位
hierarchical_memory_limit
包含 memory cgroup 的层级的内存限制，单位为字节
hierarchical_memsw_limit
包含 memory cgroup 的层级的内存加 swap 限制，单位为字节
active_anon + inactive_anon = anonymous memory + file cache for tmpfs + swap cache
active_file + inactive_file = cache - size of tmpfs
docker原生内存监控
再来说到docker原生的docker stats。其具体实现在libcontainer中可以看到。其将容器的内存监控分为cache,usage,swap usage,kernel usage,kernel tcp usage。
其中cache是从memory.stat中的cache中获取。
usage是使用memory.usage_in_bytes和memory.limit_in_bytes进行相除来计算使用率。这一方式有一个弊端，就是不够细化，没有区分出cache部分，不能真正反映内存使用率。因为一般来说cache是可以复用的内存部分，因此一般将其计入到可使用的部分。
可以考虑的改进计算方式
改进方式在统计内存使用量时将cache计算排除出去。类似于linux中计算real_used时将buffer和cache排除一样。
cache并不能直接应用memory.stat中的cache，因为其中包括了tmpfs，而tmpfs算是实际使用的内存部分。
tmpfs即share memory，共享内存
因为在memory.stat中存在有
active_file + inactive_file = cache - size of tmpfs
因此可以计算实际使用的内存量为
real_used = memory.usage_in_bytes - (rss + active_file + inactive_file)
感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具