JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
パフォーマンスモニタの監視項目：老プログラマーの備忘録：SSブログ
システム監視は、監視目的(ボトルネック、エラーや使用状況の検出)を明確にしておくことです。しかし、幾つかの項目の閾値は一般的な数値として定義できますが、多くの項目はシステム運用中にデータを取得しシステムに適合できる閾値を見極めることが大事だと思います。 扱う項目や依頼数の変化と監視項目の変化のデータを取り将来起こりうるボトルネックや障害を予想する為にもデータは日々取得し日次、週次、月次、半期及び年次などで分析を行う必要があります。 監視する項目 ・CPUのボトルネックと使用状況 ・メモリのボトルネックと使用状況 ・ディスクのボトルネックと使用状況 ・ネットワークのボトルネックと使用状況 スループット スループットは単位時間(秒)当たりにシステムが実行できる処理数 ボトルネック ボトルネックは、システムが処理を行っている時にリクエストからレスポンスを返す過程で滞留を起こしスループットの低下の
Apacheのチューニングメモ - Qiita
個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい！ prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 （以下正確ではないですが簡単に） Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
偽一茶 BLOG IT職人 : DeadLockしているSQLの見つけ方 - livedoor Blog（ブログ）
プログラムマネージャー Ruby,Rails , Project Management, Cruise Control, Inspection,Testing Framework パフォーマンス（性能）試験をしているといろいろなことが起きます。 試験中にでることによって、運用環境前に問題をつぶすことができるため非常に有用ではあります。 最近だと、ヨドバシカメラの件が新しいパフォーマンスの問題になるでしょうか。 ああいった問題も、パフォーマンス試験をしていればあんなことにはならなかったはずです。 それもトップページですから、テスト抜けではなくてまったくやっていなかったのではないかと考えてしまいます。 さて、デッドロックのお話です。 ASP.NET では、デッドロックが発生するとイベントログのアプリケーションのところに例外としてデータが残る訳なのですが、これだけですと 発生した片方のソースの場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
