Re: [HTCondor-users] More thoughts on memory limits

["Beyer, Christoph" <christoph.beyer@xxxxxxx>]

Hi,

 memory.current might be interesting for someone but memory.peak could nonetheless go into another job classadd - not having access to it makes memory management pretty much impossible on many levels ? 

Best
christoph



-- 
Christoph Beyer
DESY Hamburg
IT-Department

Notkestr. 85
Building 02b, Room 009
22607 Hamburg

phone:+49-(0)40-8998-2317
mail: christoph.beyer@xxxxxxx

----- UrsprÃngliche Mail -----
Von: "Jeff Templon" <templon@xxxxxxxxx>
An: "HTCondor-Users Mail List" <htcondor-users@xxxxxxxxxxx>
Gesendet: Montag, 2. Dezember 2024 15:15:31
Betreff: Re: [HTCondor-users] More thoughts on memory limits

Hi,

Thanks for this, as it was a big mystery to us - the memory values reported by HTCondorâs âhistoryâ command are now essentially useless, I guess this is why, you have to get âluckyâ for them to be meaningful.

Context: the typical use cases for looking at memory history are

 1) operational, why have machines been running low on memory?  The history will no longer give you hints.
 2) user-oriented: how much memory do my jobs use, so I know how much memory to specify in the JDL?  The history is no longer a reliable source of information.

Itâs almost as bad as picking some random moment in the life of the job for which the used CPU and Wall times will be reported for the job.  

> On 1 Dec 2024, at 12:24, Petr Vokac <petr.vokac@xxxxxxx> wrote:
> 
> btw: I find questionable to re-use existing cgroup slot from previous jobs with stuck processes for a new HTCondor job and I hope that developers comes with cleaner solution in future..

Yes, especially if it leads to poor accounting data.

JT



_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe

The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/