mysql डंप आयात मेरे डेवलपर की मशीन पर अविश्वसनीय रूप से धीमा है

Question

मेरे पास एक SQL डंप है, यह बहुत बड़ा (411 एमबी) है और सर्वर ए पर आयात करने में 10 मिनट लगते हैं, मेरे वर्कस्टेशन बी पर समान आयात को आयात करने के लिए 8 घंटे का एक अनुमान (पाइपव्यूअर) है (यह 40 मिनट में 31 एमबी आयात करता है ) तो यह कारक 53 धीमा है।

चश्मा:

Server A:
   MySQL Version: 5.5.30-1.1 (Debian)
   2 GB RAM
   1 core QEMU Virtual CPU version 1.0 - cpu MHz: 3400.020

Workstation B: 
   MySQL Version: 5.5.41-MariaDB-1ubuntu0.14.04.1
   14 GB RAM
   4 cores Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz - cpu MHz: 1600.000

Mysql / maria config स्टॉक कॉन्फिगर है।

मैंने कल अपने वर्कस्टेशन पर मारियाडीबी पर स्विच किया - लेकिन मारियाडीबी से पहले आंकड़े और भी खराब थे।

मैंने अपने वर्कस्टेशन पर सभी डेटाबेस पहले ही हटा दिए हैं - कोई अंतर नहीं।

बड़ा सवाल यह है: प्रदर्शन 53 कारक धीमा कैसे हो सकता है? मैं इस तरह काम नहीं कर सकता :-(

मेरा आयात आदेश:

pv sql/master.sql | mysql -h'localhost' -u'root' -p'root' 'master'

iostat -xm 5

सर्वर A:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
      17,43    0,00   30,28   51,85    0,00    0,44

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00   254,03    0,00 1305,45     0,00     6,09     9,56     0,78    0,60    0,00    0,60   0,57  74,25

कार्य केंद्र बी:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       7,32    0,00    3,22    5,03    0,00   84,42

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     1,40    0,80  172,40     0,00     0,56     6,72     1,17    6,75   12,00    6,72   5,40  93,52

dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

सर्वर A:

1073741824 bytes (1,1 GB) copied, 18,6947 s, 57,4 MB/s

कार्य केंद्र बी:

1073741824 bytes (1,1 GB) copied, 8,95646 s, 120 MB/s

Comments

क्या आप मुझे बता सकते हैं कि आप डेटाबेस को कैसे आयात करना चाहते हैं? (आपका ठोस mysql स्टेटमेंट क्या है) "क्या प्रक्रियाप्रदर्शन दिखाता है?" कहते हैं? क्या आपने देखा है कि प्रक्रिया स्ट्रेस के साथ ठोस क्या कर रही है? क्या आप कृपया यह भी देख सकते हैं कि क्या आपकी मशीन शायद स्वैपिंग कर रही है?

मैंने अपना प्रश्न संपादित किया।

— एलेक्स

InnoDB? innodb_buffer_pool_sizeप्रत्येक मशीन पर मूल्य क्या है ?

— रिक जेम्स

Answer 1

इस जवाब ने सब कुछ बहुत तेज कर दिया:

/programming//a/2167641/292408

मैं सामान्यत

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

शुरुआत में, और

COMMIT;
SET unique_checks=1;
SET foreign_key_checks=1;

अतं मै।

अब 3 मिनट हो गए।

(ट्विटर के माध्यम से @andreasemer के सौजन्य से)

Comments

बहुत बढ़िया चाल। कुछ ऐसा जो मुझे जानना चाहिए, क्या ऐसा करने का कोई दुष्प्रभाव है?

— धर्म सपुत्र

यदि आपका डेटा दूषित है, तो आयात के बाद विदेशी प्रमुख बाधाओं को पूरा नहीं किया जा सकता है।

— एलेक्स

चारों ओर शानदार काम। आपने मुझे सचमुच घंटे बचाए हैं।

— जाफो

मेरे लिए प्रदर्शन को गति नहीं दी। इसके बिना यह 23 मिनट और उसके बाद 23 मिनट (3 जीबी .sql फ़ाइल) था।

— जोशुआ पिंटर

Answer 2

ऊपर जो मैं देख रहा हूं उसे लागू करना ... मेरे पास मेरी डंप फ़ाइल पहले से ही स्वचालित रूप से कुछ द्वारा उत्पन्न की गई है जैसे:

mysqldump my_db > db-dump-file.sql

मैं इस आयात को स्वचालित करने के तो मैं कहा जाता है अपने कंप्यूटर में दो फ़ाइलें बनाई चाहते default-start-import.sqlऔर default-end-import.sqlऔर उनकी सामग्री हैं डिफ़ॉल्ट-शुरू import.sql :

SET autocommit=0;

और डिफ़ॉल्ट-अंत-आयात। एसक्यूएल :

COMMIT;
SET autocommit=1;

और जो स्क्रिप्ट मैं चला रहा हूं वह कुछ इस तरह है;

cat default-start-import.sql db-dump-file.sql default-end-import.sql | mysql my_other_db

एक ही कमांड लेकिन पढ़ने में आसान:

cat default-start-import.sql \
    db-dump-file.sql \
    default-end-import.sql \
| mysql my_other_db

इस मामले catमें उन फ़ाइलों को पाइप में भेजने से पहले उन्हें समतल करने के लिए उपयोग किया जाता है। मुझे लगता है कि यह महत्वपूर्ण है कि सभी फाइलें एक नए-पंक्ति वर्ण (फ़ाइल के अंत में एक खाली पंक्ति यदि एक पाठ संपादक से देखी जाती हैं) के साथ समाप्त होती हैं, ताकि catकमांड फाइलों के बीच की रेखाओं का विलय न करे।

आयात ठीक काम करता है, मैंने यह परीक्षण नहीं किया है कि क्या यह सक्षम-और-अक्षम-ऑटोकॉमिट चीज़ के इस सुधार के कारण वास्तव में तेज़ है, लेकिन अगर यह तेजी से चीजें बनाता है, तो यह अतिरिक्त कदम चीजों को आसान बनाते हैं।

Answer 3

मैंने कोशिश की है और --compressसाथ ही SET autocommit=0;उन्होंने एक छोटी राशि की मदद की है ...

मैंने पाया कि कई INSERT INTO ...बयानों को एक बड़े बयान में कई VALUES(...), (...)बेहतर गति के साथ परिवर्तित करना ।

मैं mysqlWAN पर SSL का उपयोग कर रहा हूं । दूरस्थ MySQL डेटाबेस को अमेज़न पर होस्ट किया गया है।

9 कॉलम और 2,100 पंक्तियों के साथ:

• 2,100 अलग INSERTबयान: 82
• 2 समेकित INSERTकथन: <1 s

7 कॉलम और 42,000 पंक्तियों के साथ:

• 42,000 अलग INSERTबयान: 1,740s
• 42 समेकित INSERTबयान: 105s

इसलिए डेटाबेस डंप (या अधिक विशेष रूप से INSERTबयानों का प्रारूप ) उत्पन्न करने वाले उपकरण के आधार पर , गति को प्रभावित किया जा सकता है।

नोट: यह .sqlमेरे परीक्षणों में डंप फ़ाइल को 60% से कम कर देता है , इसलिए यह i / o पर भी बचाएगा।

चेतावनी: पोर्टेबिलिटी की आवश्यकता वाले लोगों के लिए इस तकनीक की भौतिक सीमाएँmysql हैं ... SQL सर्वर एक समय में केवल 1,000 पंक्तियों तक सीमित प्रतीत होता है ।

फिर भी, 42,000 पंक्तियों के लिए एक समय में 1,000 पंक्तियों को करने से अभी भी 1,657% सुधार होता है!