我们运行带有多个站点（每个都有自己的域或子域）的apache2服务器，使用SSL（同一IP上也有多个证书，但主要是子域的星号证书）。 现在我们遇到一个问题，那就是当每个服务器有超过20-30个独立的站点时，重启需要20多秒。
日志不显示任何东西，我不知道如何确定需要很长时间才能重新启动。 这可能是连接 – 运行apache2ctl -S也需要大致相同的时间量（当我运行一个接一个的重启或者一个接一个的时候，如果我等了一分钟左右， apache2ctl -S快又慢）。
我怎么能解决这个问题？ 如何确定导致这些重启速度缓慢的原因（我们需要重新启动，当我们添加新的网站，并慢慢变得难以pipe理）。
– 更新 –
所以，毕竟这是一个问题。
有一些变化可能使我指向一个正确的方向：
其中一台服务器突然开始像我期望的那样快速工作。 不知道为什么发生，因为我不能确定这是什么时候发生的。 我比较了Apache的configuration，在所有的服务器上它们几乎完全相同，但是一个现在很快重启，另外两个仍然很慢（> 2分钟）。
现在，就在最近，当解决其他问题时，我遇到了一些有关ipv6设置减缓某些证书发行等的意见。我testing了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时超时？
我也想出了以下 – 它一直在closures。 如果我closuresApache，然后尝试启动，启动速度很快。
回答以前的问题：
密码被优化（所有网站获得A在ssltesting）。 交通不是很好。 这是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
请指教…
重启httpd时使用strace： http : //man7.org/linux/man-pages/man1/strace.1.html
它应该告诉你在等待期间这个过程正在做什么，所以它可能会给你一个更好的线索，看看原因是什么。
IPv4 / IPv6线索回避了Bug 459756中的glibc问题- DNSparsing器库似乎没有可靠的工作
（也RH知识库DOC-58626，我没有访问）
简而言之，RHEL6（和Fedora，Centos，Arch）正在执行并行的IPv6和IPv4 DNSparsing和不可预测的结果，因为IPv6部署有时不太可靠。
可能的解决方法是：
其他人已经提出了strace，但没有填充最有用的参数来开始给你的问题，或者给出一个更好的框架来使用你的shell历史来重新唤起它一遍又一遍…这是一个很常见的用例。 ;）
这个过程可能看起来过多，但是我喜欢尽可能地把所有的数据都捕捉到，而不是反复弄清楚我错过了一些东西，因为我试图太快以至于得不到答案。
我总是这样（这个例子是一个守护进程称为“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/
应该告诉你最有趣的文件来检查。 寻找明显的系统错误，或时间差距大或超时。 玩的开心！ 🙂