2013-01-04 16 views
9

मेरे पास एक रेल 2.3 ऐप है जो बहुत से MySQL कनेक्शन खोल रहा है। एक दिन से भी कम समय के बाद (~ 400 आरपीएम पर) एक प्रक्रिया में हमारे द्वारा उपयोग किए जाने वाले दो mysql सर्वरों के लिए 83 स्थापित कनेक्शन थे।रेल्स MySQL बहुत सारे कनेक्शन

हम mysql2 मणि ​​(0.2.18) का उपयोग कर रहे हैं, और mysql क्लाइंट है: mysql Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (i686) using readline 5.1

मैं इन लीक कहां हो रहा हूं समस्या निवारण कैसे कर सकता हूं? हमारे परीक्षण में, हम कभी भी उत्पादन में रिसाव नहीं कर पाएंगे, केवल उत्पादन में ही।

MySQL में, हम खुले कनेक्शन देखने के लिए show processlist; चला सकते हैं। ऐप सर्वर पर, हम sudo netstat -ntp | grep 3306 | grep ESTABLISHED | awk '{print $7}' | sort | uniq -c | sort -n के साथ प्रति पिन कनेक्शन की संख्या गिन सकते हैं।

+0

83 के साथ क्या गलत है? जिस तरह से आप इसे पैनिंग कर रहे हैं, वह 8300 है। – tadman

+1

84 रेल ऐप हैं, और हमारे mysql सर्वर में अधिकतम 2000 कनेक्शन हैं। तो यदि सभी रेल ऐप्स में 23 से अधिक कनेक्शन हैं, तो हम बाहर निकलते हैं। हमारा समाधान वर्तमान में हर 5 घंटे में हमारे रेल ऐप उदाहरणों को पुनरारंभ करना है। –

+0

हमने इसे "wait_timeout: 300" जोड़कर हमारे डेटाबेस.आईएमएल कॉन्फ़िगरेशन में हल करके हल किया। यह 5 मिनट के बाद अप्रयुक्त mysql कनेक्शन बंद कर देता है। –

उत्तर

6

मैंने इसे "wait_timeout: 300" को हमारे डेटाबेस.आईएमएल में जोड़कर तय किया। हालांकि यह अप्रयुक्त mysql कनेक्शन बंद करता है, यह यह नहीं बताता कि वे कहां से आए थे।

+0

क्या आप डेटाबेस क्वेरीज के साथ किसी थ्रेडिंग का उपयोग कर रहे हैं? जैसे 'Thread.new {#ActiveRecord क्वेरी}'। यह एक समस्या है जो मैं भी कर रहा हूं, लेकिन प्रतीक्षा_टाउटआउट इतनी कम सेटिंग वास्तव में मेरे लिए एक समाधान नहीं है। – Kache

1

एक यादृच्छिक विचार: mysql2 मणि ​​कांटा, MySQL 2 :: क्लाइंट # प्रारंभ में कुछ डिबगिंग जोड़ें, और अपना ऐप सामान्य के रूप में चलाएं। क्लाइंट प्रारंभ होने पर आप ढेर की कुछ पंक्तियां मुद्रित कर सकते हैं, और ट्रैक कर सकते हैं कि रिसाव कौन कर रहा है।


0

इसके लायक होने के लिए, हमारे स्टेजिंग सर्वर पर भी यही समस्या हो रही थी - यह mysql से कनेक्शन की अधिकतम_कनेक्शन संख्या तक पहुंच रहा था। मैंने पाया कि स्टार्टअप स्क्रिप्ट का उपयोग करने के बजाए सीधे कमांड लाइन से सेवा चलाने से किसी भी तरह समस्या आई है।

मुझे अभी तक पता नहीं चला है कि यह स्टार्ट अप स्क्रिप्ट में क्या था जो समस्या पैदा कर रहा था।

0

मुझे मिल रहा था बहुत सारे कनेक्शन त्रुटि, क्योंकि मैंने कई मॉडलों में अन्य डेटाबेस तक पहुंचने के लिए establ_connection का उपयोग किया था।

class AppsWebserver < ActiveRecord::Base 
    self.abstract_class = true 
    establish_connection :apps_webserver 
end 

class InternetReference < AppsWebserver 
end 

class InternetEmployee < AppsWebserver 
end 

अब कनेक्शन रेल द्वारा सही ढंग से नियंत्रित किया जाता है:

मैं इन मॉडलों

class InternetReference < ActiveRecord::Base 
    establish_connection :db_webserver 
end 

class InternetEmployee < ActiveRecord::Base 
    establish_connection :db_webserver 
end 

समाधान एक सार मॉडल में कनेक्शन खोलने और इस मॉडल से प्राप्त करना है था।

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