doc/reference
名称 reference - MRTG 2.9.22設定リファレンス 概要 MRTGの実行時のふるまいは、設定ファイルによって支配されています。 普通の設定ファイルはcfgmakerを使って生成することができます (cfgmakerマニュアルをチェックしてください)。しかし、もっと複雑な設定を するには、手でチューニングする必要があります。 このドキュメントではMRTGの全てのオプションについて解説します。 文法 MRTGの設定ファイルの書き方は、以下のようにいくつかの簡単なルールに則っています。 キーワードは行の先頭から始まらなければなりません。 キーワード行に続いて空白から始まる行は、そのキーワード行に追加されます。 空行は無視されます。 #で始まる行はコメントです。 Include: file を使って他のファイルを取り込むことができます。 例: Include: base-opti
MRTG.JP - MRTG Official Japanese site
MRTG 公式日本語サイト (最終更新日: 2002.08.06) MRTG本家サイトのドキュメントを日本語に翻訳しました。 MRTG-Jメーリングリストについて 日本独自のメーリングリストの紹介。本家のメーリングリスト（英語）についての情報はMRTGニュースグループとメーリングリストをご覧下さい。 本で読むMRTG 日本で出版されている本で、MRTGについて書かれているものを紹介します。 MRTG英語版ミラー ＊＊＊寄稿者募集中＊＊＊ MRTG-JPでは寄稿者を募集しています。MRTGの設定や 改良、使用方法などについて、このサイトに掲載してもよい という文書をお持ちの方はinfo@mrtg.jpまでぜひご連絡下さい。 このサイトはリンクフリーです。 リンクされる際に特に連絡は必要ありませんが、announceメーリングリストに参加されるとサイトに更新があった場合、お知らせが届きます。
Google Chrome、マルチプロセスで動作する理由 | エンタープライズ | マイコミジャーナル
Chromium - News and developments from the open source browser project Google ChromeはGoogleからリリースされ、とにかく動作が速いということで注目を集めた。ただし高速なのは興味深いことだが、ほかのブラウザでも積極的に改善が進められているためブラウザ事情に精通したデベロッパはさほど驚かなかっただろう。デベロッパとしてはむしろ、単一のプロセスではなく複数のプロセスを生成して動作するという点に興味を持ったのではないだろうか。Chromeには既存のオープンソースプロジェクトの成果物が活用されているため、実装の新規性よりも組み合わせや改善のうまさが際立つ。新アイディアという点で見ると、Chromeで注目すべきはマルチプロセスアーキテクチャという設計にある。 マルチプロセスアーキテクチャについてはMulti-proc
CPU使用率とロードアベレージ
ロードアベレージは、最も簡単に説明すると、実行プロセス数の平均だ。説明によっては実行待ちプロセス数や実行可能プロセス数となっているが、正確には実行プロセス数(実行中プロセス数＋実行可能プロセス数)だ。つまり、I/O待ちのプロセスはカウントされない。 ここで、たとえば、1秒間に10回実行プロセス数をカウントすると、1分間では600回カウントする。カウントした時に、毎回3、4、5あたりをうろうろしていると、平均値としては4ぐらいになる。これがロードアベレージだ。正確に、Linuxが1秒に何回カウントしているかは知らんが、どちらにせよ (カウントした時のロード数1＋...カウントした時のロード数n)/カウント数 という計算式になるので、1分に何回カウントしたかはあまり重要な数字ではない(もちろん1分に1回やら数回やらというのは困るが)。ロードの平均値を取っているのでロードアベレージだ。 ロードア
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
ロードアベレージに関する考察
ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
