85

最新の標準 Linux サーバーで可能な tcp ソケット接続の数を知っている人はいますか?

(一般に、各接続のトラフィックは少なくなりますが、すべての接続が常に稼働している必要があります。)

4

8 に答える 8

89

1600k の同時アイドル ソケット接続を達成し、同時に Linux デスクトップ (16G RAM、I7 2600 CPU) で 57k req/s を達成しました。これは、epoll を使用して C で記述されたシングル スレッドの http サーバーです。ソース コードはgithub、ブログはこちらにあります。

編集：

Java/Clojure を使用して、同じコンピューターの両方で 600k の同時 HTTP 接続 (クライアントとサーバー) を実行しました。詳細情報の投稿、HN ディスカッション: http://news.ycombinator.com/item?id=5127251

接続のコスト (epoll を使用):

  • アプリケーションは接続ごとにいくらかの RAM を必要とします
  • TCP バッファ 2 * 4k ~ 10k 以上
  • epoll(7) によると、epoll はファイル記述子用にいくらかのメモリを必要とします。

登録された各ファイル記述子は、32 ビット カーネルで約 90 バイト、64 ビット カーネルで約 160 バイトのコストがかかります。

于 2012-03-13T00:45:32.160 に答える
24

これは、問題のオペレーティングシステムだけでなく、構成、場合によってはリアルタイム構成にも依存します。

Linuxの場合：

cat /proc/sys/fs/file-max

同時に開くことができるファイル記述子の合計の現在の最大数が表示されます。http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.htmlをチェックしてください

于 2009-03-16T19:04:59.947 に答える
9

10,000? 7万？それだけですか:)

FreeBSD はおそらくあなたが望むサーバーです。これは、 100,000 接続を処理するようにチューニングすることに関する小さなブログ投稿です。これには、完了ポート メカニズムとして機能する kqueue とともに、しばらく前からゼロコピー ソケットなどの興味深い機能がいくつかあります。

Solaris は、前世紀に100,000 の接続を処理できます!. 彼らは、Linuxの方が優れていると言います

私が見つけた最良の説明は、スケーラブルな Web サーバーの作成に関するこのプレゼンテーション/ペーパーです。彼はそれをありのままに言うことを恐れていません:)

ソフトウェアについても同様です。アプリケーション層のクレチンは、OS 層に大きなイノベーションをもたらしました。Lotus Notes はクライアントごとに 1 つの TCP 接続を開いたままにするため、IBM は「1 つのプロセスで 100.000 の開いている接続」の場合の大幅な最適化を Linux に提供しました。

そして、O(1) スケジューラーは元々、無関係な Java ベンチマークで良いスコアを出すために作成されました。要するに、この肥大化は私たち全員に利益をもたらすということです。

于 2009-05-30T15:49:52.017 に答える
5

Linuxでは、非同期I/Oにepollを使用することを検討する必要があります。また、接続ごとにカーネルスペースを浪費しないように、ソケットバッファを微調整する価値があるかもしれません。

妥当なマシンで100kの接続に到達できるはずだと思います。

于 2009-03-17T18:09:10.790 に答える
3

アプリケーションによって異なります。各クライアントから数個のパッケージしかない場合、100K は Linux にとって非常に簡単です。私のチームのエンジニアが何年も前にテストを行った結果、接続が確立された後にクライアントからパッケージがない場合、Linux epoll は 50% 未満の CPU 使用率レベルで 400k fd の読み取り可能性を監視できます。

于 2011-11-27T14:52:34.007 に答える
1

どのオペレーティングシステムですか？

Windowsマシンの場合、適切に拡張できるようにサーバーを作成しているため、I/O完了ポートと非同期I/Oを使用している場合、主な制限は、アクティブな接続ごとに使用している非ページプールの量です。 。これは、マシンにインストールされているメモリの量に基づく制限に直接変換されます（非ページプールは、インストールされているメモリの合計に基づく有限の固定サイズの量です）。

トラフィックがあまり見られない接続の場合、非ページプールを使用せず、ロックされたページの制限に影響を与えない「ゼロバイト読み取り」を投稿することで、より効率的に接続を減らすことができます（他の潜在的に制限されたリソースにより、多くのソケット接続が開いている）。

それとは別に、プロファイリングする必要がありますが、適度に指定された（760MBのメモリ）サーバーで70,000を超える同時接続を取得することができました。詳細については 、 http：//www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.htmlを参照してください。

明らかに、「接続ごとのスレッド」や「選択」などの効率の低いアーキテクチャを使用している場合は、あまり印象的でない数値を達成することを期待する必要があります。しかし、私見では、Windowsソケットサーバーにそのようなアーキテクチャを選択する理由はまったくありません。

編集：ここを参照http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx ; 非ページプールの量の計算方法は、VistaおよびServer 2008で変更され、現在ではさらに多くの機能が利用可能になっています。

于 2009-03-16T22:15:42.810 に答える
-12

アプリケーションにとって現実的には、1 台のマシンで 4000 ～ 5000 を超えるオープン ソケットが非現実的になります。すべてのソケットのアクティビティをチェックして管理するだけでも、特にリアルタイム環境ではパフォーマンスの問題になり始めます。

于 2009-03-16T19:43:19.900 に答える