最近、ゲームサーバーの配備状況の背景を見て、私はそのようなパフォーマンスがある理由ですがかく乱を見てみましょう、私はCPUによって占有されたJavaプログラムの100％以上の成長時に、調査が実際にかく乱によって引き起こされたたことがわかりました。
プロセスの100％以上のCPU時間のことがわかりました
まずトップためにサーバーとの状態を確認、アプリケーションによって占有される時間よりも100％長く発見したCPUは、図に示されています：
私は、プロセス番号ビットに従ってチェックし、私のゲームのJavaバックグラウンドサービスを見つけ、CPUがあり、ほぼ満杯であるため、このような状況に至ったコードが何であるかを解決し続けます。
使用するtop -Hp 27538CPU使用時間の順序に従って、このプロセスのすべてのスレッドが表示され、この結果を参照してください。
27658スレッドは、ほとんどすべてのCPU時間のを占めており、常にこのプロセスの詳細を表示するので、されています。
jstack pid > pid.logダウンロードされたスナップショット出力ファイルの処理にため。
27658は16進0x6c0aクエリに変換（スレッド六角スレッドIDが格納されるため、スナップショットので、変換する必要がある）スレッドのスナップショットになります。
"disruptor-0" #27 prio=5 os_prio=0 tid=0x00007fa100c58000 nid=0x6c0a runnable [0x00007fa0ae080000]
java.lang.Thread.State: RUNNABLE
at com.lmax.disruptor.BusySpinWaitStrategy.waitFor(BusySpinWaitStrategy.java:39)
at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
at java.lang.Thread.run(Thread.java:748)これは、より良いスレッドのステータス情報を可視化するために、専用のスナップショットにアップロードすることができ、スタック破砕ある分析プラットフォーム。
（ブロガー自身スナップショット分析のためには、あなたが任意の提案や意見を持っている場合は、以下のコメントを残してください、初心者の段階のプロセスでもあります。）
なぜかく乱分析は全体のCPUを占有します
スナップショット上記の分析によると、かく乱が実際にスレッドに関連するポリシーを保持していることを表示させBusySpinWaitStrategyたクラスを、指示を見つけました：
* This strategy will use CPU resource to avoid syscalls which can introduce latency jitter. It is best
* used when threads can be bound to specific CPU cores.今、私たちは最終的に知っている、元はこのための戦略である結合スレッドのCPUコアを作ることです、その自然のCPUの使用時間の100％以上。
概要
Linuxシステムのプロセスを理解するだけではなく、問題のトラブルシューティングこの時点で、関係のスレッドは、これも以前にかく乱接点を持っていたもの見直しの方法により、調査Javaのオンラインサービスを開始しました。あなたが任意の提案や意見を持っている場合は、以下のコメントを残してください。
私の公共の番号を追跡することができます興味を持っている、多分驚きがあるでしょう。
