On Fri, Aug 11, 2006 at 11:52:05AM +0100 or thereabouts, Steve Thorn wrote:
> Duncan
>
> I've no idea what LHCb are doing. They sent 4000 jobs to Edinburgh and
> crashed our CE. They are also sending a number of fork jobs that are
> using at least 50 % of the CPU.
I doubt that "they" are sending fork jobs the RB does send fork jobs
as part of normall operation. One per user per RB.
>
> Steve
>
> > -----Original Message-----
> > From: Testbed Support for GridPP member institutes
> > [mailto:[log in to unmask]] On Behalf Of Duncan Rand
> > Sent: 11 August 2006 11:28
> > To: [log in to unmask]
> > Subject: Re: shared experiment area load
> >
> > We are still getting multiple lhcbsgm jobs - does anyone know
> > what the latest is regarding this issue?
> >
> > thanks
> > Duncan
> >
> > On Thu, 2006-05-25 at 10:32 +0100, Burke, S (Stephen) wrote:
> > > Testbed Support for GridPP member institutes
> > > > [mailto:[log in to unmask]] On Behalf Of Gordon, JC (John)
> > > said:
> > > > Steve, is this a bug? Or just insufficiently recognised
> > as a feature?
> > >
> > > It's really a result of the fact that we seem to be making
> > a very slow
> > > transition to VOMS, so both site configurations and user
> > practice are
> > > inconsistent. What we want to do is move fully to VOMS,
> > i.e. get rid
> > > of LDAP servers, stop having DN mappings in the map file except for
> > > special cases, and have all users use voms proxies (without the DN
> > > mapping a non-VOMS proxy should be rejected). I'm not entirely sure
> > > what still needs to be done to get to that point. Maybe
> > it's something
> > > to raise at the GDB? Even there you still need the right
> > things in the
> > > map file to get the effect you want - the job priorities
> > working group
> > > is looking at that and seems to be making some progress,
> > but we need
> > > clear instructions for sites on what they should do.
> > >
> > > > I can raise a ticket against LHCb asking Ricardo to use a
> > voms proxy
> > > > but who else should I report it to? Atlas obviously but
> > what about
> > > > the deployment team and JRA1?
> > >
> > > One short-term option for Steve and other sites would be to
> > change the
> > > map file generation so the DN only ever gets mapped to a
> > > non-privileged pool account, then if an sgm forgets to use VOMS the
> > > job will fail - a good way to train them :) Otherwise I think the
> > > software is mostly in place to use VOMS, it's mainly a deployment
> > > issue. On the middleware side I think the main lack is
> > documentation;
> > > VOMS and its associated components (e.g. LCAS and LCMAPS)
> > are easily
> > > the worst-documented piece of middleware.
> > >
> > > Stephen
> > --
> > Duncan Rand, School of Engineering and Design, Brunel
> > University, Uxbridge, UK
> > Email: [log in to unmask] Tel. +44 1895 266804
> >
--
Steve Traylen
work email: [log in to unmask]
personal email: [log in to unmask]
jabber: xmpp:[log in to unmask]
|