{"id":68,"date":"2018-01-16T19:55:17","date_gmt":"2018-01-16T19:55:17","guid":{"rendered":"https:\/\/in.nau.edu\/hpc\/?page_id=68"},"modified":"2024-08-14T09:41:35","modified_gmt":"2024-08-14T16:41:35","slug":"efficient-jobs","status":"publish","type":"page","link":"https:\/\/in.nau.edu\/arc\/overview\/efficient-jobs\/","title":{"rendered":"Efficient Jobs"},"content":{"rendered":"\n
\n
<\/p>\n

\n

\n
\n

Advanced Research Computing<\/h3>\n <\/div>\n
\n \n
\n <\/i>\n Email:<\/span>\n <\/div>\n
ask-arc​@nau.edu<\/div>\n <\/a>\n <\/div>\n<\/div>\n\n
\n<\/div>\n<\/div>\n\n

Efficient jobs<\/h1>\n

Submitting efficient jobs to Slurm is your ticket to shortest queue times, and maximum resources. If jobs are submitted in an inefficient manner, it can negatively affect you and your group’s ability to use the cluster as much as possible. Here are some of the benefits of submitting jobs efficiently:<\/p>\n

    \n
  • Faster job start times<\/li>\n
  • More resources for you<\/li>\n
  • More resources for your group<\/li>\n
  • Higher utilization of Monsoon<\/li>\n
  • More work being done in general<\/li>\n
  • <\/li>\n<\/ul>\n

    How can you make your jobs more efficient? It’s pretty easy! If you run our jobstats<\/span> wrapper script, it will provide you with a clear comparison of the most important parameters involved with the efficiency of a job:<\/p>\n

      \n
    • Job time<\/li>\n
    • CPU usage<\/li>\n
    • Memory usage<\/li>\n<\/ul>\n

      Let’s look at a couple examples of inefficient jobs:<\/p>\n

             JobID JobName   RegMem   MaxRSSS ReqCPUS   UserCPU  Timelimit  Elapsed     State\r\n6124735      MetaSeQ 126000Mn                 8 44:12.097 2-00:00:00 00:14:33 COMPLETED\r\n6124735.bat+   batch 126000Mn     3360K       8 00:00.008            00:14:33 COMPLETED\r\n6124735.0      batch 126000Mn 70060316K       8 44:12.088            00:14:18 COMPLETED<\/code><\/pre>\n
      The overall parent process for the job is the first line, the second line is the batch portion, and the third line is where the work was actually taking place in the job. Lines with a job id of jobid.0<\/span> are where you need to be taking a close look for trimming down memory. The first line will show the overall stats for the job (excluding memory) and the sum of time for all steps in the job: submit, prep, and running of the analysis code.<\/p>\n
        \n
      • The memory estimate of 126GB (ReqMem<\/span>) is over estimated by 45% versus the 70GB (MaxRSS<\/span>) which was actually utilized<\/li>\n
      • The time estimate of 2 days (Timelimit<\/span>) is over estimated by a huge amount at 95% versus the elapsed 14 minutes (Elapsed<\/span>)<\/li>\n
      • The UserCPU<\/span> number has something amiss, as well. Ideally, this number should normally be: n * elapsed<\/span>, where n<\/span> is the number of cores requested. This can indicate something strange going on. For example, the application is possibly trying to start more threads than cores asked for. If this is happening to you, ask us to help you look into it.<\/li>\n<\/ul>\n
               JobID    JobName   RegMem   MaxRSSS ReqCPUS    UserCPU  Timelimit  Elapsed     State\r\n6125571      metseq_re+    126Gn                 4   22:44:10 2-00:00:00 05:59:14 COMPLETED\r\n6125571.bat+      batch    126Gn     3364K       4  00:00.014            05:59:14 COMPLETED\r\n6125571.0         batch    126Gn 19047016K       4   22:44:09            05:59:10 COMPLETED<\/code><\/pre>\n
        This job above is not efficient in the memory or the time limit department, but is efficient with CPU usage (UserCPU<\/span>).<\/p>\n
          \n
        • Look at ReqMem vs MaxRSS on the third line. 126GB requested vs. 18GB utilized<\/li>\n
        • The time is 2 days requested vs. 6 hours elapsed<\/li>\n
        • The CPU time is right on, however. Expected would be: 24 hours (6 hours * 4 CPUs = ~24 hours of user CPU<\/span>), and we see ~22 hours.<\/li>\n<\/ul>\n
          Note:<\/strong> When the scheduler is looking for resources for your job, it has to find a window of time that matches all of your requests for resources. If time limit, memory, or CPU is overestimated, your job’s start time will suffer.<\/p>\n
          Another thing to keep in mind regarding efficient jobs: Each group on Monsoon is given a fixed amount of CPU minutes that can be in use at any one time. Currently, we have the number set at 700,000<\/span>. With this number of minutes a group can potentially run:<\/p>\n
            \n
          • 20 jobs, 4 days in length (in minutes), with 6 cores each: 20 * 5760 * 6 = 691200<\/span><\/li>\n
          • 100 jobs, 1 day in length, with 4 cores each: 100 * 1440 * 4 = 576000<\/span><\/li>\n
          • 500 jobs, 2 hours in length, with 11 cores each: 500 * 120 * 11 = 660000<\/span><\/li>\n
          • 1 job, 1.5 days in length, with 256 cores: 1 * 2160 * 256 = 552960<\/span><\/li>\n<\/ul>\n
            Any jobs submitted that would put the group over 700,000<\/span> are stuck pending until more minutes are available. Note: as jobs move along in time, their contributing minutes are subtracted from the sum as the time limit remaining becomes less and less.<\/p>\n
            Take away from all of this:<\/strong>\u00a0the efficiency of your jobs will dictate how much Monsoon resources you and your group get — it’s that simple.<\/p>\n
            Please consider running jobstats now and then to see how you are doing as far as efficiency in your jobs. The following would grab all of one’s jobs from January 1st to now:<\/p>\n
            jobstats -u userid -S 1\/1\/17<\/code><\/pre>\n
            Note:<\/strong> you can run this on any of your group members to take a look at how their jobs are faring.<\/p>\n","protected":false},"excerpt":{"rendered":"
            Efficient jobs Submitting efficient jobs to Slurm is your ticket to shortest queue times, and maximum resources. If jobs are submitted in an inefficient manner, it can negatively affect you and your group’s ability to use the cluster as much as possible. Here are some of the benefits of submitting jobs efficiently: Faster job start […]<\/p>\n","protected":false},"author":76,"featured_media":145,"parent":49,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"ring_central_script_selection":"","footnotes":""},"class_list":["post-68","page","type-page","status-publish","has-post-thumbnail","hentry"],"_links":{"self":[{"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/pages\/68","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/users\/76"}],"replies":[{"embeddable":true,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/comments?post=68"}],"version-history":[{"count":5,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/pages\/68\/revisions"}],"predecessor-version":[{"id":3610,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/pages\/68\/revisions\/3610"}],"up":[{"embeddable":true,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/pages\/49"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/media\/145"}],"wp:attachment":[{"href":"https:\/\/in.nau.edu\/arc\/wp-json\/wp\/v2\/media?parent=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}