テーブル最適化(や大量のDELETE)をほぼ無停止で行う | Gumu-Lab.
MySQLだとDELETEがとても重いです。10000件程度なら余裕ですが、100000件、1000000件にもなると手のつけようがないレベルです。その間MyISAMだとテーブルロックがかかるし、DELETEしすぎると今度は断片化してOPTIMIZE TABLEでもしないと速度低下が始まります。 OPTIMIZE TABLEやALTER TABLEはものすごく時間がかかることがあるんですよね。今回DELETEしようとしたテーブルはWebでの表示に必須の部分でして、どうせならWebをできるだけ落とさずにやってみるかという挑戦でした。 今回DELETEするのは27000000件くらいです。無理です。 処理を一度にできないと踏んだので、DELETEを増加量より多いLIMITで走らせればだんだんと減っていくのではないかと考え、実行。 ごり押しでLIMIT指定で絞ったDELETEを走らせた結果900
MySQLがメモリー不足の時に何をするか : トラブルシューティングガイド | Yakst
MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
MySQL InnoDBストレージエンジンのチューニング（後編）(EnterpriseZine) - goo ニュース
チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 ■バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッフ
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
MySQL の max_connections, table_open_cache, open_files_limit の関係 - tmtms のメモ
昔書いた記事を久々に見てみたら何書いてあるかさっぱりわからなかったので、最新情報で書き直してみます。 tmtms.hatenablog.com 以下は MySQL 5.6, 5.7 について書かれています。 MySQL の max_connectoins, table_open_cache, open_files_limit パラメータは相互に依存して動的に値が設定されます。 パラメータ名 デフォルト値 最小値 最大値 max_connections 151 1 100000 table_open_cache 2000 1 524288 open_files_limit 5000 0 4G わからないと言われたので追記。 my.cnfやコマンドラインオプション等で設定された値(またはデフォルト値)を初期値として、open_files_limit → max_connections → ta
MySQLのメモリ設定の勘所 – sawara.me
MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、「メモリです」と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず「グローバルバッファ」と「スレッドバッファ」について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と
【MySQL】総メモリー使用量を算出するSQL作ってみた - もぐめぽろぐ
必要メモリ量＝グローバルバッファのサイズ＋（各スレッドのバッファサイズの合計 × 最大接続数(max_connections)） 各スレッドのバッファサイズの合計とは、以下の値の合計値です。 sort_buffer_size myisam_sort_buffer_size read_buffer_size join_buffer_size read_rnd_buffer_size グローバルバッファのサイズは、以下の値の合計値です。 key_buffer_size innodb_buffer_pool_size innodb_log_buffer_size innodb_additional_mem_pool_size net_buffer_length ※実践ハイパフォーマンスMySQL による とあるのだが、一般的にいわれてる計算式はさらにそれに+query_cache_sizeがプラ
MySQLのインストールと各種設定、phpMyAdminのインストールと設定
データベースと管理ツールを導入 「前回」に続いて「GMO VPSを契約してWordPressを安定動作させるまでのサーバ設定方法」第五弾。 この投稿ではMySQLのインストールと初期設定。合わせて簡単なチューニングやスローログの書き出しなども設定します。また、管理用にphpMyAdminのインストールと設定を行います。 今回の解説で利用したVPSはこちら 目次 MySQLのインストールと設定 phpMyAdminのインストールと設定 MySQLのインストールと設定 グループインストールでMySQL Database serverをインストールしましたが5.1はちょっとバージョンが低いので新しいものに入れ替えます。 MySQLのアンインストール # yum erase mysql （省略） Dependencies Resolved =============================
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
MySQLのチューニングを戦う方へ
本連載もついに最終回となりました。 本連載では、MySQLクエリーチューニングことはじめで予告した通り、「チューニング箇所の洗い出しのテクニック」について説明してきましたが、「チューニングの方法」については一切触れませんでした。 「本連載ではチューニングそのものの方法については詳しく説明しません。それは見出しの通り「銀の弾丸」などはなく、MySQLのパフォーマンスチューニングは計測と改善を繰り返し行っていくべきものだからです。そのため、特定のケースにマッチする改善の手法よりも、繰り返し使われる計測の手法にフォーカスを当てて説明していきます。」 その理由としてこの一文が全てではありますが、今回は参考までに筆者が考えるチューニングの指標を紹介したいと思います。それがあなたの環境に当てはまるかどうかは、これまでに紹介してきたツールなどを利用して計測してみてください。 チューニングの基本方針 基本
MySQLのmy.cnfファイルサンプル
MySQLのバージョン インストールされたMySQLのバージョンは以下のようになります。 名前 バージョン ダウンロード元 my.cnfサンプル 以下のサンプルを参照して、my.cnfファイルを作成してください。 # このファイルは MySQL 5.6を基準として作られてあります。 # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html を参照しました。 [mysqld] ##-------------------------------------------------------------------- # mysqldの基本設定 ##-------------------------------------------------------------------- # id は 1 から 2^
パフォーマンスを求めて - お前の血は何色だ!! 4
結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20
MySQLの複合INDEX - 憂鬱なプログラマの形而上学
MySQLMySQLの複合インデックスについて。MySQLを使いこなしている人には常識の範疇にはいる知識だと思うのですが、かつての私のように、知らないとドツボにはまるので、ここにまとめておきます。タイトルでどういう内容か、もしかしたら大体、想像がつくかなと思うのですが、MySQLは1つのクエリーで1つのテーブルに対し、1つのインデックスしか機能しないということです。ようするに、あるテーブルに対して、普通に大量のインデックスを張ってもあまり意味がありません。そこで、今回は、最適な複合インデックスはどのようにしてはることができるか考えていこうじゃないか、という趣旨で書いていきたいと思います。まずは分析。テスト環境でインデックスが使われていないSQLを集めるまずは、/etc/my.cnfのパラメータを以下のように設定し、インデックスが使われていないSQLをスロークエリーに吐き出します。 slow
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【MySQL5.6】max_connections, open_table_cache の値が反映されない（my.cnfよりも小さくなってしまう） - Qiita
MySQL5.5から5.6にアップデートしたら、「Too many open files」で起動できなかったので「open_files_limit = 8192」で対処した件 | 田舎に住みたいエンジニアの日記
【php】4バイト文字を削除する at softelメモ
MySQLバックアップの基本
