मेरा अनुभव यह है कि मेरा उच्च-प्रक्रिया-गणना कार्य केवल इसके साथ सफल हुआ:
kern.maxproc=2500 # This is as big as I could set it.
kern.maxprocperuid=2048
ulimit -u 2048
/etc/sysctl.confविश्वसनीय सेटिंग के लिए पहले दो और लॉन्चड.कॉन्फ़ में ulimit मान जा सकते हैं ।
चूंकि tcp / ip मेरे द्वारा किए जा रहे काम का हिस्सा था, इसलिए मुझे टक्कर देने की भी जरूरत थी
kern.ipc.somaxconn=8192
इसके डिफ़ॉल्ट 128 से।
इससे पहले कि मैं प्रक्रिया की सीमा बढ़ाता, मुझे पर्याप्त संसाधन नहीं, "कांटा" विफलताएं मिल रही थीं। इससे पहले कि मैं kern.ipc.somaxconn बढ़ाता, मुझे "टूटी हुई पाइप" त्रुटियां मिल रही थीं।
यह मेरे राक्षस मैक, ओएस 10.5.7, फिर 10.5.8, अब 10.7.1 पर अलग-अलग प्रक्रियाओं की एक उचित संख्या (500-4000) चला रहा था। मेरे बॉस के कंप्यूटर पर लिनक्स के तहत यह सिर्फ काम किया।
मैंने सोचा था कि प्रक्रियाओं की संख्या 1000 के करीब होगी लेकिन ऐसा लगता है कि मैंने शुरू की प्रत्येक प्रक्रिया में वास्तविक काम करने वाली वास्तविक वस्तु के अलावा शेल की अपनी प्रति भी शामिल थी। बहुत उत्सव।
मैंने एक प्रदर्शन खिलौना लिखा था जो कुछ इस तरह था:
#!/bin/sh
while[ 1 ]
do
n=netstat -an | wc -l
nw=netstat -an | grep WAIT | wc -l
p=ps -ef | wc -l
psh=ps -ef | fgrep sh | wc -l
echo "netstat: $n wait: $nw ps: $p sh: $psh"
sleep 0.5
done
और ps -ef में अधिकतम प्रक्रियाओं को देखा और netstat में घूमने के TIME_WAITलिए समाप्त होने की प्रतीक्षा कर रहा है ... सीमाएं बढ़ने के साथ, मैंने 3500+ TIME_WAITआइटम चरम पर देखे ।
इससे पहले कि मैं सीमा को उठाता मैं विफलता सीमा पर 'चुपके' कर सकता था, जो 1K से नीचे शुरू हुआ, लेकिन 1190 के उच्च मूल्य तक बढ़ गया .. हर बार इसे असफलता में धकेल दिया गया, यह अगली बार थोड़ा अधिक हो सकता है, शायद कुछ के कारण कैश किया गया जो हर बार अपनी सीमा तक विस्तारित होने में विफल रहा।
हालांकि मेरे परीक्षण के मामले में एक "प्रतीक्षा" थी क्योंकि इसके अंतिम बयान में अभी भी अलग-अलग प्रक्रियाओं की योजना थी जो इसके बाहर निकलने के बाद चारों ओर लटकी हुई थी।
मुझे अधिकांश जानकारी इंटरनेट पर पोस्टिंग से मिली, लेकिन यह सब सटीक नहीं था। आपका माइलेज अलग-अलग हो सकता है।