11

高負荷時にこれらのエラーのいくつかが表示されます。

mysql_connect() [<a
href='function.mysql-connect'>function.mysql-connect</a>]: [2002] Resource
temporarily unavailable (trying to connect via
unix:///var/lib/mysql/mysql.sock)

私が知る限り、mysql サーバーは最大接続数の制限に達していませんが、クエリの処理を妨げている何かがあります。MySQL は他にどのような制限に達しますか?

MySQL 5.5.21 で RHEL 6.2 64 ビットを実行しています

4

4 に答える 4

26

システムが現在 Unix ベースであると仮定しましょう (問題の説明に示されているように)。これが正しければ、次の一連の問題が発生している可能性があります。

  1. MySQL で使用できるメモリが不足しています。

    これは、直面している可能性が最も高い問題です。MySQL の接続プール内の各接続が機能するにはメモリが必要であり、このリソースが使い果たされると、それ以上接続を確立できなくなります。もちろん、これが問題であることがわかった場合は、さまざまな操作のメモリ フットプリントと最大パケット サイズを同等にmy.cnf調整できます。

    そこで役立つ追加のスレッドを次に示しますがtop、何が起こっているのかを大まかに見積もるために、より単純なプロファイリング ツールの使用を検討することもできます。

  2. MySQL ユーザー アカウントで使用できるファイル記述子が不足しています。

    もう 1 つの一般的な問題: 1,024 境界 (既定) を超えるファイル IO を必要とする要求を処理しようとすると、操作が単に失敗する場合が発生します。これは、ほとんどのシステムが、各ユーザーが一度に使用できるオープン ファイル記述子の数にソフト制限とハード制限を指定しており、このしきい値を超えると問題が発生する可能性があるためです。

    これには通常、一連の明白な兆候がログ ファイルに表示されます。比較可能なディレクトリを確認/var/log/messagesしてください (たとえば、/var/log/mysql興味深いものが見つかるかどうかを確認します。

  3. スレッドが満足できないライブロックまたはデッドロックのシナリオに遭遇しました。

    システムが処理できる計算負荷を超えた場合、メモリとファイル記述子の枯渇に伴い、スレッドがタイムアウトする可能性があります。このエラー メッセージは表示されませんが、今後注意が必要です。

  4. で使用できる PID が不足していますfork。

    別の一般的なシナリオ:fork特定の時点で使用できる PID の数が非常に多い。システムが単純にオーバーフォークした場合、リクエストを処理できなくなります。

    これを確認する最も簡単な方法は、他のサービスがマシンに接続できるかどうかを確認することです。たとえば、ボックスに SSH で接続しようとして、それができないことを発見することは、大きな手がかりになります。

  5. アップストリーム プロキシまたは接続マネージャーがリソースを使い果たし、要求の処理を停止しました。

    クライアントと MySQL の間にサービス レイヤーがある場合は、クラッシュ、ハング、またはその他の方法で不安定になっていないかどうかを調べる必要があります。上記のアドバイスが適用されます。

  6. 65,536 回の接続の後、ポート マッパーが使い果たされました。

    可能性は低いですが、繰り返しになりますが、枯渇する可能性があります。上記のように簡単なサービス接続を確認することは、ええと、ここでも最適な寄港地です。

要するに、これはサーバーが単に「ダウン」していることを含め、リソース枯渇のシナリオです。何をブロックしているのかを確認するには、システムをさらにプロファイリングする必要があります。この場合に表示されるエラー メッセージは、クライアントがリソースを利用できないという事実だけです。より適切な解決策を判断するには、サーバーに関する詳細情報を確認する必要があります。

于 2012-04-15T21:08:50.023 に答える
3

どの制限に達しているかはまだわかりませんが、なんとか問題を回避できました。MEMORY エンジンを使用するセッション テーブル (vbulletin 内) に問題がありました。このテーブルのインデックスは HASH であったため、vbulletin がこのテーブルを 1 時間に 1 回パージすると、他のクエリを保持し、mysql をそのリソースの限界までプッシュするのに十分な時間、テーブルがロックされます。

インデックスを BTREE に変更することで、MySQL はセッション テーブルから行をより迅速に削除し、以前に達した制限を回避することができました。エラーは、マスター db サーバーを MySQL 5.5 にアップグレードしたときにのみ発生したため、最新のリリースでは MEMORY テーブルの処理が異なると推測しています。

HASH For MEMORY よりも BTREE インデックスを使用することによる速度向上については、http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/を参照してください。

于 2012-04-26T02:56:14.147 に答える
2

そうねえ、これは非常に多くのことかもしれません。ソケットのバッファ スペースが使い果たされている可能性があります。入ってくるほど速く接続を受け入れておらず、バックログの制限に達している可能性がありmysqlます（「接続が拒否されました」というエラーが表示されると思いますが、それがあなたが何をするかはわかりませんUnix ドメイン ソケットを取得します)。@MrGomezが指摘したことのいずれかである可能性があります。

同じサーバー上で Apache と MySQL を実行しており、これは高負荷下での問題であるため、Apache がシステムのリソースを枯渇させており、受信接続の切断/失敗が表示されていない (気付いている?) 可能性があります。 /requests をログに記録します。

接続プーリングを使用していますか? そうでない場合は、そこから始めます。

また、mysql_connect エラーとほぼ同時に Apache ログと syslog でエラーを探し、他に何が表示されるかを確認します。特に、MySQL を独自の専用サーバーに移行することをお勧めします。

于 2012-04-19T04:47:00.217 に答える
0

私の場合、（PHP Driver）でJSONデータ型を扱っていました。1 つのアイテムを取得するためPDOに使用していましたが、クエリに追加するのを忘れていました。追加することで問題は解決しました。fetchLIMIT 1

于 2019-07-12T16:20:12.797 に答える