使用できるゾンビプロセスの数に上限はありますか?


17

以前HP-UXシステムで作業していたが、古い管理者から、システムで使用できるゾンビプロセスの数に上限があると言われました。1024

  • これは難しい事実の上限ですか?プロセスをいくつでも持つことができるかのように、ゾンビをいくつでも持つことができると思います...?
  • ディストリビューションごとに異なる値ですか?
  • 上限に達して別のゾンビを作成しようとするとどうなりますか?

1
このブログ記事によると、Linuxでの唯一の制限はPIDの数であり、これは付随的にゾンビにのみ影響します。
バハマ

2
以下の両方の回答に言及しulimit -uます。man ulimitCルーチンに言及していないので、しばらく混乱していました-u。前述のulimitは実際には組み込みのbashツールであり、bashのマンページで説明されています。
エマニュエルベルク

回答:


11

HP-UXを利用できません。HP-UXの大ファンでもありません。

Linuxでは、プロセスごとまたはユーザーごとに、存在する子プロセスの数が制限されているようです。limitZshビルトインで見ることができます(ulimit -ubashに似ているようです):

1002 % limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         16136
  ...

これはArch Linuxラップトップ上にあります。

その制限をテストするための小さなプログラムを作成しました。

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>

volatile int sigchld_cnt = 0;

voida
sigchld_hdlr(int signo)
{
        ++sigchld_cnt;
}

int
main(int ac, char **av)
{
        int looping = 1;
        int child_cnt = 0;
        int status;

        signal(SIGCHLD, sigchld_hdlr);

        printf("Parent PID %d\n", getpid());

        while (looping)
        {
                switch (fork())
                {
                case 0:
                        _exit(0);
                        break;
                case -1:
                        fprintf(stderr, "Problem with fork(), %d children: %s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                        break;
                default:
                        ++child_cnt;
                        break;
                }
        }

        fprintf(stderr, "Sleeping, forked %d child processes\n", child_cnt);
        fprintf(stderr, "Received %d sigchild\n", sigchld_cnt);
        sleep(10);

        looping = 1;
        do {
                int x = wait(&status);

                if (x != -1)
                        --child_cnt;
                else if (errno != EINTR) {
                        fprintf(stderr, "wait() problem %d children left: \%s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                }
        } while (looping);

        printf("%d children left, %d SIGCHLD\n", child_cnt, sigchld_cnt);

        return 0;
}

wait(2)十分な回数を呼び出してすべてのゾンビを「収集」することは驚くほど困難でした。また、受信したSIGCHLDシグナルの数は、分岐した子プロセスの数と同じになることはありません。Linuxカーネルは、終了した子プロセスの数に対して1つのSIGCHLDを送信することがあります。

とにかく、私のArch Linuxラップトップでは、16088個の子プロセスが分岐します。これは、プログラムがwait(2)シグナルハンドラーでシステムコールを行わないため、ゾンビの数でなければなりません。

Slackware 12サーバーでは、6076の子プロセスを取得します。これは、の値とほぼ一致していますmaxproc 6079。私のユーザーIDには、実行中の他の2つのプロセスsshdとZshがあります。6079を作成する上記のプログラムの最初の非ゾンビインスタンスとともに。

fork(2)システムコールは、「リソース一時的に利用できません」というエラーで失敗します。どのリソースが利用できないかを示す他の証拠は見当たりません。2つの異なるxtermで同時にプログラムを実行すると、多少異なる数値が得られますが、1つのxtermで実行した場合と同じ数値になります。単なる任意の制限ではなく、プロセステーブルエントリ、スワップ、またはシステム全体のリソースであると想定しています。

私は今、それを試すために実行しているものは何も持っていません。


4

HP-UXの制限がわからない。ただし、論理的な実装では、最大サイズのプロセステーブルを使用することになります。プロセステーブルエントリの合計数は、理論的にはプロセスIDの範囲によって制限されますが、ほとんどの実装では、テーブルのサイズ制限があり、最大値ははるかに小さくなります。ほとんどのUNIXバリアントには、プロセス数に関するユーザーごとの制限もあります。ulimit -ubashで実行することで制限を確認できます。

UNIXシステムでは、プロセスID(実際のプロセスとゾンビを含む)の数ではなく、ゾンビに個別の制限があるとは考えていません。そのため、プロセスが死んでゾンビになっても、制限には影響しません。リソース(プロセステーブルのエントリ)は、プロセスが分岐するときに割り当てられ、プロセスが刈り取られると解放されます。


2

プロセスをいくつでも持つことができるかのように、ゾンビをいくつでも持つことができると思います...?

ゾンビプロセスは、最終的には特別な状態のプロセスであり、通常のプロセスと同様に、ゾンビプロセスはプロセステーブルの可用性とサイズに制限されます。

ディストリビューションごとに異なる値ですか?

確かに、他の多くのパラメーターと同じです。特定のサイズで中継したり、多くのゾンビプロセスを保持するのに十分な大きさで中継したりしないでください。ゾンビが多すぎる場合、ソリューションは大きなテーブルではありません。最終的に満杯になるからです。ゾンビプロセスはそれ自体では悪くありませんが、蓄積されたゾンビプロセスが多すぎるということは、そのようなゾンビプロセスを許可している「動作が悪い」プログラムを示しています。

上限に達して別のゾンビを作成しようとするとどうなりますか?

プロセステーブルが(通常およびゾンビプロセスで)いっぱいになると、システムに十分なリソース(メモリ、プロセッサなど)がある場合でも、新しい-通常プロセスを作成できません。不足しているリソースは、プロセステーブル内の1つのエントリだけです。すでに実行されているプログラムは、「正常に動作する」ものであっても、サブプロセスを作成する必要があるときに失敗し始めます。新しいプログラムは起動できず、単一のコマンドの実行でさえ失敗しました。


Even running single commands would fail.->それは大きな影響です。
シプルモカディム18年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.