[FreeBSD-Announce] New mailing list: performance@FreeBSD.org

[Sean Chittenden]

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
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 at 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