2

私は Netty ベースの TCP サーバーを開発して、GSM/GPRS ベースのデバイスとの接続を維持し、それらのデータを MySql データベースに保持します。現在、5K 接続が処理されています。デバイスは 30 ～ 60 秒の間隔で定期的にメッセージを送信しますが、二重通信を維持するために接続は維持されます。

サーバー アプリケーションは、通常の操作で 1 ～ 2% の CPU を消費し、最大 10% のピークがあり、平均負荷は非常に低いです。ただし、6 時間から 48 時間の通常の操作の後、サーバー アプリケーションは一定の 100% の CPU 消費でハングアップし、スレッド ダンプは epoll セレクターが CPU 使用率が高い理由であることを示します。アプリケーションはまだ数時間接続を維持し、その後 CPU 消費が 200% に増加し、ほとんどの接続が解放されます。

プロジェクトの開始時に MINA を使用しましたが、1K のアクティブな接続で同じ問題が発生したため、Netty に切り替えました。5,000 接続まで、Netty ははるかに安定しており、ハングアップ期間は 1 ～ 2 週間でした。

私たちのサーバー構成:

  • I7-2600 クアッドコア CPU、
  • 8 GB RAM、Centos 5.0、
  • JDK 6.0 を開きます。
  • Netty 3.2.4 (Netty は数時間前に 3.5.2 に更新されました)

この問題を克服するためにJDK、7.0 に更新し (JDK非同期操作用に最適化された新しい I/O 実装を備えています)、FreeBSD、Windows Server などのさまざまな OS を試します。これは、オペレーティング システムごとに I/O の処理方法が異なるためです。

どんな助けでも感謝します、ありがとう..

4

1 に答える 1

0

これは Epoll バグのように聞こえます。

アプリはバックエンド システムへの接続をプロキシしています。プロキシには、バックエンド システムにリクエストを送信するために使用できるチャネルのプールがあります。プールのチャネルが不足している場合、プロキシに送信されたリクエストを処理できるように、新しいチャネルが生成されてプールに入れられます。プールはアプリの起動時に読み込まれるため、CPU が急増するのにまったく時間がかかりません (アプリのライフサイクルの 22 秒)。Source

Netty には回避策が組み込まれています。ただし、どのバージョンからかはわかりませんが、後で更新する必要があります。 

System.setProperty("org.jboss.netty.epollBugWorkaround", "true");
于 2015-05-15T14:50:09.403 に答える