Webアプリケーションが今こそ知るべき、 RDBMSのパフォーマンスチューニングの勘所 / rdb-basic
MySQLでスレーブを複数台並べている。 負荷増加やサーバ障害で新規スレーブを追加したい。 で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。 それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。 というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。 クエリを実行して主要テーブルのIndexをロードする 低い振り分け比率でサービスに投入してしばらく待つ tcpdump + (mk|pt)-query-digest等で既存スレーブのクエリを流し込む 基本的にサービス投入前の完璧なウォームアップは無理ゲーなので、 普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、という
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
2. 私は誰 • ⽒氏名: 滝澤 隆史 @ttkzw • 所属: 株式会社ハートビーツ ▫ 普段はサーバの構築や運⽤用をやっています。 • チーム名: zzz ▫ メンバー: @ttkzw ⼀一⼈人チーム ▫ hubでギネスを飲みながらサバフェスの申し込み 画⾯面を⾒見見ていて、チーム名を考えていたら、間 違ってPOSTしてしまった。 ▫ 開催⽇日近くにチーム名の⼀一覧が公開されるまで、 どのチーム名で申し込んだか思い出せなかった。 2 2015/03/26サバフェス！ 2015 Spring 3. 注意事項 • 本資料料はIDCフロンティア様主催の「サバフェ ス！ 2015 Spring」に特化した内容です。 ▫ https://2015spring.serverfesta.info/ • ここで紹介したパラメータを参考にする場合は その内容を理理解した上でご
2013/10/05に開催された日本PostgreSQLユーザ会 第27回しくみ＋アプリケーション勉強会での講演です。 http://www.postgresql.jp/wg/shikumi/shikumi27 ---- コンピュータシステムにおける性能測定とは、技芸です。 性能測定というと、単に測定ツールを実行するだけの作業だと考えられがちです。しかし実際には、何のために測定をするのか、そのために何を測定するべきか、そして何を使って測定するべきかを理解した上で行わなければ全く意味を成さない、深みのある技芸の世界です。 講演者の所属する研究室では長年にわたりデータベースシステムの研究・開発を行ってきました。その過程で培われた性能測定の技芸について、最近の実例も交えつつその考え方をご紹介したいと思います。Read less
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
【今回の内容】 前回は基本的なＳＱＬを備忘録で簡単にまとめていたけど、 【SQL入門】基本的なSQLを目的別にまとめてみた - ＦＯＲ ＳＥ その中に気になることがあったので調べたものをメモとして紹介します。 今の自分の現場では、重複行を絞り込む時に、「distinct」と「group by」を使う人それぞれいました。 distinctとgroup byは同じように重複行を消すという意味では どちらでもいいのかなーと思っていたけど、 疑問に思ったので少し調べてみました。 【疑問】distinctとgroup by は重複行を消す目的ならどちらを使ってもよいのか？ 【結論】 結果としてはどちらも重複行を消すという意味では同じらしい。 だが、一般的にgroup byは集合関数（sumとかcountとか）と一緒に使うので、 そもそもの目的用途が違うのではという話があった。 また、どちらが性能が良
9. 問題の実装 9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?php class BlackListDB { const DBPATH = "/tmp/db.gdbm"; public function isBlock($id) { $dbh = dba_open(self::DBPATH, "r", "gdbm"); if ($dbh === false) { return null; } $ret = dba_exists($id, $dbh); dba_close($dbh); return $ret; } } 10. 問題点 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?php class BlackListDB { const DBPATH = "/tmp/db.gdbm"; publ
1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. ＼こんにちは！／ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. ＼しゃべること！／ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
12. © CROOZ,Inc. 12 １．INDEXとはなにか 何枚目がなにかを事前にメモっておけば良い！ スート ランク 位置 ハート Q 1 スペード 9 2 : : : ダイヤ 1 40 : : : スペード 6 45 なぜなら、要求は「カードを引く回数を最も少なく してスペード6を探すこと」 セコいとかおもうヒトはいるか もしれませんが何もセコいこ はしていないです。 前提条件など一切ないから このメモさえあれば位置を指定して1回引けば済む
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
3大ボトルネックを解消すれば終わり，ではない これまでの連載では，ディスクI/O，CPU，ネットワークI/Oの3つの観点で，大規模データを処理するときのボトルネックの傾向と改善点について説明しました。それらの改善策をすべてを実施すれば，もう何も心配する必要はないのでしょうか？ 残念ながら，よかれと思って実施したチューニングがほかの箇所に影響を与える可能性があります。最終回となる今回は，その具体例を見ていきましょう。 データを圧縮した場合，CPUボトルネックが生じやすくなる 大規模データを扱うときは，データの総量を小さくしてストレージ装置のコストを削減するため，圧縮機能の利用を検討することが多いです。 データを圧縮する場合，RDBMSの機能を利用するのが一般的です。たとえばOracle Databaseには，以下のように何種類かの圧縮機能があります。 標準圧縮機能 OLTP圧縮機能（Adva
前回は，CPUボトルネックを解消するアプローチとして「並列化」および「リソース・マネジメント」をご紹介しました。今回は，それらをOracle Database上で実装する方法についてご紹介します。環境はOracle Database 11gR2を想定しています。 処理を並列化する2つの手法 Oracle Database上のSQL処理を並列化するには，2つの手法があります。 1．アプリケーション側でSQLを分割して同時実行する Oracle Databaseでは，1セッションあたり1つのサーバ・プロセスが立ち上がります。複数セッションから複数のSQLを同時に実行すれば，複数のOSプロセスが処理を行うので，複数のCPUコアが利用されます。 この手法は，SQLを分割する手間がありますが，大規模バッチでは有効です。 2．Oracle Databaseの並列化機能を利用する 大規模データを参照する
I/Oの「レスポンス」と「スループット」とは？ 連載第1回でご紹介したように、大規模データ処理を行うデータベースで一番大きな課題となるのは、ディスクI/O（以降、単にI/Oと表記します）のボトルネックです。数百GBやTBクラスの巨大データウェアハウスの場合、SQLが実行される時間のほとんどがI/Oを待つ時間となっているケースが多々あります。 ここでは、I/Oボトルネックが発生するおもな原因を、「レスポンス」と「スループット」という概念から見ていきましょう。それぞれ、広義では以下の定義となります。 I/Oレスポンス＝I/O要求処理にかかる応答時間 I/Oスループット＝単位時間当たりのI/O処理量 Oracle Databaseに当てはめると、以下のように定義できます。 I/Oレスポンス＝1データブロックの読み出しや書き込みにかかる時間 I/Oスループット＝単位時間あたりの読み出しや書き込み
DBサーバでとある日を境にswapが発生していることに気がつきました。 サーバはメモリ32GB搭載していて、そのうちの24GBをinnodb_buffer_pool_sizeに割り当てています。 他のthread毎のメモリ設定値を見てもおかしそうな点はなかったのでググってみました。 MySQL と NUMA アーキテクチャと Swap Insanity MySQL InnoDBストレージエンジンのチューニング（後編） なるほど…。 それぞれのCPUがローカルでメモリを管理しているので、 2CPU積んでいるサーバだと、AというCPUで実行されているスレッドが、BというCPUが確保しているメモリ領域にアクセスするには、AのCPUを経由しないといけないわけですね。 このメモリアクセスが不均一になる方式をNUMAアーキテクチャというみたいです。 NUMAアーキテクチャのメモリ管理が、ノードという単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
