MySQL InnoDB टेबल-स्तरीय ताले के लिए प्रतीक्षा पर लटकता है

Question

मेरे पास एक बड़ा उत्पादन वेब-एप्लिकेशन (ग्लासफ़िश 3.1 + MySQL 5.5) है। सभी टेबल InnoDB हैं। एक बार कई दिनों के आवेदन पूरी तरह से लटका हुआ है।

सबसे लंबे समय तक 'टाइम' के साथ

update user<br> 
set user.hasnewmessages = NAME_CONST('in_flag',_binary'\0' COLLATE 'binary') 
where user.id = NAME_CONST('in_uid',66381) 

insert into exchanges_itempacks 
set packid = NAME_CONST('in_packId',332149), type = NAME_CONST('in_type',1), itemid = NAME_CONST('in_itemId',23710872) 

प्रश्नों हैं: SHOW FULL PROCESSLIST अलग टेबल पर कई सरल डालने या अद्यतन प्रश्नों लेकिन सभी के होने का दर्जा

तालिका स्तर ताला

उदाहरण के लिए प्रतीक्षा कर रहा है पता चलता टेबल-स्तरीय लॉक के लिए भी इंतजार कर रहा है। कृपया यह पता लगाने में सहायता करें कि क्यों MySQL स्तर लॉक प्राप्त करने का प्रयास करता है और इन सभी तालिकाओं को लॉक कर सकता है। इनो डीबी लॉकिंग के बारे में सभी लेखों का कहना है कि यदि आप ऐसा करने के लिए मजबूर नहीं करते हैं तो यह इंजन कोई टेबल लॉकिंग का उपयोग नहीं करता है।

मेरे my.cnf इस है:

innodb_flush_log_at_trx_commit = 0 
innodb_support_xa = 0 
innodb_locks_unsafe_for_binlog = 1 
innodb_autoinc_lock_mode=2 

द्विआधारी लॉग बंद है। मेरे पास "लॉक टेबल" या अन्य स्पष्ट लॉकिंग कमांड नहीं हैं। लेनदेन READ_UNCOMMITED हैं।

SHOW ENGINE INNODB STATUS उत्पादन: http://avatar-studio.ru:8080/ph/imonout.txt

Answer 1

मुझे लगता है कि जब MySQL एक पूर्ण तालिका ताला (अर्थात ऑटो इंक का प्रयोग करके) करता है कुछ स्थितियों रहे हैं। मुझे एक लिंक मिला जो आपकी मदद कर सकता है: http://mysqldatabaseadministration.blogspot.com/2007/06/innodb-table-locks.html

सभी कॉन्स के काम/रोलबैक और बंद होने वाले जावा दृढ़ता कोड की भी समीक्षा करें। (अंततः ब्लॉक में बंद करना।)

MySQL कॉन्फ़िगरेशन में innodb_table_locks=0 सेट करने का प्रयास करें। http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_table_locks

बस कुछ विचार ...

Answer 2

यह सरल लग सकता है, लेकिन आप एक लंबे समय से चल चुनिंदा बयान है कि है संभवतः अद्यतन और आवेषण बाहर ताला लगा नहीं है? कोई प्रश्न नहीं है जो वास्तव में चल रहा है और लॉक नहीं है?

Answer 3

क्या आपने InnoDB के बजाय MyISAM का उपयोग करने पर विचार किया है?

यदि आप किसी भी लेनदेन संबंधी सुविधाओं का उपयोग नहीं कर रहे हैं, तो माईसाम अधिक समझ में आ सकता है। इसका आसान, अनुकूलित करने में आसान है, और चूंकि इसमें परिष्कृत लेनदेन क्षमताएं नहीं हैं, इसलिए आपके my.cnf में कॉन्फ़िगर करना आसान है।

इसके अलावा, आपके ऐप द्वारा बनाए गए डीबी लोड के प्रकार के आधार पर, माईसाम अधिक उपयुक्त हो सकता है। मैं रीड-हेवी अनुप्रयोगों के लिए माईसाम पसंद करता हूं, फिर से, इसे कॉन्फ़िगर करना और समझना आसान है।

अन्य सुझाव:

• यह एक अच्छा विचार के लिए एक रास्ता अपने एसक्यूएल में NAME_CONST का उपयोग नहीं करने के लिए हो सकता है। "This function was added in MySQL 5.0.12. It is for internal use only." जब ओपन सोर्स उत्पाद का प्रलेखन यह कहता है, तो शायद इसकी सलाह पर ध्यान देना एक अच्छा विचार है।

• डिफ़ॉल्ट रूप से, MySQL भंडार सभी InnoDB टेबल 1 भारी फ़ाइल में & स्कीमा डेटा, वहाँ ओएस स्तर है कि विशेष फ़ाइल है कि MySQL कि सभी तालिका पहुंच को रोकता है को propogates पर ताला किसी तरह का हो सकता है। innodb_file_per_table विकल्प का उपयोग करके, आप उस संभावित समस्या को समाप्त कर सकते हैं। यह MySQL को और अधिक स्थान कुशल बनाता है।

Answer 4

इस मामले में

आप एक ही एक दूसरे को स्तंभ के साथ कई अलग अलग डेटाबेस तालिका बनाने के लिए और नहीं तालिका के अनुसार इनसेट अधिक तो 3000 पंक्ति करते हैं, इस मामले में यदि आप तालिका में अधिक डेटा दर्ज करना चाहते हैं आप बनाने के लिए एक और गतिशील तालिका (कोड का उपयोग कर तालिका उत्पन्न करें) और इस तालिका में नया डेटा डालें और उस तालिका से डेटा तक पहुंचें। आपकी स्थिति में यदि अधिक से अधिक तालिका उत्पन्न करना होगा तो आपको नया डेटाबेस बनाना होगा।

मुझे लगता है कि यह युक्ति आपको अपने डेटाबेस को अधिक सावधानीपूर्वक डिजाइन करने और त्रुटि हल करने में मदद करेगी।

Answer 5

क्या आप अपने डेटाबेस द्वारा बैकअप लेने के लिए MSQLDump का उपयोग कर रहे हैं, जबकि यह अभी भी आपके एप्लिकेशन द्वारा एक्सेस किया जा रहा है? यह उस व्यवहार का कारण बन सकता है।

Answer 6

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