[GE users] qselect problem

Kirk Patton kpatton at transmeta.com
Tue May 4 14:33:54 BST 2004


On Tue, May 04, 2004 at 10:14:55AM +0200, Andy Schwierskott wrote:
> Kirk,
> 
> could you please send the definition of the failing complex attributes:
> 
>   # qconf -sc host| egrep "os|platform|release....."

os               os         STRING none            ==    YES         NO         none 
platform         march      STRING none            ==    YES         NO         none 
release          release    STRING none            ==    YES         NO         none 

> 
> and examples how their definition look in the hosts and global host:
> 
>   # qconf -se global

hostname                   global
load_scaling               NONE
complex_list               NONE
complex_values             license_a=5,arcadia=4,hspice=6,vampire-drc=6,vampire-lvs=6,solid=190,simplex_v_storm=2,dynacore=10,finsim=999
load_values                NONE
processors                 0
user_lists                 NONE
xuser_lists                NONE
projects                   NONE
xprojects                  NONE
usage_scaling              NONE
resource_capability_factor 0.000000

> 
> and some examples of e.g. the Linux hosts:
> 
>   # qconf -se <hostname>
hostname                   op240-000.transmeta.com
load_scaling               NONE
complex_list               NONE
complex_values             slots=3,exclusive=1,running=50
load_values                arch=i686,num_proc=2,mem_total=3972.656250M,swap_total=8063.742188M,virtual_total=12036.398438M,bitsize=32-bit,os=Linux,platform=i386,release=2.4.20-18.7smp,vendor-rel=7.3,cpuinfo=_AMD_Opteron(tm)_Processor_248_,relative_speed=75,cpuf=75,load_avg=0.120000,load_short=0.010000,load_medium=0.120000,load_long=0.410000,mem_free=3686.937500M,swap_free=8063.742188M,virtual_free=11750.679688M,mem_used=285.718750M,swap_used=0.000000M,virtual_used=285.718750M,cpu=0.400000,np_load_avg=0.060000,np_load_short=0.005000,np_load_medium=0.060000,np_load_long=0.205000
processors                 2
user_lists                 NONE
xuser_lists                NONE
projects                   NONE
xprojects                  NONE
usage_scaling              NONE
resource_capability_factor 0.000000

> 
> Or are the attribute defined at a queue level (partially) as well?
> 
> A simple test I did (host complex attribute setting) works well.
> 
> Did you verify the your "qselect" command (which is a symlink) point to the
> correct "qstat" command?

I did not not modify the symlink. It points to the qstat command in the same directory.
> 
> Does "qstat" select the correct queues:
> 
>   # qstat -f -l os=Linux

No, it returns nothing

Thanks,
Kirk
> 
> 
> Andy
> 
> > Hello,
> >
> > I recently upgraded my master host to 5.3p6 and have noticed strange behavior
> > with qselect.
> >
> > The command
> > qselect -l os=Linux
> >
> > produces
> >
> > "no queues remaining after selection"
> >
> > If I run
> >  qstat -F | grep os=
> >
> > I get lots of matches
> >  hl:os=Linux
> >  hl:os=Linux
> >  hl:os=Linux
> >  hl:os=Linux
> >  hl:os=Linux.....
> >
> > Does anyone have any suggestions on how to determine why queues are not getting selected?
> >
> > Running other selections using qstat does work, but many of the complexes fail to return
> > a match.
> > These items fail to produce a match,
> > load_avg=0.940000
> > load_short=1.070000
> > load_medium=0.940000
> > load_long=0.560000
> > np_load_avg=0.470000
> > np_load_short=0.535000
> > np_load_medium=0.470000
> > np_load_long=0.280000
> > mem_free=3.15G
> > mem_total=3.88G
> > swap_free=7.87G
> > virtual_free=11.02G
> > mem_used=749.02M
> > swap_used=0.000000
> > virtual_used=749.02M
> > relative_speed=75.000000
> > bitsize=32-bit
> > os=Linux
> > platform=i386
> > release=2.4.20-18.7smp
> > vendor-rel=7.3
> > cpuinfo=_AMD_Opteron(tm)_Processor_248_
> >
> > These items produce a match
> > license_a=5.000000
> > arcadia=4.000000
> > hspice=6.000000
> > vampire-drc=6.000000
> > vampire-lvs=6.000000
> > solid=190.000000
> > simplex_v_storm=2.000000
> > dynacore=5.000000
> > finsim=999.000000
> > arch=i686
> > num_proc=2.000000
> > swap_total=7.87G
> > virtual_total=11.75G
> > swap_rsvd=0.000000
> > swap_rate=0.000000
> > slots=1.000000
> > s_vmem=infinity
> > h_vmem=infinity
> > s_fsize=infinity
> > h_fsize=infinity
> > cpu=50.600000
> > systype=0.000000
> > glibc=0.000000
> > cpuf=75.000000
> > exclusive=1.000000
> > running=49.000000
> > qname=common.op240-000
> > hostname=op240-000.transmeta.com
> > tmpdir=/tmp
> > calendar=NONE
> > seq_no=13000.000000
> > rerun=1.000000
> > s_rt=infinity
> > h_rt=infinity
> > s_cpu=infinity
> > h_cpu=infinity
> > s_data=infinity
> > h_data=infinity
> > s_stack=infinity
> > h_stack=infinity
> > s_core=infinity
> > h_core=infinity
> > s_rss=infinity
> > h_rss=infinity
> > min_cpu_interval=00:05:00
> > priority=common
> >
> > Thanks,
> > Kirk
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
> 

-- 
Kirk Patton
Unix Administrator
Transmeta Inc.
Tel. 408 919-3055

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list