[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Condor advise
the schedd is really the CPU hungry thing on condor.
We run 1300 nodes with a Dual Xeon 2.8Ghz and 2GB of Ram (Negotiator and Schedd). The Collector is running on a 1Ghz P3 with 2GB of Ram. For the Ram, I would calculate at least 1MB per shadow (so 2GB if you want some caching) and for the CPU, the higher the spec, the better. Please keep in mind, that the schedd is a single threading program (so hyperthreading / dual cpu will not use you anything for the schedd). A dual CPU will be helpful if you run more on the system then just a schedd e.g. negotiator and collector or some servers (quill, postgres, NFS, etc).
You can also have more then one submitter in your pool. All of them will need WRITE_ACCESS to your machines.
If you scale up you might want to increase some limits (file descriptors etc). I wrote about this on an earlier post to the list. You can find the email here:
University of Plymouth
> To all condor-experts/users
> I'd like to know what the requirements are for sumbission machines to a
> We now have approximately 60 cpu's in our grid and with 60 jobs at a
> time, the submitmachine could be very busy as scheduler and
> What happens if we grow to maybe 300+ cpu's ? Should we then use a high
> performance submission machine for example? I've read something about
> that a sheduler machine can starve for cpu time?
> So what's the critical success factor for such a grid?
> Could you give advise in these and is it possible to suggest how to
> build a sophisticated gridcomputing system.
> We work at the university with MS Windows systems and mostly Fortran
> applications for gridcomputing.
> Kind regards,
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> The archives can be found at either