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のEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
よく使う strace のオプション - ablog
Linux で strace を使ってシステムコールのトレースを調べる時によく使うオプションをメモ。 特にお気に入りのオプションは -T、-c、-ff & -o です。 書式 システムコールを詳細に追う tt: 行頭にタイムスタンプを出力(マイクロ秒) T: 行末にシステムコール内での所要時間を出力(マイクロ秒) ff: 子プロセスのシステムコールもトレースし、-o との併用でプロセス（スレッド）毎に別ファイルに出力 o: 指定したファイル名に出力。-ff と併用すると、ファイル名. に出力 s: 出力文字数を指定。デフォルト32文字。read/write システムコールなどで読み書きした内容を全て確認したい場合は、大きくする。 p: プロセスIDを指定。 $ strace -Ttt -ff -s 1500000 -o <ログ出力先ファイル名> -p <PID> もしくは $ strace
Kodama's tips page
Kodama's home / tips. Linux ディスクキャッシュの開放 以下は Linux 2.6.16 以降. 2.6.15 以前では, /proc/sys/vm/bdflush で行う. 概要 一時的にキャッシュを開放したい場合 ディスク装置のバッファキャッシュ キャッシュのメモリー使用量の調整 キャッシュの書き込み間隔の調整 概要 ディスク装置の中のディスクの回転速度や読み書き速度と コンピュータのデータ転送速度には大きな差がある. この速度の違いを調整するために, 一時的なデータの置き場所として使われるものをバッファキャッシュと云う. ディスク装置に組み込まれたバッファキャッシュと, 主メモリーの空いた部分にとるバッファキャッシュの2段階があることに注意. 通常は気にする必要は無いが, 能力の測定でファイルの読み書きを行う場合などに影響する. Linux では, 主メモリ
6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst
NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか？ Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない)というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_maxip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて値を変
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redmineチューニングの実際と限界 - Redmine performance tuning
ヤフー社内でやってるMySQLチューニングセミナー大公開
MySQL Clusterを運用して10ヶ月間