<div dir="ltr"><div><div>Sorry for spamming, I've found the answer just answer posting the question. The resolution for my issue was to add FAIR_TREE to PriorityFlags. Fairshare factor for the user who submitted the job was low because of his high utilization of resources and sshare -u login was showing 0.00000 for him.<br><br></div>cheers,<br></div>Marcin <br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-15 11:00 GMT+01:00 Marcin Stolarek <span dir="ltr"><<a href="mailto:stolarek.marcin@gmail.com" target="_blank">stolarek.marcin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I'm working on a priority multifactor plugin configuration and I'm not sure if I'm missing something or the behaviour I see is the result of bug. Basically<br><br></div># sshare | grep XX<br> XX                               <wbr>     1    0.071429        4367      0.031536   0.736368<br><br></div>which I read as fairshare factor = 0.73, quite hight<br><br></div># sprio -w<br>          JOBID   PRIORITY        AGE  FAIRSHARE<br>        Weights                  1000      10000<br><br></div>and than the jobs is account YY and XX respectively:<br># sprio<br>          JOBID   PRIORITY        AGE  FAIRSHARE<br></div>        9150547          1          0          0                       <--YY<br><div>        9265691          8          8          0                       <--XX<br><br></div><div>I'm using TRESBilling, however, I expected fairshare priority component to be simply fairshare factor (from sshare) * fairshare weight..<br><br></div><div>cheers,<br></div><div>Marcin<br></div><div><br></div></div>
</blockquote></div><br></div>