MySQLのメモリ設定の勘所 – sawara.me
MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、「メモリです」と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず「グローバルバッファ」と「スレッドバッファ」について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
分散を考慮したMySQLの運用 DBのスケールアウト戦略
Tweet Tweet前回は、大きなデータを効率良く扱う OSのキャッシュと分散についてまとめた。ここでは、分散を考慮したMySQLの運用といったDBのスケールアウト戦略について解説する。 １ インデックスを正しく運用する 分散を考慮したMySQL運用、3つのポイント OSのキャッシュを活かす インデックス（索引）を適切に設定する スケーリングを前提とした設計 OSのキャッシュを活かす 全データサイズに気を配る：データ量＜物理メモリを維持、メモリが足りない場合は増設など スキーマ設計がデータサイズに与える影響を考慮する ※正規化：クエリが複雑になって速度が落ちるときがあるため、速度とデータサイズのトレードオフを考える インデックス重要 MySQLのインデックスは基本B+木（ビープラスツリー）というデータ構造である。B+木はB木（ビーツリー）から派生したデータ構造で、外部記憶の探索時にシーク
mydumperを試す!!: Ma note
DBサーバーを刷新したので、ついでにバックアップ手法も見直し。 現状ではDBの肥大化に伴い、通常のmysqldumpではバックアップ、リストアともに１時間超えするようになってしまった。 候補として、XtraBackupや、LVM等でスナップショットなどもあるけど、なんだかんだテキストベースのDDL、DMLが都合がいい。俗に言う論理バックアップというやつかな。 ということで、mydumperを導入してみる。 mydumperはマルチスレッドなmysqldumpみたいなもので、スレッド数次第ではなかなかの性能を発揮しそう？ http://www.mydumper.org/ 早速、本サイトに行くが何かリンク切れ。。。 色々模索してみると、yumからインストール出来そうな情報発見。 1.Download the latest remi-release rpm from http://rpms.fa
MySQLシステム変数
MySQLには、様々なシステム変数が存在します。 これらは、my.cnfなどの設定ファイルやMySQLの起動時オプションで 制御することが可能です。 システム変数は、以下のSQL文で参照できます。 SHOW VARIABLES; SHOW VARIABLES like 'charset%'; また、以下のSQL文で更新できます。 SET GLOBAL sort_buffer_size = 10 * 1024 * 1024; SET SESSION sort_buffer_size = 10 * 1024 * 1024; システム変数には、サーバ共通の値と セッション(接続)共通の値とがあります。 前者を変更すると、その後開かれる全てのセッションに影響があります。 後者を変更すると、現在のセッションでのみ影響があります。 以下、MySQL5.0.16に対応したシステム変数一覧です。 自動イン
クラウド時代の新常識はこれだ！「MySQL クラウド向け InnoDB チューニング」｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
クラウド時代の新常識はこれだ！「MySQL クラウド向け InnoDB チューニング」 こんにちは。インフラエンジニアの nobuh です。 株式会社インサイトテクノロジー様主催の db tech showcase sapporo 2015 が 9月10日、11日の2日間にわたって開催されました 。 今回、弊社も発表する機会を頂きましたので、インフラエンジニアとして日々 MySQL と格闘して培ったノウハウについてお話させて頂きました。その発表で使ったスライドがこちらです。 クラウド上の仮想サーバーを使って MySQL の管理やチューニングに日々邁進されている方々にご覧いただけると幸いです。 今までにも MySQL に関していくつか記事を掲載していますので、この機会に是非ご覧ください！ → OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
mk(pt)-query-digestをもっと活用しよう！ - 筋トレとともに生きるDBAの雑記
もはやこれが無くては障害対応ができないぐらい中毒になっているmk-query-digestさんについてです。 mk-query-digest - Analyze query execution logs and generate a query report, filter, replay, or transform queries for MySQL, PostgreSQL, memcached, and more. 例えばこんなことが起きたときは、何を差し置いてもまずtcpdumpを取りに行きます。 状況がおさまってしまってからでは遅いのです。 Load Averageの高騰 Too Many Connections lock wait timeout tcpdump -i bond0 -s 65535 -x -n -q -tttt 'port 3306' > tcpdump.out
pt-ioprofileでMySQLのテンポラリテーブルのサイズを測る
Percona-Toolkitのうちの1つにpt-ioprofileというやつがあって、 straceでwriteやread, fsyncのシステムコール呼び出し状況を記録して、 lsofでファイルディスクリプタ番号と紐付けて、集計して出してくれたりする。 一番単純な使い方は多分こんな感じ。 # pt-ioprofile --cell sizes --run-time 60 2013年 1月 6日 日曜日 17:08:03 JST Tracing process ID 1824 total read pread64 pwrite64 write open _llseek filename 2191 0 1024 1167 0 0 0 /var
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLやSSDとかの話 前編
MySQL :: MySQL 8.4 Reference Manual :: 17.17.3 InnoDB Standard Monitor and Lock Monitor Output