今日はカンファレンス「
MySQL Performance 」でした。 スピーカーはDmitry Kravchukでした。
maghamedのおかげで、私はすでに会議の60％を知っていました。
会議自体は、MySQLの起源の年代順に興味深いものでした。 モンティとデビッドが一緒になった1995年から今日まで、MySQL Perfバージョン。
気に入らなかったもの：
- Sunには、MySQL Perfのインサイダーバージョンがあり（パフォーマンスは5.4よりわずかに高い）、急いで展開することはありません。
- ほぼすべての会議で「Sun this、Sun that。」
- Maatkitは注意を奪われました（おそらく敵の開発のため？）
- 彼は、会社が「スケーラブルなシステム」-ページあたり1,500件のリクエストを持っているリスナーに満足していました。 同時に、彼らのテクライドはmemcacheの松葉杖を考慮しています。
- サンドイッチはありませんでした:(
何が好きでしたか：
- スピーカー:)。 ドミトリーはすべての質問に答え、活発な議論がありました。 スピーチの最後にヒントが出ましたが、これについて聞いたことがなく、どこにも見られませんでした。
- 「信頼するが、検証する」という原則。 Dmitryは誰も信じなかったため、MySQLのパフォーマンスを完全にテストしました。
- ホールにはパーコナ出身の男性がいました。彼は時々ドミトリーの回答を手伝いました。
- MySQLは進化しています！ 近年のSunの購入にもかかわらず、パフォーマンスに多くの注意が払われ、バージョン5.4の出現に至りました。
忘れないように、私自身のためのいくつかのヒント：
- 各アプリケーションは一意であり、サーバーは特定のニーズ（QoS）に合わせて構成する必要があります
- 現在、innodb_max_dirty_pages_pctにバグがあります。 この値は単に無視されます。 パッチがありますが、まだメインブランチに到達していないようです（間違っている可能性があります）
- innodb_max_dirty_pages_pctにバグがある限り、innodb_log_fileを使用してダーティページフラッシュに影響を与えることができます（理由を聞かないで、Dimaに尋ねてください）
- 以前に聞いたことのない興味深いオプションは、innodb_flush_log_trx_commitです。 値は0、1、2。 1秒あたりのコミット数= 1フラッシュ）。 当然のことながらパフォーマンスに最適なオプション2
- innodb_io_capacity-ハードドライブの機能に応じて設定する必要があります。 Dmitryは2000を提供しました
- クエリキャッシュが20 MB以上-悪
- ダブルライトバッファを有効にすると、場合によってはパフォーマンスの最大30％を失う可能性があります
- データベース自体のランダム読み取りのため、REDOログ、ビンログ、ダブルライトバッファは異なるハードドライブに保存する必要があります
- 時にはmax_purge_logで遊ぶ価値がある
- Dmitryのブログdimitrik.free.fr