Linux Performance Analysis and Tools
Video: http://joyent.com/blog/linux-performance-analysis-and-tools-brendan-gregg-s-talk-at-scale-11x ; This talk for SCaLE11x covers system performance analysis methodologies and the Linux tools to support them, so that you can get the most out of your systems and solve performance issues quickly. This includes a wide variety of tools, including basics like top(1), advanced tools like perf, and ne
第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スループット＝単位時間あたりの読み出しや書き込み
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
