サーバが重い時の負荷の正体を突き止める
WEB+DB PRESS Vol.65｜gihyo.jp … 技術評論社. WEB+DB PRESS の特集１「WEBエンジニアが知るべきインフラの基礎知識」が非常にまとまってて良かった。 闇雲にtopコマンドとかネットで調べながら調査してたので今後のためにもメモ。 ロードアベレージ(忙しさの度合い) uptimeコマンドを使って見る。 [root@suusuke ~]# uptime 22:27:30 up 202 days, 18:48, 1 user, load average: 0.07, 0.15, 0.08 0.07という数字は処理を実行したいが、何かしらの処理で実行できなくて待たされている状態のプロセス数 何かしらの要因とは？ 他のプロセスにCPUが使われていて、空くのを待っている状態（CPU使用率） ディスクに読み書き要求を発行してその結果を待っている状態（I/O待ち率）
JMeterを利用した負荷テストでどのようにスレッド数、Ramp-Up期間、ループ回数をどうやって決めるか考える - 基本へ帰ろう
what 前回の測定は、Ramp-Up期間がすべて 1 という極端なものであり、あまりよろしくないと聞いた。 そのため、再度、負荷テストを行う。 今回行いたい測定は、前回同様「サーバの負荷限界値」である。 負荷計測環境 前回とほぼ同じだが、負荷テスト対象のWebアプリケーションのバージョンが少々あがっている。 妥当なRamp-Up期間の決定について JMeterで負荷テストするのはいいのだが、以下の数値をどのように決めるのに非常に悩む。 スレッド数 Ramp-Up期間 ループ回数 どうしたらよいものか、考えてみた。 itarchitect.jp 上記にテストシナリオ作成のヒントが書いてあるので読んでみた。「現実に即したテスト」という視点が非常に重要であると書いてある。 記事のヒット率の以下のようになる。 スレッド数が大きい場合は、Ramp-Up期間を「0」に設定すべきではない。（異常な状態
JMeterについてもう一歩進んでみる - oknknicの日記
以前 JMeterについて調べてみた - oknknicの日記 で、JMeterの基本中の基本の操作について書いた。 今回は、もう一歩進んで、実際に利用する際の視点で書いてみる。 WEBアプリ負荷テストの観点 ユーザ数 同時リクエスト数 同時ログインユーザ数 連続稼働時間 ネットワークの太さ JMeterを実行するPC（1台で複数ユーザ担当）に接続されているLANの太さ クライアントPCから計測対象までのネットワークの太さ、物理距離 JMeterでできること 複数のリクエストを一気に送出できる 一台のマシンからマルチスレッドで 複数台のマシンを1台のマシンから操作して 多様な種類のリクエストを送出できる 複数のリクエストを時系列で組み合わせることができる 単純な繰り返しや、ログイン→業務処理→ログアウトなど タイミングも設定可能 テストシナリオをWebブラウザの操作から生成できる その他細
サーバ監視に超使える〜topコマンドのまとめ:phpspot開発日誌
サーバ監視に超使える〜topコマンドのまとめ サーバを運用しているとよく使うtopコマンドですが、標準のtop以外にも色々便利なものがあるのでまとめてみました。 ボトルネックといえば、ネットワーク、ディスクIO、スワップ、CPU、メモリといったものが関連しますが、ツールで視覚化することでより分かりやすい対策がとれますね。 htop こちらも、通常のtopよりもさらに多数の情報を表示してくれるツール。 CPUやメモリの状態が視覚的にグラフで表示されていたり、複数CPUがある場合もそれぞれに利用率を表示してくれてわかりやすいです。 pstreeで表示するようなツリー+topコマンドのような表示も t を押せば切り替えられます。 公式サイト上にある128コア積んだマシンのhtop結果が面白い。 次のようにすべてグラフで表示されているため、128コアあったとしても瞬時に負荷が把握できますね。 io
JMeterで高負荷をかけたい場合 | きぬろぐ
負荷測定ツールにOSSのApache JMeterというものがあります。かなり汎用的でつぶしがきくよいツールで、私もよく使います。JMeterについては以下の資料がよくまとまっています。 Apache JMeterで 負荷試験をしよう！ で、負荷をかける場合にはそのサーバの限界性能がどこかを探るケースが存在しますが、クライアント側のスペック不足やシナリオの作成方法が原因で負荷をかけきれないというケースがあります。スペック不足はともかくとして、シナリオ作成の方法がまずいことで計測結果が不十分になることはかっこわるいので、私が気がついた対処方法をまとめます。 ループはループコントローラで書け! 負荷をかける場合に、ユーザ1 – ユーザ10000迄のデータに連続してアクセスしたいケースがあったとしましょう。JMeterでこれを実装するには「While Controller」と「ループコントローラ
「ニフティrクラウドユーザーブログ」は、移転しました。
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 ＞ ニフティクラウドユーザーブログ
JMeter Knowledge log
2011年9月26日月曜日 JMeter : 定数スループットタイマで陥りやすい落とし穴 JMeterにはいくつかの種類のタイマ部品が用意されていますが、その中でも定数スループットタイマを好む人が多いようです。 このブログを訪れる人でも検索キーワード「定数スループットタイマ」というのは上位に来ています。 さて、そんな人気の高い定数スループットタイマを使って負荷テストを行う場合に、陥りやすい落とし穴があることを知っていますか？ それをやってしまうと、負荷の与え方が不適切となってしまい、したがって適切なデータが取得できなくなってしまうのです。でもって場合によっては本番運用でドカーン、と火を吹いてしまう、と。 以前に、「定数スループットタイマの誤訳」という記事を書きました。これも日本語を鵜呑みにしてしまうと、とんでもないことになってしまいます。 ただ、これはすぐに気づきますので、ひっか
[Think IT] サーバが重いってどういうこと? (3/3)
bi、boの値が大きい程ディスクアクセスが頻繁に行われています。ディスクアクセスが増えると、待ちプロセスが増加して、b、waの値が増えていきます。ディスクアクセスが増えて待ちプロセスが増えると、どんなに高速CPUでどんなにメモリを搭載していても処理がなかなか実行されなくなり、大きなボトルネックとなってしまいます。 ディスクI/Oが多い場合は次のような対策を行います。 アドホックな対策 該当プロセスを終了させる 恒久的な対策 ディスクアクセスが少なくなるようにプログラムを変更する ディスクを高速なものに変更する ディスクを増やす、RAID構成にするなどしてI/Oを並列化させる サーバを増やして負荷分散する
はてなブログ | 無料ブログを作成しよう
わたし的棚ぼた一万円選書 急に千葉さんに手渡された封筒、開けてみたら1万円札が1枚。何ごとかと思えば、同期の出張を代わったお礼をもらったらしい。 「葵はワンオペで育児してくれたから」と半分わけてくれました。 泡銭の1万円 これはもう、わたし的1万円選書をしろという思し召しなのでは……
rsyncの負荷を抑える方法 - 理想未来ってなんやねん
リモートサーバーとのファイル同期の際にrsyncコマンドを使用すると便利ですが、特に何も指定しない場合は全力で働いてくれるため負荷が掛かります。 rsyncの負荷を抑える方法について、いくつか記載したいと思います。 1. 転送速度を調整する bwlimitオプションを付けることで、転送する速度を調整できます。 指定する値の単位はKbps単位で指定すします。 例えば、1MB/secの場合は 1024KB/sec→8192 Kbps/secなので --bwlimit=8192を指定します。 rsync -e "ssh" --bwlimit=8192 remotehost:/remote_srcdir/ /local_destdir 2. sshを使用する場合、負荷の低い暗号方式でCPU負荷を抑える ssh経由でrsyncを使用する場合、セキュリティ上特に問題がなければ arcfour(RC4)
アプリエンジニア向け：「サーバがなんか重い」時にすること - Qiita
アプリケーションエンジニアの人には「なんか重い」という状況に遭遇したらインフラの人にタスクを投げる、という人もいるかも知れません。けど、その重さのどこに原因があるのか。CPUか、ネットワークか、IOかくらいの診断はできた方がアプリ開発においても有益です。 「せっかくつくったシステムがなんか重い」 そんな時にアプリケーションエンジニアとしてできることを書きます。 本職のインフラの人にはぬるい内容だと思います。何を隠そう僕自身がアプリ寄りの人間なので、突っ込んだ話はできないのです。あしからずご了承ください。 なんかサーバが重いなー まずはロードアベレージを調べる サーバが重いと思ったら、まず真っ先にすべきことは対象ホストにSSH接続してロードアベレージを調べることでしょう。ロードアベレージとは 実行されずに待たされているプロセスの数 のことで、多すぎるとやばいと認識しておきましょう。ロードアベ
Linuxサーバの反応が遅い(重い)場合の原因の調査手順
概要 Linuxサーバの反応が遅い場合の調査手順のメモ。 実行する場合は自己責任でお願いします。 原因として考慮すべき事項 サーバが遅い場合には様々な原因がありますが、以下を考慮します。 CPU負荷 メモリ不足 ディスクI/O負荷 ネットワークI/O負荷 まず、どれが原因か調査する必要があります。 top コマンド 最初は「top」コマンドを利用します。 top - xx:xx:xx up 0 min, 1 user, load average: 1.44, 0.51, 0.18 Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2057692k total, 291
Linux高負荷の原因を調査 | StrapyaNext Engineers'Blog
Posted 2011年11月21日 by 山口 & filed under Linux. Linuxサーバが高負荷状態になったときの原因調査めも。 まずは、 1.サーバのロードアベレージを確認 topコマンドで確認(ディストリビューションにより出力形式に差異あり)。 topコマンドで出力される項目のうちload average：の値に注目する。 左から順に1、5、15分間の実行待ちプロセスの平均数が表示される。 ロードアベレージがCPUの数より大きい場合は処理が追いついていない いわゆる高負荷状態といえる。 例えばCPUが1つのサーバは1以上、マルチコアで2つのサーバは 2以上の数値だと高負荷状態に陥っている。 =========================================== CPUコア数の確認は以下のコマンドを実行する。 0,1と2つ表示ならCPU数は2つ。 ただ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
