Am 23.03.2011 um 14:26 schrieb Mark Dixon: >> When "cpu" and "mem" is already the reserved integral value, you can compute >> this "maxvmem" easily affterwards. There it no need to set it IMO. > > They completely different things, aren't they? Isn't maxvmem the peak vmem > used during the job, whereas mem ought to be the time integral?
It should be. But as you said and I checked, it's set to the h_vmem request. So I wanted to point out, that the current implementation is redundant: $ qacct -j 1234 ... cpu 120.000 mem 90.000 io 0.000 iow 0.000 maxvmem 768.000M 92160 / 120 = 768 -- Reuti > Besides, even if you can calculate it from the other fields, having maxvmem > is so much easier to read for the users e.g. to see how much vmem they used, > so they know what to ask for in subsequent similar jobs. > > Back in 6.0-land, it also was the most reliable method I could find to see if > your job failed due to exceeding any requested h_vmem. > > >>> 2) It's interesting to have the actual cpu time in the accounting file, so >>> that you can see if cpu time / run time ~= 1.0 >> >> Yes, as long as the jobs are not reprioritized with different nice values >> and/or the exechosts are oversubscribed, i.e. you have slots=cores. >> >> You would charge for the run time then (in case you do it)? > > We charge for elapsed time, which we get from ru_wallclock. _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
