Greg Stein wrote on Mon, Nov 12, 2012 at 21:48:23 -0500:
> On Mon, Nov 12, 2012 at 9:13 PM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
> > Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> >
> >> Greg Stein wrote on Mon, Nov 12, 2012 at 19:01:25 -0500:
> >>>
> >>> In October, svn.apache.org generated about 900M of logs(*). Is that a
> >>> problem? I wouldn't think so. At that rate, a simple 1T drive could
> >>> hold over 83 years of logs. Are there installations busier than
> >>
> >> How many years would those 1TB disks last for if all neon clients were
> >> converted to serf?
> >
> > I have a checkout of the gcc tree, it has 78,000 files. Now it uses
> > svn: but if it were to use http: then the serf checkout log would be 4
> > orders of magnitude bigger than the neon log. 83 years becomes 1 or 2
> > days.
> >
> > The neon log is independent of the size of the checkout, the serf log
> > scales with the size of the checkout. If this were memory we would say
> > we have a scaling problem. Do scaling problems not apply to disk space?
>
> The log is proportional to the work done by the server. If you want to
> perform capacity planning, then "REPORT" doesn't tell you much. The
> serf requests enable better balancing, use of multiple cores,
> reverse-proxies to balance across machines, etc.
>
> As Justin states, there are well-known solutions to dealing with logs.
>
All the same, if the logs grow by four orders of magnitude, it's a change
of behaviours, so we should warn admins so they can deploy those solutions
before they run into the issue themselves.
r1408579 takes a quick stab at this -- feel free to edit to taste.
> Cheers,
> -g
Received on 2012-11-13 05:51:01 CET