共享服务器上的用户 cron 作业同时运行并陷入争用的情况相当常见（据我所知）。因此负载爆炸，Nagios 发怒，Apache 停止响应，您无法通过 SSH 登录，因为它超时了，等等。我无法单方面决定用户不能运行 cron，但我想解决 pgrep crond|wc -l 返回 >50 的问题。
似乎应该可以通过限制在任何给定时间运行的 crond 进程的数量或类似操作来错开它们（比如发送 SIGSTOP 直到其中一些清除，只会减少黑客攻击），但我还没有找到任何好的线索。
硬件：4 CPU 及以上，低端是配备~8GB 内存的 Dell 1435s，RAID 10 WD EADS，主要是 Plesk 和 cPanel，但也有一些邪恶的 Sphera 系统。
你是如何解决这个问题的，sf？
答案1
您可以使用cron.allow和cron.deny来限制用户对 cron 的访问，或者您可以使用PAM 限制限制 CPU 使用率、进程数等。除此之外，解决方案是创建一些东西来监控和处理cron用户的任务，因为 cron 实际上对要运行的任务数没有限制。
我认为 CPanel 与同时运行的 cron 作业数量有关，但它是一个特定的工具（不确定）。
答案2
我认为您遇到了其中一个问题：
内存不足，无法同时运行 crontab。您可以通过以下方法修复：
- 添加更多 RAM
- 限制用户可以分配的最大内存
- 重新安排作业以降低并发作业的数量 - 您可能需要替换 crond 并使用其他调度程序
高 I/O。您可以通过以下方法修复：
- 降低 I/O 优先级
ionice - 重新安排作业以降低并发作业的数量
- 降低 I/O 优先级
尝试找出机器是否正在进行交换，如果夜间没有进行交换，则将 cron I/O 优先级类更改为空闲：
sudo ionice -c 3 -p $(pgrep cron)
答案3
我总是在随机时间（特别是几分钟）安排 cronjobs。我经常看到在午夜运行的 cron 示例，例如：
0 0 * * * /usr/bin/echo "Job ran"
如果您定义了很多这样的作业，那您就是在自找麻烦。不幸的是，这些作业通常是长时间运行的系统作业。我还倾向于在整个批处理窗口的不同时间安排作业。（23 至 05）小时。
我喜欢 Ubuntu 上使用的新的 cron 规范。它有几个/etc/cron.*目录来指定要运行的作业。它们按顺序运行，而不是并行运行以限制负载。
您应该能够看到位于 中的文件中安排了什么/etc/spool/cron/crontabs。读取这些文件需要 root 权限。如果是用户导致问题，请与他们讨论该问题。
您还可以检查/var/log/syslogCRON 条目来查看何时运行什么。