Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (19 - 21 of 431)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Ticket Resolution Summary Owner Reporter
#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
#118 fixed IZ659: sge_execd creates world-writeable files in active_jobs directory gsregid
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=659]

        Issue #:      659              Platform:     PC       Reporter: gsregid (gsregid)
       Component:     gridengine          OS:        Linux
     Subcomponent:    cleanup          Version:      5.3p5       CC:    None defined
        Status:       NEW              Priority:     P5
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    ernst (ernst)
      QA Contact:     ernst
          URL:
       * Summary:     sge_execd creates world-writeable files in active_jobs directory
   Status whiteboard:
      Attachments:

     Issue 659 blocks:
   Votes for issue 659:


   Opened: Wed Feb 4 09:50:00 -0700 2004 
------------------------


Using sge-5.3p5 on Linux (x86, kernel 2.4, glibc
>= 2.2):

When a new job is submitted using qsub, on the
execution host, <exec_host>, in the directory in
<execd_spool_dir>/<exec_host>/active_jobs, a new
directory is created (e.g., <job_id>.1) in which
the three files ("error", "trace", and
"exit_status") are created with permissions of
0666 which gives write permission to all users.

I downloaded the source "Grid Engine 5.3p5 source
tarball, V53p5_TAG" and found the following calls
to "creat()" in the
"source/daemons/common/err_trace.c" file:

err_trace.c:213:      if ((fd=creat("error",
0666))>=0)
err_trace.c:220:      if ((fd=creat("trace",
0666))>=0)
err_trace.c:227:      if ((fd=creat("exit_status",
0666))>=0)

The numbers 213, 220, 227 are the line numbers
within err_trace.c.  I recommend using permissions
of 0664 to avoid allowing all users to write to
these files.

As of 2004-02-04, the most recent revision of this
file (1.6) in the CVS repository still contained
the above calls to creat() with 0666 permissions.

Thank you for your time.  Please contact me with
any questions/comments.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Note: See TracQuery for help on using queries.