0

Rackspace をホスティング プロバイダーとして使用し、クラウド サーバー ホスティングを使用して、256 MB プランを使用しています。

Geronimo 2.2 を使用して Java アプリケーションを実行しています。

サーバーは問題なく起動し、Geronimo を非常に高速にロードしますが、Web アプリケーションのデプロイを開始すると、非常に時間がかかり、一度デプロイすると、ページをナビゲートするのに永遠に時間がかかります。

サーバー アクティビティを監視しており、CPU はそれほどビジーではありませんが、メモリの 60% が使用されています。これが問題でしょうか？

もしそうなら、私の選択肢は何ですか？このクラウド サーバーをより多くの RAM を備えたものにアップグレードするか、ホスト プロバイダーを自分のニーズにより適したものに変更することを検討する必要がありますか?

編集: アプリケーションをデプロイせず、Geronimo をロードしただけでも、Geronimo をシャットダウンしようとすると接続時間がかかる場合があることに注意してください。

また、データベースはアプリケーションと同じサーバー上にあります。（ただし、クエリが集中しているとは言いません）

更新:
@matiu が提案した後、free -m を実行してみました。これが出力です。

             total       used       free     shared    buffers     cached
Mem:           239        232          6          0          0          2
-/+ buffers/cache:        229          9
Swap:          509        403        106

これは、 ps uxを実行した場合とはまったく異なる結果でした。これにより、以前の 60% を取得できました。

iostat チェックを行ったところ、約 25% の iowait 時間で、デバイスは常に書き込みと読み取りを行っていました。

更新:
私のホスティングを 512MB にアップグレードしました。注意すべきことは、Geronimo でも使用されている Java の Permanent Generation メモリーのことを忘れていたことです。そのため、より多くの RAM が必要であり、より多くの RAM で問題が解決したことがわかりました。(さすがに) わーい。

4

3 に答える 3

1

私はあなたが「スワッピング」に出くわしていると推測しています。

ご存じのとおり、Linux はメモリの一部をディスクにスワップ アウトします。これは、あまりアクセスされないメモリに最適です。

Java がヒープとヒープを使い始めると、Linux が起動します。

  1. メモリ ブロック A をディスクにスワップして、ブロック B を読み取るためのスペースを作る
  2. ブロックBの読み書き
  3. ブロック B をディスクにスワップして、他のブロック用のスペースを確保します。

ディスクは RAM よりも数千倍遅いため、メモリ使用量が増加すると、マシンはますます停止に近づきます。

256 MB のクラウド サーバーでは、512 MB のスワップ スペースが得られます。

チェック中：

これが当てはまるかどうかは、free -m..このページで確認できます。このページでは、出力の読み方を示しています。

次に、「iostat 5」でスワップ パーティションのディスク IO レートを確認します。300 以上の書き込み速度は、水に浸かってほとんど死んでいることを意味します。スワップ パーティションの書き込み速度を 1 秒あたり 50 ブロック未満に、読み取り速度を 1 秒あたり 500 ブロック未満に抑えたいと思います。可能であれば、両方ともほとんどの場合ゼロにする必要があります。ディスクは RAM よりも数千倍遅いことに注意してください。

JavaがRAMを食べているかどうかを確認するには、実行topしてヒットshift+mし、メモリ消費量でプロセスを並べ替えます。

必要に応じて .. でスワップ パーティションを無効にすることができますswapoff -a.. 次に、Web コンソールを開き、サイトに少しアクセスします.. コンソールに「OOM Killed process xxx」のようなエラー メッセージがすぐに表示されます (OOM はメモリ不足だと思います）。Linux がプロセスを強制終了してメモリ要求を満たそうとしているのを見たら。それが起こったら、ハードリブートするのが最善です。

修正:

RAMを使用しているJavaの場合..このリンクが役立つ場合があります。

簡単な修正は、クラウド サーバーのサイズをアップグレードすることだと思います。

別の Java RTE の方が優れている場合があります。

32 ビットの chrootで実行すると、使用する RAM が少なくなる場合があります。

于 2012-01-05T11:05:18.777 に答える
0

linode などから仮想専用 Linux サーバーを実行することを検討する必要があります。Java サービスの開始方法やファイアウォールなどについて心配する必要がありますが、いったん正しく設定すると、事実上、独自のホスティング プロバイダーになり、スタンドアロンの実際の Linux ボックスで実行できることは何でも実行できるようになります。 .

メモリに関しては、十分ではないという証拠が得られるまでアップグレードしません。60% 使い切られても 100% 使い切られません...

Java は通常、割り当てられたものは何でも取得できると想定しています。つまり、最大 200MB を指定すると、使用量がはるかに少なくても 200MB を使用しても問題ないことがわかります。-Xincgc インクリメンタル ガベージ コレクタを使用して、Java のメモリ使用量を減らす方法があります。実際には、不要になったときにシステムにメモリのチャンクを返すことになります。これは実際にはちょっとした秘密です。これを指摘する人はいないでしょう...

于 2012-01-05T07:17:06.217 に答える
0

私の経験に基づくと、VPS のメモリと CPU 負荷はかなり関連しています。つまり、アプリケーション サーバーが使用可能なすべてのメモリを占有すると、CPU 使用率が急上昇し始め、最終的にアプリケーションにアクセスできなくなります。

ただし、これは単なる副作用です。問題の原因を調査する必要があります。

メモリ消費量が非常に多い場合は、複数の原因が考えられます。

  1. これは正常なことです。おそらく、すべてのプロセス (アプリケーション サーバー、その中のアプリケーション、バックグラウンド プロセス、デーモン、オペレーティング システムなど) をまとめると、膨大な量のメモリが必要になるところまで来ているのでしょう。これは最も可能性の低いシナリオです。
  2. メモリ リーク - フレームワークまたは一部のライブラリ (可能性は低い) または独自のコード (可能性) のバグが原因で発生する可能性があります。これは、監視して解決できます。
  3. 膨大な量のリクエスト - 各リクエストの処理には CPU とメモリの両方が必要です。1 秒あたりのリクエスト数とメモリ消費量の相関関係を確認できます。つまり、監視して解決することができます。

CPU 使用率に関心がある場合:

  1. ここでも、アプリケーションへのリクエストを監視します。リクエストの数が一定の場合 - 特別なことは何も起こらないはずです。
  2. 1 つのコンポーネントがほとんどのリソースを使い果たしています (データベースが同じサーバーにインストールされていて、非効率的なクエリのためにすべての CPU パワーを使用している可能性がありますか? スロー ログが役立ちます)。

ご覧のとおり、これは簡単な作業ではありませんが、役立つツール サポートがあります。私は個人的にJava メロディーとプローブを使用しています。

于 2012-01-05T07:23:08.503 に答える