Matthew,
this is generally a bad idea :
many users are logged into the login node, some of them run a graphic
desktop in VNC, they sometime
start (heavy) compilation and once in a while, they even run a
(hopefully) small MPI application so they do not have to use the batch
manager (e.g. write a script and wait for the resources)
head node can also run several monitoring daemons (not to mention a NFS
server) and this node can be quite "noisy" (OS jitter). once in a while,
some end users will just ask too much memory and the oom killer will be
invoked (and it sometimes kill process you do hope it spared)
bottom line, it is virtually impossible to predict how much RAM and CPU
will be available when a job runs.
most MPI applications are synchronous, which means the performance is
driven by the slowest node.
The head node might or might not be the slowest node, this is quite
unpredictable and end users will likely end up complaining about random
performances of their application.
if your budget allows it, i strongly recommend you do not run jobs on a
head node.
that being said, you might consider running an "overflow" queue but only
for single node jobs on the head node
Cheers,
Gilles
On 4/14/2016 4:57 AM, Matthew Larkin wrote:
Has anyone in the users list conducted any kind of analysis about
using a head node as a compute node in a distributed system?
Does it effect resources, or simply chance performance in any way?
Thanks!
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2016/04/28934.php
