ここで何が起こったのかを必死に理解しようとしましたが、この特定の問題はどこにも見られませんでした。私はデータベースサーバー（リモート、データウェアハウス内、sshによってアクセスされる）の管理を「継承」しました（データクローラーとして機能するLinuxサーバー上でいくつかのphpデーモンが実行され、挿入mysqlへの比較的安定したストリームで情報を処理します。
数日前、サーバーがクラッシュし、再び起動しました。再起動したmysqlサーバーとクローラーにログインし、それ以上考えませんでした。1 日半後、mysql サーバーが動作を停止し、ログインできなかったため診断できず、「/etc/init.d/mysql stop」またはその種類に応答しませんでした。ログ ファイルによると、非常に定期的に (4 分 16 秒に 1 回) エラーをスローし続け、開いているファイル ハンドラーが多すぎると述べています。ただし、クローラーをシャットダウンすると、再度ログインできましたが、mysql はエラーをスローし続けました。lsof を確認したところ、「プロトコルを識別できません」というエラーが表示された多くのオープン ソケットが表示されました。
mysqld 28843 mysql 1990u sock 0,4 2856488 プロトコルを識別できません
mysqld 28843 mysql 1989u sock 0,4 2857220 プロトコルを識別できません
^数千行
クローラーがやったことだと思い、mysqlを再起動したところ、失敗したソケットが消えました。しかし、クローラーが実行されていないときでも、mysql が新しいものを開き続けていることに驚きました。これは非常に定期的に行われ、クローラーがアクティブかどうかに関係なく、1 分間に約 2 つの新しいソケットが失敗しました。mysql が時間を稼ぐために許可されるファイル ハンドラの最大量を増やしましたが、明らかに診断と恒久的な解決策を探しています。
私がフォーラムで見つけたそのようなエラー (ソケット リーク) のすべての説明は、ソケットを閉じているのではなく、独自のソフトウェア リークに関するものであるようです。しかし、これはそれを行うmysql自体のようであり、サーバーがクラッシュして再起動しただけで、正常に機能したときからコードに変更はありません。
何か案は？