我有一個用獨立的python進程實現的master/worker模型。主進程保存受互斥鎖保護的作業/結果列表。許多工人在許多機器上運行(大約200個工人進程)。主/工比例?
我注意到,在每臺機器上,工人的工作量往往比其他工人的工作量多出0-20%,機器的工作量比其他工人的工作量多出0-20%。最快/最慢的工人和機器每天都不同。
這是一個主/工模型的概念性問題,它是否提示有問題的實現或一切都很好?
我有一個用獨立的python進程實現的master/worker模型。主進程保存受互斥鎖保護的作業/結果列表。許多工人在許多機器上運行(大約200個工人進程)。主/工比例?
我注意到,在每臺機器上,工人的工作量往往比其他工人的工作量多出0-20%,機器的工作量比其他工人的工作量多出0-20%。最快/最慢的工人和機器每天都不同。
這是一個主/工模型的概念性問題,它是否提示有問題的實現或一切都很好?
對於+/- 20%的事情,最簡單的解釋是您看到負載平衡問題;一些工人的工作比同齡人多20%。這可能代表一個實施問題,或者它可能只是離散的;如果你有200個工作進程,但有1040個大致相同的工作要做,那麼1/5的工作進程將會有額外20%的工作要做,除非你能細分工作,否則沒有什麼可以做的。更精細。
主/員工擴展(並像其他任何事情一樣處理這些負載平衡問題),直到主進程中共享資源的爭用開始變得不平凡。通過將關鍵部分(受互斥鎖保護的部分)減少到絕對最小值,您可以稍微向前推進縮放;通過聚合工作單元以減少請求(但注意到這與改善負載均衡的相反方向一致);或者擁有多個主人(可能是主人的等級)。如果這不起作用,則必須開始考慮更多的對等工作調度算法,其中不再存在單個瓶頸。一個對等的模擬大師/工作者被稱爲work stealing,這是(恕我直言)似乎不應該工作,直到有人向你顯示它的事情之一;它最近已被Cilk推廣。這個想法是,每個人都可以得到一份任務清單,如果同伴需要更多的工作,他們會隨機偷取它們,並繼續徘徊直到完成任務。實現比主/工更復雜,但避免了單主瓶頸。
工作人員尋找下一個工作單元時碰撞發生的頻率如何?數據輸入和輸出的大小和預期的處理時間是否相同?有很大的I/O還是全部受CPU限制? – 2010-10-25 14:12:49