Googleコンピューティングエンジン上で実行される分散型の相互依存タスクをスケジュール設定する。途中で作業員を追加してインスタンスを開始すると、タスクはスケジューリングされません（ただし、スケジューラーには問題ありません）。私は（http://distributed.readthedocs.io/en/latest/scheduling-state.html#distributed.scheduler.decide_workerから）ためであると推測：「。これは、労働者の占有に優先しますタスクは、我々は労働者との間で送信されるバイト数を最小限にすることを選択した後、データ通信を必要とする場合は、」データ通信の代わりに純粋にアイドルに基づいてタスクをスケジュールする
タスクツリーを途中で実行すると、残りのタスクはすべて、すでに実行されているタスクの結果に依存します。したがって、上の見積もりを解釈すると、新しい従業員は、従属データが決してそこに存在することはなく、常に「古い」従業員であるため、どれくらい空いていてもスケジュールされることはありません。
ただし、転送するデータの量はかなり少なく、通常は小さな文字列であることを確認します。したがって、この場合、データ通信よりも怠惰が優先されるようになると、はるかに意味があります。 ？？
その複雑化：（例えば「スケジューラポリシー」を設定したり、多分調整することができ、コメント＃1の後
アップデートデータ-VS-怠惰トレードオフの係数を持ってできるようにすることも可能ですfactor：すべてのタスクがリソースフレームワークを使用して、CPUバインドタスク用のワーカーセット（「CPU = 1」）またはネットワークバインドタスク用のワーカーセット（「NET = 1」）のいずれかで実行されていることを確認します。この分離は、サーバのアップロード/ダウンロードの過負荷を避け、最大/ダウンロードタスクを特定の最大値に制限する一方で、他のタスクを拡張することができるようにするために行われました。 tを維持しながらタスクを盗む方法彼は資源の制限？
更新2：公開されている問題は、https://github.com/dask/distributed/issues/1389です。これを実装する計画はありますか？
ああ、その後、それは問題になる可能性があります：「タスクは、特に、特定の労働者上で実行するように制限されている場合（たとえば、特別なハードウェアが必要な場合のように）盗むことはありません。すべての私のタスクにはカスタム制限があります.CPUバインドタスクまたはネットワークバインドタスクのために異なる作業者セットがあるためです.CPUワーカーにネットワークバインドタスクを実行させたくありません。 ）、逆の場合（CPU接続のタスクを最大接続数以上に拡大できるようにするため）。この状況を反映するために質問を更新します。 –