[torqueusers] [SOLVED] problems with many job submissions
chemadm at hamilton.edu
Fri May 15 08:00:00 MDT 2009
First I just wanted to say thanks for the comments from everyone.
Besides having to talk to the user about how they are submitting jobs
(I have a meeting with them next week about it), I think I found
something that helped. I increased max_connections in /etc/my.cnf on
the mysql server and that seemed to do the trick... the rest of their
jobs finished up very quickly (despite the fact the jobs didn't do
much of anything). Just thought I would pass it along. Thanks again,
On May 14, 2009, at 1:23 PM, Roy Dragseth wrote:
> On Thursday 14 May 2009 17:45:22 Steve Young wrote:
>> Hi all,
>> I have been experiencing a problem with a user submitting thousands
>> of jobs. Out of most of the jobs they seem to either finish in a
>> matter of seconds or aren't even doing anything. I'm using torque,
>> maui and gold. Now I'm using a routing queue to contain the 10,000
>> jobs they submit (all single cpu jobs). The routing queue works fine
>> and routes to the proper execution queue (able to run 116 at a time).
>> However, I notice as the system is chewing through the jobs trying to
>> execute them they drop off so fast the system is having a hard time
>> trying to keep up. The mysql server goes to 100% and even a load on
>> goldd. I suspect it's because the flurry of jobs starting/stopping so
>> fast that creating the reservations and other record-keeping in maui/
>> gold is making this load.
>> I'm hoping to get the user to make some changes to how they submit
>> jobs (but they can be difficult at times). I suspect that even if the
>> jobs ran for 5 minutes or so that then the system could at least keep
>> up. So I'm curious to know if any others ran into this type of
>> and what you did to solve it. Are there some changes in torque/maui/
>> gold that I could make to help alleviate this?
> I posted the exact same question on the gold list last year (but the
> at pnl.gov is gone and I could not find the thread on the
> If you do not want to write your own layer between maui and gold
> you're pretty
> much stuck.
> We ended up limiting the number of idle and running jobs per user.
> default each user is limited to 200 running jobs and 16 idle jobs
> USERCFG[DEFAULT] MAXJOB=200 MAXIJOB=16
> Our policy is not to optimize the batch system for lots of small
> jobs. By
> setting the above limits we sort of encourage our users to adjust
> their work
> setup. Even if you bring down the response time from accounting the
> will be limited, Amdahls law will kick in eventually...
> If you're using postgres as the backend for gold you should vacuum the
> database regularly. The gold user has this in crontab
> # su - gold
> -bash-3.00$ crontab -l
> 00 04 * * * sh /opt/gold/vacuum.sh
> -bash-3.00$ cat /opt/gold/vacuum.sh
> # vacuum the database, makes it run faster.
> /usr/bin/psql -c "vacuum; vacuum analyze;"
> Doing this brought down the accounting response down from 6 to 1
> (our db server is really slow...)
> The Computer Center, University of Tromsø, N-9037 TROMSØ Norway.
> phone:+47 77 64 41 07, fax:+47 77 64 41 00
> Roy Dragseth, Team Leader, High Performance Computing
> Direct call: +47 77 64 62 56. email: roy.dragseth at uit.no
> mauiusers mailing list
> mauiusers at supercluster.org
More information about the torqueusers