Benpianは、3つの質問の合計を引き起こしました：
1、ulimitの調整（そうでなければ、デフォルトのプロセスのみ1024個のスレッドを作成することができます）
2、XSSの設定（XSSメモリ、ここで設定されたデフォルトのスレッド1Mは、246Kにスレッドによって占有しました）
メモリ不足が理由、または調整はulimit OOMの存在後の問題でも、メモリは我々はすべてここに問題を認識しているに比べてメモリ（外ヒープで占められ、このサービスを通し、そして最終的に発生し、このスレッドスタックの問題の外の説明3。 ）
注：（スレッドのJavaの各インスタンスは、オペレーティングシステムがローカルメモリのサーバーインスタンスに要求され、ヒープメモリのサイズは、JVMで直接使用されていない注目されるように構成された,,,）
オンラインダイレクトメモリ分析を使用する場合は、同様の問題がこれであるがありました、
ラインサーバコ8Gメモリ、PS -efによって| grepをjavaの、あなたは、3つのサービスの展開、合計を表示することができます
最初の二つのロボットサービスがのXms 2G、3GなどのJVM -Xmsのため、当社のコアセットのパラメータに設定されました
この時点で、それはサーバ自体を削除してから食べ500Mメモリ、7Gメモリを食べてきた、メモリはこの時点でのみ利用可能です
サーバが異常に頻繁にエラーた時500Mほど、
新しいネイティブスレッドを作成できません、最初に疑わLinuxサーバが設定
プロセスは、スレッドの原因少ない数を開くのulimitに-a発見を見ることができ、サーバが最適化されていない、デフォルトのパラメータ値はulimitが、1024 -u確かに値番号を作成するために、最大スレッドLinuxサーバを調整されていないことを、
この時点では、Linuxの-u 10240のパラメータを調整することで、作成できるスレッドの既存の番号は10で乗算され、
それを言及する必要があります（この場合には、JVMは、スレッドセット、この時点で設定するための単一のスレッドのスタックメモリのための246Kであります小さなメモリフットプリント、
より多くのスレッドが）の数がOKであることを保証するために作成することができます
インスタンス化の作成でJavaスレッド、サーバーへのオペレーティングシステム用のアプリケーションメモリ：セットのulimitパラメータのこの時点で、一日かけて、ローカルスレッドの作成は、チップのメモリ例外を失敗した理由が確認され、この時間を繰り返しスレッドの作成は、ので、この場合の問題はすでに明白であることができ、作成するJVMのヒープメモリ空間を使用するように設定されていませんが、また残りの500M基本的なサーバのメモリは、スレッドの数を作成するのに十分ではない、と3の展開プロジェクトの場合は、突堤3つの容器を開けました
同時に実行されている3つのプロジェクトは、オープンスレッドの数は、解決策は、この時点であるので、十分ではありません500Mメモリ、でなければなりません
サーバーのメモリを増やす1.アプリケーション、
2.は、JVMの三個の容器の構成パラメータを再調整しました
その小さな曲JVMヒープメモリ構成、スレッド、-Xms調整と-Xmxヒープメモリのコンフィギュレーションを作成する使用のための大きい余剰サーバメモリ、
もちろん、それはXmxのヒープメモリ構成を調整されているので、同期はまた、若い世代を調整し、XMN構成、
ここでは3の私たちの基本的な配分比率：1、である、ヒープメモリの割合は、若い世代を設定します