उपयोगकर्ता शिकायत करते हैं कि mysqldump के चालू होने पर सिस्टम धीमा चलता है

Question

MYSQL डेटाबेस (ibdata1) का आकार 73 GB है और इसे INNODB तालिकाओं के लिए Windows 2008 O / S पर समर्पित डेटाबेस सर्वर के रूप में चलाने के लिए कॉन्फ़िगर किया गया है। हम mysqldump mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --dableable-keys --add-drop-table --comcom-insert - का उपयोग करके बैकअप चला रहे हैं set-charset - संपीडन --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb035.sql

बैकअप फ़ाइल Proddb0635.sql को डेटाबेस सर्वर से एक अलग सर्वर पर संग्रहीत किया जाता है। रैम 12 जीबी है। INNODB बफर पूल का आकार 6 जीबी है। अतिरिक्त mem.pool 32 एमबी है। क्वेरी कैश आकार 2 जीबी नेट बफर लंबाई 16 एम मैक्स है। पैकेट का आकार 1 जीबी।

mysql संस्करण 5.0.67 है।

जब बैकअप नहीं चल रहा है तो उपयोगकर्ता प्रदर्शन से खुश हैं।

जब बैकअप INNODB चल रहा हो तो बफर पूल हिट दर 100% के करीब होती है। कोई लंबित पठन या लंबित लेखन नहीं है। निर्दोष प्रतीक्षा मुफ्त है। सीपीयू का उपयोग अधिकतम न्यूनतम 9% से अधिकतम 15% तक नहीं है। क्वेरी कैश हिट दर mysqlbackup के साथ या उसके बिना चलने के बारे में 40% कम है। वर्तमान में विंडोज टास्क मैनेजर प्रदर्शित कर रहा है कि 10GB RAM का उपयोग किया जा रहा है। क्या मुझे केवल 2GB RAM उपलब्ध के साथ क्वेरी कैश को बढ़ाना चाहिए? mysqlld-nt में 9.2 जीबी रैम और mysqldump 5 एमबी रैम ले रहा है। अलोस ने नोट किया कि डंप फ़ाइल का आकार --compress विकल्प की उपस्थिति या अनुपस्थिति में समान है।

क्या मैं iNNODB बफर पूल का आकार घटा सकता हूँ?

धन्यवाद

Answer 1

विंडोज में एक ज्ञात समस्या है, कि जब आप एक बड़ी फ़ाइल को किसी अन्य सर्वर पर धकेलते हैं, तो उपयोगकर्ता की प्रक्रियाओं के बजाय सिस्टम मेमोरी को आवंटित की जाने वाली सभी मेमोरी समाप्त हो जाती है। आप कार्य प्रबंधक की भौतिक मेमोरी (MB) अनुभाग में देख सकते हैं कि सिस्टम कैश में कितनी मेमोरी आवंटित की गई है।

यह एक स्थानीय डिस्क का बैकअप लेकर हल किया जा सकता है, फिर रिमोट मशीन को उस फाइल को खींच सकता है।

Comments

धन्यवाद, मन्दिनी। हम अपने डिस्क SAN.Does पर संग्रहीत है कि एक भी फर्क पड़ता है?

— dbachacha

यह एक मुद्दा है कि भंडारण कैसे प्रस्तुत किया जाता है। भंडारण के रूप में होने के नाते SAN भंडारण है किसी अन्य मशीन के लिए नेटवर्क पर फ़ाइलों को कॉपी करने की कोई आवश्यकता नहीं है। MySQL सर्वर पर एक नया LUN पेश करें फिर उस मशीन का बैकअप लें। यदि आपको टेप बैकअप के लिए किसी अन्य मशीन में फ़ाइलों को प्राप्त करने की आवश्यकता है, तो SAN का उपयोग करें। LUN को स्नैप करें, स्नैपशॉट को बैकअप सर्वर में प्रस्तुत करें, फ़ाइलों का बैकअप लें, फिर स्नैपशॉट को हटा दें। अगले दिन दोहराएं। यह शायद सभी लिपिबद्ध हो सकता है।

— मर्डनी

आपका पहला सुझाव: सिस्टम कैश में # परिवर्तन नहीं हुआ। LUN के बारे में, मैं इसे अपने उन सहयोगियों को बताऊंगा जो सिस्टम एंड नेटवर्क टीम में काम करते हैं।

— dbachacha

मैंने अन्य सर्वर पर चलने के लिए बैकअप स्क्रिप्ट को स्थानांतरित किया और इसमें काफी सुधार हुआ है। इसके अलावा हमने पाया कि एप्लिकेशन कोड एक sinngle कनेक्शन का पुन: उपयोग नहीं कर रहा है, लेकिन डेटाबेस सर्वर के लिए एक अनुरोध में वर्गीकृत कई कार्यों में खुला / बंद है। इसके अलावा, मैंने पाया कि एक एनआईसी कार्ड बैकअप डेटा और ऑनलाइन लेनदेन डेटा द्वारा साझा किया जाता है। इसलिए, हम केवल बैकअप के लिए एक समर्पित NIC की योजना बना रहे हैं। बहुत बहुत धन्यवाद।

— dbachacha

Answer 2

यहाँ कुछ विचार हैं जो मुझे अपने हालात को देखते हुए mysqldump के प्रदर्शन को बेहतर बनाने के बारे में हैं। यहाँ आपकी आज्ञा है:

mysqldump --skip-opt --quick --single-transaction -create-options --extended-insert -disable-keys --add-drop-table - अपूर्ण-इन्सर्ट --set-charset --compress - -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

पहली बात जो मैंने नोटिस की है कि आप आउटपुट को एक फाइल सिस्टम पर रीडायरेक्ट कर रहे हैं। यह 'devNas' कहता है इसलिए मैं यह मानने जा रहा हूं कि यह नेटवर्क अटैच्ड स्टोरेज है । मैं बैकअप के लिए एनएएस का प्रशंसक हूं, लेकिन इसे उत्पादन ट्रैफिक से अलग भौतिक एनआईसी से जुड़ा होना चाहिए । आप बैंडविड्थ को संतृप्त नहीं कर सकते हैं, लेकिन वे अभी भी प्रतिस्पर्धा करते हैं। यह --quick झंडे की वजह से एक समस्या के रूप में अधिक होने जा रहा है, क्योंकि यह स्मृति में रखने के बजाय हर पंक्ति को फ्लश करता है।

अगली चीज़ जो मैं देख रहा हूँ वह यह है कि आपने --compress। ऐसा लगता है कि आप स्थानीय रूप से mysql चला रहे हैं क्योंकि आपने -h स्विच का उपयोग नहीं किया है। यह इस संदर्भ में अनावश्यक सीपीयू का उपयोग कर सकता है। क्या - आवश्यक है? यह केवल mysqldump क्लाइंट और mysql सर्वर के बीच डेटा को संपीड़ित करता है, न कि फ़ाइल सामग्री को।

अगला, मैं देख रहा हूँ कि आप -सिंगल-लेनदेन ध्वज का उपयोग कर रहे हैं। यह अतिरिक्त सीपीयू का कारण बनने वाला है क्योंकि यह हर चयन पर mysqldump के हिस्से के रूप में परीक्षण कर रहा है।

इसका प्रदर्शन से कोई लेना-देना नहीं है, लेकिन आप उपयोग कर रहे हैं - महत्वपूर्ण-कुंजियाँ जो केवल MyISAM ( मैनुअल ) पर काम करती हैं ।

आप एक ऑफ़लाइन होस्ट से दूरस्थ रूप से mysqldump चलाने और NAS से डंप फ़ाइल को स्थानांतरित करने के साथ प्रयोग करना चाह सकते हैं, ताकि इस ऑपरेशन को अधिक से अधिक बैंड से बाहर ले जाया जा सके।

Comments

हां, मैंने नेटवर्क और सिस्टम प्रशासक से जांच की थी। यह नेटवर्क अटैच्ड स्टोरेज है। मैं mysqldump को किसी भिन्न सर्वर पर ले जाने का प्रयास कर सकता हूं। इसके अलावा, अब यह मेरे लिए समझ में आता है - .com के उपयोग के बारे में। मैनुअल ने कहा कि - कॉमप्रेस क्लाइंट और सर्वर के साथ काम करता है, फिर भी मैंने इसे यह देखने के लिए रखा है कि क्या इससे कोई फर्क पड़ता है। क्लाइंट के बीच किस तरह का डेटा प्रवाहित होता है जो mysqldump और mysql डेटाबेस सर्वर को चलाता है। डेटा mysql डेटाबेस सर्वर और devNas के बीच बह रहा है। MySQl प्रलेखन और पुस्तक डेटाबेस डिजाइन और ट्यूनिंग INNODB तालिकाओं के लिए एकल-लेन-देन के उपयोग को पसंद करते हैं।

— dbachacha

मैंने अन्य सर्वर पर चलने के लिए बैकअप स्क्रिप्ट को स्थानांतरित किया और इसमें काफी सुधार हुआ है। इसके अलावा हमने पाया कि एप्लिकेशन कोड एक sinngle कनेक्शन का पुन: उपयोग नहीं कर रहा है, लेकिन डेटाबेस सर्वर के लिए एक अनुरोध में वर्गीकृत कई कार्यों में खुला / बंद है। इसके अलावा, मैंने पाया कि एक एनआईसी कार्ड बैकअप डेटा और ऑनलाइन लेनदेन डेटा द्वारा साझा किया जाता है। इसलिए, हम केवल बैकअप के लिए एक समर्पित NIC की योजना बना रहे हैं। बहुत बहुत धन्यवाद।

— dbachacha

मुझे खुशी है कि यह मदद कर रहा है। शुभकामनाएँ।

— 22

यहां मुझे निम्नलिखित परिदृश्य को समझने में सहायता की आवश्यकता है: mysql डेटाबेस सर्वर ए पर है। mysqldump सर्वर B पर चलता है जो सर्वर C पर डेटा को डंप करता है। हमारे पास सर्वर A से सर्वर C तक एक समर्पित NIC है। क्या यह सही है? मुझे यकीन नहीं था कि पिछली रात mysqldump सर्वर ए पर चल रहा था। मैं सीपीयू विवाद को कम करने के लिए इसे एक अलग सर्वर पर चलाना चाहूंगा।

— dbachacha

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

— 20

Answer 3

OBSERVATION # 1

यहाँ कुछ ध्यान में रखना है जब InnoDB के खिलाफ mysqldump प्रदर्शन किया जाता है।

InnoDB बफर पूल में जो भी गंदे पृष्ठ मौजूद हैं, उन्हें पहले डिस्क में फ्लश किया जाना चाहिए। एक mysqldump एक InnoDB तालिका की निस्तब्धता को ट्रिगर करेगा जिसमें अभी भी इसमें गंदे पृष्ठ हैं।

एक सर्वर विकल्प है, जिसे innodb_max_dirty_pages_pct कहा जाता है । डिफ़ॉल्ट मान 75 MySQL 5.5 है और 5.5 से पहले MySQL के संस्करणों में 90 है। उत्पादन परिवेश में यह संख्या डिफ़ॉल्ट मान पर छोड़ना ठीक है।

यह देखने के लिए कि क्या आपके पास InnoDB बफर पूल में बहुत सारे गंदे पृष्ठ हैं, इसे चलाएं:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

BTW एक पृष्ठ 16 के रूप में इस शो से है:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

जब यह InnoDB और mysqldump आता है, तो आप इस संख्या को दो परिस्थितियों में कम कर सकते हैं।

CIRCUMSTANCE 1: इसे स्थायी रूप से 0 पर सेट करें

बस इसे my.ini में जोड़ें:

[mysqld]
innodb_max_dirty_pages_pct=0

यह InnoDB बफर पूल को दुबला और क्षुद्र बनाए रखेगा। डंप की जा रही InnoDB तालिका को फ्लश करने का चरण त्वरित होगा क्योंकि संभव है कि कुछ गंदे पृष्ठ संभवत: (शायद 0) को mysqldump द्वारा संचालित करने से पहले फ्लश किया जाए।

एकमात्र दोष यह है कि यदि आप अत्यधिक ट्रैफ़िक वाले डीबी से mysqldump हैं, तो गंदे पृष्ठ को अधिक बार फ़्लश करने के कारण I / O लिखने में थोड़ी वृद्धि हो सकती है। आप यह निर्धारित कर सकते हैं कि क्या ऐसा करने से यह पुनः आरंभ नहीं होगा mysql:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

12-24 घंटों के लिए सेटिंग छोड़ दें, यदि लेखन प्रदर्शन स्वीकार्य है, तो आप जाने के लिए अच्छे हैं। यदि नहीं, तो इसे वापस सेट करें:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2: mysqldump से लगभग 1 घंटा पहले इसे सेट करें

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Mysqldump चलाएं

SET GLOBAL innodb_max_dirty_pages_pct = 90;

OBSERVATION # 2

आपके पास - mysqldump विकल्प के रूप में अपूर्ण सम्मिलित करें । यह VALUES क्लॉज़ से पहले प्रत्येक INSERT प्रतिमा पर कॉलम नाम एम्बेड करेगा। पंक्तियों के प्रत्येक बैच पर - अनुकूलित-सम्मिलित, के साथ भी कॉलम के नाम mysqldump में भेजे जा रहे हैं। आप mysqldump को भेजे गए बाइट्स की मात्रा को कम कर सकते हैं - अपूर्ण-सम्मिलित करके।

सिफ़ारिश करना

यदि आपके पास एक और विंडोज सर्वर है जिसे स्लेव के रूप में सेटअप किया जा सकता है, तो उत्पादन मशीन के बजाय उस गुलाम से mysqldumps करें।

Comments

धन्यवाद। मैं यह बताना भूल गया कि उपयोगकर्ता शिकायत करते हैं कि "सेव" पढ़ने के बजाय समय लेता है। मैं आपके अवलोकन # 2 को तुरंत लागू करूंगा। मैं निश्चित रूप से दास होने की आपकी सिफारिश और फिर गुलाम से mysqldump लेना पसंद करता हूं।

— dbachacha

innodb_buffer_pool_dirty_pages बैकअप शुरू होने से ठीक पहले बहुत अधिक नहीं था। यह लगभग 9 से अधिकतम है। 196. मास्टर-स्लेव एक अच्छी सिफारिश भी है।

— dbachacha

मैंने अन्य सर्वर पर चलने के लिए बैकअप स्क्रिप्ट को स्थानांतरित किया और इसमें काफी सुधार हुआ है। इसके अलावा हमने पाया कि एप्लिकेशन कोड एक sinngle कनेक्शन का पुन: उपयोग नहीं कर रहा है, लेकिन डेटाबेस सर्वर के लिए एक अनुरोध में वर्गीकृत कई कार्यों में खुला / बंद है। इसके अलावा, मैंने पाया कि एक एनआईसी कार्ड बैकअप डेटा और ऑनलाइन लेनदेन डेटा द्वारा साझा किया जाता है। इसलिए, हम केवल बैकअप के लिए एक समर्पित NIC की योजना बना रहे हैं। बहुत बहुत धन्यवाद। यदि इस काम में से कोई भी नहीं है, तो मुझे यकीन है कि मास्टर दास भी अच्छा होगा।

— dbachacha