This text governs the conditions under which processes that are more demanding on system resources (memory, CPU, disk operations, etc.) or are of a more long-term nature, etc., may be run on generally available shared faculty machines.
When running such processes, it is generally necessary to take care that you do not have exclusive access to the faculty machines and that other users can use them at the same time (this is particularly relevant for Aisa). Therefore, it is necessary to run such processes in a considerate manner, in particular so that interactive users are not restricted. This can be done by following the instructions below.
For larger scale computations (duration in days, multiple machines, CPU intensive) it is also necessary to report them with a brief justification and duration to
For non-repetitive short-term processes or when you are interactively debugging your programs, these instructions do not need to be applied. Also, running calculations on Aura works in a different mode and not all the restrictions described here apply.
Faculty machine administrators continuously monitor machine usage. If notified by an administrator, the generated load should be reduced. Processes that are not reported or are placing excessive load on the machine(s) may be terminated without notice. Also, in the event of repeated or serious non-compliance with the instructions herein, administrators may proceed to temporarily block the account.
It is undesirable to run calculations on machines in classrooms that are directly used for teaching (Nymfe23-74 and sometimes Luna01-12) during teaching or potential testing times, i.e. generally between 07:45-20:15. However, it is generally best to run calculations only at night if possible.
If the calculations are of a longer term nature and are part of a research or thesis, it is advisable to use the Aura computation server designed for this purpose. If you do not have access to one, you can request one if justified by contacting
For CPU-intensive processes, you should set them to the lowest priority of +19, for example by using
nice -n +19 ./program
It is also possible to restrict the running of process threads to only specified CPU cores with the command
taskset -c 1-2,4 ./program
If the running process generates a higher I/O load with disk operations (random access, large transfers), it is advisable to place files with such access in a folder on the local disk (
/tmp), not in the home directory (
/home/xlogin), since this is accessible over the network via NFS and the volume on which the data is located is also used by other machines.
The amount of memory used by processes running from a single shell instance can be limited when running more memory-intensive computations by using the
ulimit -v command as a precaution against running out of or overusing memory. You can also set a limit on the time consumed by a process by using the
ulimit -t command ; if the limit is exceeded, the process will terminate with a KILL signal. For more information about this command and its other options, see the
help ulimit command or the documentation for the
setrlimit system call.
During computations, it is advisable to continuously monitor the state or load of the machine (disk, memory, I/O, load, process state), for which the following tools are used, for example:
top, htop- summary information about the system and its processes
ps ux- listing information about my processes
iostat- listing information about I/O operations
who- listing of logged-in users (relevant only for machines in classrooms and halls)
df- disk volume capacity usage