[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HTCondor-users] Best practices for leaving cores/memory available for machine OS



I’m running an HTCondor pool in which all machines are available to run tasks at all times, i.e., they do not become unavailable when the keyboard or mouse is moved on those machines. I’m interested to know what the best practice is for setting up resource slots on these machines. By default, HTCondor seems to create one slot per core and evenly divide the machine’s memory among the slots. For example, one of the machines in the pool has 8 GB of RAM and 2 cores, and HTCondor created two slots on that machine, each with 1 core and 4 GB of RAM.


My worry is that in the event that both of these slots are 100% utilized by user-submitted jobs, this leaves no cores or memory free for the operating system itself, the Condor daemons, etc. What is the standard practice here? Do HTCondor pool administrators typically customize the slot allocation on worker machines to leave 1 or 2 cores and some fraction of RAM free for the OS itself, or is HTCondor’s default behavior of evenly dividing all the resources of the machine among the job slots considered to be a reasonable default?


By the way, all servers in this pool are running Windows, in case the best practice here depends on the underlying OS.



Jesse Farnham

Disclaimer: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please notify the sender immediately and destroy/delete this e-mail. You are hereby notified that any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly prohibited.

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All information contained in this communication is not warranted as to completeness or accuracy and is subject to change without notice. Any comments or statements made in this communication do not necessarily reflect those of AQR Capital Management, LLC and its affiliates.