2008-09-22 13 views
7

में कम जावा एकल प्रक्रिया थ्रेड सीमा मुझे जावा 1.6 (1.6.0_02 या 1.6.0_04) का उपयोग कर Red Hat Linux (कर्नेल संस्करण 2.4.21-37.ELsmp) चल रहे परीक्षण मशीन पर कोई समस्या का सामना कर रहा है)। समस्या यह है कि, एक थ्रेड समूह में धागे की एक निश्चित संख्या बनाई जाने के बाद, ऑपरेटिंग सिस्टम अनिच्छुक या अब और बनाने में असमर्थ है।Red Hat Linux

यह जावा बनाने के धागे के लिए विशिष्ट प्रतीत होता है, क्योंकि सी थ्रेड-सीमा प्रोग्राम लगभग 1.5k धागे बनाने में सक्षम था। इसके अतिरिक्त, यह जावा 1.4 जेवीएम के साथ नहीं होता है ... यह 1.4k से अधिक धागे बना सकता है, हालांकि स्पष्ट रूप से ओएस के संबंध में उन्हें अलग-अलग संभाला जा रहा है।

इस मामले में, जिस धागे पर इसकाट रहा है वह केवल 2 9 धागे है। यह एक साधारण जावा प्रोग्राम के साथ टेस्टेबल है जो तब तक थ्रेड बनाता है जब तक कि यह कोई त्रुटि न हो और उसके बाद बनाए गए धागे की संख्या प्रिंट करता हो। त्रुटि

java.lang.OutOfMemoryError: unable to create new native thread

यह ऐसी प्रक्रियाओं से अप्रभावित प्रतीत होता है जैसे अन्य प्रक्रियाओं या उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले धागे की संख्या या उस समय सिस्टम की स्मृति की कुल मात्रा का उपयोग किया जा रहा है। एक्सएमएस, एक्सएमएक्स, और एक्सएसएस जैसी जेवीएम सेटिंग्स कुछ भी नहीं बदलती हैं (जो उम्मीद है, इस मुद्दे पर देशी ओएस थ्रेड निर्माण के साथ लगता है)।

 
core file size  (blocks, -c) 0 
data seg size   (kbytes, -d) unlimited 
file size    (blocks, -f) unlimited 
max locked memory  (kbytes, -l) 4 
max memory size  (kbytes, -m) unlimited 
open files     (-n) 1024 
pipe size   (512 bytes, -p) 8 
stack size   (kbytes, -s) 10240 
cpu time    (seconds, -t) unlimited 
max user processes   (-u) 7168 
virtual memory  (kbytes, -v) unlimited 

उपयोगकर्ता प्रक्रिया सीमा मुद्दा हो प्रतीत नहीं होता:

"ulimit-एक" के उत्पादन में इस प्रकार है। गलत क्या हो सकता है, इस बारे में जानकारी के लिए खोज करना बहुत अधिक नहीं हुआ है, लेकिन this post इंगित करता है कि कम से कम कुछ Red Hat कर्नेल स्टैक के लिए आवंटित 300 एमबी मेमोरी की प्रक्रिया को सीमित करते हैं, और स्टैक के लिए 10 एमबी प्रति थ्रेड पर, ऐसा लगता है मुद्दा वहां हो सकता है (हालांकि यह अजीब और असंभव लगता है)।

मैं इस परीक्षण करने के लिए के साथ "ulimit -s" ढेर आकार बदलने की कोशिश की है, लेकिन किसी भी मूल्य 10240 के अलावा अन्य और JVM की एक त्रुटि के साथ शुरू नहीं करता है: मैं आम तौर पर प्राप्त कर सकते हैं

Error occurred during initialization of VM 
Cannot create VM thread. Out of system resources.

लिनक्स के आसपास, लेकिन मुझे वास्तव में सिस्टम कॉन्फ़िगरेशन के बारे में बहुत कुछ पता नहीं है, और मैं इस तरह की स्थिति को विशेष रूप से संबोधित करने में कुछ भी नहीं ढूंढ पा रहा हूं। सिस्टम या जेवीएम सेटिंग्स के कारण किसी भी विचार के कारण यह सराहना की जाएगी।

संपादन: plinth द्वारा वर्णित थ्रेड-सीमा कार्यक्रम को चलाने में, 1529 वें धागे को बनाने की कोशिश करने तक कोई विफलता नहीं थी।

यह मुद्दा 1.4 जेवीएम (1.6.0_02 और 1.6.0_04 जेवीएम के साथ होता है, इस समय 1.5 जेवीएम के साथ परीक्षण नहीं कर सकता) का उपयोग नहीं किया गया है।

इस प्रकार धागा परीक्षण मैं उपयोग कर रहा हूँ के लिए कोड है:

public class ThreadTest { 

    public static void main(String[] pArgs) throws Exception { 

     try { 
     // keep spawning new threads forever 
     while (true) { 
      new TestThread().start(); 
     } 
     } 
     // when out of memory error is reached, print out the number of 
     // successful threads spawned and exit 
     catch (OutOfMemoryError e) { 
     System.out.println(TestThread.CREATE_COUNT); 
     System.exit(-1); 
     } 
    } 

    static class TestThread extends Thread { 
     private static int CREATE_COUNT = 0; 
     public TestThread() { 
     CREATE_COUNT++; 
     } 
     // make the thread wait for eternity after being spawned 
     public void run() { 
     try { 
      sleep(Integer.MAX_VALUE); 
     } 
     // even if there is an interruption, dont do anything 
     catch (InterruptedException e) { 
     } 
     } 
    } 
} 

यह रखती हूँ कि आप एक 1.4 JVM के साथ इस चलाते हैं जब यह किसी भी अधिक सूत्र नहीं बना सकते हैं और एक को मारने की आवश्यकता होती है सकते हैं - 9 (कम से कम यह मेरे लिए किया)।

अधिक संपादित करें:

ऐसा लगता है कि प्रणाली है कि समस्या हो रही है LinuxThreads मॉडल सूत्रण, जबकि एक अन्य प्रणाली है कि ठीक काम करता है NPTL मॉडल का उपयोग कर रहा है उपयोग कर रहा है।

+0

सिर्फ सभी नए प्रोग्रामर अभाव होने के लिए एक छोटा सा sidenote: कभी नहीं का उपयोग 'जबकि (सही)' कहीं भी स्कूल परियोजनाओं और निजी प्रयोग और _NEVER_ धागे के हजारों बनाने के लिए, के अलावा अपने अनुप्रयोग सबसे अधिक संभावना है गंभीर बग अगर यह करता है - या फिर आपका एप्लिकेशन डिज़ाइन त्रुटिपूर्ण है। बस कहना .. – specializt

उत्तर

4

एनपीटीएल थ्रेडिंग के साथ कर्नेल को एक नए संस्करण (2.6.something) में अद्यतन करना यह तय किया गया है।

4

क्या आपने this resource पर देखा है? यह बताता है कि आपको थ्रेड की अधिकतम संख्या खोजने के लिए थ्रेड-सीमा चलाने में सक्षम होना चाहिए और glibc संकलित करके इसे ट्विक कर सकते हैं।

+0

आश्चर्यजनक रूप से पर्याप्त, थ्रेड-सीमा विफल होने से पहले 1528 धागे बनाने में सक्षम था। हम्म। – ColinD

0

आप इसे JRockit JVM के साथ की कोशिश कर सकते हैं के साथ है? आईआईआरसी, स्टॉक सन जेवीएम की तुलना में इसका एक अलग थ्रेडिंग मॉडल था।

0

/etc/security/limits.d/90-nproc.conf में सेटिंग्स आपके /etc/security/limits.conf सेटिंग्स को ओवरराइड कर सकती हैं। इससे सिस्टम ulimit -u में दिखाए गए तरीके से कार्य कर सकता है।

https://bugzilla.redhat.com/show_bug.cgi?id=823030