Hi J.H.,
On Mon, 08 Jan 2007 23:25:18 -0800, J.H. wrote:
> On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
> > > they cache just fine and it's not that big of a deal, and there are much
> > > longer poles in the tent right now.
> >
> > The images are being regenerated every other minute
Hi J.H.,
On Mon, 08 Jan 2007 23:25:18 -0800, J.H. wrote:
On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
they cache just fine and it's not that big of a deal, and there are much
longer poles in the tent right now.
The images are being regenerated every other minute or so, so I
On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
> Hi JH,
>
> On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> > On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > > their presence generates traffic on all
Hi JH,
On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > their presence generates traffic on all web servers regardless of the
> > one the visitor is using, as each
Hi again.
On Tue, 2007-01-09 at 06:09 +0100, Adrian Bunk wrote:
> On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
> > Hi again.
> >
> > On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> > > Nigel Cunningham wrote:
> > > > On Tue, 2006-12-26 at 08:49 -0800, H. Peter
On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
> Hi again.
>
> On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> > Nigel Cunningham wrote:
> > > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> > >> The two things git users can do to help is:
> > >>
> > >> 1.
Hi again.
On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> Nigel Cunningham wrote:
> > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >> The two things git users can do to help is:
> >>
> >> 1. Make sure your alternatives file is set up correctly;
> >> 2. Keep your trees
Salut Willy,
On Mon, 8 Jan 2007 20:37:58 +0100, Willy Tarreau wrote:
> Hi Jean,
>
> On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
> > Hi Peter,
> >
> > On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> > > Willy Tarreau wrote:
> > >
> > > > Just evil suggestion, but if
On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> Hi JH,
>
> On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
> > The root cause boils down to with git, gitweb and the normal mirroring
> > on the frontend machines our basic working set no longer stays resident
> > in memory, which is
Hi JH,
On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
> The root cause boils down to with git, gitweb and the normal mirroring
> on the frontend machines our basic working set no longer stays resident
> in memory, which is forcing more and more to actively go to disk causing
> a much higher I/O
On Sun, 17 Dec 2006 10:23:54 -0800, Randy Dunlap wrote:
> I can't really say since I have no performance/profile data to base
> it on. There has been some noise about (not) providing mirror services
> for distros. Is that a big cpu/memory consumer? If so, then is that
> something that
Hi Jean,
On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
> Hi Peter,
>
> On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> > Willy Tarreau wrote:
> >
> > > Just evil suggestion, but if you contact someone else than HP, they
> > > might be _very_ interested in taking HP's
Hi Peter,
On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> Willy Tarreau wrote:
>
> > Just evil suggestion, but if you contact someone else than HP, they
> > might be _very_ interested in taking HP's place and providing whatever
> > you need to get their name on www.kernel.org. Sun and
Hi Peter,
On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
Willy Tarreau wrote:
Just evil suggestion, but if you contact someone else than HP, they
might be _very_ interested in taking HP's place and providing whatever
you need to get their name on www.kernel.org. Sun and IBM do
Hi Jean,
On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
Hi Peter,
On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
Willy Tarreau wrote:
Just evil suggestion, but if you contact someone else than HP, they
might be _very_ interested in taking HP's place and
On Sun, 17 Dec 2006 10:23:54 -0800, Randy Dunlap wrote:
I can't really say since I have no performance/profile data to base
it on. There has been some noise about (not) providing mirror services
for distros. Is that a big cpu/memory consumer? If so, then is that
something that kernel.org
Hi JH,
On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic working set no longer stays resident
in memory, which is forcing more and more to actively go to disk causing
a much higher I/O
On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
Hi JH,
On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic working set no longer stays resident
in memory, which is forcing more
Salut Willy,
On Mon, 8 Jan 2007 20:37:58 +0100, Willy Tarreau wrote:
Hi Jean,
On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
Hi Peter,
On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
Willy Tarreau wrote:
Just evil suggestion, but if you contact
Hi again.
On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
The two things git users can do to help is:
1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned,
On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
Hi again.
On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
The two things git users can do to help is:
1. Make sure your
Hi again.
On Tue, 2007-01-09 at 06:09 +0100, Adrian Bunk wrote:
On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
Hi again.
On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Hi JH,
On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
* Drop the bandwidth graphs. Most visitors certainly do not care, and
their presence generates traffic on all web servers regardless of the
one the visitor is using, as each graph
On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
Hi JH,
On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
* Drop the bandwidth graphs. Most visitors certainly do not care, and
their presence generates traffic on all web servers
Randy Dunlap wrote:
Hi,
I'm sure that all of this ext3fs etc. discussion is good,
but let me clarify: I would be much happier if the kernel.org
main page and the finger_banner info were updated at the same
time that new tarballs were put onto kernel.org.
Tough sh*t.
Now someone may say
Greg KH wrote:
Well, I create my repos by doing a:
git clone -l --bare
which makes a hardlink from Linus's tree.
But then it gets copied over to the public server, which probably severs
that hardlink :(
Any shortcut to clone or set up a repo using "alternatives" so that we
don't have
On Sat, Jan 06, 2007 at 11:22:31PM -0500, Jeff Garzik wrote:
> >On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >>Not really. In fact, it would hardly help at all.
> >>
> >>The two things git users can do to help is:
> >>
> >>1. Make sure your alternatives file is set up correctly;
>
On Sat, 06 Jan 2007 11:21:15 -0800 J.H. wrote:
> It's an issue of load, and both machines are running 'hot' so to speak.
> When the loads on the machines climbs our update rsyncs take longer to
> complete (considering that our loads are completely based on I/O this
> isn't surprising). More or
On Sat, 06 Jan 2007 11:21:15 -0800 J.H. wrote:
It's an issue of load, and both machines are running 'hot' so to speak.
When the loads on the machines climbs our update rsyncs take longer to
complete (considering that our loads are completely based on I/O this
isn't surprising). More or less
On Sat, Jan 06, 2007 at 11:22:31PM -0500, Jeff Garzik wrote:
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Not really. In fact, it would hardly help at all.
The two things git users can do to help is:
1. Make sure your alternatives file is set up correctly;
2. Keep your trees
Greg KH wrote:
Well, I create my repos by doing a:
git clone -l --bare
which makes a hardlink from Linus's tree.
But then it gets copied over to the public server, which probably severs
that hardlink :(
Any shortcut to clone or set up a repo using alternatives so that we
don't have
Randy Dunlap wrote:
Hi,
I'm sure that all of this ext3fs etc. discussion is good,
but let me clarify: I would be much happier if the kernel.org
main page and the finger_banner info were updated at the same
time that new tarballs were put onto kernel.org.
Tough sh*t.
Now someone may say
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to
Hi.
On Sat, 2007-01-06 at 23:10 -0500, Jeff Garzik wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >> Nigel Cunningham wrote:
> >>> Hi.
> >>>
> >>> I've have git trees against a few versions besides Linus', and have just
> >>> moved all
On Sat, 6 Jan 2007, Jeff Garzik wrote:
>
> Also, I wonder if "git push" will push only the non-linux-2.6.git objects, if
> both local and remote sides have the proper alternatives set up?
Yes.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Not really. In fact, it would hardly help at all.
The two things git users can do to help is:
1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.
If you do this,
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > I've have git trees against a few versions besides Linus', and have just
> > moved all but Linus' to staging to help until you can get your new
> > hardware. If others were encouraged to do the
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually
On Sat, 06 Jan 2007 12:20:27 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>
> >> Unfortunately that affects all three of: dcache, icache, and mbcache.
> >> Maybe we could split that sysctl in two (Andrew?), so that one sysctl
> >> affects dcache/icache and another
Andrew Morton wrote:
Unfortunately that affects all three of: dcache, icache, and mbcache.
Maybe we could split that sysctl in two (Andrew?), so that one sysctl
affects dcache/icache and another affects mbcache.
That would be simple enough to do, if someone can demonstrate a
need.
Is
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually
On Sat, 06 Jan 2007 15:13:50 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> >>
> BTW, yesterday my 2.4 patches were not published, but I noticed that
> they were not even signed not bziped on hera. At first I simply thought
> it was
On Sat, 06 Jan 2007 11:37:46 -0800
Nicholas Miell <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> > >
> > >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> > >>> they were not even signed not bziped on hera.
H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic
script
has been temporarily been disabled
On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>> they were not even signed not bziped on hera. At first I simply thought
> >>> it was related, but right now I have a doubt. Maybe the
On Sat, Jan 06, 2007 at 11:18:37AM -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>>BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>>they were not even signed not bziped on hera. At first I simply thought
> >>>it was related, but right now I have a doubt. Maybe
It's an issue of load, and both machines are running 'hot' so to speak.
When the loads on the machines climbs our update rsyncs take longer to
complete (considering that our loads are completely based on I/O this
isn't surprising). More or less nothing has changed since:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic script
has been temporarily been disabled on hera too ?
The script
On Mon, 18 Dec 2006 22:52:51 -0800 J.H. wrote:
> On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
> > On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> > (...)
> >
> > > So we know the problem is there, and we are working on it - we are
> > > getting e-mails about it if not daily
On Mon, 18 Dec 2006 22:52:51 -0800 J.H. wrote:
On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
So we know the problem is there, and we are working on it - we are
getting e-mails about it if not daily than every
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic script
has been temporarily been disabled on hera too ?
The script
It's an issue of load, and both machines are running 'hot' so to speak.
When the loads on the machines climbs our update rsyncs take longer to
complete (considering that our loads are completely based on I/O this
isn't surprising). More or less nothing has changed since:
On Sat, Jan 06, 2007 at 11:18:37AM -0800, H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic
On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic
On Sat, 06 Jan 2007 11:37:46 -0800
Nicholas Miell [EMAIL PROTECTED] wrote:
On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply
H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic
script
has been temporarily been disabled
On Sat, 06 Jan 2007 15:13:50 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually
Andrew Morton wrote:
Unfortunately that affects all three of: dcache, icache, and mbcache.
Maybe we could split that sysctl in two (Andrew?), so that one sysctl
affects dcache/icache and another affects mbcache.
That would be simple enough to do, if someone can demonstrate a
need.
Is
On Sat, 06 Jan 2007 12:20:27 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Unfortunately that affects all three of: dcache, icache, and mbcache.
Maybe we could split that sysctl in two (Andrew?), so that one sysctl
affects dcache/icache and another affects mbcache.
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Not really. In fact, it would hardly help at all.
The two things git users can do to help is:
1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.
If you do this,
On Sat, 6 Jan 2007, Jeff Garzik wrote:
Also, I wonder if git push will push only the non-linux-2.6.git objects, if
both local and remote sides have the proper alternatives set up?
Yes.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi.
On Sat, 2007-01-06 at 23:10 -0500, Jeff Garzik wrote:
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to
Willy Tarreau wrote:
Just evil suggestion, but if you contact someone else than HP, they
might be _very_ interested in taking HP's place and providing whatever
you need to get their name on www.kernel.org. Sun and IBM do such
monter machines too. That would not be very kind to HP, but it might
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?
Not really. In fact, it would hardly help at all.
Russell King wrote:
Ergo, downloads via http from ftp.uk.kernel.org are at best unreliable
for multiple requests.
I agree that it's not directly your problem, and isn't something you
have direct control over. However, if you want to round-robin the
.kernel.org IP addresses between different
Dave Jones wrote:
A wild idea just occured to me. You guys are running Fedora/RHEL kernels
on the kernel.org boxes iirc, which have Ingo's 'tux' httpd accelerator.
It might not make the problem go away, but it could make it more
bearable under high load. Or it might do absolutely squat
Dave Jones wrote:
A wild idea just occured to me. You guys are running Fedora/RHEL kernels
on the kernel.org boxes iirc, which have Ingo's 'tux' httpd accelerator.
It might not make the problem go away, but it could make it more
bearable under high load. Or it might do absolutely squat
Russell King wrote:
Ergo, downloads via http from ftp.uk.kernel.org are at best unreliable
for multiple requests.
I agree that it's not directly your problem, and isn't something you
have direct control over. However, if you want to round-robin the
cc.kernel.org IP addresses between different
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?
Not really. In fact, it would hardly help at all.
Willy Tarreau wrote:
Just evil suggestion, but if you contact someone else than HP, they
might be _very_ interested in taking HP's place and providing whatever
you need to get their name on www.kernel.org. Sun and IBM do such
monter machines too. That would not be very kind to HP, but it might
On Sat, 16 Dec 2006, J.H. wrote:
> - Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, Dec 19, 2006 at 09:36:06AM -0500, Dave Jones wrote:
> On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
>
> > I'll have to look into it - but by and large the round robining tends to
> > work. Specifically as I am writing this the machines are both pushing
> > right around
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
> I'll have to look into it - but by and large the round robining tends to
> work. Specifically as I am writing this the machines are both pushing
> right around 150mbps, however the load on zeus1 is 170 vs. zeus2's 4.
> Also when we peak
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
> > If the frontend machines are not taken off-line too often, it should
> > be no big deal for them to handle something such as LVS, and would
> > help spreding the load.
>
> I'll have to look into it - but by and large the round robining
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
If the frontend machines are not taken off-line too often, it should
be no big deal for them to handle something such as LVS, and would
help spreding the load.
I'll have to look into it - but by and large the round robining tends to
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
I'll have to look into it - but by and large the round robining tends to
work. Specifically as I am writing this the machines are both pushing
right around 150mbps, however the load on zeus1 is 170 vs. zeus2's 4.
Also when we peak the
On Tue, Dec 19, 2006 at 09:36:06AM -0500, Dave Jones wrote:
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
I'll have to look into it - but by and large the round robining tends to
work. Specifically as I am writing this the machines are both pushing
right around 150mbps,
On Sat, 16 Dec 2006, J.H. wrote:
- Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line unsubscribe
On Tue, 2006-12-19 at 07:46 +0100, Willy Tarreau wrote:
> On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> > On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > > J.H. wrote:
> > > ...
> > > > >The root cause boils
On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
> On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> (...)
> > Since it's apparent not everyone is aware of what we are doing, I'll
> > mention briefly some of the bigger points.
> >
> > - We have contacted HP to see if we can get
On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > J.H. wrote:
> > ...
> > > >The root cause boils down to with git, gitweb and the normal mirroring
> > > >on the
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
> Since it's apparent not everyone is aware of what we are doing, I'll
> mention briefly some of the bigger points.
>
> - We have contacted HP to see if we can get additional hardware, mind
> you though this is a long term solution and
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
Since it's apparent not everyone is aware of what we are doing, I'll
mention briefly some of the bigger points.
- We have contacted HP to see if we can get additional hardware, mind
you though this is a long term solution and will
On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
J.H. wrote:
...
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines
On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
Since it's apparent not everyone is aware of what we are doing, I'll
mention briefly some of the bigger points.
- We have contacted HP to see if we can get additional
On Tue, 2006-12-19 at 07:46 +0100, Willy Tarreau wrote:
On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
J.H. wrote:
...
The root cause boils down to with git,
On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > J.H. wrote:
> ...
> > >The root cause boils down to with git, gitweb and the normal mirroring
> > >on the frontend machines our basic working set no longer stays resident
> >
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> J.H. wrote:
...
> >The root cause boils down to with git, gitweb and the normal mirroring
> >on the frontend machines our basic working set no longer stays resident
> >in memory, which is forcing more and more to actively go to disk
J.H. wrote:
The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.
OK, thanks for the summary.
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our
Pavel Machek wrote:
Would you accept help from someone else than HP? kernel.org is very
important, and hardware is cheap these days... What are the
requirements for machine to be interesting to kernel.org? I guess
AMD/1GHz, 1GB ram, 100GB disk is not interesting to you
quoting
Hi!
> The problem has been hashed over quite a bit recently, and I would be
> curious what you would consider the real problem after you see the
> situation.
>
> The root cause boils down to with git, gitweb and the normal mirroring
> on the frontend machines our basic working set no longer
Hi!
The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic working set no longer stays
Pavel Machek wrote:
Would you accept help from someone else than HP? kernel.org is very
important, and hardware is cheap these days... What are the
requirements for machine to be interesting to kernel.org? I guess
AMD/1GHz, 1GB ram, 100GB disk is not interesting to you
quoting
J.H. wrote:
The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.
OK, thanks for the summary.
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our
1 - 100 of 120 matches
Mail list logo
