第4回 大規模データ処理におけるCPUの2大ボトルネックとは | gihyo.jp
「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック 第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。 ……しかし、次はだれかからこう聞かれることでしょう。 「CPUの使用率が異様に低いままなんだけど……？」 「CPUの使用率がずっと100％で張り付いているんだけど……？」 どっちやねん！と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。 ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。そして多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。 CPUボトルネックは
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
