You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a lot of fancy resource monitoring now so that if a user's initial guess is wrong, we update categories accordingly. But if the user's initial factory configuration is wrong, they still have to look at their plotting page or logs and manually translate that information into an optimal factory configuration. We could add a command such as:
lobster factory config.py factory.json
That would open up factory.json and update cores, memory, and disk with the optimal values based on the best guesses from the resource monitor, with a simple algo for trying to get the 'lowest common denominator' of resources across categories (although eventually we may want to talk to the cctools team about the possibility of having multiple core/memory/disk combinations in a single factory to optimize packing). We could allow the user to pass a cores argument so that they could have a higher-core config version for the ND pool (where we're running Parrot, and caching matters more) vs the T3 pool.
The text was updated successfully, but these errors were encountered:
Totally in! We could even do that on the fly? I think that the cores option would be a must-be. I think we still want to minimize the amount of workers to not overload communication with the master, even when running on our T3.
How about providing a few options to the user to choose from? It could be max resources adjusted for cores, or a mix with proportional allotment, i.e., lowest common denominator adjusted for cores with proportional adjustment according to expected tasks per category? Display them and have the user choose from 1-n, as they still have the best idea what will fit on the cluster?
We have a lot of fancy resource monitoring now so that if a user's initial guess is wrong, we update categories accordingly. But if the user's initial factory configuration is wrong, they still have to look at their plotting page or logs and manually translate that information into an optimal factory configuration. We could add a command such as:
That would open up
factory.json
and updatecores
,memory
, anddisk
with the optimal values based on the best guesses from the resource monitor, with a simple algo for trying to get the 'lowest common denominator' of resources across categories (although eventually we may want to talk to the cctools team about the possibility of having multiple core/memory/disk combinations in a single factory to optimize packing). We could allow the user to pass acores
argument so that they could have a higher-core config version for the ND pool (where we're running Parrot, and caching matters more) vs the T3 pool.The text was updated successfully, but these errors were encountered: