It's a bug introduced by another bug fix in SGE 6.2u5, and Oracle was first who fixed the bug in Oracle Grid Engine. Then we added a workaround in SGE 6.2u5p1 in Open Grid Scheduler, and Son of Grid Engine copied it. I think Univa also fixed the bug at some point, as the fix was copied by Son of Grid Engine (and dropped the workaround). OGS will just stick with the workaround as we don't like the workaround or the fix...
You will just need to upgrade your SGE 6.2u5 cluster with a patched SGE execd - either compile execd yourself or in fact you can get it from the hwloc drop-in upgrade package: http://gridscheduler.sourceforge.net/projects/hwloc/GridEnginehwloc.html Rayson On Tue, Aug 2, 2011 at 8:15 AM, Jesse Becker <[email protected]> wrote: > On Mon, Aug 01, 2011 at 07:41:41PM -0400, William Deegan wrote: >> >> Should the maxvmem column in the accounting file be the true max memory >> footprint of the running process? (and children?) > > I've seen problems with 6.2u5 in the accounting records. It appears to > "wrap" at 4GB, which probably indicates a 32/64 bit issue. I think > there's information about it in the mailing list. > > I'm not sure about child processes. > > -- > Jesse Becker > NHGRI Linux support (Digicon Contractor) > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
