Custom Query (431 matches)
Results (109 - 111 of 431)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#85 | fixed | IZ483: reporting of reason for job abort | fy | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=483] Issue #: 483 Platform: All Reporter: fy (fy) Component: gridengine OS: All Subcomponent: execution Version: 5.3p2 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: andreas (andreas) QA Contact: pollinger URL: * Summary: reporting of reason for job abort Status whiteboard: Attachments: Issue 483 blocks: Votes for issue 483: Opened: Wed Feb 5 08:11:00 -0700 2003 ------------------------ When a job exceeds one of the resource limits, say h_rt, the job is killed with SIGKILL, however, there is no clear indication as to why the job was killed. None of the files in $SGE_JOB_SPOOL_DIR provide any added information, so writing an epilog does not help. The best we can do is guess from the failed code (=100), and end_time-start_time. The enhancment being asked for is some kind of reason as to why the job was killed, e.g. (reason=limit_exceeded, limit=h_rt). ------- Additional comments from andreas Fri Apr 15 06:56:13 -0700 2005 ------- HOWTOFIX: In case a job was terminated due to limit exeeded a new SSTATE_* such as SSTATE_LIMIT_EXCEEDED is needed. Each time sge_execd initiates job termination a flag must be set with that job. This will sge_execd to report SSTATE_LIMIT_EXCEEDED for those jobs/tasks. ------- Additional comments from andreas Mon Jul 25 02:15:10 -0700 2005 ------- Changed execd logging in Maintrunk from Info to Warning to improve diagnosics. Further improvements seem possible. Added related comments to daemons/execd/execd_signal_queue.c ------- Additional comments from andreas Mon Aug 8 04:16:35 -0700 2005 ------- See issue 1743 for a reasonable 6.0 based workaround and an RFE how to generally improve job diagnostics based oo job life-cycle information available in reporting(5). ------- Additional comments from sgrell Mon Dec 12 03:04:05 -0700 2005 ------- Changed the subcomponent. Stephan |
|||
#87 | fixed | IZ512: performance of non unique hashtables can be improved | joga | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=512] Issue #: 512 Platform: All Reporter: joga (joga) Component: gridengine OS: All Subcomponent: qmaster Version: 5.3p3 CC: None defined Status: STARTED Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: joga (joga) QA Contact: ernst URL: * Summary: performance of non unique hashtables can be improved Status whiteboard: Attachments: Issue 512 blocks: Votes for issue 512: Opened: Mon Mar 24 05:49:00 -0700 2003 ------------------------ Non unique hash tables (module cull_hash) show bad performance, if there is a huge amount of entries for one hashkey (see also issue 493). Their performance should be improved. This can for example be accieved by setting a unique hash key on the members of the non unique object list. Additional memory overhead should be analyzed and carefully evaluated against performance improvements. ------- Additional comments from joga Tue Mar 30 04:23:27 -0700 2004 ------- started ------- Additional comments from sgrell Mon Dec 12 03:03:07 -0700 2005 ------- Changed the subcomponent. Stephan ------- Additional comments from ernst Tue Aug 19 02:55:53 -0700 2008 ------- Isn't this already implemented? |
|||
#98 | fixed | IZ570: qstat -s prsz bug | Dave Love <d.love@…> | alexger |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=570] Issue #: 570 Platform: All Reporter: alexger (alexger) Component: gridengine OS: SunOS Subcomponent: clients Version: 5.3p2 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: andreas (andreas) QA Contact: roland URL: * Summary: qstat -s prsz bug Status whiteboard: Attachments: Issue 570 blocks: Votes for issue 570: Opened: Wed Jun 18 06:06:00 -0700 2003 ------------------------ The job with job-ID=61 is actually pending. > qstat -s prsz ################################################################################ -- FINISHED JOBS - FINISHED JOBS - FINISHED JOBS - FINISHED JOBS -- ################################################################################ job-ID prior name user state submit/start at queue master ja-task-ID --------------------------------------------------------------------------------------------- 61 0 simple.sh alexger qw 06/18/2003 16:33:54 55 0 VVVVVVVVVV alexger qw 06/11/2003 14:46:36 57 0 Sleeper moscat qw 06/16/2003 16:56:25 58 0 Aborted alexger qw 06/17/2003 09:48:28 59 0 Sleeper alexger qw 06/17/2003 10:07:28 60 0 simple.sh alexger qw 06/17/2003 11:38:28 > qstat -s p job-ID prior name user state submit/start at queue master ja-task-ID --------------------------------------------------------------------------------------------- 61 0 simple.sh alexger qw 06/18/2003 16:33:54 ------- Additional comments from alexger Wed Jun 18 06:08:57 -0700 2003 ------- I use SGE 5.3p2 and the `qstat -s prsz` command seems to display pending jobs together with recently finished. The job with job-ID=61 is actually pending. Since the first job in the output can be earlest and pending and all other jobs can have later submit-time and be finished I don't see the possibility to distinguish it. > qstat -s prsz ################################################################################ -- FINISHED JOBS - FINISHED JOBS - FINISHED JOBS - FINISHED JOBS -- ################################################################################ job-ID prior name user state submit/start at queue master ja-task-ID --------------------------------------------------------------------------------------------- 61 0 simple.sh alexger qw 06/18/2003 16:33:54 55 0 VVVVVVVVVV alexger qw 06/11/2003 14:46:36 57 0 Sleeper moscat qw 06/16/2003 16:56:25 58 0 Aborted alexger qw 06/17/2003 09:48:28 59 0 Sleeper alexger qw 06/17/2003 10:07:28 60 0 simple.sh alexger qw 06/17/2003 11:38:28 > qstat -s p job-ID prior name user state submit/start at queue master ja-task-ID --------------------------------------------------------------------------------------------- 61 0 simple.sh alexger qw 06/18/2003 16:33:54 ------- Additional comments from andreas Thu Dec 11 08:30:47 -0700 2003 ------- Sorry for the late reply: Is it true that the jobs 55-60 actually were finished jobs? If so the fix/enhancement here might be to display finished jobs always with a 'z' state indicator. ------- Additional comments from sgrell Thu Feb 26 08:11:21 -0700 2004 ------- In case of qstat -s prsz can one not desdinguish between pending jobs and finished jobs. We need a new job state for it. Therefor it is an enhancement request. Stephan ------- Additional comments from sgrell Mon Dec 12 03:00:09 -0700 2005 ------- Changed the Subcomponent. Stephan ------- Additional comments from roland Mon Feb 13 01:22:15 -0700 2006 ------- see stephans comment ------- Additional comments from roland Mon Feb 13 01:23:29 -0700 2006 ------- switched to ENHANCEMENT |
Note: See TracQuery
for help on using queries.