mysqlカードはほとんどのスレッドが長い間sending dataの状態にあります。

サーバーがあります。アクセス量はとても大きくて、毎日250 wぐらいダイナミックなpvがあります。データベースの検索は平均毎秒600回近くの別のサーバーです。走るプログラムはこれと同じです。でも、毎日約40 wダイナミックなpvの前の時間に何回も連続してカードで死んだことがあります。その時の状態はサーバーが崩壊していないので、データベースは正常に登録できます。ただし、すべての検索カードは「sending data」の状態で、長い間実行できません。これらの簡単なsql文は、時々A表に集中して、B表に集中しています。同時に、いくつかのカードがロック状態やudate状態でmysqlを見ています。sending dataの状態は二つの状況を表しています。一つはmysqlはすでにデータを調べて、クライアントに送っています。もう一つは、mysqlはデータをどこで読み込むべきかをすでに知っています。データファイルからmysqlの公式ページを読み込んでいます。これはmysqlのバグではないですが、公式ではどのように処理するかは分かりません。まずsql最適化の観点から調べてみました。カードの死したsql文は全部簡単な検索で、消耗が非常に低く、インデックスが非常に良いので、sql文の問題ではないと思います。そして、遅い検索ログにも遅く調べられませんでした。表を最適化しました。つまりoptimize tableです。数日後に発見されますが、やはりカードが死ぬ場合があります。その後、併発性能を増やしたいと考えて、key_を増やしました。buffer thread_cacheなど一連のメモリ配置は、あまり効果がないことを発見しました。状況はまた後にして、query_を。cacheはデフォルトの16 Mまで減少し、あまり変動しないデータを静的にしました。驚いたことに、12日間が過ぎました。もう問題はありませんでした。cacheはこの問題に役に立つかもしれません。データの更新が頻繁ですから、query_cacheの更新も頻繁です。でもmysqlの状態を見て、query_cacheの命中率はかなり高くて、75%ぐらいです。問題はプログラムに出るかもしれないと思いますが、調べられませんでした。その後、静的になったのは製品の説明文で、一つの製品の説明は三、五十の漢字だけです。ここで問題が発生した疑いが大きいです。一つのページには7、8つの製品があります。合わせて3、500個の漢字があります。多くないですが、この表から調べたデータの量はかなり大きいはずです。mysqlは頻繁にこの表からデータを取ります。しかし、カードの死語はこの時計を調べているわけではないので、使いやすいものがないので、気がふさぎます。いずれにしても問題はよさそうです。まず記録を残してください。後でレベルが高くなったら、また調べます。MySQLはプロセスがいっぱいで死にやすい重要な原因の一つとして、駅を建てるのは容易ではないです。私の予想をはるかに超えました。経済のほかに技術的な問題もあります。しかし、この時間にどのように問題を考え、解決するかを学びました。特にいくつかの問題を連続的に解決しました。本当に開発者ではないと言えます。あるいは他の技術者が解決できるものではないです。これに対する自信もますます高まりました。これについて言えば、私達の駅の布衣生活ネットwww.yes 81.netについて、基本的な配置、LINUX 9.0システム、JBOSS S 42 WEBサービス、MYSQLはメーデーから今まで運行しています。前に問題が発生したのも確認してから長い間解決していませんでした。故障が発生するとCPUは100%ぐらい走りました。システムは応答していません。MYSQL、JBOSSプロセスは死んでしまいました。当初は大きなデータテーブルにインデックスを作成して解決しました。今回の問題はこれと似ています。死ぬ時はほとんどサービスが応答しませんでした。バックグラウンドのMYSQLプロセスを見ると、なんと私が設置した1000個の制限を超えました。1日目に3000個の配置を変更しました。これと関係があるかどうか考えてみます。最近の訪問量が増えました。本当の話を言って、私はやはり併発の1000の接続を信じないで、しかし事実は目の前に並べて、今すぐ1000の過程はここで塞ぎます！2日目に3000もダメと発見しました。プロセスリストで見たら、基本的にはプロセスがいっぱいで、各プロセスはsending data状態になります。2日間探しても問題は解決できません。起動パラメータを再設定しても、外来攻撃をチェックしても解決できません。一部の人の話によると、一時バッファ表を512 Mに増やしても助けはありません。このような接続を増やすごとにほとんどカードが死にます。しかもsending data状態です。データが送れませんか？それとも照会が完了しませんか？この問題を持って、開発とのコミュニケーションは、データのデッドロックや提出されていない問題がありますか？また、正常な場合もありますが、ほとんどは正常ではないデッドロックです。長い間調べましたが、プログラムには問題が発見されていませんでした。命令によってプログラムの正確なコードに位置します。何の問題ですか？以前MS SQLSERVR 2000で発生したデータベースの破損を思い出して、修復を試みました。渋滞命令によっていくつかの重要な表に集中しています。一つはレストラン情報表（4万件の記録）です。修復命令で修復できません。設定のタイプはinouboxで、タイプをMYISAMに変更して修復しても、エラーは報告されていませんが、システムを再起動したら問題は解決されます。