SSLを使用したApache2の再起動が遅い
SSL（同じIP上の複数の証明書ですが、ほとんどの場合サブドメインのアスタリスク証明書）を使用して、複数のサイト（それぞれに独自のドメインまたはサブドメインがあります）でApache2サーバーを実行します。現在、サーバーごとに20〜30を超える個別のサイトがある場合、再起動に20秒以上かかるという問題が発生しています。
ログには何も表示されず、再起動にこれほど時間がかかるものを理解する方法がわかりません。これは接続されている可能性があります-_Apache2ctl -S_の実行にもほぼ同じ時間がかかります（再起動を次々に実行するか、-Sを次々に実行すると、1分ほど待つと、1秒未満の高速になります）。
この問題をトラブルシューティングするにはどうすればよいですか？これらの遅い再起動の原因を特定する方法（新しいサイトを追加し、ゆっくりと管理できなくなったときに再起動する必要があります）。
-更新-
ですから、この間ずっと、これはまだ問題です。
私を正しい方向に向ける可能性のあるいくつかの変更がありました：
サーバーの1つが突然、私が期待するほど速く動作し始めました。正確にいつ起こったのか正確に特定できないので、なぜそれが起こったのかわかりません。 Apacheの構成を比較したところ、すべてのサーバーでほぼ同じですが、1つは高速で再起動し、他の2つはまだ低速です（> 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]
_つまり、apacheを再起動しようとすると、タイムアウトが発生する可能性のあるipv6に問題があるように見えますか？
また、次のことも理解しました。シャットダウンには常に時間がかかります。 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
_お知らせ下さい...
Httpdを再起動するときにstraceを使用します： http://man7.org/linux/man-pages/man1/strace.1.html
プロセスが待機期間中に何をしているかを教えてくれるはずなので、原因が何であるかについてのより良い手がかりを与えるかもしれません。
IPv4/IPv6の手がかりは、 Bug 459756-DNSリゾルバーライブラリが確実に機能していないようです のglibcの問題を思い出させます。
（RHナレッジベースDOC-58626も、アクセスできません）
つまり、RHEL6（およびFedora、Centos、Arch）は、IPv6とIPv4のDNS解決を並行して実行しており、IPv6の展開の信頼性が低い場合があるため、予測できない結果が生じていました。
考えられる回避策は次のとおりです。
- 「optionssingle-request-reopen」を/ etc/resolve.confに追加します。これにより、A要求とAAAA要求はsockestを共有するように強制されます。 resolv.confのmanページはこちら
- [nscd]（またはdnsmasq、含まれていません）のようなローカルキャッシュネームサーバーを実行します
他の人はstraceを提案しましたが、あなたの問題を考えると、またはシェル履歴を使用して何度もそれを再起動するためのより良いフレームワークを与えて、それを始めるための最も有用な引数を記入していません...これは非常に一般的なユースケースです。 ;）
このプロセスは過度に思えるかもしれませんが、答えを得るのに速すぎて何かを見逃したことを繰り返し把握するのではなく、可能な場合は最初にデータをキャプチャするためにあらゆることを行います。
私はいつもこのようなもので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
次に、/ tmp /にcdします。大量の「strace。*」ファイルがあるかもしれませんが、実際には最近触れたものだけに興味があるでしょう。だから、
ls -latr /tmp/
検査する最も興味深いファイルを教えてくれるはずです。明らかなシステムエラー、時間の大きなギャップ、またはタイムアウトを探します。楽しんで！ :)