我们运行 apache2 服务器，该服务器有多个站点（每个站点都有自己的域或子域），使用 SSL（同一 IP 上也有多个证书，但子域大多使用星号证书）。现在我们遇到一个问题，当每台服务器有超过 20-30 个独立站点时，重新启动需要 20 秒以上。
日志没有显示任何内容，我不确定如何找出重新启动需要这么长时间的原因。这可能是有关联的 - 运行apache2ctl -S也需要大致相同的时间（当我一次又一次地运行重新启动或一次又一次地运行 -S 时，它很快 <1s，如果我等一分钟左右，它又会变慢）。
我该如何解决这个问题？如何确定导致重启缓慢的原因（我们在添加新站点时需要重启，但这种情况逐渐变得难以管理）。
- 更新 -
所以，经过这么长时间，这仍然是一个问题。
有一些变化可能会为我指明正确的方向：
其中一台服务器突然开始像我预期的那样快速运行。不确定为什么会发生这种情况，因为我无法确定具体发生的时间。我比较了 Apache 配置，它们在所有服务器上几乎完全相同，但现在一台服务器重新启动很快，其他两台仍然很慢（>2 分钟）。
现在，就在最近对其他问题进行故障排除时，我看到一些关于 IPv6 设置减慢某些证书颁发速度等的评论。我已经测试了 IPv6 连接，我发现的唯一差异是，在一台快速服务器上尝试这个：
wget -6 https://google.com/
我明白了：
--2017-06-09 07:49:32-- https://google.com/ Resolving google.com (google.com)... 2a00:1450:4009:809::200e Connecting to google.com (google.com)|2a00:1450:4009:809::200e|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYfhKSPR5hfHhPY5mBEsMgNyY24 [following] --2017-06-09 07:49:33-- https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYfhKSPR5hfHhPY5mBEsMgNyY24 Resolving ipv6.google.com (ipv6.google.com)... 2a00:1450:401b:802::200e Connecting to ipv6.google.com (ipv6.google.com)|2a00:1450:401b:802::200e|:443... connected. HTTP request sent, awaiting response... 503 Service Unavailable 2017-06-09 07:49:33 ERROR 503: Service Unavailable.
而在速度较慢的服务器上，相同请求会产生以下结果：
--2017-06-09 07:50:37-- https://google.com/
Resolving google.com (google.com)... 2404:6800:4003:802::200e
Connecting to google.com (google.com)|2404:6800:4003:802::200e|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.google.com/ [following]
--2017-06-09 07:50:37-- https://www.google.com/
Resolving www.google.com (www.google.com)... 2404:6800:4001:80b::2004
Connecting to www.google.com (www.google.com)|2404:6800:4001:80b::2004|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'
[ <=> ] 10,382 --.-K/s in 0.001s
2017-06-09 07:50:37 (18.4 MB/s) - 'index.html' saved [10382]
换句话说，ipv6 似乎存在一些问题，可能会导致尝试重新启动 apache 时超时？
我还发现了以下问题 - 它的关闭需要很长时间。如果我关闭 Apache，然后尝试启动它，启动速度会很快。
回答前面的问题：
密码已优化（所有网站在 SSL 测试中均获得 A）。流量不是很大。以下是 2 分钟重启前的服务器状态转储：
Apache Server Status for s3.example.com (via 0.0.0.0)
Server Version: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.21 OpenSSL/1.0.1f
Server MPM: prefork
Server Built: May 9 2017 16:14:10
Current Time: Friday, 09-Jun-2017 08:05:46 UTC
Restart Time: Friday, 09-Jun-2017 07:57:35 UTC
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 8 minutes 10 seconds
Server load: 0.00 0.00 0.00
Total accesses: 15 - Total Traffic: 23 kB
CPU Usage: u0 s0 cu0 cs0
.0306 requests/sec - 48 B/second - 1570 B/request
1 requests currently being processed, 7 idle workers
____W___........................................................
................................................................
......................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 11047 0/2/2 _ 0.00 456 0 0.0 0.00 0.00 77.0.0.0 s3.example.com:80 NULL
2-0 11049 0/3/3 _ 0.00 219 0 0.0 0.00 0.00 127.0.0.1 s3.example.com:80 GET /server-status?auto HTTP/1.1
4-0 11051 0/7/7 W 0.00 0 0 0.0 0.01 0.01 77.0.0.0 s3.example.com:443 GET /server-status HTTP/1.1
6-0 11166 0/2/2 _ 0.00 35 0 0.0 0.00 0.00 127.0.0.1 s3.example.com:443 \x16\x03\x01
7-0 11167 0/1/1 _ 0.00 333 1 0.0 0.00 0.00 77.0.0.0 s3.example.com:443 NULL
Srv Child Server number - generation
PID OS process ID
Acc Number of accesses this connection / this child / this slot
M Mode of operation
CPU CPU usage, number of seconds
SS Seconds since beginning of most recent request
Req Milliseconds required to process most recent request
Conn Kilobytes transferred this connection
Child Megabytes transferred this child
Slot Total megabytes transferred this slot
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 0
subcaches: 32, indexes per subcache: 88
index usage: 0%, cache usage: 0%
total entries stored since starting: 0
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 0
total retrieves since starting: 0 hit, 1 miss
total removes since starting: 0 hit, 0 miss
Apache/2.4.7 (Ubuntu) Server at s3.example.com Port 443
请指教...
答案1
重新启动 httpd 时使用 strace：http://man7.org/linux/man-pages/man1/strace.1.html
它应该告诉您在等待期间该过程正在执行什么，因此它可能为您提供有关原因的更好的线索。
答案2
IPv4/IPv6 线索让我想起了Bug 459756 - DNS 解析器库似乎无法可靠运行
（还有 RH 知识库 DOC-58626，我无权访问）
简而言之，RHEL6（以及 Fedora、Centos、Arch）正在执行并行 IPv6 和 IPv4 DNS 解析，结果不可预测，因为 IPv6 部署有时不太可靠。
可能的解决方法是：
- 添加“选项单一请求重新打开”到/etc/resolv.conf。这将强制 A 和 AAAA 请求共享一个套接字。 resolv.conf 手册页在这里
- 运行本地缓存名称服务器，如 [nscd]（或 dnsmasq，不包括） 3
答案3
其他人建议使用 strace，但是考虑到您的问题，并没有填写最有用的参数来启动它，或者没有提供一个更好的框架来使用您的 shell 历史记录一遍又一遍地重新调用它......这是一个相当常见的用例。;)
这个过程可能看起来有些过度，但我喜欢在可能的情况下尽一切努力首先捕获我的数据，而不是因为我试图快速获得答案而反复发现我错过了什么。
我总是用类似这样的方法进行 strace（此示例针对名为“httpd”的守护进程，请根据需要进行调整）：
daemon="httpd"; rm /tmp/strace.* ; service $daemon restart ; (strace -v -a 40 -f -ff -tt -yy -s 128000 -o /tmp/strace -p "`pidof $daemon`" & ) && sleep 1 && service $daemon restart
然后，cd 到 /tmp/。你可能有大量的“strace.*”文件，但你实际上可能只对最近接触的文件感兴趣。因此，
ls -latr /tmp/
应该会告诉您最值得检查的文件。查找明显的系统错误、较大的时间间隔或超时。玩得开心！:)