Sahip olabileceğiniz zombi işlemlerinin sayısının üst sınırı var mı?


17

Eskiden bir HP-UX sistemi ile çalışıyordum ve eski yönetici, sistemde sahip olabileceğiniz zombi işlemlerinin sayısının üst sınırı olduğunu söyledi, sanırım 1024.

  • Bu zor bir tavan mı? Sanırım herhangi bir sayıda işlem yapabiliyormuş gibi herhangi bir sayıda zombileriniz olabilir ...?
  • Dağıtımdan dağıtıma farklı bir değer var mı?
  • Üst sınıra ulaşıp başka bir zombi yaratmaya çalışırsak ne olur?

1
Bu blog makalesine göre , Linux'taki tek sınır, zombileri sadece tesadüfen etkileyen PID sayısıdır.
bahamat

2
Her iki cevap da aşağıda belirtilmiştir ulimit -u. man ulimitBana herhangi bir söz ile bir C rutin var gibi bir süre karıştı -u. Bahsedilen ulimit aslında yerleşik bir bash aracıdır ve bash man sayfasında açıklanmıştır.
Emanuel Berg

Yanıtlar:


11

Kullanabileceğim HP-UX yok ve asla büyük bir HP-UX hayranı olmadım.

Linux'ta, kaç alt işlem bulunduğuna ilişkin işlem başına veya belki kullanıcı başına bir sınır olduğu görülmektedir. limitYerleşik Zsh ile görebilirsiniz ( ulimit -ubash ile benzer görünüyor ):

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

Bir Arch linux dizüstü bilgisayarda.

Bu sınırı test etmek için küçük bir program yazdım:

#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)Yeterli kez arayarak tüm zombi "toplamak" şaşırtıcı derecede zordu . Ayrıca, alınan SIGCHLD sinyallerinin sayısı hiçbir zaman çatallanan alt süreçlerin sayısı ile aynı değildir: Bence linux çekirdeği bazı çıkış işlemleri için bazen 1 SIGCHLD gönderir.

Her neyse, Arch linux dizüstü bilgisayarımda 16088 alt işlemin çatallandığını görüyorum ve program wait(2)sinyal işleyicide sistem çağrıları yapmadığı için bu zombi sayısı olmalı .

Slackware 12 sunucumda değeri ile yakından eşleşen 6076 alt işlem alıyorum maxproc 6079. Kullanıcı kimliğimde çalışan 2 işlem sshdve Zsh var. Yukarıdaki programın zombi olmayan ilk örneği ile birlikte 6079 yapar.

fork(2)Sistem çağrısı bir "Kaynak geçici olarak kullanılamıyor" hatası ile başarısız olur. Hangi kaynağın mevcut olmadığına dair başka bir kanıt görmüyorum. Programımı aynı anda 2 farklı xterm'de çalıştırırsam biraz farklı sayılar alırım, ancak bir xterm'de çalıştırıyormuşum gibi aynı sayıya kadar eklerler. Ben sadece keyfi bir sınır değil, işlem tablosu girdileri, takas ya da bazı sistem çapında kaynak olduğunu varsayalım.

Şu anda denemek için çalışan başka bir şeyim yok.


4

HP-UX'in sınırlarının ne olduğunu bilmiyorum. Ancak size mantıksal uygulamanın maksimum boyutta bir işlem tablosuna sahip olduğunu söyleyebilirim. Toplam işlem tablosu girişi sayısı teorik olarak işlem kimlikleri aralığıyla sınırlıdır, ancak uygulamaların çoğu tablo için çok daha küçük bir maksimum değer sağlayan bir boyut sınırına sahiptir. Çoğu unix varyantının işlem sayısı için kullanıcı başına bir sınırı vardır; ulimit -ubash içinde koşarak sınırı görebilirsiniz .

Unix sisteminin zombiler üzerinde ayrı bir sınır olmasını beklemiyorum, işlem kimlikleri (zombileri olduğu kadar gerçek süreçleri de içeriyor) sayısı yerine. Dolayısıyla, bir süreç öldüğünde ve bir zombi olduğunda, bu sınırı etkilemez: bir süreç çatallandığında kaynak (süreç tablosundaki giriş) tahsis edilir ve işlem tekrarlandığında serbest bırakılır.


2

Sanırım herhangi bir sayıda işlem yapabiliyormuş gibi herhangi bir sayıda zombileriniz olabilir ...?

Bir zombi süreci nihayet bir süreçtir -özel bir durumda- sonra zombi süreçleri, normal süreçlerde olduğu gibi süreç tablosunun kullanılabilirliği ve boyutu ile sınırlıdır .

Dağıtımdan dağıtıma farklı bir değer var mı?

Elbette, diğer birçok parametre gibi. Belirli bir boyutta veya birçok zombi işlemini tutacak kadar büyükse geçiş yapmamalısınız. Çok fazla zombi alıyorsanız, çözüm büyük bir tablo değildir, çünkü sonunda doldurulacaktır. Bir zombi süreci tek başına kötü değildir, ancak çok fazla birikmiş zombi sürecine sahip olmak, zombi süreçlerine izin veren "kötü davranılmış" bir programın bir göstergesidir.

Üst sınıra ulaşıp başka bir zombi yaratmaya çalışırsak ne olur?

İşlem tablosu - düzenli ve zombi süreçleri - dolu olduğunda, sistem yeterli bellek-işlemci, işlemci, vb. Olsa bile, yeni-düzenli-süreç oluşturulamaz. Tek eksik kaynak, işlem tablosundaki tek bir girdidir. Zaten çalışan programlar - hatta bu "iyi davranmış" - bir alt süreç oluşturmaları gerektiğinde başarısız olmaya başlayacaktır. Yeni programlar başlatılamadı ve tek komutların çalıştırılması bile başarısız olurdu.


Even running single commands would fail.-> bu büyük bir etki.
Shiplu Mokaddim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.