最近我们有一个 apache 服务器，由于 SYN 泛滥，它的响应非常缓慢。解决方法是启用 tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf)。
如果您想要更多背景知识，我在这里发布了一个关于此的问题。
启用 syncookies 后，我们开始大约每 60 秒在 /var/log/messages 中看到以下消息：
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic 告诉我，这意味着 syn backlog 已满，所以我将 tcp_max_syn_backlog 提高到 4096。在某些时候，我还通过发出sysctl -w net.ipv4.tcp_synack_retries=3. 这样做之后，频率似乎下降了，消息的间隔在大约 60 到 180 秒之间变化。
接下来我发出了sysctl -w net.ipv4.tcp_max_syn_backlog=65536，但仍然在日志中收到消息。
在所有这一切中，我一直在观察处于 SYN_RECV 状态的连接数（通过运行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'），它永远不会高于大约 240，远低于积压的大小。但是我有一个 Red Hat 服务器，它在 512 左右徘徊（此服务器的限制是默认值 1024）。
是否有任何其他 tcp 设置会限制积压的大小，或者我是否在咆哮错误的树？SYN_RECV 连接的数量是否应该netstat -tuna与积压的大小相关？
尽我所能，我正在处理这里的合法连接， …
我们有一个在 Debian etch (!) 上运行 MySQL 5.0 的数据库服务器，并决定是时候升级了。它现在在 Debian 挤压上运行 5.1。
该数据库服务器在 SATA RAID 阵列上有大约 1.2TB 的 MyISAM 数据和 2GB 的内存。通常速度不是这个服务器运行的查询的一个因素，它主要是后台的东西。
升级时，Debian 软件包运行维护脚本来升级表，但升级每个表需要很长时间。长，我的意思是每张桌子大约需要 18 个小时，而按照目前的速度，做很多事情大约需要 6 周。这是一个相当大的问题。
我试过将全局 key_buffer 增加到 512MB，这似乎符合建议，但没有效果。
问题似乎是它使用了“Repair with keycache”方法，这比 sort 方法慢得多：
mysql> show processlist;
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| 5 | debian-sys-maint | localhost | xxxxxxxxxxxxxxxx | Query | 45146 | Repair with keycache | REPAIR TABLE `xxxxxxxxxxxxxxxx`.`xxxxxxxxxxxxxxxxxxxx`
由于需要升级，其他表无法访问：
mysql> …我有两个单元，nginx.service 和 certbot.service，由它们各自的 Debian 软件包提供：
nginx.服务：
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed
[Install]
WantedBy=multi-user.target
certbot.服务：
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true
还有一个计时器 certbot.timer （也由 certbot deb 包提供）：
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00 …我有两个运行 Debian 5 稳定版的 Dell R410 Web 服务器（2 个四核 Xeon E5520 w/ 8gb ram）。他们的修补程序已经被忽视了一段时间，所以最近我们进行了一次修补程序以更新所有内容 - 它运行的应用程序的新版本需要 PHP 5.3.6。内核没有更新，因为它来自 Debian backports 存储库（安装的版本是 2.6.30-bpo.1-amd64）。
自打补丁以来，用户抱怨网站速度缓慢。大多数请求是立即提供的，但它会一次又一次地“卡住”请求。卡住的请求中似乎没有任何可辨别的模式。
这些服务器位于负载平衡器之后，它们同时更新，并且在运行修补程序时都开始出现此问题。他们当时没有重新启动，但从那以后就没有任何效果。
我在服务器上设置了一个脚本来循环time curl localhost:80/alive，其中有一个简单的 index.html 文件，其中只包含“OK”。奇怪的是，这些请求仍然以与实际 php 内容请求相同的频率和持续时间延迟。常见的时间有3秒、9秒、25秒、45秒，有的超过3分钟。45 秒是常见的响应时间，但当然浏览器早在此之前就放弃了，因此实际上没有响应。
apache worker 配置如下：
<IfModule mpm_prefork_module>
StartServers 50
MinSpareServers 10
MaxSpareServers 150
ServerLimit 500
MaxClients 500
MaxRequestsPerChild 5000
</IfModule>
对于具有 8GB 内存的服务器来说，这对我来说似乎是明智的。在实践中，worker 数量很少超过 170，所以我们没有达到这个限制并且有足够的空闲内存。平均负载低，徘徊在 0.5-1.5 左右
内核是一个旧的 backport，所以我尝试将它更新到 lenny 的最新 backport (2.6.32-bpo.5-amd64)，但它在启动时出现恐慌，我不得不让我们的主机用旧的重新启动它，所以在我们尝试更新他们的 bioses 并使用 Debian 6 格式化它们之前，我想探索其他选项。
Apache 似乎是罪魁祸首，所以下一步是更新到最新的 apache 向后移植，但该版本从 2.2.9-10+lenny4 到 2.2.9-10+lenny9 是一个相当小的颠簸，所以我没有t 预计会有任何重大变化。
PHP …