症状：
- 服务器无响应 - 负载增加，所有服务停止
- 连接丢失 - Ping/SSH
- 重启后刷新 MySQL 主机 - 因为 MySQL 拒绝新连接
- Apache 间歇性崩溃
- 通常发生在清晨 - 但一周中有 2 天除外
所做的更改：
- 更新操作系统 - 至 Ubuntu 10.04.4 LTS
- 不确定 MySQL 服务器是否也在此过程中进行了更新
- 当前 MySQL 版本 - mysql Ver 14.14 Distrib 5.1.63，适用于 debian-linux-gnu (x86_64)，使用 readline 6.1
- 将 Plesk 从 10.4.4 更新 #47 更新至 11.0.9 更新 #23
- 几乎每天都重启
- 所有 cron 在服务器崩溃时停止
- 创建 MySQL 日志来监控查询的锁定时间
可能的原因：
- 硬件故障
- 软件配置不正确（MySQL、Apache 等）
职责：
- 小型网络服务器
- 运行我们的计费系统 - WHMCS
- 负责 CRON
- 批量电子邮件解决方案 - 没有送达时间与服务器崩溃相吻合
建议的解决方案：
- 将机器移至 VM
- 格式化并恢复 Plesk 服务器备份并从那里获取？
附注：
- 似乎是我们所有 Linux 服务器的 Apache 普遍故障 - 间歇性问题
- 我们是否在 Apache 配置中做了一些根本性的错误？（我知道这是一个次要问题，只是想确保它不可能具有任何相关性）
答案1
我从来不用 prtg，但如果我没看错，你的内存已经用完了。你的服务器问题持续了大约凌晨 1 点到凌晨 2-3 点，即使没有完全崩溃。虽然问题似乎是从 12 点开始的。你的服务器负载就在那一刻猛增。
在那段时间里：
- 图表内存（交换）可用 2，交换使用量增加到 6G-7G，与 1G 的物理内存相比，这很多
- 图表内存（真实）可用 2/SNMP Linux Meminfo 2，所有内存都已使用
虽然内存似乎是主要原因。但也可能（或部分问题）是由 CPU 功率不足引起的。由于上一个请求仍在处理，新的请求进来，越来越多的请求堆积在服务器上。
我建议增加内存，并找出凌晨 12 点正在运行的内容。
答案2
听起来你需要对根本原因做一些真正的分析。
- 配置和监控 apache服务器状态了解网络服务器负载。
- 设置系统监控基本指标（CPU、内存、磁盘活动），以查看瓶颈究竟在哪里
- 在重新启动时和正常运行期间密切监控
dmesg，以验证没有明显的硬件问题。
一旦您获得了几天的可靠数据，您就可以采取下一步行动（您现在认为正在采取的行动 - 寻求建议。）
答案3
99.9% 的时间，在像您这样的设置中，mysql 的配置错误，因为机器太小，无法处理分配的连接数量。一个非常平均的mysql 的设置将连接限制设置为 200，每个传入的连接通常占用 10 到 100mb，具体取决于查询/缓存等。
我见过许多公司将连接限制设置为超出实际机器的最大内存（根据其配置方式）。当 MySQL 尝试寻址内存并被分配到交换区时，会导致系统崩溃。您通常可以在 dmesg 中看到跟踪。
发布您的 MySQL 配置 + CPU/VCPU 数量和内存，很可能是 MySQL 配置不正确。mysql 的文档很难理解，但有一些帮助脚本可以为您提供一些思路。我会尝试找到我过去使用过的最准确的脚本之一，不幸的是我记不起脚本名称了。
还要记住，查看 mysql 日志不会向您展示真实情况。