Mark Kirkwood wrote:
Doug Barton wrote:
The Apache page:
http://httpd.apache.org/docs/2.3/misc/perf-tuning.html
It mentions FIN_WAIT_2 not 1, so this might be a different/new problem.
IIRC it actually is the same problem, but in any case you're missing
the bit where 4.x is EOL. :) Hence
On Wed, May 28, 2008 at 06:13:04PM -0400, Robert Blayzor wrote:
Here is what I have on the server now:
and loader.conf
accf_http_load=YES
You shouldn't bother with this. Let the apache22 rc.d script handle
loading it dynamically. Use apache22_http_accept_enable=yes in
rc.conf.
I've read
On Tue, 27 May 2008 11:45:19 -0400 Michael Proto [EMAIL PROTECTED]
wrote about Re: broken re(4):
MP Any hints what I should do next to find the culprit?
MP I'm running 6.3 on the exact same Jetway board at home, and while I
MP haven't been bitten by the DOWN/UP issue I have seen the occasional
On Wed, 28 May 2008 17:56:10 +0200 Gerrit Kühn
[EMAIL PROTECTED] wrote about Re: broken re(4):
GK PY http://people.freebsd.org/~yongari/re/re.HEAD.20080519
GK Somehow the two interfaces seem to interfer with each other. Can I
GK provide further information for fixing this?
Meanwhile I booted
On 2008-05-29 11:58, Gerrit Kühn wrote:
Can I do anything else? Is the newer patch (from yesterday) in your
directory above worth giving a try?
FYI, that patch doesn't compile, due to a typo... Fix below:
--- re.HEAD.20080528.orig 2008-05-29 13:08:15.0 +0200
+++ re.HEAD.20080528
Pawel Jakub Dawidek a écrit :
On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote:
I'm playing around with ZFS.
Currently, I just use it for storage, with a zpool of 4 sata disks.
The system and boot disk is still formatted with UFS.
As I'm quite pleased with ZFS features,
On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote:
I'm playing around with ZFS.
Currently, I just use it for storage, with a zpool of 4 sata disks.
The system and boot disk is still formatted with UFS.
As I'm quite pleased with ZFS features, I'd like to try ZFS on root. The
On Sat, May 24, 2008 at 04:08:28PM -0400, Zaphod Beeblebrox wrote:
On Sat, May 24, 2008 at 12:26 PM, Andrew Hill [EMAIL PROTECTED] wrote:
but what struck me as odd is the desire to create two separate zpools - one
for data storage and one for the system. i think one of zfs's greatest
Doug Barton wrote:
Mark Kirkwood wrote:
Doug Barton wrote:
The Apache page:
http://httpd.apache.org/docs/2.3/misc/perf-tuning.html
It mentions FIN_WAIT_2 not 1, so this might be a different/new problem.
IIRC it actually is the same problem, but in any case you're missing the
bit where
On May 29, 2008, at 8:44 AM, Stephen Clark wrote:
You know it really pains me when people blithely say just upgrade to
X.X where X is the latest release.
It is generally just not that simple to upgrade - there are all
sorts of dependencies with other software that have to be considered.
Robert Blayzor wrote:
On May 29, 2008, at 8:44 AM, Stephen Clark wrote:
You know it really pains me when people blithely say just upgrade to
X.X where X is the latest release.
In my first message I did not say it blithely, I actually said
something like begin looking at 7.0 ASAP. However,
On Thu, 29 May 2008 23:03:01 +1000 Dewayne Geraghty
[EMAIL PROTECTED] wrote about RE: broken re(4):
DG You might try, after rebooting, to physically unplug and replug your
DG networking cables.
I already did try that one or twice, without any success.
DG I have a few EN-15000 and SN-18000
I got really poor performance when I try to upload files to the box (via
pureFTP or Samba) when using jumbo frames somewhat above 2k.
uname -a :
FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28
17:45:14 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CARENATH
Does the trace show the window size being negotiated correctly?
- Original Message -
From: Arnaud Houdelette [EMAIL PROTECTED]
I got really poor performance when I try to upload files to the box (via
pureFTP or Samba) when using jumbo frames somewhat above 2k.
uname -a :
FreeBSD
On Thu, 29 May 2008 13:10:48 +0200 Dimitry Andric [EMAIL PROTECTED]
wrote about Re: broken re(4):
DA FYI, that patch doesn't compile, due to a typo... Fix below:
Thanks, I will try that patch tomorrow.
Meanwhile I have set up two more machines. Now I have 5 ITX systems, each
with 2 re-NICs, and
Gerrit Kühn wrote:
On Tue, 27 May 2008 11:45:19 -0400 Michael Proto [EMAIL PROTECTED]
wrote about Re: broken re(4):
MP Any hints what I should do next to find the culprit?
MP I'm running 6.3 on the exact same Jetway board at home, and while I
MP haven't been bitten by the DOWN/UP issue I
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gerrit Kühn
Sent: Thursday, 29 May 2008 7:58 PM
To: Gerrit Kühn
Cc: [EMAIL PROTECTED]; freebsd-stable@freebsd.org
Subject: Re: broken re(4)
On Wed, 28 May 2008 17:56:10 +0200 Gerrit Kühn [EMAIL PROTECTED]
Gerrit Kühn wrote:
Meanwhile I have set up two more machines. Now I have 5 ITX systems,
each with 2 re-NICs, and only one is behaving strange.
In that case I would suspect that the one piece of hardware
that is misbehaving is broken and needs to be replaced.
The only hardware thing that is
On 2008-05-29 17:13, Gerrit Kühn wrote:
On Thu, 29 May 2008 13:10:48 +0200 Dimitry Andric [EMAIL PROTECTED]
Meanwhile I have set up two more machines. Now I have 5 ITX systems, each
with 2 re-NICs, and only one is behaving strange.
Just as a data point, my ITX board is a JetWay J7F4K1G2E.
On Thu, 29 May 2008 18:52:55 +0200 (CEST) Oliver Fromme
[EMAIL PROTECTED] wrote about Re: broken re(4):
OF In that case I would suspect that the one piece of hardware
OF that is misbehaving is broken and needs to be replaced.
I agree. I just do not know yet which part is broken.
OF The only
On Thu, 29 May 2008 19:09:12 +0200 Dimitry Andric [EMAIL PROTECTED]
wrote about Re: broken re(4):
DA I have 5 ITX systems, each with 2 re-NICs, and only one is behaving
DA strange.
DA Just as a data point, my ITX board is a JetWay J7F4K1G2E.
The ones I have are JW J7F4K1G5 A, I guess. I will
I guess nobody mentioned the obvious thing to check: Make sure
TCP keepalive is turned on.
sysctl net.inet.tcp.always_keepalive=1
If you don't do this then dead TCP connections can build up, particularly
on busy servers, due to the other end simply disappearing.
Without
On May 29, 2008, at 3:12 PM, Matthew Dillon wrote:
I guess nobody mentioned the obvious thing to check: Make sure
TCP keepalive is turned on.
sysctl net.inet.tcp.always_keepalive=1
Thanks Matt.
I also thought that a keepalives were not running and sessions just
stuck around
:On May 29, 2008, at 3:12 PM, Matthew Dillon wrote:
:I guess nobody mentioned the obvious thing to check: Make sure
:TCP keepalive is turned on.
:
:sysctl net.inet.tcp.always_keepalive=1
:
:
:Thanks Matt.
:
:I also thought that a keepalives were not running and sessions just
:stuck
On May 29, 2008, at 3:30 PM, Matthew Dillon wrote:
It is quite possible that the other ends of the connection are
still
live and that the issue could very well be a timeout setting in the
server config file instead of something in the TCP stack.
Good point, I didn't think about
On May 29, 2008, at 3:30 PM, Matthew Dillon wrote:
It is quite possible that the other ends of the connection are
still
live and that the issue could very well be a timeout setting in the
server config file instead of something in the TCP stack.
I think we're onto something here,
Arnaud Houdelette wrote:
I also tried with tso disabled. Same results. Is it related to the re(4)
driver ? Or to the TCP stack ?
Having used em driver with 7-RELEASE and 7-STABLE, I can assure you that
large MTU size (9100) works well and gives 100mb/s transfer rates easily.
So I can only
:I think we're onto something here, but for some reason it doesn't make
:any sense. I have keepalives turned OFF in Apache:
:
:When I tcpdump this, I see something sending ack's back and forth
:every 60 seconds, but what? Apache? I'm not sure why. I don't see
:any timeouts in Apache
On May 29, 2008, at 5:32 PM, Matthew Dillon wrote:
Now, the connection is also in a half-closed state, which means
that
one direction is closed. I can't tell which direction that is
but my
guess is that 1.1.1.1 (the apache server) closed the 1.1.1.1-
2.2.2.2
direction and the
:This is exactly what we're seeing, it's VERY strange. I did kill off
:Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in
:fact sending these probe packets, every 60 seconds, which the client
:responds to... (most of the time).
Ach. Now that I think about it, it is
On May 29, 2008, at 8:55 PM, Matthew Dillon wrote:
It's got to a be a bug on the client(s) in question. I can't think
of anything else. You may have to resort to injecting a TCP RST
packet (e.g. via a TUN device) to clear the connections.
That would be most unpleasant... and also
Robert Blayzor wrote:
On May 29, 2008, at 8:55 PM, Matthew Dillon wrote:
It's got to a be a bug on the client(s) in question. I can't think
of anything else. You may have to resort to injecting a TCP RST
packet (e.g. via a TUN device) to clear the connections.
That would be most
On Thu, May 29, 2008 at 04:25:33PM +0200, Arnaud Houdelette wrote:
I got really poor performance when I try to upload files to the box (via
pureFTP or Samba) when using jumbo frames somewhat above 2k.
uname -a :
FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28
On Thu, May 29, 2008 at 01:10:48PM +0200, Dimitry Andric wrote:
On 2008-05-29 11:58, Gerrit K?hn wrote:
Can I do anything else? Is the newer patch (from yesterday) in your
directory above worth giving a try?
FYI, that patch doesn't compile, due to a typo... Fix below:
---
34 matches
Mail list logo
