オンライン高並行性サービスは、大きな川のそばに静かに立っている堤防のようなものです。洪水の影響にいつでも対処する準備が整っています。オンライン高並行性サービスのスレッドプールは、次のような多くの問題も引き起こします。 、高いCPU使用率、サービススレッドのハングなど。これらは、スレッドプールの不適切な使用、または保護と機能低下の適切な処理の失敗が原因で発生します。
もちろん、一部の小規模なパートナーはスレッドプールを保護する考えを持っていますが、そのような経験と印象はありますか。スレッドプールのスレッドがより多く設定され、パフォーマンスが低下する、設定が低下する、またはパフォーマンスが低下する場合があります。どのように設定すればよいですか。スレッドプールはどうですか？
小規模パートナーの何年にもわたる設計レビューの結果、小規模パートナーは経験と直観に基づいてスレッドプール内のスレッド数を設定し、オンラインの状況に応じて数を調整して、最終的に最適な値を見つけることがわかりました。これは経験によるものです。機能する場合もあれば機能しない場合もありますが、機能する場合もありますが、最適な数の設定を見つけるには多大な費用がかかります。
実際、スレッドプールの設定は十分な根拠があり、理論的な計算に基づいて設定できます。
まず、理想的な状況を見てみましょう。つまり、処理されるすべてのタスクは計算タスクです。現時点では、スレッドの数はCPUコアの数と同じである必要があります。各CPUがスレッドを切り替えずにスレッドを実行するようにすると、効率が最高になります。もちろん、これは理想的な状況です。
この場合、一定量のQPSを実現したい場合は、以下の計算式を使用します。
スレッド数の設定=目標QPS /（1 /実際のタスク処理時間）
たとえば、ターゲットQPS = 100、タスクの実際の処理時間は0.2秒、100 * 0.2 = 20スレッドであるとします。ここでの20スレッドは物理的な20 CPUコアに対応している必要があります。そうでない場合、推定QPSインデックスには到達しません。
しかし実際には、インメモリコンピューティングに加えて、オンラインサービスはデータベース、キャッシュ、外部サービスへのアクセスに関するものであり、ほとんどの時間はIOタスクを待機しています。
IOタスクが多い場合は、アムダールの法則を使用して計算します。
スレッド数の設定= CPUコア数*（1 + io /コンピューティング）
たとえば、4コアCPUを想定すると、各タスクのIOタスクはタスク全体の80％を占めます4 *（1 + 4）= 20スレッドここでの20スレッドは4コアCPUに対応します。
スレッド内のスレッド数の設定に加えて、スレッドキューサイズの設定も非常に重要です。これは理論的な計算からも取得できます。ルールは、目標の応答時間に従ってキューサイズを計算することです。
キューサイズ=スレッド数*（対応するターゲット時間/実際のタスク処理時間）
たとえば、ターゲットの対応する時間を0.4秒とすると、ブロッキングキューの長さは20 *（0.4 / 0.2）= 40として計算されます。
また、スレッドプールの数を設定する場合、次のベストプラクティスがあります。
-
スレッドプールの使用では、スレッドの最大数とスレッドの最小数を考慮する必要があります。
-
シングルパートサービスの場合、スレッドの最大数はスレッドの最小数と同じである必要があり、混合サービスは最大数と最小数の間のギャップを適切に広げて、CPUコアの全体的な使用率を調整できます。
-
スレッドキューのサイズは制限付きキューに設定する必要があります。そうしないと、プレッシャーがサービス全体を圧倒します。
-
スレッドプールは必要な場合にのみ使用し、設計パフォーマンスの評価とストレステストを実行する必要があります。
-
スレッドプールの障害戦略と障害後の補償を考慮する必要があります。
-
バックグラウンドのバッチ処理サービスは、オンラインのユーザー指向のサービスから分離する必要があります。