2010-10-31 9 views
26

पृष्ठभूमि नहीं होती है: मैं वर्तमान में एक इंट्रानेट साइट है कि MochaUI पुस्तकालय (virtual desktop demo से काम कर) का उपयोग करता है पर काम कर रहा हूँ। मैं Mootools 1.2.4 और MochaUI 0.9.7 का उपयोग कर रहा हूँ। मेरे "वर्चुअल डेस्कटॉप" कार्यान्वयन में खोले गए विंडो आईफ्रेम के माध्यम से अपनी सामग्री लोड करते हैं। कुछ लोड किए गए पृष्ठ सीएसएस और स्क्रिप्टिंग के मामले में बहुत भारी हैं, इसलिए यह महत्वपूर्ण है कि उपयोगकर्ता ऑब्जेक्ट को खिड़की बंद कर लेते समय पर्याप्त रूप से कचरा इकट्ठा किया जाता है। यह पुस्तकालय द्वारा स्पष्ट रूप से देखभाल की जाती है (फ़ायरफ़ॉक्स का उपयोग करते समय यह उचित काम करता है)।Chrome की स्मृति को मुक्त करने में विफल रहता है, कचरा संग्रहण के रूप में उम्मीद (Mootools/MochaUI पुस्तकालय)

अद्यतन मूल रूप से पोस्ट किया गया प्रश्न बाद के संपादन/अपडेट से काफी लंबा हो गया था। शीर्षक अब सटीक नहीं था, इसलिए मैंने इसे भी बदल दिया। इसके अलावा, आंशिक समाधान के लिए नीचे मेरा जवाब देखें।

यहाँ आवश्यक बिंदु हैं:

  1. क्रोम इसलिए तरह goofs:

    • क्रोम जब वे बंद कर दिया रहे MochaUI खिड़की वस्तुओं के लिए आबंटित स्मृति को मुक्त करने के लिए विफल रहता है। इसके बजाए, जब तक पृष्ठ रीफ्रेश नहीं हो जाता है, तब तक स्मृति उपयोग पर कम बाध्य सेट करने के बाद, क्रोम का मेमोरी उपयोग फ्रीज (शाब्दिक रूप से) स्तर पर पहुंच जाता है।
    • प्रक्रिया द्वारा उपयोग की जाने वाली मेमोरी बाद की खिड़की खोलने/बंद करने के साथ बढ़ती जा रही है। आखिरकार, कुछ प्रकार की टोपी तक पहुंच जाती है, और स्मृति उपयोग नाटकीय रूप से कूदने के बजाए चढ़ाई करना शुरू कर देता है।
    • यह समस्या सबसे स्पष्ट है जब प्रश्न में खिड़कियां काफी भारी (स्मृति-वार) iframe सामग्री लोड कर रही हैं। जिस विंडो का मैं सभी परीक्षण प्रयोजनों के लिए उपयोग कर रहा हूं वह अपने आईफ्रेम में 580 केबी पेज (बिना छेड़छाड़) लोड करता है।
  2. अजीब पर्याप्त, उम्मीद कचरा संग्रहण जगह ले करता है, जब

    • ब्राउज़र बाद में कम से कम है
    • अन्य टैब एक ही ब्राउज़र विंडो में खोला जाता है
    • एक मेमोरी टाइमलाइन डेवलपर टूल्स में दर्ज की जा रही है। (कॉमेडी विकल्प)
    • क्या यह व्यवहार # 1 को हल करने के लिए कोई संभावित दृष्टिकोण सुझाता है?
+5

बहुत दिलचस्प सवाल और अच्छा विवरण। मुझे बिल्कुल यकीन नहीं है कि अपराधी क्या है, हालांकि मैं आपको चेतावनी दूंगा कि एक मौका है कि कोई समाधान नहीं होगा। या यदि कोई है, तो आसान नहीं है। Google प्रोग्रामिंग के लिए एक बहुत आलसी दृष्टिकोण लेता है। हालांकि क्रोम सबसे तेज़ लोड होता है और हर प्रमुख ब्राउजर की कम से कम मेमोरी का उपयोग करता है, लेकिन यह उन बग्स के साथ झुका हुआ है जिन्हें मैं फ़ायरफ़ॉक्स या ओपेरा में सपना नहीं देखूंगा। एंड्रॉइड बनाम आईओएस के साथ ही। – stevendesu

+0

मैंने Google के क्रोम वेबमास्टर सहायता फ़ोरम पर इस प्रश्न का एक बहुत विस्तृत/लंबा संस्करण पोस्ट किया और मुझे कोई जवाब नहीं मिला, इसलिए इस बार मैंने इसे और अधिक बिंदु बनाने का फैसला किया! मैं मानता हूं कि यह एक बग की तरह लगता है (या यह बताता है कि क्रोम कैसे निर्धारित करता है कि कौन सी ऑब्जेक्ट कचरा एकत्र की जाती है)। ऐसा लगता है कि कचरा संग्रह का एक और अधिक कठोर स्तर होता है जो तब होता है जब क्रोम कम हो जाता है, और मेरी खिड़की की वस्तुएं क्रोम के मानकों से पूरी तरह से कचरा नहीं होती हैं। टिप्पणी के लिए धन्यवाद! – freenatec

+4

@steven_desu: न केवल Google प्रोग्रामिंग के लिए आलसी दृष्टिकोण लेता है, यह किसी भी प्रकार की शिकायतों या समस्याओं के प्रति उत्साहित रूप से उदासीनता से लगता है। –

उत्तर

6

मुझे यकीन है कि अगर यह विंडोज में परीक्षण किया गया था नहीं कर रहा हूँ, लेकिन अगर इतना है कि यह पृष्ठ फ़ाइल के लिए सभी डेटा ले जाता है जब भी आप खिड़कियों में एक खिड़की को कम से कम यह ध्यान रखें। खिड़की को फिर से खोलते समय यह स्मृति ब्लॉक को तब तक नहीं ले जाएगा जब तक कि प्रोग्राम उन्हें एक्सेस करने का प्रयास नहीं करता है, और इस प्रकार कोई कचरा पेजफाइल में रहता है लेकिन वास्तव में एकत्र नहीं किया जाता है।

यदि आप इसे स्वचालित करना चाहते हैं, तो यह न केवल प्रोग्राम को धीमा कर देगा बल्कि यह किसी भी स्मृति समस्याओं के साथ भी मदद नहीं करेगा।

https://micksmix.wordpress.com/2010/01/08/why-does-task-manager-show-an-applications-memory-usage-drop-after-minimizing-it-to-the-the-taskbar/

+0

इंट्रानेट पर मौजूद सभी मशीनें जो साइट का उपयोग कर रही हैं, विंडोज एक्सपी चलाते हैं, मुझे विश्वास है। मैंने पेजफाइल के साथ उस मुद्दे को नहीं माना था, हालांकि क्रोम को अपने न्यूनतम राज्य (किसी भी तरह से, जो भी प्रभाव पड़ता है) को स्वचालित/ट्रिक करना एक लंबी शॉट अवधारणा थी ...आदर्श रूप से, मुझे अपना जावास्क्रिप्ट कोड बदलने का कोई तरीका मिलेगा ताकि क्रोम वस्तुओं को सामान्य रूप से एकत्रित कचरा होने के लिए पहचान सके। – freenatec

+1

क्या आपने चर के साथ वेरिएबल/ऑब्जेक्ट्स को शून्य करने की कोशिश की है? – William

+0

जहां तक ​​मैं लाइब्रेरी के कार्यों को समझता हूं जो विंडो-क्लोजिंग व्यवहार को संभालते हैं, ऐसा लगता है कि खिड़की बंद होने पर सभी प्रासंगिक ऑब्जेक्ट्स को शून्य में सेट किया जाता है। विंडोज़ (आईफ्रेम में) में लोड की गई सामग्री अधिक मेरा कोड है, और यह कुछ हद तक गन्दा है और शायद लीक में योगदान देता है ... हालांकि, मुझे ध्यान रखना चाहिए कि विंडोज़ बंद होने पर फ़ायरफ़ॉक्स स्पष्ट रूप से स्मृति को मुक्त करता है (3-5 की धुन तक) लगभग 5 सेकंड में एमबी)। दूसरी ओर, प्रासंगिक क्रोम प्रक्रिया का मेमोरी उपयोग विंडोज़ बंद होने पर स्थैतिक रहता है, और एकमात्र चीज जो इसे कम करती है, ब्राउज़र को कम कर रही है। – freenatec

3

अद्यतन
MochaUI closingJobs समारोह में निम्न परिवर्तन क्या मैं पहले यहां पोस्ट पर एक बड़ा सुधार कर रहे हैं में थोड़ा और अधिक जानकारी के लिए इस यूआरएल को देखते हैं। मुख्य परिवर्तन अब iframe के ऑननलोड ईवेंट को मैन्युअल रूप से src property को बदलकर बुलाया जाता है, जब windowEl.destroy विधि DOM से iframe को हटा देती है। (here से विचार मिला)।

यदि आप इस कोड का उपयोग करना चाहते हैं, तो बस मौजूदा क्लोजिंग जॉब्स फ़ंक्शन को हटाएं और इस कोड को अपनी जगह पेस्ट करें। यह 0.9.7 और 0.9.8 दोनों MochaUI के साथ काम करना चाहिए, और या तो Mootools 1.2.4 या 1.3।


closingJobs: function(windowEl){   
    windowEl.setStyle('visibility', 'hidden'); 
    var instances = MUI.Windows.instances; 
    var instance_id = windowEl.id 
    var cleanup_delay = 50; 

    /* 
    Reset canvases with width/height = 0. 
    This pretty reliably frees a few hundred Kb of 
    memory in chrome. 
    */   
    instances[instance_id].canvasControlsEl.width = 0; 
    instances[instance_id].canvasControlsEl.height = 0; 
    instances[instance_id].canvasEl.width = 0; 
    instances[instance_id].canvasEl.height = 0;   

    if(instances[instance_id].options.loadMethod == 'iframe') 
    { 
/* 
The following line determines how long to delay the execution of 
the windowEl.destroy function. The line below gives 10 milliseconds 
per DOM element in the iframe's document. 
You could probably do just as well with a hard-coded value. 
*/   
     cleanup_delay = instances[instance_id].iframeEl.contentDocument.getElementsByTagName("*").length * 10;    

/* 
Set the Browser property in the iframe's window to Internet Explorer. 
This causes Mootools to run its purge function, which iterates over 
all the iframe document's DOM elements, removing events/attributes etc. 
Assuming you have mootools included in the iframe content.  
*/ 
     if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools) 
     {   
      if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools.version.contains("1.3"))     
       instances[instance_id].iframeEl.contentDocument.defaultView.Browser.ie = true; 
      else   
       instances[instance_id].iframeEl.contentDocument.defaultView.Browser.Engine.trident = true; 
     }     

     instances[instance_id].iframeEl.src = "javascript:false"; 
    }  

    MUI.cleanWindow.delay(cleanup_delay, null, windowEl);  
}, 

cleanWindow: function(windowEl) 
{        
    var instances = MUI.Windows.instances; 
    var instance_id = windowEl.id 
    if (Browser.ie){ 
     windowEl.dispose(); 
    } 
    else { 
     windowEl.destroy(); 
    }  
    instances[instance_id].fireEvent('onCloseComplete'); 

/* 
Changed - Only execute getWindowWithHighestZindex() and focusWindow() 
functions if there will actually be open windows after the 
current one closes. 
*/ 
    if (instances[instance_id].options.type != 'notification' && instances.__count__ > 1){ 
     var newFocus = MUI.getWindowWithHighestZindex(); 
     MUI.focusWindow(newFocus); 
    }  
    if (this.loadingWorkspace) this.windowUnload(); 
    if (MUI.Dock && $(MUI.options.dock) && instances[instance_id].options.type == 'window'){ 
     var currentButton = $(instances[instance_id].options.id + '_dockTab'); 
     if (currentButton != null){ 
      MUI.Dock.dockSortables.removeItems(currentButton).destroy(); 
      currentButton = null; //Is this necessary? 
     }   
     MUI.Desktop.setDesktopSize(); 
    } 

    //Changed - moved this to the end of the function. 
    delete instances[instance_id]; 
} 
+1

में थोड़ी अधिक है, mootools का कौन सा संस्करण उपयोग किया जा रहा है। mootools 1.3 कुछ हद तक सरलीकृत तत्व है .prototype.destroy तो ऐसा लगता है: http://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L677 पुराने बनाम http://github.com/mootools/mootools-core/blob/1.2x/Source/Element/Element.js#L579 जो उपरोक्त अजीब 'साफ() 'फ़ंक्शन पर जाता है। –

+0

1.2.4। मैं वही सामान 1.3 के साथ देख रहा हूं (0.9.7 मोचाउ बिल्ड के साथ)। मेरे परीक्षण में मैंने संगतता परत का उपयोग किया, हालांकि मुझे यकीन नहीं है कि यह एक कारक है। फिक्स I ऊपर सुझाए गए सुझावों का क्रोम के मेमोरी व्यवहार पर 1.2.4 के साथ 1.3 के समान प्रभाव पड़ता है। जो कुछ भी बदल सकता है, यद्यपि: आपकी पहली टिप्पणी के आधार पर मैंने मोचा यूई के गिथब में कुछ और जगह बनाई - मैं पूरी तरह से अनजान था कि 0.9.8 शाखा में हाल ही की गतिविधि थी! मेरे ध्यान में लाने के लिए धन्यवाद। – freenatec

+0

कोई चिंता नहीं! पुराने मोचौई ... के साथ काम करना मुश्किल रहा है। मैं अभी भी अपनी खुद की शाखा का समर्थन कर रहा हूं क्योंकि बड़ी संख्या में फिक्स को लागू करना है और अब 0.9.8 या 1.0 का उपयोग करना असंभव होगा! ओह अच्छा! –