0

現在、自家醸造バッチ プロセッサを Gearman に置き換えることを検討しています。数百メガのメモリ (PHP) を必要とするレポートを実行します。そのため、これらのレポートを実行しすぎると、サーバーがロックされます。メモリが少なくなり、サーバーが過負荷になり、サーバーがクラッシュした場合に、制御プロセスが多くのワーカーに生成されるのを防ぐために、ロジックを追加する必要がありました。

Gearman に切り替えた場合、システム メモリが少なくなった場合に追加のワーカーを防ぐための何らかのロジックが用意されていますか? ワーカーを制限するオプションが表示されますが、これで問題が直接解決されるわけではありません。さらに、1 つのシステムが圧倒された場合に、システム間でワークロードのバランスをとるのに十分スマートですか?

他の人はどのような推奨事項を持っていますか? 条件が整ったときに、独自のチェックを Gearman に挿入してワーカーを生成することはできますか? または、他にどのような解決策がありますか?

LAMP スタックで開発していますが、Gearman にはあまり詳しくないので、必要に応じて非難してください。

4

1 に答える 1

1

ワーカーの数を制限することが有効です。レポートで 3 ~ 400 MB のメモリを使用することが予想される場合は、ワーカーの数を 400 MB 程度に制限してください。

メモリ使用量が予想よりも少ない場合、Gearman 自体を拡張してワーカーを生成することはできませんが、ワーカーを処理してそれを行うラッパーを作成することはできます。そのルートに進む前に、GearmanManagerを拡張してそのような問題を処理する方法を確認してください。ただし、私の提案は、そのままにしておくことです。代わりに、予想される負荷の種類を正確に経験してから、ワーカーの数を調整することをお勧めします (レポートのリクエストがどれだけ速く受信されるか、レポートのメモリのサイズの両方)。レポートを要求しているユーザーへの応答がどれだけ迅速に必要か)。

Gearman は、最も応答性の高いサーバーに自動的に負荷分散します。タスクが Gearmand に到着すると、使用可能なすべてのワーカーをポーリングし、新しいタスクが到着したことを通知し、最初に応答したクライアントがタスクを取得します。これは、サーバーに負荷がかかると、リクエストへの応答が遅くなり、タスクは通常、処理能力の高いサーバーで終了することを意味します (ネットワーク遅延の差異は無視します)。これにより、さまざまなサイズのサーバーも自動的に処理されます。

于 2012-07-23T09:19:14.693 に答える