Mailing-List: contact users-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@archiva.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <9E24FE73B6CFAC4592582CA1A18643DC0F6CFF3A@OAEXCH2SERVER.oa.oclc.org>
References: 
 <9E24FE73B6CFAC4592582CA1A18643DC0F6CFEBD@OAEXCH2SERVER.oa.oclc.org>
	<A9C78AA4-0969-4F2B-82C1-85126048EFEC@apache.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFEBF@OAEXCH2SERVER.oa.oclc.org>
	<1DF7651A-F3F3-44F7-8C95-6D5DA10EE3D9@apache.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFEE2@OAEXCH2SERVER.oa.oclc.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFEE4@OAEXCH2SERVER.oa.oclc.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFF10@OAEXCH2SERVER.oa.oclc.org>
	<0F53549C-A8B8-4A65-A11D-47EA7554B3EE@apache.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFF26@OAEXCH2SERVER.oa.oclc.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFF28@OAEXCH2SERVER.oa.oclc.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFF2B@OAEXCH2SERVER.oa.oclc.org>
	<9ECF5F81-E680-43A6-8D02-ACCC7AA787CF@apache.org>
	<9E24FE73B6CFAC4592582CA1A18643DC0F6CFF3A@OAEXCH2SERVER.oa.oclc.org>
Date: Wed, 2 Nov 2011 08:51:52 +0100
Message-ID: 
 <CAPoyBqQVEvm4RWAxtYEkUaaWk9Mt79UGsnO4O6oC2tssTzxL9g@mail.gmail.com>
Subject: RE: 100% CPU in Archiva 1.3.5
From: Olivier Lamy <olamy@apache.org>
To: users@archiva.apache.org
Content-Type: multipart/alternative; boundary=14dae9340981c4ba8004b0bbbe16

--14dae9340981c4ba8004b0bbbe16
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Maybe a thread dump could help us to debug.
Any chance you provide one ?
Did you have time to test with 1.4 m1 ?
--
Olivier
Le 1 nov. 2011 15:43, "Stallard,David" <stallard@oclc.org> a =E9crit :

> We do have a fairly large number of Continuous Integration builds that
> can trigger many times per day, each build uploading new snapshots.  It
> sounds like that could be a problem based on your second point below.
> However, that structure has been in place for well over a year and we've
> only had this CPU problem for 2 weeks.  Maybe we just happened to cross
> some threshold that has made it more problematic?
>
> I'll look into reducing the number of scans and keeping them to off-peak
> hours.
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Monday, October 31, 2011 6:34 PM
> To: users@archiva.apache.org
> Subject: Re: 100% CPU in Archiva 1.3.5
>
> Top replying with a few points:
>
> - artifact upload limits are only via the web UI, maven deployments can
> push artifacts as large as needed.
> - individual artifacts of that size shouldn't be a big problem (it's a
> once off hit), but regularly updating snapshots of that size will cause
> it to build
> - the scan time below is quite long, particularly for the purge. You
> might want to push the scanning schedule out to an "off peak" time - the
> purge doesn't need to run that often, and most operations are done
> on-demand with the scan just filling in any gaps.
>
> HTH,
> Brett
>
> On 01/11/2011, at 2:15 AM, Stallard,David wrote:
>
> > I'm not sure if this is useful, but here are the summaries of the most
>
> > recent hourly scans...from archiva.log:
> >
> >
> > .\ Scan of internal \.__________________________________________
> >  Repository Dir    : <path removed>/internal
> >  Repository Name   : Archiva Managed Internal Repository
> >  Repository Layout : default
> >  Known Consumers   : (7 configured)
> >                      repository-purge (Total: 58857ms; Avg.: 1; Count:
> > 58702)
> >                      metadata-updater (Total: 419ms; Avg.: 209; Count:
> > 2)
> >                      auto-remove
> >                      auto-rename
> >                      update-db-artifact (Total: 98ms; Avg.: 49; Count:
> > 2)
> >                      create-missing-checksums (Total: 120ms; Avg.: 60;
> > Count: 2)
> >                      index-content (Total: 0ms; Avg.: 0; Count: 7)
> > Invalid Consumers : <none>
> >  Duration          : 2 Minutes 56 Seconds 896 Milliseconds
> >  When Gathered     : 10/31/11 11:02 AM
> >  Total File Count  : 268305
> >  Avg Time Per File :
> > ______________________________________________________________
> >
> >
> > .\ Scan of snapshots \.__________________________________________
> >  Repository Dir    : <path removed>/snapshots
> >  Repository Name   : Archiva Managed Snapshot Repository
> >  Repository Layout : default
> >  Known Consumers   : (7 configured)
> >                      repository-purge (Total: 325200ms; Avg.: 8;
> Count:
> > 39805)
> >                      metadata-updater (Total: 5915ms; Avg.: 50; Count:
> > 116)
> >                      auto-remove
> >                      auto-rename
> >                      update-db-artifact (Total: 17211ms; Avg.: 148;
> > Count: 116)
> >                      create-missing-checksums (Total: 15559ms; Avg.:
> > 134; Count: 116)
> >                      index-content (Total: 34ms; Avg.: 0; Count: 475)
>
> > Invalid Consumers : <none>
> >  Duration          : 7 Minutes 17 Seconds 416 Milliseconds
> >  When Gathered     : 10/31/11 11:10 AM
> >  Total File Count  : 166275
> >  Avg Time Per File : 2 Milliseconds
> > ______________________________________________________________
> >
> >
> >
> > -----Original Message-----
> > From: Stallard,David
> > Sent: Monday, October 31, 2011 9:57 AM
> > To: 'users@archiva.apache.org'
> > Subject: RE: 100% CPU in Archiva 1.3.5
> >
> > I need to correct my previous message...it turns out we do have
> > artifacts larger than 40M even though that is the defined maximum, I'm
>
> > not sure at this point how that is happening.
> >
> > In our internal repository we have 40 artifacts which are over 100M in
>
> > size, with the largest one being 366M.  In snapshots, we have 61
> > artifacts that are >100M, where the largest is 342M.  I'm not sure how
>
> > significant these sizes are in terms of the indexer, but wanted to
> > accurately reflect what we're dealing with.
> >
> > -----Original Message-----
> > From: Stallard,David
> > Sent: Monday, October 31, 2011 9:43 AM
> > To: 'users@archiva.apache.org'
> > Subject: RE: 100% CPU in Archiva 1.3.5
> >
> > Brett Porter said:
> >>> It's not unexpected that indexing drives it to 100% CPU momentarily,
> > but causing it to become unavailable is unusual.
> > How big are the artifacts it is scanning?<<
> >
> > The CPU was still at 100% on Monday morning, so having the weekend to
> > index didn't seem to improve anything; the indexing queue was up to
> > about 3500.  We got a report that downloads from Archiva are extremely
>
> > slow, so I just bounced it.  CPU was immedately at 100% after the
> > bounce, and the indexing queue is at 6.  I expect that queue to
> > continually rise, based on what I've seen after previous bounces.
> >
> > Our upload maximum size was 10M for the longest time, but we had to
> > raise it to 20M a while back and then recently we raised it to 40M.
> > But I would think that the overwhelming majority of our artifacts are
> > 10M or less.
> >
> > Is there a way to increase the logging level?  Currently, the logs
> > don't show any indication of what it is grinding away on.  After the
> > startup stuff, there really isn't anything in archiva.log except for
> > some Authorization Denied messages -- but these have been occurring
> > for months and months, I don't think they are related to the 100% CPU
> > issue that just started up about a week ago.
> >
> >
> >
> >
> >
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
>
>

--14dae9340981c4ba8004b0bbbe16--