rsnt_translations
56,430
edits
No edit summary |
No edit summary |
||
Line 29: | Line 29: | ||
<!--T:217--> | <!--T:217--> | ||
Note that all Gurobi license checkouts are handled by a single license server located in Ontario; it is therefore important to limit license checkout attempts as much as possible. Rather than checking out a license for each invocation of Gurobi in a job---which may occur dozens or even hundreds of times---you should ensure that your program, whatever the language or computing environment used, only makes a single license checkout and then reuses this license token throughout the lifetime of the job. This will improve your job's performance because contacting a remote license server is very costly in time; moreover, responsiveness of our license server for everyone using Gurobi will also improve. <span style="color:red">Failure to use Gurobi carefully in this regard may ultimately result in random intermittent license checkout failures for all users. If this happens, you will be contacted and asked to kill all your jobs until your program is fixed and tested to ensure the problem is resolved.</span> Some documentation on this subject for C++ programs may be found [https://www.gurobi.com/documentation/9.5/refman/cpp_env2.html here], explaining how to create a single Gurobi environment which can then be used for all your models. Python users can consult this [https://www.gurobi.com/documentation/9.5/refman/py_env_start.html page], which discusses how to implement this same idea of using a single environment and thus a single license token with multiple models. Other programs | Note that all Gurobi license checkouts are handled by a single license server located in Ontario; it is therefore important to limit license checkout attempts as much as possible. Rather than checking out a license for each invocation of Gurobi in a job---which may occur dozens or even hundreds of times---you should ensure that your program, whatever the language or computing environment used, only makes a single license checkout and then reuses this license token throughout the lifetime of the job. This will improve your job's performance because contacting a remote license server is very costly in time; moreover, responsiveness of our license server for everyone using Gurobi will also improve. <span style="color:red">Failure to use Gurobi carefully in this regard may ultimately result in random intermittent license checkout failures for all users. If this happens, you will be contacted and asked to kill all your jobs until your program is fixed and tested to ensure the problem is resolved.</span> Some documentation on this subject for C++ programs may be found [https://www.gurobi.com/documentation/9.5/refman/cpp_env2.html here], explaining how to create a single Gurobi environment which can then be used for all your models. Python users can consult this [https://www.gurobi.com/documentation/9.5/refman/py_env_start.html page], which discusses how to implement this same idea of using a single environment and thus a single license token with multiple models. Other programs that call Gurobi, such as R, can also easily trigger the problem when run in parallel, especially when many simultaneous parallel jobs are submitted and/or run. | ||
== Interactive allocations == <!--T:5--> | == Interactive allocations == <!--T:5--> |