我有一个与这里几乎相同的问题:Cron 作业不再起作用
但是,根据接受的答案,我似乎找不到任何与内存相关的问题,所以我认为我应该提出一个新问题,而不是回答那个问题。
版本:
uname -a
Linux __hostname__ 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
sudo systemctl --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
我的每小时 cron 作业成功执行了几个星期,但在某个时候,它们在我的两台服务器上都停止执行(它们不是同时在两台服务器上停止的)。这些作业注册在技术用户的 crontab 中,即该用户没有登录 shell。它们设置为每小时 03 分钟执行(任务是将某些日志文件导入数据库,我们为每小时日志滚动预留了 3 分钟)。
执行成功:
Nov 13 18:03:01 server02 CROND[8057]: (__tech_user__) CMD (/opt/xxx/LogImporter/start.sh &>/opt/xxx/LogImporter/import.log)
Nov 13 18:03:01 server02 CROND[8058]: (__tech_user__) CMD (/opt/yyy/LogImporter/start.sh &>/opt/yyy/LogImporter/import.log)
当时没有其他日志。一小时后执行失败:
Nov 13 19:03:01 server02 CROND[12006]: (__tech_user__) CMD (/opt/xxx/LogImporter/start.sh &>/opt/xxx/LogImporter/import.log)
Nov 13 19:03:01 server02 CROND[12007]: (__tech_user__) CMD (/opt/yyy/LogImporter/start.sh &>/opt/yyy/LogImporter/import.log)
Nov 13 19:03:01 server02 CROND[12009]: (CRON) EXEC FAILED (/usr/sbin/sendmail): Resource temporarily unavailable
Nov 13 19:03:01 server02 CROND[12008]: (CRON) EXEC FAILED (/usr/sbin/sendmail): Resource temporarily unavailable
Nov 13 19:03:01 server02 CROND[12002]: (__tech_user__) MAIL (mailed 71 bytes of output but got status 0x0001#012)
Nov 13 19:03:01 server02 CROND[12003]: (__tech_user__) MAIL (mailed 71 bytes of output but got status 0x0001#012)
注意:__tech_user__
是实际用户名的替代。
Server01 和 Server02 生成相同的错误日志,但 Server01 在同一天的 3 小时前“崩溃”了。当我手动启动相同的脚本时,它运行正常。作为参考,以下是 start.sh:
#!/bin/bash
export JAVA_HOME=/opt/xxx/Java/jdk1.8.0_221
export PATH=$JAVA_HOME/bin:$PATH
#Use lockfile to avoid simultaneous instances
exec 200>/opt/xxx/LogImporter/start.lock
flock -n 200 || exit 1
java -cp /opt/xxx/LogImporter/LogImporter.jar x.y.z.logimporter.LogImporter /opt/xxx/LogImporter/
正如我上面提到的,我没有看到任何明显的内存问题。在 Server01 上,我运行了所有内容的双实例(单独的环境),但仍然有可用内存:
top - 11:04:25 up 38 days, 22:43, 2 users, load average: 0.18, 0.25, 0.31
Tasks: 205 total, 1 running, 204 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 0.3 sy, 0.0 ni, 98.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16265944 total, 321012 free, 7956004 used, 7988928 buff/cache
KiB Swap: 4063228 total, 3924988 free, 138240 used. 7148196 avail Mem
Server02 有更多(仅限单一环境):
top - 12:01:17 up 38 days, 23:39, 3 users, load average: 0.23, 0.19, 0.21
Tasks: 199 total, 1 running, 198 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.0 us, 1.4 sy, 0.0 ni, 94.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16265944 total, 3711468 free, 5559448 used, 6995028 buff/cache
KiB Swap: 4063228 total, 3930364 free, 132864 used. 9602824 avail Mem
有趣的是,我在每台服务器上都有一个每日 cron 作业,每天 00:15 运行,它们也在同一天失败(最后一次成功运行是在 11 月 13 日 00:15,从 11 月 14 日 00:15 开始每天都失败)。我为技术用户准备的完整 crontab:
服务器01:
15 0 * * * /opt/xxx-env1/Logrotator/logrotate.sh &>/opt/xxx-env1/Logrotator/logrotate.log
15 0 * * * /opt/xxx-env2/Logrotator/logrotate.sh &>/opt/xxx-env2/Logrotator/logrotate.log
3 * * * * /opt/xxx-env1/LogImporter/start.sh &>/opt/xxx-env1/LogImporter/import.log
3 * * * * /opt/xxx-env2/LogImporter/start.sh &>/opt/xxx-env2/LogImporter/import.log
3 * * * * /opt/yyy/LogImporter/start.sh &>/opt/yyy/LogImporter/import.log
服务器02:
15 0 * * * /opt/xxx/Logrotator/logrotate.sh &>/opt/xxx/Logrotator/logrotate.log
3 * * * * /opt/xxx/LogImporter/start.sh &>/opt/xxx/LogImporter/import.log
3 * * * * /opt/yyy/LogImporter/start.sh &>/opt/yyy/LogImporter/import.log
我尝试注释掉一些作业,在每个服务器上只留下 1 个,但问题仍然存在。我还注意到,我不知道这是否是个问题,crond.service 显示 TasksCurrent 非常高:
sudo systemctl show crond.service
Type=simple
Restart=on-failure
NotifyAccess=none
RestartUSec=30s
...
MemoryCurrent=18446744073709551615
TasksCurrent=18446744073709551615
Delegate=no
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
...
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=no
TasksMax=18446744073709551615
但是,我在我的测试服务器上看到相同的数字,并且 crontab 执行正常(尽管我没有每小时的工作,只有每日的工作)。
答案1
嗯。与我提到的另一个问题类似,这是一个完全不同的应用程序。在同一台服务器上运行 Tomcat 8.5,我出于不同的原因在两台服务器上重新启动了它,并且 cron 作业再次运行……我被难住了。虽然我注意到有更多可用内存:
服务器01:
top - 14:23:35 up 39 days, 2:02, 2 users, load average: 0.26, 0.50, 0.43
Tasks: 201 total, 1 running, 200 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 2.2 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16265944 total, 1149468 free, 5950648 used, 9165828 buff/cache
KiB Swap: 4063228 total, 3926524 free, 136704 used. 9160900 avail Mem
服务器02:
top - 14:23:27 up 39 days, 2:01, 3 users, load average: 0.13, 0.25, 0.28
Tasks: 199 total, 1 running, 198 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 0.1 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16265944 total, 5178096 free, 3902808 used, 7185040 buff/cache
KiB Swap: 4063228 total, 3930364 free, 132864 used. 11246396 avail Mem
在 Tomcat 上运行的应用程序发生内存泄漏并非不可能。但我们之前就有可用内存,Server02 上有超过 3.5 G 的内存,我认为这已经足够了。