Linux システムの TCP 接続数に影響を与える要因

Linux システムの TCP 接続の数に影響を与える主な要因は、メモリと許可されるファイル記述子の数です。これは、各 TCP 接続が一定量のメモリを占有し、各ソケットがファイル記述子であるためです。他の 1024 以下のポートは通常予約されているポートです。

#このチュートリアルの動作環境: linux7.3 システム、Dell G3 コンピューター。

TCP アプリケーションでは、サーバーが事前に固定ポートで待機し、クライアントが積極的に接続を開始し、3 回のハンドシェイク後に TCP 接続が確立されます。では、単一マシンの場合、同時 TCP 接続の最大数はどれくらいでしょうか?

TCP 接続を識別する方法

接続の最大数を決定する前に、まずシステムが TCP を識別する方法を見てみましょう。繋がり。システムは、4 つのタプルを使用して TCP 接続を一意に識別します: {localip, localport,remoteip,remoteport}。

クライアントの TCP 接続の最大数

クライアントが TCP 接続リクエストを開始するたびに、ポートがバインドされていない限り、システムは通常はアイドル状態のポートを選択します。 ローカル ポート (ローカル ポート) は排他的であり、他の TCP 接続と共有することはできません。 TCP ポートのデータ型は unsigned short であるため、ローカル ポートの最大数は 65536 のみです。ポート 0 は特別な意味を持っているため使用できません。このように、使用できるポートは最大でも 65535 のみです。がクライアントとして使用される場合、クライアントの TCP 接続の最大数は 65535 であり、これらの接続は異なるサーバー IP に接続できます。

サーバーの TCP 接続の最大数

サーバーは通常、ローカル ポートでリッスンするように固定されており、クライアントの接続要求を待ちます。アドレスの再利用 (Unix の SO_REUSEADDR オプション) を考慮しないと、サーバー側に複数の IP があっても、ローカルのリッスン ポートは排他的になるため、リモート IP (つまり clientip) とリモート ポート (クライアント) のみが存在します。サーバー側の TCP 接続の 4 タプル (ポート) は可変であるため、最大 TCP 接続はクライアント IP 数 × クライアント ポート数になります。IPV4 の場合、IP アドレスの分類などの要因に関係なく、最大 TCP 接続数は、 TCP 接続数は、約 2 の 32 乗 (IP 数) × 2 の 16 乗 (ポート数)、つまり、サーバー側の 1 台のマシンの最大 TCP 接続数は、約 2 の 48 乗です。 。

実際の tcp 接続数

上記は、単一マシンの理論上の最大接続数です。実際の環境では、マシン リソース、オペレーティング システムなどの影響を受けるため、特にサーバー側では、同時 TCP 接続の最大数は理論上の上限には程遠いです。 Unix/Linux での接続数を制限する主な要因は、メモリと許可されるファイル記述子の数です (各 TCP 接続は一定量のメモリを占有し、各ソケットはファイル記述子です)。さらに、1024 未満のポートは通常、予約済みのポート。デフォルトの 2.6 カーネル構成では、テスト後、各ソケットは 15 ～ 20k のメモリを占有します。

したがって、サーバー側でメモリを増やし、ファイル記述子の最大数などのパラメーターを変更することで、単一マシン上の最大同時 TCP 接続数が 100,000、さらには数百万を超えても問題ありません。 。

これは明らかに誤解です。65535 は使用可能なポートの総数を指しており、サーバーが同時に 65535 個の同時接続しか受け入れられないという意味ではありません。

例:

Web サイトを作成し、それを TCP ポート 80 にバインドしました。その結果、この Web サイトにアクセスするすべてのユーザーは、サーバーのポート 80 にアクセスすることになります。他のポート。可視ポートは再利用できます。 Linux サーバーがポート 80 でのみサービスをリッスンする場合でも、100,000 または 100 万人のユーザーがサーバーに接続できます。 Linux システムでは接続数に制限がありませんが、サーバーが多数の接続に耐えられるかどうかは、サーバーのハードウェア構成、ソフトウェア アーキテクチャ、および最適化によって決まります。

01

2 つのプロセスが通信する必要がある場合、最も基本的な前提は、プロセスを一意に識別できることです。プロセス 。ローカル プロセス通信では、PID を使用してプロセスを一意に識別できますが、PID はローカルでのみ一意であり、ネットワーク内の 2 つのプロセス間で PID 競合が発生する可能性が非常に高くなります。

現時点では、IP アドレスでホストを一意に識別し、TCP 層のプロトコルとポート番号でホストのプロセスを一意に識別する別の方法を見つける必要があります。このように、IP アドレス +プロトコル + ポート番号を使用してホストを一意に識別できる、ネットワーク内のプロセス。

ネットワーク上のプロセスを一意に識別できるようになると、ソケットを使用して通信できるようになります。ソケットはアプリケーション層とトランスポート層の間の抽象化層であり、TCP/IP 層の複雑な操作をいくつかの単純なインターフェイスに抽象化し、アプリケーション層がネットワーク内で通信するためのプロセスを呼び出して実装できるようにします。

ソケットは Unix に由来し、「オープン-読み取り/書き込み-クローズ」モードの実装です。サーバーとクライアントはそれぞれ、「ファイル」では、接続を確立して開いた後、相手が読み取れるように自分のファイルにコンテンツを書き込んだり、相手のコンテンツを読み取ったりして、通信が終了したらファイルを閉じることができます。

02

接続を判断できるのは 4 つのことだけです:

1. サーバーの IP

2. サーバーのポート

3. クライアントの IP

4. クライアントのポート

サーバーの IP とポートは、クライアントの IP とポートが変更されない限り変更されません。それぞれが異なり、接続番号が決定されます。

ソケットは複数の接続を確立できます。TCP 接続は 4 つのタプル (source_ip、source_port、destination_ip、destination_port)、つまり (source IP、Source) としてマークされます。ポート、宛先 IP、宛先ポート）は 4 つの要素の組み合わせです。 4 つの要素の組み合わせのうち 1 つの要素が異なれば、異なる接続を区別できます。

例:

->ホスト IP アドレスは 1.1.1.1、ポート 8080 でリッスンします

->メッセージが 2.2.2.2 接続から来た場合リクエスト、ポート 5555。この接続の 4 タプルは (1.1.1.1, 8080, 2.2.2.2, 5555)

->この時点で、2.2.2.2 はポート 6666 を使用して 2 番目の接続要求を送信しました。新しい接続の 4 つのタプルは (1.1.1.1, 8080, 2.2.2.2, 6666)です。

すると、ホストの 8080 ポートは 2 つの接続を確立しました;

-> (2.2.2.2) から送信された 3 番目の接続要求、ポートは 5555 (または 6666) です。 3 番目の接続の要求は、上の 2 つの接続と区別する方法がないため、確立できません。

同様に、同じポート番号と IP アドレスに TCP ソケットと UDP ソケットをバインドできます。

ポート番号は同じですが、プロトコルが異なるためです。異なるものは同じであるため、ポートは完全に独立しています。

TCP/UDP は通常、5 つのタプルを使用して接続を見つけます:

source_ip、source_port、destination_ip、destination_port、protocol_type

つまり (source IP、送信元ポート、宛先 IP、宛先ポート、プロトコル番号)

要約すると、同時サーバーの数は TCP の 65535 ポートによって決まりません。サーバーが同時に耐えられる同時実行数は、帯域幅、ハードウェア、プログラム設計などの多くの要因によって決まります。

タオバオ、テンセント、トウティアオ、百度、新浪、ビープビープなどが、サーバークラスターを使用しているため、毎秒数億の同時アクセスに耐えられる理由がわかります。サーバークラスタは全国の大きな計算機室に分散しており、アクセス数が少ないときは一部のサーバーを停止し、アクセス数が多いときは継続的に新しいサーバーを立ち上げます。

常識 1: ファイル ハンドルの制限

Linux でネットワーク サーバー プログラムを作成する友人は、各 TCP 接続がファイル記述子を占有する必要があることを知っている必要があります。が使い果たされており、新しい接続が到着したときに返されるエラーは 「ソケット/ファイル: 非常に多くのファイルを開けません」 です。

現時点では、開くことができるファイルの最大数に関するオペレーティング システムの制限を理解しておく必要があります。

• プロセス制限

  • ulimit -n を実行すると 1024 が出力され、プロセスが最大 1024 個のファイルしか開けないことを示します。このデフォルト構成では、最大数千の同時 TCP 接続を確立できます。

  • 一時的な変更: ulimit -n 1000000 ただし、この一時的な変更は現在ログインしているユーザーの現在の使用環境に対してのみ有効であり、システムの再起動または再起動後に無効になります。ユーザーがログアウトします。

  • 再起動後に無効になる変更 (ただし、CentOS 6.5 でテストしたところ、再起動後は無効になりませんでした): /etc/security/limits.conf ファイルを編集します。変更された内容は次のとおりです。

    * ソフト ノードファイル 1000000

    * ハード ノードファイル 1000000

  • 永続的な変更: edit /etc /rc .local の後に次の内容を追加します。

    ulimit -SHn 1000000

• グローバル制限

  • cat /proc/sys/fs/file-nr 出力 9344 0 592026 をそれぞれ実行します: 1. 割り当てられたファイル ハンドルの数、2. 割り当てられたファイル ハンドルの数割り当てられているが使用されていない、3. ファイル ハンドルの最大数。ただし、カーネル バージョン 2.6 では、2 番目の項目の値は常に 0 です。これはエラーではなく、実際には、割り当てられたすべてのファイル記述子が使用されたことを意味します。

  • この値をより大きな値に変更し、root 権限で /etc/sysctl.conf ファイルを変更できます。

    fs.file-max = 1000000

    net.ipv4.ip_conntrack_max = 1000000

    #net.ipv4.netfilter.ip_conntrack_max = 1000000

#常識 2: ポート番号の範囲制限?

オペレーティング システムでは、1024 未満のポート番号はシステムによって予約されており、1024 ～ 65535 はユーザーによって使用されます。各 TCP 接続はポート番号を占有するため、最大 60,000 を超える同時接続が可能です。そんな間違った考えを持っている友達も多いのではないでしょうか？ (私も昔はそう思っていました)

分析してみましょう

• TCP 接続を識別する方法: システムは、4 つのタプルを使用して TCP 接続を一意に識別します: {ローカル IP、ローカル ポート、リモート IP、リモート ポート}。さて、『UNIX ネットワーク プログラミング: 第 1 巻』の第 4 章にある accept の説明を取り出して概念的なものを見てみましょう 2 番目のパラメータ cliaddr はクライアントの IP アドレスとポート番号を表します。サーバーとして、実際にはバインド中にのみポートを使用します。これは、ポート番号 65535 が同時実行量の制限ではないことを示しています。

• サーバーの TCP 接続の最大数: 通常、サーバーはローカル ポートでリッスンするように固定されており、クライアントの接続要求を待機します。アドレスの再利用 (Unix の SO_REUSEADDR オプション) を考慮しない場合、サーバー側に複数の IP がある場合でも、ローカル リスニング ポートは排他的であるため、サーバー側の TCP 接続 4 タプルにはリモート IP (つまり、クライアント IP) のみが含まれます。 ) とリモート ポート (クライアント ポート) は可変であるため、最大 TCP 接続数はクライアント IP 数 × クライアント ポート数になります。IPV4 の場合、IP アドレスの分類などの要因に関係なく、最大 TCP 接続数は約2の32乗（IP数））×2の16乗（ポート数）、つまりサーバ側の1台のマシンの最大TCPコネクション数は約2の48乗となります。

#共通設定

#1. ユーザー プロセスが開くことができるファイル数の制限を変更します

Linux の場合プラットフォーム上で、クライアント プログラムを作成するかサーバー プログラムを作成するかに関係なく、同時実行性の高い TCP 接続を処理する場合、同時実行の最大数は、ユーザーが開くことができるファイル数に関するシステムの制限の影響を受けます。単一プロセス内で同時に実行できます (これは、システムが接続ごとにソケット ハンドルを作成する必要があり、各ソケット ハンドルがファイル ハンドルでもあるためです)。 ulimit コマンドを使用すると、システムが現在のユーザー プロセスが開くことを許可するファイル数の制限を表示できます:

[speng@as4 ~]$ ulimit -n
1024

これは、現在のユーザーの各プロセスが最大 1024 個のファイルを開くことができることを意味します。この 1024 個のファイルから各プロセスを削除する必要がある 標準入力、標準出力、標準エラー、サーバー監視ソケット、プロセス間通信用の Unix ドメイン ソケットなどのファイルをオープンする必要があるため、残りのファイル数はクライアントソケット接続に使用できるのは、約 1024-10=1014 だけです。つまり、デフォルトでは、Linux ベースの通信プログラムは同時に最大 1014 の同時 TCP 接続を許可します。

より多くの同時 TCP 接続をサポートしたい通信ハンドラの場合は、現在のユーザーが同時に開くファイルの数に関する Linux の

ソフト制限 (ソフト制限) とハード制限 (ハード制限)## を変更する必要があります。プロセス。 ＃。ソフト制限は、Linux が現在のシステムが耐えられる範囲内でユーザーが同時に開くことができるファイルの数をさらに制限することを意味します。ハード制限は、システムが同時に開くことができるファイルの最大数を計算して計算します。システムのハードウェア リソース (主にシステム メモリ) に基づきます。通常、ソフト制限はハード制限以下です。
上記の制限を変更する最も簡単な方法は、ulimit コマンドを使用することです。

[speng@as4 ~]$ ulimit -n

上記のコマンドでは、設定する単一プロセスによってオープンできるファイルの最大数を指定します。システムが「操作が許可されていません」のようなメッセージを表示する場合は、上記の制限の変更が失敗したことを意味します。実際には、 で指定された値が、ユーザーが開いたファイル数に対する Linux システムのソフト制限またはハード制限を超えているためです。したがって、ユーザーが開くファイルの数に関する Linux システムのソフト制限とハード制限を変更する必要があります。

最初のステップ

、/etc/security/limits.conf ファイルを変更し、ファイルに次の行を追加します。

...
# End of file
speng soft nofile 10240
speng hard nofile 10240
root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535
[test@iZwz9e1dh1nweaex8ob5b7Z config]$

speng は、変更するユーザーを指定します。開いているファイルの数の制限。「*」記号を使用して、すべてのユーザーの制限を変更することを指定できます。ソフトまたはハードは、ソフト制限とハード制限のどちらを変更するかを指定します。10240 は、変更する新しい制限値を指定します。つまり、開いているファイルの最大数を変更します (ソフト制限値はハード制限以下である必要があることに注意してください)。変更を加えた後、ファイルを保存します。

2 番目のステップ

では、/etc/pam.d/login ファイルを変更し、ファイルに次の行を追加します。

session required /lib/security/pam_limits.so

これは、ユーザーの後に次のことを Linux に伝えます。システムのログインが完了します。 最後に、pam_limits.so モジュールを呼び出して、ユーザーが使用できるさまざまなリソースの数に対するシステムの最大制限 (ユーザーが開くことができるファイルの最大数の制限を含む) を設定する必要があります。 pam_limits.so モジュールは、/etc/security/limits からシステム制限を設定します。設定は .conf ファイルから読み取られて、これらの制限値を設定します。変更後、このファイルを保存します。

3 番目のステップ

では、オープン ファイルの最大数に関する Linux システム レベルの制限を確認します。次のコマンドを使用します。

[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158

これは、この Linux システムが許可していることを示します。同時に開くことができる最大数 (つまり、すべてのユーザーが開いているファイルの総数を含む) は 12158 ファイルであり、これは Linux システムレベルのハード制限です。開いているファイルの数に関するユーザーレベルの制限はすべて、これを超えてはなりません価値。通常、このシステム レベルのハード制限は、Linux システムの起動時にシステム ハードウェア リソースに基づいて計算された、同時にオープンされるファイルの最適な最大数です。特別な必要がない限り、この制限は制限する必要がない限り変更しないでください。ユーザー レベルで開かれるファイルの数。この制限を超える値を設定します。このハード制限を変更する方法は、/etc/rc.local スクリプトを変更し、次の行をスクリプトに追加することです。

echo 22158 > /proc/sys/fs/file-max

これは、Linux にシステムレベルのハード制限を強制的に設定するためのものです。起動完了後、開いているファイルの数は 22158 になります。変更後、このファイルを保存します。

完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用 ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit -n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次 ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。

通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。

2、修改网络内核对TCP连接的有关限制（参考对比下篇文章“优化内核参数”）

在Linux上编写支持高并发TCP连接的客户端通讯处理程序时，有时会发现尽管已经解除了系统对用户同时打开文件数的限制，但仍会出现并发TCP连接数增加到一定数量时，再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。

第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时，进一步分析为什么无法建立TCP连接，会发现问题出在connect()调用返回失败，查看系统错误提示消息是“Can’t assign requestedaddress”。同时，如果在此时用tcpdump工具监视网络，会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。其实，问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如，内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时，由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中)，如果现有的TCP客户端连接已将所有的本地端口号占满，则此时就无法为新的TCP客户端连接分配一个本地端口号了，因此系统会在这种情况下在connect()调用中返回失败，并将错误提示消息设为“Can’t assignrequested address”。有关这些控制逻辑可以查看Linux内核源代码，以linux2.6内核为例，可以查看tcp_ipv4.c文件中如下函数：

static int tcp_v4_hash_connect(struct sock *sk)

请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的如下函数中设置：

void __init tcp_init(void)

内核编译时默认设置的本地端口号范围可能太小，因此需要修改此本地端口范围限制。

第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：

net.ipv4.ip_local_port_range = 1024 65000

这表明将系统对本地端口范围限制设置为1024~65000之间。请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。

第二步，执行sysctl命令：

[speng@as4 ~]$ sysctl -p

如果系统没有错误提示，就表明新的本地端口范围设置成功。如果按上述端口范围进行设置，则理论上单独一个进程最多可以同时建立60000多个TCP客户端连接。

第二种无法建立TCP连接的原因可能是因为Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP连接数有限制。此时程序会表现为在 connect()调用中阻塞，如同死机，如果用tcpdump工具监视网络，也会发现根本没有TCP连接时客户端发SYN包的网络流量。由于 IP_TABLE防火墙在内核中会对每个TCP连接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrackdatabase中，这个数据库的大小有限，当系统中存在过多的TCP连接时，数据库容量不足，IP_TABLE无法为新的TCP连接建立跟踪信息，于是表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP连接数的限制，方法同修改内核对本地端口号范围的限制是类似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：

net.ipv4.ip_conntrack_max = 10240

这表明将系统对最大跟踪的TCP连接数限制设置为10240。请注意，此限制值要尽量小，以节省对内核内存的占用。

第二步，执行sysctl命令：

[speng@as4 ~]$ sysctl -p

如果系统没有错误提示，就表明系统对新的最大跟踪的TCP连接数限制修改成功。如果按上述参数进行设置，则理论上单独一个进程最多可以同时建立10000多个TCP客户端连接。

3、使用支持高并发网络I/O的编程技术

在Linux上编写高并发TCP连接应用程序时，必须使用合适的网络I/O技术和I/O事件分派机制。
可用的I/O技术有同步I/O，非阻塞式同步I/O(也称反应式I/O)，以及异步I/O。《BIO,NIO,AIO的理解》

在高TCP并发的情形下，如果使用同步I/O，这会严重阻塞程序的运转，除非为每个TCP连接的I/O创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高TCP并发的情形下使用同步 I/O是不可取的，这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。
从I/O事件分派机制来看，使用select()是不合适的，因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能，poll()也是不合适的，尽管它可以支持的较高的TCP并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个 I/O请求创建一个线程来实现的，这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经得到改进)。
综上所述，在开发支持高并发TCP连接的Linux应用程序时，应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制，这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。

内核参数sysctl.conf的优化

/etc/sysctl.conf 是用来控制linux网络的配置文件，对于依赖网络的程序（如web服务器和cache服务器）非常重要，RHEL默认提供的最好调整。

推荐配置（把原/etc/sysctl.conf内容清掉，把下面内容复制进去）：

net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

这个配置参考于cache服务器varnish的推荐配置和SunOne 服务器系统优化的推荐配置。

varnish调优推荐配置的地址为：http://varnish.projects.linpro.no/wiki/Performance

不过varnish推荐的配置是有问题的，实际运行表明“net.ipv4.tcp_fin_timeout = 3”的配置会导致页面经常打不开；并且当网友使用的是IE6浏览器时，访问网站一段时间后，所有网页都会打不开，重启浏览器后正常。可能是国外的网速快吧，我们国情决定需要调整“net.ipv4.tcp_fin_timeout = 10”，在10s的情况下，一切正常（实际运行结论）。

修改完毕后，执行：

/sbin/sysctl -p /etc/sysctl.conf
/sbin/sysctl -w net.ipv4.route.flush=1

命令生效。为了保险起见，也可以reboot系统。

调整文件数：

linux系统优化完网络必须调高系统允许打开的文件数才能支持大的并发，默认1024是远远不够的。

执行命令：

echo ulimit -HSn 65536 >> /etc/rc.local
echo ulimit -HSn 65536 >>/root/.bash_profile
ulimit -HSn 65536

备注：

对mysql用户可同时打开文件数设置为10240个；
将Linux系统可同时打开文件数设置为1000000个（一定要大于对用户的同时打开文件数限制）；
将Linux系统对最大追踪的TCP连接数限制为20000个（但是，建议设置为10240；因为对mysql用户的同时打开文件数已经限制在10240个；且较小的值可以节省内存）；
将linux系统端口范围配置为1024～30000（可以支持60000个以上连接，不建议修改；默认已经支持20000个以上连接）；

综合上述四点，TCP连接数限制在10140个。
这10240个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通讯的unix域socket等文件。

因此，当需要对TCP连接数进行调整时只需要调整ulimit参数。

Linux下查看tcp连接数及状态命令：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

相关推荐：《Linux视频教程》

以上がLinux システムの TCP 接続数に影響を与える要因の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。