I'd prefer reasonably high "hard" limits - if someone does need more space, they can request it from the sysadmins. Quite frankly, if people are over-using resources intentionally now, there's nothing to say they won't continue to do so in future given the chance.
---- User:Hersfold hersfoldwiki@gmail.com
On 5/15/2012 6:38 PM, Marcin Cieslak wrote:
Krinklekrinklemail@gmail.com wrote:
On May 14, 2012, at 11:31 PM, DaB. wrote:
Hello all,
the resources on the TS are free, but limited; so we all have to use the resources fair. Some limits (like memory-usage) are set and controlled by the system, but others are not and it is in the responsibility of every single user to make sure to not mis- or overuse resources. So it is for example NOT a good idea to run 200 processes in parallel to get more CPU-resources than you would normally get. And it is not a good idea to use a amount of memory which is just below the slayer-daemon-limit without any purpose.
It would only be reached if: * The user might accidentally run a proces that is taking more than he expected. The limit would kill the problem before it runs out of hand. * The user might be misbehaving. The limit is working against that. * The user might be hosting a tool that naturally takes more space. He requests the additional space and explains why he needs it. In most cases this will be granted without any problems.
UNIX has a good infrastructure to do that already. See limit(1), setrlimit(2). Actually Solaris (in comparison to Linux) is much more flexible in working with resource assignement for projects.
What could be done is to set "soft" memory, number of processes, maximum running time of a process and other limits by default.
Users, if there is a legitimate need, could raise those limits themselves (like, "I need 2GB of RAM for my PHP process to run MediaWiki unittests now").
Right now I don't see any limits on willow:
willow$ ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 10240 coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited
If this would be abused, "hard" limits can be introduced, which cannot be overriden by user.
Also, system accounting could also be enabled (see sar(1), sar(1M)) to regularly report on all resources used by users in the system.
Process accounting (see acct(1M)) also provides a valuable information about what was run by users and when.
Solaris has even ready cron scripts to prepare daily reports to summarize the information and send them by email.
//Saper
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette