记录------线上问题的排查和解决，docker内存扩容

问题描述：2023年0920 ，客户反馈系统无法生成排班数据（排班就是远程的调度服务定时调用系统的接口生成一批数据），反馈到我领导处，本来不属于我去排查的，由于另一位同事在忙其他事情，无法从中抽身出来。到我接手时，我时完全没有接触过此项目和服务器的。接到此问题时，我首先是去和负责过的同事对接了解具体的情况主要针对这几个问题：
问题一：现在是有什么问题？（带着问题去了解是比较好的，习惯这么问了）
问题就是本来可以生成排班信息的，现在生成不了了
问题二：最近改过这个模块吗？
没有改过

问完我最想问的问题，我就去找到代码和服务器数据库
开始查找数据，使用最傻的一个sql一个sql的去看，结合日志信息。

遇到的第一个困难就是找不到docker容器的日志信息。
后面经过不断的百度和实验终于找到办法
使用命令

docker inspect container_id |grep log

这个命令可以查看你容器挂载主机上的日志文件信息。

找到日志文件信息后根据代码结合日志的办法查询
最后发现当执行自动生成业务逻辑的时候，系统会自己自动重启
执行了一个for循环查询数据的业务逻辑，查询次数大概有2500左右

执行过程中服务居然死了又重启，服务器一直在重复这个步骤，由此怀疑大概率是某种原因导致服务挂了，然后docker一直在重启spring应用。我就根据这个思路去百度查询。
然后看到了一篇文章说内存泄漏可能导致进程直接kill掉，从而导致服务重启
文章描述为：

由此启发，我怀疑是内存问题导致应用kill了。
因此上网找查看此容器的内存利用率的命令
通过docker stats 即可查看所有的容器，后面加容器id可查看某个容器的内存和cpu的使用率。
查看发现这个应用服务的内存只有2.4G（2468M）然后使用率到达了95%，CPU使用率1.5%，由此可见是内存的问题导致应用kill了

查看利用率只需要查看这个参数即可。
由此看来，结合我的使用体验来说，登入进入系统的时候也非常的卡，查询某个页面经常超时，更加断定是内存的问题，最后给对应的docker容器进行扩容。
设置容器大小可以在启动容器时指定
参考此文章：https://blog.youkuaiyun.com/m0_61415495/article/details/130265509
也可以在容器运行时修改其大小。
后面修改内存大小后应用的响应速度提高了不少。定时任务还得第二天看看是否正常。