docker容器的内存问题排查（“内存丢失”）

容器内可用内存远没有达到cgroup限制，就已经OOM(Out Of Memory Killer)。容器套餐4c8g，top看占内存最多的进程大约17m左右，总共100个，总内存也不到2g，但是memoryusage_in_bytes已经达到8g（free看也是一样），cache也只有几百兆，久而久之，cache所占内存也被耗尽，容器内进程oom，实际可用内存不到1g。在这记录下问题排查过程。

由于达到oom的现场已经不在，现在使用下面的场景进行演示：

容器套餐4c8g，working_set内存68g（容器内一般用working_set来评内存使用情况，working_set=rss+活跃的cache），rss600m，cache17g，业务进程使用2g。目前working_set远小于rss+cache。

发现使用内存最多的php-fpm 进程用了17M，129个进程，一共使用内存21g。内存使用了74g、未使用450M、cache17g（我们使用了lxcfs做容器视图隔离，所以内存显示的是容器的真实情况），还有5g左右内存去哪了

2、进到内存容器cgroup

确实是7g多

没有占用内存特别大的项，也就是远没达到top所见。另外忘记说，上边单位都是字节

果然是5g

可以看出关于文件元数据缓存就占了4g多，上图第三列是对象数量，第四列是对象大小，所以xfs_inode占用内存=3959772 960 /1024/1024/1024,约等于35g，xfs_ili 07g，这已经4g多了。所以基本可以断定是业务进程 *** 作文件多过导致

可见session文件数与slab中的xfs_inode基本相当，所以可以断定罪魁祸首在此

经过与业务沟通，他们清理的大量session文件后，slab内存明显降下来了。

>

安装:

yum -y install vixie-cron

yum -y install crontabs

启动:

/sbin/crond

配置:

crontab -u root -e

(-u 指定用户,相当于添加/etc/crontab记录时指定的用户, /etc/crontab为系统级别,crontab为当前用户)

添加记录,比如, 每5分钟执行一次,使用文件锁:

/5 flock -xn /tmp/get-tenderlock /usr/bin/php /var/> 原因请参考:>

网络问题。JAR（JavaArchive）是Java的归档文件docker无法运行，是网络问题。网络是由若干节点和连接这些节点的链路构成，表示诸多对象及其相互联系。网络是信息传输、接收、共享的虚拟平台。

以上就是关于docker容器的内存问题排查（“内存丢失”）全部的内容，包括:docker容器的内存问题排查（“内存丢失”）、如何解决docker宿主机无法访问容器中的服务、docker容器下crontab使用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！