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(a)gmail.com
On 5/15/2012 6:38 PM, Marcin Cieslak wrote:
Krinkle<krinklemail(a)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(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette