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.
Sincerely, DaB.
P.S: It is totally in the rules to disable a user-account because of resource- misusing.
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.
Sincerely, DaB.
P.S: It is totally in the rules to disable a user-account because of resource- misusing.
-- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Maybe we can handle this in a similar way we handle home directory storage. There is a default limit that should be fine for most users.
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.
Sounds like a good policy for CPU/RAM as well. Although I suppose it isn't as easy to enforce.
Although we can in SGE, right ?
-- Krinkle
Krinkle krinklemail@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
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
There have been arrangements with some projects that need a lot of space by nature, like mine, The WikiMiniAtlas. But loging in today for the first time I received a quota warning with an ultimatum to free space within 4.9 days. Since when is that active? Daniel
On Tue, May 15, 2012 at 6:32 PM, Hersfold hersfoldwiki@gmail.com wrote:
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
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
Hello At Wednesday 16 May 2012 21:28:30 DaB. wrote:
There have been arrangements with some projects that need a lot of space by nature, like mine, The WikiMiniAtlas. But loging in today for the first time I received a quota warning with an ultimatum to free space within 4.9 days. Since when is that active?
the quota-service is active since years, but to tell the true not for everybody because there are some bugs in the system. The roots plan to fix this on short-term-base and we will send another mail about this in the next days; but it should not affect you yet. But nevertheless: if you need more disc-space for some reason: Open a jira-bug and you will (most likely) get it.
Daniel
Sincerely, DaB.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Is this also supposed to solve TS-1317 [1]??
[1] https://jira.toolserver.org/browse/TS-1317
Thanks and greetings! DrTrigon
On 16.05.2012 21:31, DaB. wrote:
Hello At Wednesday 16 May 2012 21:28:30 DaB. wrote:
There have been arrangements with some projects that need a lot of space by nature, like mine, The WikiMiniAtlas. But loging in today for the first time I received a quota warning with an ultimatum to free space within 4.9 days. Since when is that active?
the quota-service is active since years, but to tell the true not for everybody because there are some bugs in the system. The roots plan to fix this on short-term-base and we will send another mail about this in the next days; but it should not affect you yet. But nevertheless: if you need more disc-space for some reason: Open a jira-bug and you will (most likely) get it.
Daniel
Sincerely, DaB.
_______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
So no answer at all... that's a pitty!
To have at least some information, I wrote a small script:
#!/usr/bin/env python
# http://www.alecjacobson.com/weblog/?p=1039
import subprocess, re, smtplib, email.mime.text
quota = subprocess.Popen("quota -v", shell=True, stdout=subprocess.PIPE).stdout.read() size = re.findall("[\d.]+", quota) percent = float(size[1])/float(size[2]) * 100
# if the percentage is a above some threshold then send an email if (percent > 90.): # sender's and recipient's email addresses FROM = "drtrigon@toolserver.org" TO = ["dr.trigon@surfeu.ch"] # must be a list # Create a text/plain message msg = email.mime.text.MIMEText(quota) msg['Subject'] = "!QUOTA! %.1f%%" % percent msg['From'] = FROM msg['To'] = ", ".join(TO) # Send the mail server = smtplib.SMTP("localhost") server.sendmail(FROM, TO, msg.as_string()) server.quit()
which is invoked as follows from cron(ie)tab:
qcronsub -l h_rt=00:05:00 -l virtual_free=50M -m as -j y -b y -N maintenance $HOME/warnuserquota.py >/dev/null
may be this helps other users having the same problems/issues.
Greetings DrTrigon
On 12.06.2012 21:39, Dr. Trigon wrote:
Is this also supposed to solve TS-1317 [1]??
[1] https://jira.toolserver.org/browse/TS-1317
Thanks and greetings! DrTrigon
On 16.05.2012 21:31, DaB. wrote:
Hello At Wednesday 16 May 2012 21:28:30 DaB. wrote:
There have been arrangements with some projects that need a lot of space by nature, like mine, The WikiMiniAtlas. But loging in today for the first time I received a quota warning with an ultimatum to free space within 4.9 days. Since when is that active?
the quota-service is active since years, but to tell the true not for everybody because there are some bugs in the system. The roots plan to fix this on short-term-base and we will send another mail about this in the next days; but it should not affect you yet. But nevertheless: if you need more disc-space for some reason: Open a jira-bug and you will (most likely) get it.
Daniel
Sincerely, DaB.
_______________________________________________ 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
_______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry, this copy'n'paste is useless - thus I attached the file here.
On 09.07.2012 19:20, Dr. Trigon wrote:
So no answer at all... that's a pitty!
To have at least some information, I wrote a small script:
#!/usr/bin/env python
import subprocess, re, smtplib, email.mime.text
quota = subprocess.Popen("quota -v", shell=True, stdout=subprocess.PIPE).stdout.read() size = re.findall("[\d.]+", quota) percent = float(size[1])/float(size[2]) * 100
# if the percentage is a above some threshold then send an email if (percent > 90.): # sender's and recipient's email addresses FROM = "drtrigon@toolserver.org" TO = ["dr.trigon@surfeu.ch"] # must be a list # Create a text/plain message msg = email.mime.text.MIMEText(quota) msg['Subject'] = "!QUOTA! %.1f%%" % percent msg['From'] = FROM msg['To'] = ", ".join(TO) # Send the mail server = smtplib.SMTP("localhost") server.sendmail(FROM, TO, msg.as_string()) server.quit()
which is invoked as follows from cron(ie)tab:
qcronsub -l h_rt=00:05:00 -l virtual_free=50M -m as -j y -b y -N maintenance $HOME/warnuserquota.py >/dev/null
may be this helps other users having the same problems/issues.
Greetings DrTrigon
On 12.06.2012 21:39, Dr. Trigon wrote:
Is this also supposed to solve TS-1317 [1]??
Thanks and greetings! DrTrigon
On 16.05.2012 21:31, DaB. wrote:
Hello At Wednesday 16 May 2012 21:28:30 DaB. wrote:
There have been arrangements with some projects that need a lot of space by nature, like mine, The WikiMiniAtlas. But loging in today for the first time I received a quota warning with an ultimatum to free space within 4.9 days. Since when is that active?
the quota-service is active since years, but to tell the true not for everybody because there are some bugs in the system. The roots plan to fix this on short-term-base and we will send another mail about this in the next days; but it should not affect you yet. But nevertheless: if you need more disc-space for some reason: Open a jira-bug and you will (most likely) get it.
Daniel
Sincerely, DaB.
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
On 09/07/12 20:52, Dr. Trigon wrote:
Sorry, this copy'n'paste is useless - thus I attached the file here.
On 09.07.2012 19:20, Dr. Trigon wrote:
So no answer at all... that's a pitty!
To have at least some information, I wrote a small script:
Sorry Trigon, but it doesn't work. It is calculating the percentage of the hard limit at which your soft limit is set. Not really what you wanted :)
Moreover, even if you fixed it ( float(size[0])/float(size[1]) ), it has problems with eg. using 600.0K out of the 500.0M quota.
Also, no need to hardcode the email address. You could simply run: (echo Subject: You are reaching your quota && quota -v ) | mail $USER
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry Trigon, but it doesn't work. It is calculating the percentage of the hard limit at which your soft limit is set. Not really what you wanted :)
May be we do not have the same 'quota -v' output, mine is:
Disk quotas for drtrigon (uid 1340): Filesystem usage quota limit timeleft files quota limit timeleft /home 308.2M 500.0M 1000.0M 6016 0 0
You have to consider that '1340' from '(uid 1340)' does also match the regex, so it should work fine. At least for me it does for shure since I got mail as expected. :)
Moreover, even if you fixed it ( float(size[0])/float(size[1]) ), it has problems with eg. using 600.0K out of the 500.0M quota.
That is in fact true - but to be honest if you use below 1MB you do not have any need to run this script at all... do you? ;)
Also, no need to hardcode the email address. You could simply run: (echo Subject: You are reaching your quota && quota -v ) | mail $USER
This is a good hint indeed! Thanks for that! Since I should have mentioned my script as "cheap'n'dirty" solution there is a lot space for improvement! On the other hand it is just a work-a-round for a service that should be done by the toolserver anyway and thus I did not have the motivation to write "perfect" but "just working" code.
I have mentioned that I just wanted to let profit other toolserver users from it - nobody HAS to use it... ;) Furthermore I do not give up the hope that finally some day the toolserver will do this job and the script can be trashed anyway... ;))
Greetings and have fun! DrTrigon
On 11/07/12 23:44, Dr. Trigon wrote:
Sorry Trigon, but it doesn't work. It is calculating the percentage of the hard limit at which your soft limit is set. Not really what you wanted :)
May be we do not have the same 'quota -v' output, mine is:
Disk quotas for drtrigon (uid 1340): Filesystem usage quota limit timeleft files quota limit timeleft /home 308.2M 500.0M 1000.0M 6016 0 0
You have to consider that '1340' from '(uid 1340)' does also match the regex, so it should work fine. At least for me it does for shure since I got mail as expected. :)
I stand corrected. I had only tested with the second line.
Cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12.07.2012 01:18, Platonides wrote:
I stand corrected. I had only tested with the second line.
In fact it is very good thing to look at other codes and check them BEFORE running... ;) Thanks for your work and feedback!
Greetings
toolserver-l@lists.wikimedia.org