hiro_yのブックマーク - はてなブックマーク

コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
hiro_y 2009/09/04
MySQLのチューニング。Linuxまわり。I/Oスケジューラをdeadlineに。

mysql
リンク
フツーな日常 - MySQLのTips
http://forge.mysql.com/wiki/Top10SQLPerformanceTipsというのがあったので、和訳してみる。 (11/23 追記)id:pekeqさんとsodaさんのコメントを受け一部更新 (4/27 追記と修正)id:hirose31さんの指摘を受け修正。あと元のサイトが構成変更していたので追従クエリのパフォーマンスに関するTips(データベースのデザインとインデックスについても) EXPLAINを使ってクエリの実行プロファイルを取れスロークエリログを使え(常に有効にしておけ！) GROUP BYを使っているか使えるなら、DISTINCTを使うな Insertのパフォーマンスバッチ処理によるINSERTとREPLACE INSERTの代りにLOAD DATAを使う LIMIT m,nは案外速くない 2000件以上のレコードに対してORDER BY RA
hiro_y 2007/04/27
MySQLのチューニング、翻訳。

mysql
リンク
Prepared statementを使うとQuery cacheが効かない - フツーな日常
4.1の日本語化されたマニュアルばかり読んでいたらこの動作への言及が無かったため見落していたが、5.0に対応したオリジナルである英語版にはちゃんと注意が書いてあった。道理ででnot_cachedばかりが増えていくわけだ。それだけコード側でのprepared statementの利用が徹底されているということは、それはそれで良いのだけど、どうしよう。繰り返し利用しないようなSQLでパラメータも固定のものはprepareしないでいきなり実行するように書き換えてしまうべきか。無論、Injection対策になる部分を無理矢理書き換える必要はないんだけど。機能として同じような場所で動くものだから協調して動作させるのが難しそうではあるが、本質的に共存不可能なものではないので実装自体が改善してくれると嬉しい。 (追記) よくよく考えると共存はかなり面倒な実装になりそう。そもそもPrepared st
hiro_y 2007/02/07
prepared statementを使うとクエリがキャッシュされない件。

mysql
リンク
1