GitHub - tkuchiki/slp: SlowLog Profiler for MySQL and PostgreSQL
$ slp --help slp is a MySQL/PostgreSQL SlowLog Profiler Usage: slp [flags] slp [command] Available Commands: completion Generate the autocompletion script for the specified shell diff Show the difference between the two profile results help Help about any command my Profile the slowlogs for MySQL pg Profile the slowlogs for PostgreSQL Flags: --config string The configuration file -h, --help help f
スロークエリログをどう使えばいいのかって疑問、全て解決
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭
今回答えを出したい問いはこちら！！ インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ！！！！それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな！ indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t
kintone の性能改善について紹介します - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。 今回は、サイボウズ製品のひとつである kintone に対して行った性能改善の成果を紹介したいと思います。kintone は面倒なコーディング無しに業務アプリケーションのようなものを作ることができ、様々なデータを格納したり、複雑な条件で検索したりソートしたり、アクセス権もきめ細やかに設定したりできるというサービスです。この kintone はサービスの性質上、多種多様で複雑なクエリを発行します。またデータ量も膨大で MySQL だけで計数十テラバイトのデータが存在しており、クエリの処理時間が長時間かかってしまうこともあります。 サイボウズでは kintone の性能改善に力を入れており、今回はその成果を紹介しようと思います。 はじめに kintone はテナントごとに大きく使い方が異なり、性能改善が効くケースもあれ
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
MySQLのメモリ設定を追求してみよう – OpenGroove
（2015年1月追記：これは現時点で約5年前に書いた記事です。各種パラメータは名称や仕様が変更されている可能性があるため、最新の情報を参考にしてください） MySQLのメモリの話を考えていたら何が何だか分からなくなってきたので、my.cnfでの設定に絡めてまとめてみようと思う。そもそも、MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。 max_connections x [スレッド領域用メモリ合計値] に、以下をプラス。 [グローバル領域用メモリ合計値] DB専用サーバの場合だとこの値をマシン搭載メモリの8〜9割くらいにする、と想定するのがひとつの指針となるようだ。しかし32bit版Linux OSの場合は2〜3GBまでの制限があるため、搭載メモリがそれ以上あったとし
Devsの常識、DBAは非常識
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 はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
