これは非常に一般的な問題ですが、私にとってはますます頻繁に現れる問題です。私はこの一般的な状況に対して適切な措置を決定しようとしています。これは、今後私と他のシステム管理者に役立つと思うからです。しかし、すべての場合の共通分母はjavaです。私がスタックオーバーフローの代わりにここでこの質問をするのは、これがシステム管理者の質問だからです。ここに置くのはとても適切だと思います。
1人のユーザーが私に来て、「私のアプリケーションは非常に遅いです。あなたが私に提供したサーバーのパフォーマンスが悪いです。サーバーはベアメタル、OpenVZ、またはKVMかもしれません。」すべての場合において、オペレーティングシステムはCentOS 6です。ユーザーがこれを言うのは、ページの読み込み時間（JIRA）またはベンチマークの数値を言うことです。 (Seleniumまたは専用アプリケーション)
今、サーバー自体には問題がないという恥ずかしい疑いがあります。sshサーバーに入ってみると負荷が1より少ないですね。メモリ使用量も良好で、空きメモリ範囲は2～20GBです。結局確認しiowaitてみるvmstatと0ですね。 CPUアイドル状態は99です。
Javaを見ると、topプロセスのCPU比が約200％であることがわかります。これは4〜24コアのシステムにあります。
プロセッサの割り当てはKVMやベアメタルとopenvz間違いなく違いますか？ ）クライアントでこれが発生した場合は、openvzホストkvmに移動して同様の状況を確認することもできます。 CPUアイドル率は99％です。 iowaitは0です。メモリには時々何百もの空き容量があります。
strace、およびを使用してこれらのJavaプロセスとスレッドを観察しましたstrace -f。多数のfutex、clock、epoll.grepを反転すると、ほとんどioctl、stat、sendtoが残ります。
これが発生するアプリケーション：Selenium、JIRA、その他の独自のJavaアプリケーション。しかし、いつもJavaです。
私はJavaプロセスのnicenessを調整しようとしましたが、私が知っている限り、nicenessはプロセスがスケジューリングされる方法にのみ影響します。負荷が低いと速度を上げるのに役立ちません。
たまにアプリケーションで mysql を使う場合がありますが、上部の mysql を見るとそこには CPU 使用量がほとんどないことがわかります。これがボトルネックであれば、CPU使用率が高くなると思います。
要点：サーバーはうまく機能しますが、アプリケーションが不都合であることをユーザーにどのように証明できますか？理論的には、終了しないwhileループが発生するため、アプリケーションが遅くなる可能性があります。これにより、私はこれが不可能であり、停電問題を解決するのと似ていると信じていました。 o_Oしかし、Javaをもう少しうまく機能させるように調整することもできますし、実行中のアプリケーションをプロファイリングし、コードスニペットを指し、「これが問題です」と言う方法があるかもしれません。
ベストアンサー1
シャーロック！
不可能なものが取り除かれたら、残ることはいくら不可能であっても真実でなければなりません。 --アーサーコナンドイル
まず確認したいかもしれません。これパフォーマンスの問題の原因とそれを診断する方法についての議論です。 LinuxをSmartOSと比較しますが、これは投稿の視点とは少し異なりますが、パフォーマンスの問題の原因を明らかにするのにも役立ちます。
一般に、ソフトウェアパフォーマンスの問題をデバッグするときは、同じJavaバージョン、同じカーネル、同じユーザースペースなどを使用して、別の物理システムにまったく同じソフトウェア構成を複製する必要があります。パフォーマンスの問題が存在しない場合は、物理ハードウェア、ハイパーバイザー/コンテナー階層、またはマシンのインストールの問題を調べ始めることができます。
ユーザーが以前に特定のOS /バージョン構成でソフトウェアを実行したことがない場合、これはあなたのサーバーであるとすぐに主張することはできません。むしろ立証責任を任せるそれらこれを実証するために、CentOS 6（同じマイナーバージョン、同じハイパーバイザー、およびベアメタルで実行されていない場合は同じホストOSを使用）を実行して、より良いパフォーマンスを達成できました。
パフォーマンスが良い場合は、優れたシステム仕様があります（たとえば、インフラストラクチャの低コストプロセッサの1GB KVMで動作しますが、独自の24コアIvy Bridge E5システムには8つのPCIe SSDハードウェアがあります）。 1000％高速RAID0）その後、物理ハードウェアについて話し始めることができます。物理ハードウェアが同じか非常に似ている場合は、OS/ハイパーバイザーの構成について議論を開始できます。
また、アプリケーションのパフォーマンスとユーザー数、データワークロードによっては、ユーザーに割り当てられたハードウェアが操作に十分でない可能性も考慮に入れることができます。非常に重要な顧客であり、顧客満足度を維持することがビジネスにとって重要である場合は、仮想コンテナまたはVMインスタンスに適用される制限の一部を無効にして、一時的により多くのRAMまたはCPU時間、ネットワーク帯域幅を提供できます。などを参照して役立つことを確認してください。その場合、そのワークロードで望ましいパフォーマンスを得るには、より大きな仮想マシンを購入する必要があることをユーザーに知らせる必要があります。
状況から逃げてください（あなたの問題ではないとき）
何らかの理由でユーザーが別々のハードウェアで同じソフトウェア構成を試みることを断固として拒否した場合は、アプリケーションのパフォーマンスの問題を解決するのに役立ちます（Brendan Greggが説明したように、Linuxでは困難または不可能な場合があります）。場合によっては、パフォーマンスコストを「余裕」にするか、単にユーザーが間違っていると主張する必要があります。これは、システムで開発者をサポートする不幸な副作用です。
この時点で、ユーザーとのビジネス関係が何であるかを諮問することができます。提供する場合管理されていない民間セクターホスティングでは、ユーザーコードのパフォーマンスを保証する責任がないと主張する必要があるかもしれません。
提供する場合管理する問題が間違っているかどうかにかかわらず、ソフトウェアの人々が問題を解決するようにホストしたり、他の方法で同意したりする場合は、袖を蹴り、手を汚し、より洗練されたパフォーマンス分析ツールを実行して、次のことを確認する必要があります。あなたは見つけることができます実際質問。ネットワークソケットをブロックする非常におしゃれなプロトコルですか？メモリI / Oによって制限されていますか？または、BIOSでVT-xが有効になっていませんか？リストにも多くの可能性があります。
このセクションを要約すると、次のようになります。問題解決の責任がないというビジネス的または政治的な言い訳を見つけることができれば、それはおそらく最も簡単で効果的な方法です。残念ながら、これはユーザーが問題を解決することができず、代わりに他のビジネスパートナーを見つける可能性があることを意味します。
炎のくしゃみ（問題があるとき）
共通のトピックがJavaのように見えるので、少なくとも最初に、Javaプロセス自体が非常に遅いコードを実行していることを確認できます。この目的のために、開発者/ユーザー/クライアントは理想的にはJavaプログラム（およびすべての依存ライブラリ）のソースコードを提供できます。
良い環境でプログラムを実行してみてくださいアナライザ。無料アナライザと無料ではないアナライザがあります。無料のアナライザーには例が付属しています。インターネット豆。プロファイラがアプリケーションを正常に起動して検出できるようにすることは、アプリケーションが何であるかによって難しい場合がありますが、結果はほぼ常にある程度意味があります。
もちろん、Java VM（または関連するRDBMS）が「合理的」であると考えているもの（ハードウェアと作業量を考慮している場合）よりも多すぎるCPU、メモリI / O、またはディスクI / Oを実行しているかどうかを使用および/またはhtop検出iotopするできます。これは非常に広範なツールであり、時にはパフォーマンスの問題がプログラムの内容に関連しているため、常に包括的な情報を提供するわけではありません。いいえリソースのボトルネックに関連しない可能性がある他のタスクを待っている間にこれを実行してください。これは、エンジンが正常に動作していることを確認するために自動車の始動を行うのと同じくらい一般的です。開始しないとどうなりますか？これがより深く掘り下げる必要がある場合、適切なJavaプロファイラが役に立つ理由です。
最後に、Brendan Greggが講演で話し、DTraceについて述べたことを繰り返します。 DTraceの完全な機能は、dtrace-on-linuxの再実装や競合他社（SystemTapなど）によってまだLinuxに複製されていません。つまり、あなたはできます試みる次のいずれかのツールを使用して役立つことを確認してください。一部洞察力は以下と比較できます。まったく。
もちろん、これらの「スイス軍用ナイフ」タイプのツールを使用するには、特別な専門知識が必要です。多くの経験（読み取り：試行錯誤とインターネット検索）により、ほとんどの専門知識を得ることができます。単にツールを実行して問題を指摘する問題ではありません。利用可能なデータに基づいて問題を解決する必要があります。簡単ではありません。パフォーマンスが最小化されます。