Sean Chittenden
2003-Apr-09 00:16 UTC
[FreeBSD-Announce] New mailing list: performance@FreeBSD.org
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@FreeBSD.org List URL: http://lists.FreeBSD.org/mailman/listinfo/freebsd-performance List admin: freebsd-performance-owner@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 welcome. 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?" or: "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?" or: "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..." or: "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?" or: "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 lookups." or: "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@FreeBSD.org "FreeBSD: The Power [and Speed/Reliability] To Serve." -- Sean Chittenden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 202 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-announce/attachments/20030408/decacebb/attachment.bin