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.
