[FreeBSD-Announce] New mailing list: performance@FreeBSD.org
seanc at FreeBSD.org
Tue Apr 8 22:47:31 PDT 2003
I'm pleased to announce the formation of a new mailing list dedicated
to the performance of FreeBSD under high load or extreme conditions.
Address: performance at FreeBSD.org
List URL: http://lists.FreeBSD.org/mailman/listinfo/freebsd-performance
List admin: freebsd-performance-owner at freebsd.org
The performance@ mailing list exists to provide a place for hackers,
administrators, and/or concerned parties to discuss performance
related topics pertaining to FreeBSD. Acceptable topics includes
talking about FreeBSD installations that are either under high load,
are experiencing performance problems, or are pushing the limits of
FreeBSD. Concerned parties that are willing to work toward improving
the performance of FreeBSD are highly encouraged to subscribe to this
list. This is a highly technical list ideally suited for experienced
FreeBSD users, hackers, or administrators interested in keeping
FreeBSD fast, robust, and scalable.
The performance@ list is not a question-and-answer list that replaces
reading through documentation, but it is a place to make contributions
or inquire about unanswered performance related topics. Answered
questions and performance related FAQ's will end up in a compiled list
or integrated into the existing documentation.
Flames, trolls, wars, and bikesheds will not be tolerated.
Constructive, progressive posts, and patches, however, are very
Examples of questions that would be appropriate on the performance@
list include (if they haven't already been answered or incorporated
into the FAQ/docs):
"Hi, I've got 60K connections per box and I'm drowning because I
don't have enough empirical port #'s available. What's the best
hack/work around given my CPU is only at 20% and RAM is in the same
neck of the woods?"
"I think I've pushed sendfile() as far as it can go and now my apps
are lagging 2-15sec. I thought sendfile() was supposed to return -1
and EWOULDBLOCK when the call would block, but if there aren't any
sf_buf's available, sendfile() _is_ blocking and my app performance
nose dives in the worst of ways. What's the best work around or is
there a fix for this problem?"
"I'm throwing out about 50Mbps of traffic, but am rate shaping my
bits as they head out. I've consequently used up all of my
mbufclusters but not individual mbufs. How can I tune this so that
they balance out? I've noticed the same problem with high latency
connections that are from over seas and that it effectively DDoS'es
my machines when things get busy..."
"Now that I've got it in balance, I can't seem to get more than 130K
mbufclusters in use without the kernel panicing on startup. I know
I have more KVM available than is required but something 'just
sucks' in the way that mbufclusters are allocated at the moment. Am
I the only one noticing this?"
"Now that I've got a firewall up front and am using stateful
firewall rules, has anyone else noticed that the hashing algorithm
used for dynamic rules blows goats? I've got about 600K stateful
rules at the moment and most of the time is spent doing hash key
"Has anyone noticed that FreeBSD's async IO falls apart when the
system load hits around 10? When I try and push any amount of bits
through it using a threaded app and *poof* I start getting incorrect
return values. Anyone else had this happen?"
If there are any problems or questions regarding the list, please
don't hesitate to contact the list administrator at:
freebsd-performance-owner at FreeBSD.org
"FreeBSD: The Power [and Speed/Reliability] To Serve."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 202 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-announce/attachments/20030408/decacebb/attachment.bin
More information about the freebsd-announce