Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
TCP高速化などを図ったLinuxカーネル3.6、リリース
TCP高速化などを図ったLinuxカーネル3.6、リリース：仮想環境でのI/O性能を改善するVFIOも Linuxカーネルの新バージョン、「Linux 3.6」が10月1日にリリースされた。Linus Torvalds氏はこのリリースについて、アーキテクチャやファイルシステムに大幅な変更はないとしながらも、「着実な進歩」だと表現している。 カーネル3.6では、まずネットワーク接続を高速化するため、TCP Small QueuesやTCP Fast Openといった機能が盛り込まれた。TCP Small Queuesは、1つのキューに含まれるパケットの数に上限を設けることでRTTなどを減らし、ひいてはバッファサイズに起因する遅延や輻輳といった問題（Bufferbloat）を解決することを狙ったもの。一方TCP Fast Openは、TCPコネクション確立時のプロセスを最適化することで、Web
Linuxで3万（10万）プロセスを同時に起動させてみた
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 といっても、きちんとした検証をしたわけではないので、あくまで「こういう環境でこういう事をやるとこうなる」という参考程度のものと理解してい頂ければ幸いです。 Linux上でプロセスは同時に何個起動できるのか 数年前にC10K問題が流行りました。これは、簡単に言うと、万のオーダーでプロセスを立ち上げる事になると、現状のOSではそれを想定した設計になっていないためまともに動かなくなる、といった問題でした。 だったら、「10万プロセス位を同時に立ち上げてみて、どうなるか試してみようぜ！」と思い、会社のエンジニアと一緒に試してみました。検証環境は、メモリ48GでCPUはHyperThreading込で24コアです。そこで動いていたOSはDebianでL
ほえほえ LinuxファイルI/Oチューニング
Linuxは私の使っている範囲ではファイルI/Oがパフォーマンスボトルネックになっていることが多い。で、チューニングの情報を集めてみるのだが、なかなか役立つ情報を入手できない。 決まって全般的なチューニングの進め方について述べ、次にボトルネックの調べ方について述べる。 最後にチューニングパラメータ設定手順のヒントだけを非常に簡単に挙げておわってしまう。いや、どこがボトルネックなのか最初に一発で分かればいいよ？ でも全般的なチューニングの進め方でそうしたドキュメントが述べている通り、色々な可能性を繰り返しチューニングしながらつぶしていかなきゃいけないんだよね。 そのためには具体的なチューニングパラメータの設定手順がなきゃできないんだよね。それを教えろよ！それを！ ということで、今回はLinuxファイルI/Oチューニングについて調べた。大きなファイルの書き込み(ex. cpコマンド)を行うと、
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
2010年11月18日 "ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード | gihyo.jp
Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判（というより非難）し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「I'm also very happy」「it is a _huge_ improvement」「Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
Varnish - Trac
Welcome to the Varnish project Varnish is a state-of-the-art, high-performance HTTP accelerator. It uses the advanced features in Linux 2.6, FreeBSD 6/7 and Solaris 10 to achieve its high performance. Some of the features include A modern design VCL - a very flexible configuration language Load balancing with health checking of backends Partial support for ESI (the sensible part of ESI) URL rewr
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
