2011-08-04 13 views
7

私はWebアプリケーションのベンチマーキングを行っています。ほとんどの場合、UPDATES(場合によってはINSERT)クエリの約1%で発生する問題があります。私はこれらのリクエストについてプロファイリングを行いました。それは多くの時間を要するクエリ終了ステップのようです。"クエリ終了"ステップが非常にランダムな時間に非常に長く

starting 0.000029 
checking permissions 0.000005 
Opening tables 0.000017 
System lock 0.000005 
init 0.000032 
Updating 0.000052 
end 0.000030 
**query end 1.825892** 
closing tables 0.000025 
freeing items 0.000020 
logging slow query 0.000007 
logging slow query 0.000029 
cleaning up 0.000008 

私はドキュメント

最後まで行ってきましたとおり:これが最後に発生したが、ALTER TABLEのクリーンアップの前に、VIEWを作成、削除、INSERT、SELECT、またはUPDATEステートメント。

query end:この状態は、クエリを処理した後、アイテムを解放する前に発生します。

これは、私のUPDATEのクリーンアップに時間がかかることを意味しますか? この手順は正確には何ですか、どのようにパフォーマンスを改善できますか?

おかげ

答えて

11

複数のスレッドが同時にファイルを書きたいの連動に問題があるな/etc/my.cnf

innodb_flush_log_at_trx_commit = 0 

を追加することによって解決される問題、このようにログは毎秒フラッシュされます。

+0

多くのおかげで、同じ問題がありました。 – Frode

+6

innodb_flush_log_at_trx_commit = 0を設定することは、軽く採用するソリューションではなく、トランザクションの耐久性を根本的に変えます! –

+2

合意。 innodb_flush_log_at_trx_commitをnaiveに設定すると、危険なことがあります。その答えは誤解を招きます。 –

関連する問題