Date: Fri, 8 Dec 2006 14:33:30 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: processes not getting fair share of available disk I/O (was: Re: TCP parameters and interpreting tcpdump output ) Message-ID: <20061208193330.GA69614@xor.obsecurity.org> In-Reply-To: <200612080141.BAA07359@sopwith.solgatos.com> References: <20061208000932.GA35387@xor.obsecurity.org> <200612080141.BAA07359@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 07, 2006 at 05:41:51PM +0000, Dieter wrote: > > However, I don't know what you mean by "data is lost". Data should > > never be lost from the filesystem regardless of how slow the I/O is > > happening, unless there's something else going wrong (e.g. driver > > bug). > >=20 > > Also, rtprio should not be used in general - see the manpage. Were > > you using rtprio in your original scenario? It can easily cause > > resource starvation. >=20 > I have data arriving on Ethernet. The data rate is 2.5 MB/s max, > but the other end only has a small buffer. If the BSD box doesn't read > the port fast enough, the data is lost. I have a C program (port2file) > reading from the port into a *large* circular buffer, currently 431,226,8= 80 > bytes. This should be enough to buffer over 2 minutes of data. It does > non-blocking 64KB writes to stdout. Shell script calls this program and > redirects stdout to a disk file. Very little if any other i/o to this > disk. Even with disk cache in write-through mode, I can write at about > 6-7 MB/s. The process needs very little CPU. Sounds like this should > be no problem. >=20 > And it seems to work okay if the system is otherwise idle. >=20 > The problem is that if some other process is writing to some other disk, > it somehow slows down writes to ALL disks. Enough that, dispite the non-= blocking > writes (?), the TCP receive window shrinks and shrinks and finally is sma= ller > than a packet. The src machine obediantly stops sending packets, its sma= ll > buffer fills up, and data is lost. >=20 > Things I have done so far: >=20 > BIG buffer (over 2 minutes worth). >=20 > The port2file process cranks up the TCP receive window from 65700 to 1= 97100. >=20 > It also cranks up rtprio from 20 to 5. >=20 > sysctl net.inet.tcp.delayed_ack=3D0 >=20 > The only process running rtprio is port2file. All other processes are > either default priority or niced down with the classic nice(1). Thanks for explaining the problem in more detail. Did this problem start before you made port2file run with rtprio? Can you please include a copy of your kernel configuration file and dmesg? Kris --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFeb4KWry0BWjoQKURAqwCAJ0alPuCL2YATCMXXOclbVlza1wEHgCfe5bB MYgkuKF/40EmL7Iv2KmjDbU= =4WhP -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061208193330.GA69614>