【メモ】 サーバのLoad Averageなどを監視するコマンド「top」をログに保存する
コマンドラインから設定する topの結果をlogに出力する – Code Design top -b -d 60 > /log/top.log -b オプションはバッチモード。結果を標準出力に出力する。 -d オプションは動作間隔。単位は秒（小数点以下も2桁まで指定可能。マイナスは不可）。省略するとデフォルト設定で起動する。間隔を短くしすぎるとログが膨大になりすぎるのでここでは60秒で設定。監視目的ならば短い方が良いかと（平均を把握しやすいので）。 本当なら記録するファイルは決めておいて、単位時間でローテーションさせるのが普通だと思うんだけど、とりあえずこれでも動いたので参考までに。 top -b -d 60 > /log/top.log_`date +%y%m%d` 「top.log_090609」というファイル名でログが保存される。 cronで設定する もし定常的にログを保存することに
ボトルネックめも – Worklog
＜性能テスト＞ ■ボトルネックの解析の基本 性能限界が生じた場合にいきなり、システムリソースの計測値から 調査するのはふさわしくない。 サーバーリソースの細かい計測値を複数取得して比較検討しても ボトルネックが切り分けしずらい。 ボトルネックの発生するタイミングはサーバーリソースを計測せずともわかる。↓ 応答時間：性能ボトルネックが発生するまでは一定で推移 ＝＞途中応答遅延している時点でボトルネック スループット：性能ボトルネックが発生するまでは増加を続ける ＝＞途中頭打ちになっている時点がボトルネック ■ボトルネック詳細要因の切り分け方法 ボトルネックのタイミングのサーバーリソースを確認 ＝＞ノード単位の切り分け、どのサーバーがボトルネックか？ ネットワーク機器 性能限界時に顕著にわかる現象：CPU使用率100%、帯域使用率100% 主な劣化要因：物理ボードの処理能力限界 システムバス処
mixi Engineers’ Blog » Linux Programming、epollの話
お久しぶりです、初めての日本の夏に圧倒されているトールマエサカです。 今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。 このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています： 一つもしくは複数のディスクリプタを監視 ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける 準備が整ったディスクリプタの通知 アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバーのCPU負荷などを調べるときに、psは使用できない。 - なんちゃってエンジニア
