AWSのubuntuインスタンスで多数のウェブサーバー(nginx、php5.6-fpm)を実行しています。それらは数ヶ月間正常に動作していますが、過去数日で、インスタンスが起動した後はすべて正常であるという問題が発生し始めましたが、12時間ほど後にネットワーク呼び出しが失敗し始めます(特にこれではインスタンスソケットtcpがredisを呼び出します)。
Tcpdumpでいくつかの調査を行ったところ、udpチェックサムの失敗が原因でDNSルックアップがスローされているようです。
17:13:38.013346 IP(tos 0x0、ttl 64、id 46236、offset 0、flags [DF]、proto UDP(17)、length 103)10.0.0.121.34071> 10.0.0.2.53:[bad udp cksum 0x14df -> 0x3ae1!] 25855+ Type20736? xxxxxxxx.us-east-1.rds.amazonaws.com。 (75)
Telnetを使用して同じインスタンスからRedisサーバーに接続する場合は問題ありませんが、fpmにのみ影響するようです。同様に奇妙なことに、インスタンスが開始されてから少しの間だけ発生します。最初はすべての要求が正常に処理されます。同様に、php5.6-fpmサービスを再起動すると、しばらくの間問題が解決するようです。
私はこの時点でほとんど知識の終わりにいるので、誰かが私を正しい方向に向けることができれば幸いです!
欠陥のあるセキュリティ修正プログラムがインストールされています-これは SN-3239-2 の問題のようです。
GNU libcのセキュリティアップデート(とりわけ)...
GNU Cライブラリの
getaddrinfo()
関数での無制限のスタック割り当て。
....あなたが説明したのと同様の問題を引き起こしたと思われるリグレッション(意図しないABIの変更)が含まれていました...プロセスが再起動されるまで、DNS解決は最終的に機能しなくなります。
元の更新はリリース2017-03-20で、修正は2017-03-21にリリースされました。最新のOSセキュリティ修正を適用すると、問題が解決するはずです。
不良チェックサムは チェックサムオフロード が原因である可能性があります。
それが当てはまるかどうかを確認します。これは、次のコマンドを実行することで実行できます。
Sudo ethtool --show-offload ethX
パケットのcontentについてtcpdumpが何を言っているかをもう少し掘り下げる価値があるかもしれませんが、特に、ある種のレートに達していないのではないかと思います。制限。 NXDOMAIN
などのリターンパケットを確認することをお勧めします。
それが問題だった場合は、何らかのキャッシングリゾルバーがあると役立つ場合があります。
updated以下のコメントを説明します:
サービス自体を再起動することで問題が「修正」される場合(追加情報をありがとう@ Liam Wiltshire )、レート制限が正しく聞こえないことに同意します(または、少なくとも、アップストリームはしません)。
ローカルリソースによるレート制限は、検討する価値のある可能性があると思います。たとえば、conntrackエントリの制限がないこと、またはulimit
されたオープンファイル(つまり、nofiles
が低い)を確認します。
そうは言っても、悪いセキュリティパッチ/悪いソフトウェアリードはかなり有望に見えるので、@ Michael --sqlbot の提案に間違いなく重みを与えます(そしてポイントを与えました)。