コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
Prepared statementを使うとQuery cacheが効かない - フツーな日常
4.1の日本語化されたマニュアルばかり読んでいたらこの動作への言及が無かったため見落していたが、5.0に対応したオリジナルである英語版にはちゃんと注意が書いてあった。 道理ででnot_cachedばかりが増えていくわけだ。それだけコード側でのprepared statementの利用が徹底されているということは、それはそれで良いのだけど、どうしよう。繰り返し利用しないようなSQLでパラメータも固定のものはprepareしないでいきなり実行するように書き換えてしまうべきか。無論、Injection対策になる部分を無理矢理書き換える必要はないんだけど。 機能として同じような場所で動くものだから協調して動作させるのが難しそうではあるが、本質的に共存不可能なものではないので実装自体が改善してくれると嬉しい。 (追記) よくよく考えると共存はかなり面倒な実装になりそう。そもそもPrepared st
MySQLのパラメータ調整 - フツーな日常
先日和訳したTipsの元のドキュメントを見に行ったら項目毎に整理されていた。パラメータの項目については直接記述するのではなく外部のドキュメントを参照するようになっていたので、そちらも翻訳した。 http://docs.cellblue.nl/easy_mysql_performance_tweaks/ 訳を貼っておいて言うのもなんですが、そんなに目を惹くような事は書いていなかったです。内容はごくごく基本的なことだけ。 以下の項目は影響度の大きい順に並んでいます。 Key Buffer Key bufferはテーブルのインデックスを保持します。多くのメモリとkey bufferはそれだけ速いルックアップを実現できます。必要に応じて調整してください。大容量はもちろんいいことですが、スワップはなんとしても避けて下さい。経験則としてシステムメモリの1/4を割り当てるのが良いとされています。 key
フツーな日常 - 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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
