डायरेक्ट बाइटबफर कभी भी हॉर्नेटक सर्वर पर क्यों बढ़ रहा है ओओएम की ओर जाता है?

विन्यासडायरेक्ट बाइटबफर कभी भी हॉर्नेटक सर्वर पर क्यों बढ़ रहा है ओओएम की ओर जाता है?

मैं सेटअप एक स्टैंडअलोन HornetQ (2.4.7-अंतिम) Ubuntu 12.04.3 LTS (जीएनयू/लिनक्स 3.8.0-29-सामान्य x86_64) पर क्लस्टर। उदाहरण में 2 कोर के साथ 16 जीबी रैम है और मैंने JVM में -Xms5G -Xmx10G आवंटित किया है।

बाद HornetQ विन्यास में पता सेटिंग है:

<address-settings> 
     <address-setting match="jms.queue.pollingQueue"> 
     <dead-letter-address>jms.queue.DLQ</dead-letter-address> 
     <expiry-address>jms.queue.ExpiryQueue</expiry-address> 
     <redelivery-delay>86400000</redelivery-delay> 
     <max-delivery-attempts>10</max-delivery-attempts> 
     <max-size-bytes>1048576000</max-size-bytes> 
     <page-size-bytes>10485760</page-size-bytes> 
     <address-full-policy>PAGE</address-full-policy> 
     <message-counter-history-day-limit>10</message-counter-history-day-limit> 
     </address-setting> 
     <address-setting match="jms.queue.offerQueue"> 
     <dead-letter-address>jms.queue.DLQ</dead-letter-address> 
     <expiry-address>jms.queue.ExpiryQueue</expiry-address> 
     <redelivery-delay>3600000</redelivery-delay> 
     <max-delivery-attempts>25</max-delivery-attempts> 
     <max-size-bytes>1048576000</max-size-bytes> 
     <page-size-bytes>10485760</page-size-bytes> 
     <address-full-policy>PAGE</address-full-policy> 
     <message-counter-history-day-limit>10</message-counter-history-day-limit> 
     </address-setting> 
     <address-setting match="jms.queue.smsQueue"> 
     <dead-letter-address>jms.queue.DLQ</dead-letter-address> 
     <expiry-address>jms.queue.ExpiryQueue</expiry-address> 
     <redelivery-delay>3600000</redelivery-delay> 
     <max-delivery-attempts>25</max-delivery-attempts> 
     <max-size-bytes>1048576000</max-size-bytes> 
     <page-size-bytes>10485760</page-size-bytes> 
     <address-full-policy>PAGE</address-full-policy> 
     <message-counter-history-day-limit>10</message-counter-history-day-limit> 
     </address-setting> 
     <!--default for catch all--> 
     <!-- delay redelivery of messages for 1hr --> 
     <address-setting match="#"> 
     <dead-letter-address>jms.queue.DLQ</dead-letter-address> 
     <expiry-address>jms.queue.ExpiryQueue</expiry-address> 
     <redelivery-delay>3600000</redelivery-delay> 
     <max-delivery-attempts>25</max-delivery-attempts> 
     <max-size-bytes>1048576000</max-size-bytes> 
     <page-size-bytes>10485760</page-size-bytes> 
     <address-full-policy>PAGE</address-full-policy> 
     <message-counter-history-day-limit>10</message-counter-history-day-limit> 
     </address-setting> 
    </address-settings>

10 अन्य वाइल्डकार्ड द्वारा निर्दिष्ट डिफ़ॉल्ट पता करने के लिए बाध्य कतारों रहे हैं।

समस्या

समय डायरेक्ट ByteBuffer स्मृति धीरे-धीरे आकार में बढ़ जाती है और यहां तक कि स्वैप स्पेस अंततः OutOfMemoryError फेंक ("सीधी बफर स्मृति") पर है की अवधि के दौरान।

मैंने बहुत सारे जेवीएम और जेएमएस ट्यूनिंग की कोशिश की है लेकिन व्यर्थ में। यहां तक कि एक -XX निर्दिष्ट करना: JVM को MaxDirectMemorySize = 4G के परिणामस्वरूप उसी कारण से प्रारंभिक ओओएमई हुआ। ऐसा लगता है कि बाइटबफर को पढ़ा नहीं जा रहा है या जीसी अपरिवर्तित स्मृति का दावा नहीं कर रहा है।

क्या किसी को भी पहले एक ही समस्या का सामना करना पड़ा है?

किसी भी सुझाव का स्वागत है और अग्रिम धन्यवाद।

स्रोत

2016-01-24 Tushu

आप '-Dio.netty.leakDetectionLevel = पागल' – Ferrybig

इस से संबंधित है के साथ जावा दिखा सकता हूं? http://www.evanjones.ca/java-bytebuffer-leak.html –

मैं hornetq के internals बारे में कुछ पता नहीं है, इसलिए इस जवाब केवल सामान्य रूप में DBBs को शामिल किया गया:

एक साधारण रिसाव
इसके, DBB वस्तुओं बस अभी भी पहुंचा जा सकता है और इस तरह मुक्त नहीं कर रहे हैं। यह या तो किसी बग से या एप्लिकेशन के गलत उपयोग से उत्पन्न हो सकता है।
यहां सामान्य दृष्टिकोण एक ढेर डंप लेने और यह निर्धारित करने के लिए है कि वस्तुओं को जीवित रखता है।
बफर पहुंचने योग्य नहीं हैं लेकिन कचरा कलेक्टर पुराने जीन संग्रह को निष्पादित करता है, इसलिए शायद ही कभी ऐसा लगता है कि जब तक वे वास्तव में एकत्र नहीं होते हैं और मूल स्मृति मुक्त हो जाती है। यदि सर्वर -XX:+DisableExplicitGC के साथ चलता है जो अंतिम-डुबकी को दबाता है तो पूर्ण जीसी ने कोशिश की जब MaxDirectMemorySize सीमा तक पहुंच गई।
डीबीबी की समय पर रिलीज सुनिश्चित करने के लिए जीसी को अधिक बार चलाने के लिए ट्यूनिंग करना उस मामले को हल कर सकता है।

स्रोत

2016-01-24 18:55:57 the8472

मैंने सत्यापित किया है कि हीप स्पेस काफी अच्छी तरह से प्रबंधित होता है और नियमित रूप से कचरा इकट्ठा होता है। ढेर की जगह कभी भी 3 जीबी से ऊपर नहीं जा रही है लेकिन बफर पूल बढ़ता जा रहा है। जावा VisualVM के माध्यम से एक मैनुअल जीसी ट्रिगर करने पर भी इसका कोई प्रभाव नहीं पड़ता है। – Tushu

मेरे उत्तर में दो अंक हैं। यदि आपने दूसरे को नकार दिया तो शायद यह पहला व्यक्ति है। – the8472

हॉर्नेटक आंतरिक रूप से नेटटी का उपयोग करता है और यदि कोई रिसाव है तो इसे होना चाहिए। यह मेरी समस्या हल नहीं करता है हालांकि मैं इसके बारे में ज्यादा कुछ नहीं कर सकता। – Tushu

डायरेक्ट बाइटबफर कभी भी हॉर्नेटक सर्वर पर क्यों बढ़ रहा है ओओएम की ओर जाता है?

उत्तर

संबंधित मुद्दे