Webアプリケーションが今こそ知るべき、 RDBMSのパフォーマンスチューニングの勘所 / rdb-basic - Speaker DeckWebアプリケーションが今こそ知るべき、 RDBMSのパフォーマンスチューニングの勘所 / rdb-basic
InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記
MySQLでスレーブを複数台並べている。 負荷増加やサーバ障害で新規スレーブを追加したい。 で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。 それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。 というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。 クエリを実行して主要テーブルのIndexをロードする 低い振り分け比率でサービスに投入してしばらく待つ tcpdump + (mk|pt)-query-digest等で既存スレーブのクエリを流し込む 基本的にサービス投入前の完璧なウォームアップは無理ゲーなので、 普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、という
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
性能測定道 事始め編
2013/10/05に開催された日本PostgreSQLユーザ会 第27回しくみ＋アプリケーション勉強会での講演です。 http://www.postgresql.jp/wg/shikumi/shikumi27 ---- コンピュータシステムにおける性能測定とは、技芸です。 性能測定というと、単に測定ツールを実行するだけの作業だと考えられがちです。しかし実際には、何のために測定をするのか、そのために何を測定するべきか、そして何を使って測定するべきかを理解した上で行わなければ全く意味を成さない、深みのある技芸の世界です。 講演者の所属する研究室では長年にわたりデータベースシステムの研究・開発を行ってきました。その過程で培われた性能測定の技芸について、最近の実例も交えつつその考え方をご紹介したいと思います。Read less
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
【SQL入門】group by,distinctどちらが性能がよいのか - 新卒から文系エンジニア→人材業界に転職した人のブログ
【今回の内容】 前回は基本的なＳＱＬを備忘録で簡単にまとめていたけど、 【SQL入門】基本的なSQLを目的別にまとめてみた - ＦＯＲ ＳＥ その中に気になることがあったので調べたものをメモとして紹介します。 今の自分の現場では、重複行を絞り込む時に、「distinct」と「group by」を使う人それぞれいました。 distinctとgroup byは同じように重複行を消すという意味では どちらでもいいのかなーと思っていたけど、 疑問に思ったので少し調べてみました。 【疑問】distinctとgroup by は重複行を消す目的ならどちらを使ってもよいのか？ 【結論】 結果としてはどちらも重複行を消すという意味では同じらしい。 だが、一般的にgroup byは集合関数（sumとかcountとか）と一緒に使うので、 そもそもの目的用途が違うのではという話があった。 また、どちらが性能が良
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
第7回 大規模データ処理におけるCPUとI/Oのバランスをどう考えるか：RDBMSでも大規模データをあきらめないためには｜gihyo.jp … 技術評論社
3大ボトルネックを解消すれば終わり，ではない これまでの連載では，ディスクI/O，CPU，ネットワークI/Oの3つの観点で，大規模データを処理するときのボトルネックの傾向と改善点について説明しました。それらの改善策をすべてを実施すれば，もう何も心配する必要はないのでしょうか？ 残念ながら，よかれと思って実施したチューニングがほかの箇所に影響を与える可能性があります。最終回となる今回は，その具体例を見ていきましょう。 データを圧縮した場合，CPUボトルネックが生じやすくなる 大規模データを扱うときは，データの総量を小さくしてストレージ装置のコストを削減するため，圧縮機能の利用を検討することが多いです。 データを圧縮する場合，RDBMSの機能を利用するのが一般的です。たとえばOracle Databaseには，以下のように何種類かの圧縮機能があります。 標準圧縮機能 OLTP圧縮機能（Adva
第5回 大規模データ処理でのCPUボトルネックを解消するには：RDBMSでも大規模データをあきらめないためには｜gihyo.jp … 技術評論社
前回は，CPUボトルネックを解消するアプローチとして「並列化」および「リソース・マネジメント」をご紹介しました。今回は，それらをOracle Database上で実装する方法についてご紹介します。環境はOracle Database 11gR2を想定しています。 処理を並列化する2つの手法 Oracle Database上のSQL処理を並列化するには，2つの手法があります。 1．アプリケーション側でSQLを分割して同時実行する Oracle Databaseでは，1セッションあたり1つのサーバ・プロセスが立ち上がります。複数セッションから複数のSQLを同時に実行すれば，複数のOSプロセスが処理を行うので，複数のCPUコアが利用されます。 この手法は，SQLを分割する手間がありますが，大規模バッチでは有効です。 2．Oracle Databaseの並列化機能を利用する 大規模データを参照する
第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp
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スループット＝単位時間あたりの読み出しや書き込み
【メモ】MySQLでのswap発生とNUMAアーキテクチャ - FAT47の底辺インフラ議事録
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ページを開く
Life with IT
サバフェス！ 2015 Spring LT資料
本当に怖いパフォーマンスが悪い実装 #phpcon2013
Devsの常識、DBAは非常識
MySQL Index勉強会外部公開用
Twitterにおける大規模システム構築、3つの原則
