kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: MAX limit of file descriptor
Date: Mon, 11 Feb 2013 14:24:16 -0500	[thread overview]
Message-ID: <61126.1360610656@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Sat, 09 Feb 2013 13:10:47 +0800." <20130209051047.GA2806@debian.localdomain>

On Sat, 09 Feb 2013 13:10:47 +0800, horseriver said:

>    In one process ,what is the max number of opening file descriptor ?
>    Can it be set to infinite ?
>
>    In network programing ,what is the essential for  the maximum of connections
>    dealed per second

In general, you'll find that "number of file descriptors" isn't what ends up
killing you for high-performance network programming.  What usually gets you
are things like syn floods (either intentional ddos or getting slashdotted),
because each time you do an accept() on an incoming connection you end up
using userspace resources to handle the connection.  So the *real* question
becomes "how many times per second is your box able to fork() off an httpd,
do all the processing required, and close the connection?"

A secondary gotcha is that dying TCP connections end up stuck in FIN-WAIT and
FIN-WAIT-2,

And if you're trying to drive multiple 10G interfaces at line speed, it
gets even more fun.  Fortunately, for my application (high performance disk
servers) the connections are mostly persistent, so it's "only" a problem of
getting disks to move data that fast. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130211/3494baf2/attachment.bin 

  parent reply	other threads:[~2013-02-11 19:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-09  5:10 MAX limit of file descriptor horseriver
2013-02-09 15:49 ` Peter Teoh
2013-02-09 17:08   ` Gaurav Jain
2013-02-09 17:09     ` Gaurav Jain
2013-02-10 22:07     ` horseriver
2013-02-11 17:16       ` Mulyadi Santosa
2013-02-11 19:36       ` Valdis.Kletnieks at vt.edu
2013-02-10 12:29 ` michi1 at michaelblizek.twilightparadox.com
2013-02-10 14:47   ` Peter Teoh
2013-02-10 17:50     ` michi1 at michaelblizek.twilightparadox.com
2013-02-11 19:24 ` Valdis.Kletnieks at vt.edu [this message]
2013-02-12  5:45   ` michi1 at michaelblizek.twilightparadox.com
2013-02-12  9:31 ` Peter Teoh
2013-02-12  9:38   ` Peter Teoh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61126.1360610656@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).