docker给容器分配内存

---

一、docker容器的内存问题排查（“内存丢失”）容器内的可用内存远远未达到组限制，出现OOM（OutOfMemoryKiller）。包装内含4c8g。顶部工序约需17m衰弱。总共有100个进程。缓存只有几兆字节。随着时间的推移，占用的内存单元也被耗尽，容器内的处理器oom，可用内存不足1g。注意这里的发酵过程。
由于已经不再有实现OOM的阶段，所以使用以下任务进行演示：
容器包4c8g，working_set内存6.8g（working_set通常用于评估内存使用情况。container，working_set=rss+activecache），rss600m，cache1.7g，企业主郑程用的是2g。目前working_set比rss+cache小很多。
发现使用内存最多的php-fpm进程为17M，129个进程，总共使用了2.1g内存。使用的内存为7.4g，未使用450M，缓存1.7g（隔离视图容器我们使用lxcfs，因此内存显示了容器的真实位置），剩余的5g内存在哪里？
2.包含cgroup的内存
确实是7g多
没有哪一项占用内存特别大，就是离顶部很远。另外，我提到上面的单位都是字节
，是5g
可以看出元数据缓存文件超过4g，上面第三列图片是对象大小，第四列是对象的大小，所以占用内存xfs_inode=3959772*960/1024/1024/1024，也就是大约=3.5g，xfs_ili0.7g，也就是已经4g多了。因此，基本上可以断定业务流程处理的文件过多。罪魁祸首就在眼前
通过这个过程并与他们分担Post任务，大量的session文件被清除，内存表也被明显减少。

---

二、【Docker】KylinV10下MySQL容器内存占用异常的解决方法[Docker]KylinV10MySQL容器内存使用异常的解决方案
KylinV10MySQL容器中，启动时内存使用率极高，无业务运行时内存使用率异常参数设置open_files_limit超过16GB。经过一系列的排查和努力，问题的根本原因在于open_files_limit参数的值与默认值相差较大。该参数控制MySQL同时打开的文件数量，直接占用内存。
早期，尽管查看了内存分配和调整了内存参数，但没有发现明显的内存泄漏。查阅资料后尝试将MySQL参数与默认值进行比较并调整参数值，但内存占用并没有改善。最后与正常的系统配置进行对比，发现open_files_limit参数是问题的关键。由于KylinV10可能存在兼容性问题，容器启动时open_files_limit会重置为异常值。
为了解决这个问题，我修改了脚本，在启动MySQL服务之前将openfiles参数设置为特定值，然后重新构建MySQL镜像。这样可以保证open_files_limit设置正确，从而解决内存使用异常的问题
虽然解决过程比较耗时，从周五晚上一直到周六凌晨，通过这次经历，我不仅解决了工作中的问题，还拓展了我对MySQL的认识以及相关的知识。它。这再次证明，面对问题时，总能找到合适的解决方案。