MySQLサーバには、MySQLクライアントからのクエリとその実行結果をキャッシュし、次回から同じ内容のクエリが要求された場合にキャッシュから応答する、クエリキャッシュという仕組みがあります。キャッシュから応答させることによってデータベースへアクセスする負荷を軽減し、また応答速度自体の向上も狙ったものです。 デフォルト状態ではクエリキャッシュを使用しない設定になっています。以下のように現在の「クエリキャッシュに使用するメモリ量の最大値」であるquery_cache_sizeを確認してください。
先日、Amazon EC2のm1.smallは時分割によるCPUの配分が行われていることを確認したのですが、それでは、より小さなインスタンスであるt1.microでは、どのようにCPUを割り当てられているのでしょうか。 前提知識 EC2のインスタンスタイプの解説では、m1.smallはCPUの性能が1ECU、t1.microは2ECUだけど短時間しか維持できないという風に説明されています。t1.microは、m1.smallの4分の1程度の値段設定なので、最大2ECUとはいえ、かなりおおきな制約(短時間?)が課されていると推定できます。どのような制約が課されているのかを確認し、t1.microの性能特性を調査します。 公式情報 m1.small 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit) t1.micro Up t
AmazonEC2のサーバのCPUは、ECUという単位の処理能力で表現されます。標準的なインスタンスである、m1.small, m1.large, m1.xlargeでは、それぞれ、1ECU*1コア, 2ECU*2コア, 2ECU*4コアという風に表されています。ここで気になるのは、m1.smallだけ、1コア当たりの処理能力が低いという事実です。m1.small以外のインスタンスではCPUコア当たりの処理能力は2ECUなのですが、m1.smallだけは1ECUです。m1.smallだけ異なるCPUが割り当てられているとは考えづらいので、おそらく時分割で共有しているのでしょう。Amazonのサイトで具体的な記述を見つけることが出来なかったので、実際に検証してみました。 スモール インスタンス – デフォルト* 1.7 GB メモリ 1 ECU(1 ECU × 1仮想コア) 160 GB イ
Jeremy Zawodny 氏のブログに MySQL, Linux, and Thread Caching という興味深い記事があったので、理解するために自分翻訳してみた。この記事は、今はないけれども rember.yahoo.com で MySQL を使ったときの話のようです。ちなみに MySQL のバージョンは 4.0.4。 わぉ、とても忙しい一週間だった。私は、remeber.yahoo.com の MySQL サーバや関連するものごとに実に何日かを費した。そして、私は1日か2日を休息に使った(睡眠やシャワーなど) ところで、私はいくつか興味深い発見をした。もっとも驚いたことは MySQL サーバがとても忙しくなったときの Linux 上でのスレッドキャッシングの挙動だ。ポイントは、忙しいときのみということだ。忘れずに。 あなたも分かっていると思うが、われわれがすべてのウェブサーバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く