Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (169 - 171 of 431)

Ticket Resolution Summary Owner Reporter
#587 fixed IZ2766: man qsub uses GE_* instead of SGE_* for defined variables reuti
Description

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

        Issue #:      2766             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    man              Version:      6.2         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     man qsub uses GE_* instead of SGE_* for defined variables
   Status whiteboard:
      Attachments:

     Issue 2766 blocks:
   Votes for issue 2766:


   Opened: Wed Oct 29 03:55:00 -0700 2008 
------------------------


The man page of qsub mentions for all but one (SGE_ARCH) by SGE defined environment variables GE_*
instead iof SGE_*.
#588 fixed IZ2767: qping info output always shows warning/error Dave Love <d.love@…> juby
Description

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

        Issue #:      2767             Platform:     All      Reporter: juby (juby)
       Component:     gridengine          OS:        All
     Subcomponent:    qmaster          Version:      6.2         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    ernst (ernst)
      QA Contact:     ernst
          URL:
       * Summary:     qping info output always shows warning/error
   Status whiteboard:
      Attachments:

     Issue 2767 blocks:
   Votes for issue 2767:


   Opened: Fri Oct 31 08:30:00 -0700 2008 
------------------------


ive noticed that, out of the box, the qping 'info' output for my 6.2 qmaster
looks like this:

: qping -info host $SGE_QMASTER_PORT qmaster 1
10/31/2008 11:20:02:
SIRM version:             0.1
SIRM message id:          1
start time:               10/30/2008 11:18:37 (1225379917)
run time [s]:             86485
messages in read buffer:  0
messages in write buffer: 0
nr. of connected clients: 3
status:                   2
info:                     MAIN: E (86485.35) | signaler000: E (86484.85) |
event_master000: E (0.25) | timer000: E (5.25) | worker000: W (84.24) |
worker001: W (9.25) | listener000: W (2.53) | listener001: W (6.55) |
scheduler000: W (9.24) | ERROR
malloc:                   arena(1228800) |ordblks(743) | smblks(1) | hblksr(0) |
hblhkd(0) usmblks(0) | fsmblks(48) | uordblks(929344) | fordblks(299456) |
keepcost(76824)
Monitor:                  disabled


pretty much all the time, even under the following conditions:
- no visible problem (jobs get queued and run, commands like qstat, qconf, etc
work, qmon is functional)
- a clean, minimal install of 6.2 using berkeley db RPC (no execd, no shadowd,
no arco)
- a clean, minimal install of 6.2 using classic spooling (no execd, no shadowd,
no arco)


In addition, my 6.2 / berkeley db RPC install went through a few days of
relatively frequent deadlocks, with errors of the form:

|E|error writing object with key "JOB:     259" into berkeley database: (-30995)
DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock

This is after restarts of the RPC server and qmaster. The spooling database is
stored on a local filesystem (the db has since been rebuilt, have not seen a
deadlock yet since rebuilding)

Also, qping on execds always report a warning:

: qping -info exechost $SGE_EXECD_PORT execd 1
10/31/2008 11:13:21:
SIRM version:             0.1
SIRM message id:          1
start time:               10/31/2008 11:04:49 (1225465489)
run time [s]:             512
messages in read buffer:  0
messages in write buffer: 0
nr. of connected clients: 2
status:                   1
info:                     sge_execd_process_messages: W (509.61) | WARNING
malloc:                   arena(135168) |ordblks(26) | smblks(3) | hblksr(0) |
hblhkd(0) usmblks(0) | fsmblks(112) | uordblks(77240) | fordblks(57928) |
keepcost(51464)
Monitor:                  disabled


lx24-x86
Fedora core 4

: qstat -help | head -1
GE 6.2

   ------- Additional comments from juby Fri Oct 31 08:31:13 -0700 2008 -------
assigning os to linux

   ------- Additional comments from crei Thu Feb 26 07:25:34 -0700 2009 -------
I think this problem is not only linux specific
#592 fixed IZ2777: Setting SHARETREE_RESERVED_USAGE affects CPU time accounting orlandorichards
Description

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

        Issue #:      2777             Platform:     PC       Reporter: orlandorichards (orlandorichards)
       Component:     gridengine          OS:        Linux
     Subcomponent:    qmaster          Version:      6.1u4       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    ernst (ernst)
      QA Contact:     ernst
          URL:
       * Summary:     Setting SHARETREE_RESERVED_USAGE affects CPU time accounting
   Status whiteboard:
      Attachments:

     Issue 2777 blocks:
   Votes for issue 2777:


   Opened: Wed Nov 5 07:16:00 -0700 2008 
------------------------


Use of the SHARETREE_RESERVED_USAGE=true flag also makes the accounting behave
as though ACCT_RESERVED_USAGE were enabled, even when it is explicitly disabled.

   ------- Additional comments from orlandorichards Wed Nov 5 07:20:03 -0700 2008 -------
Further info:
We have:

  execd_params                 SHARETREE_RESERVED_USAGE=TRUE \
                               ACCT_RESERVED_USAGE=FALSE

so would expect the CPU time to be recorded as roughly UTIME + STIME - but this
is not the case. Instead, it is always recorded as equal to (or "1" greater
than) wallclock time.

Setting SHARETREE_RESERVED_USAGE to FALSE gives the expected behaviour (CPU time
= 0, wallclock = 20 for a "sleep 20s" job).


Note: See TracQuery for help on using queries.