मेरा एप्लिकेशन विंडोज सर्वर 2000 पर चल रहा है। स्मृति उपयोग बढ़ता रहता है (145 मीटर से)।मेरा टॉमकैट एप्लिकेशन का मेमोरी उपयोग क्यों बढ़ रहा है?
क्या यह सामान्य है? मैं जावा के लिए नया हूँ। संस्करण टोमकैट 5.5 है।
यह सामान्य नहीं है, और शायद memory leak का संकेत है।
यह देखने के लिए कि आपका आवेदन कहां लीक हो रहा है, आपको memory profiler का उपयोग करने का प्रयास करना चाहिए।
सामान्य रूप से, आपको लूप या दोहराए गए ऑपरेशंस की तलाश करनी चाहिए जहां वस्तुओं को बनाया गया है लेकिन disposed of सही ढंग से नहीं।
आपके पास मेमोरी लीक हो सकती है। मैं सबसे पहले यह निर्धारित करने के लिए कि आपके पास परमजन स्पेस है या सिर्फ मेमोरी मेमोरी है और फिर यह पता लगाने के लिए आगे बढ़ें कि रिसाव कहां है। क्या आप हमें कुछ और जानकारी दे सकते हैं? स्मृति के रूप में आपके आवेदन में क्या चल रहा है?
यदि आप इस तरह की समस्या का निदान करने के लिए अपेक्षाकृत नए हैं, तो मैं jprofiler की अनुशंसा करता हूं। आप एक पूर्ण कार्यात्मक परीक्षण संस्करण डाउनलोड कर सकते हैं और स्मृति में कौन सी ऑब्जेक्ट्स देख सकते हैं यह देखने के लिए मेमोरी स्नैपशॉट ले सकते हैं। आप इस जानकारी का उपयोग यह पता लगाने के लिए कर सकते हैं कि कौन सी वस्तुएं रिसाव का स्रोत हैं।
यह ऐप वर्षों से चल रहा है। हाल ही में, मुझे यह समस्या मिली, क्योंकि वेबसाइट बहुत धीमी गति से चल रही है। मैं सोच रहा हूं कि किसी ने कॉन्फ़िगरेशन बदल दिया है या नहीं। मुझे नहीं लगता कि स्मृति मेमोरी है क्योंकि कोई भी कोड बदलता नहीं है। – user68461
यदि यह केवल बढ़ता है, तो यह एक स्मृति रिसाव है। लेकिन अगर यह आपके अधिकतम ढेर तक बढ़ता है, तो बूंद हो जाता है, तो यह सामान्य कचरा संग्रहण व्यवहार होता है। अधिक जानने के लिए आप कई टूल का उपयोग कर सकते हैं। सबसे सरल बात यह है कि जेकोनसोल (जेडीके का हिस्सा) से जुड़ना और समय के साथ अपने ढेर का निरीक्षण करना है।
आप विभिन्न स्विच और पैरामीटर जैसे -verbose: gc से शुरू करने के साथ कचरा संग्रहण जानकारी भी देख सकते हैं।
आप मेमोरी लीक निदान करने के लिए चाहते हैं, तो उत्कृष्ट उपकरणों की एक संख्या में उपलब्ध कई मुफ्त जो कि ग्रहण, NetBeans, IntelliJ के साथ काम, आदि
सूर्य के डिफ़ॉल्ट व्यवहार को "सर्वर" हॉटस्पॉट है भी शामिल है, SoftReference एस (कैश के लिए उपयोग) को साफ़ करने के बजाय ढेर को बड़ा करने के लिए। डिफॉल्ट उन्हें अधिकतम ढेर आकार के प्रत्येक मेगाबाइट के लिए एक सेकंड के लिए रखना था। तो, अधिकतम आकार में ढेर बढ़ने की उम्मीद है। यदि आप वास्तव में OutOfMemoryException के साथ मेमोरी से बाहर निकलते हैं या प्रदर्शन खराब हो जाता है (अत्यधिक जीसी या छोटे कैश के कारण), तो आपको मेमोरी लीक की तलाश करनी होगी।
इसके अलावा टॉमकैट सर्वर अक्सर एप्लिकेशन को पुनः लोड करने के बाद मेमोरी लीक से पीड़ित होते हैं। उदाहरण के लिए, टोमकैट सभी अनुप्रयोगों के बीच थ्रेड साझा करता है, जो अक्सर मूल्यों को अनुचित रखने के लिए सूर्य के ThreadLocal कार्यान्वयन का कारण बनता है।
टॉमकैट रिसाव नहीं करता है जब तक कि अनुप्रयोग वीएम में हुक को पीछे या स्थापित नहीं करते हैं। –
कुछ ढांचे, मूर्ख क्लाउडलोडर्स के साथ बहुत कुछ होता है ... – wds
मैं अपने कथन को थोड़ा सा योग्यता संपादित करूंगा। उदाहरण के लिए, सूर्य थ्रेडलोकल कार्यान्वयन आम तौर पर लीक की ओर जाता है क्योंकि टॉमकैट धागे को त्याग नहीं देता है। मुझे नहीं पता कि पागलबोब की सद्भावना कार्यान्वयन क्या करती है। –
आईएमओ टॉम हौटिन का जवाब सबसे अच्छा है। यह तब तक बढ़ता है जब तक यह अधिकतम हिट नहीं करता है, फिर जीसी चलाता है। एक सर्वर वातावरण में यह समझ में आता है: आप सबसे अच्छा प्रदर्शन चाहते हैं, सर्वोत्तम स्मृति उपयोग नहीं। आप स्मृति की कुल मात्रा की पूर्व-गणना करते हैं, फिर प्रत्येक ऐप को अधिकतम दें और फिर सब कुछ फिट बैठता है और इसका सर्वश्रेष्ठ प्रदर्शन होता है। इस व्यवहार को tweaked किया जा सकता है।
यह देखने के लिए कि वास्तव में कितना उपयोग किया जा रहा है, jconsole का उपयोग करें। जीसी करें और देखें कि यह क्या नीचे जाता है। उस संख्या को समय के साथ नहीं बढ़ना चाहिए या आपके पास स्मृति रिसाव है। मेमोरी रिसाव डीबग करने के लिए visualvm का प्रयोग करें।
प्रत्येक बार जब आप कोई एप्लिकेशन पुनः लोड करते हैं तो यह अतिरिक्त पर्म जेन मेमोरी का उपयोग करता है जिसे पुनः दावा नहीं किया जा सकता है (सूर्य जेवीएम में, जेआरॉकिट जैसे अन्य लोगों को यह समस्या नहीं है)। उत्पादन में आपको ऐप को पुनः लोड नहीं करना चाहिए। हर बार टॉमकैट को पुनरारंभ करें।यदि आप वास्तव में इसे जारी रखना चाहते हैं तो आप अधिकतम मेमोरी बढ़ा सकते हैं और फ्लैग के साथ अधिकतम पर्म जेन मेमोरी भी बढ़ा सकते हैं-XX: MaxPermSize = 256m
MaxPermSize बिल्कुल मेरी समस्या साबित हुई। हम विकास के दौरान आवेदन के अद्यतन संस्करणों को लगातार तैनात कर रहे थे। –
प्रोग्राम के साथ Lambda Probe आप आसानी से टोमकैट में मेमोरी उपयोग को देख सकते हैं । (विकल्प सिस्टम जानकारी - मेमोरी उपयोग)। आप एक ग्राफ में देख सकते हैं उत्तरजीवी अंतरिक्ष पेर्म जनरल पर्याप्त जनरल ईडन अंतरिक्ष कोड कैश
बस को बिल्ला इस warfile तैनाती और स्टार्टअप विकल्प जावा स्टार्टअप के लिए -Dcom.sun.management.jmxremote निर्धारित किया है।
अब आप देख सकते हैं कि स्मृति का कौन सा हिस्सा बढ़ता है।
सर्वर जेवीएम के लिए यह सामान्य है। –
@ एसजेबोथा: निरंतर वृद्धि निश्चित रूप से/सामान्य/सामान्य नहीं है। – GEOCHET
मुझे लगता है कि यह निर्भर करता है कि यह बिना किसी सीमा के निरंतर विकास है या नहीं –