MySQL उदाहरण "SYNC इंडेक्स कर रहा है"

12

संकट

MySQL 5.6.20 का एक उदाहरण (ज्यादातर सिर्फ) InnoDB तालिकाओं के साथ एक डेटाबेस सभी INSERT, UPDATE और DELETE प्रश्नों के साथ 1-4 मिनट की अवधि के लिए सभी अद्यतन कार्यों के लिए सामयिक स्टालों का प्रदर्शन कर रहा है जो कि "क्वेरी एंड" स्थिति में शेष हैं। यह स्पष्ट रूप से सबसे दुर्भाग्यपूर्ण है। MySQL धीमी क्वेरी लॉग पागल क्वेरी समय के साथ यहां तक ​​कि सबसे तुच्छ प्रश्नों को लॉग कर रहा है, उनमें से सैकड़ों उसी टाइमस्टैम्प के साथ उस समय बिंदु के अनुरूप हैं जहां स्टॉल को हल किया गया है:

# Query_time: 101.743589  Lock_time: 0.000437 Rows_sent: 0  Rows_examined: 0
SET timestamp=1409573952;
INSERT INTO sessions (redirect_login2, data, hostname, fk_users_primary, fk_users, id_sessions, timestamp) VALUES (NULL, NULL, '192.168.10.151', NULL, 'anonymous', '64ef367018099de4d4183ffa3bc0848a', '1409573850');

और डिवाइस के आंकड़े बढ़े हुए दिखाई दे रहे हैं, हालांकि इस समय सीमा में I / O लोड की अधिकता नहीं है (इस मामले में अपडेट 14:17:30 - 14:19:12 ऊपर के बयान से टाइमस्टैम्प के अनुसार रुक रहे थे):

# sar -d
[...]
02:15:01 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:16:01 PM    dev8-0     41.53    207.43   1227.51     34.55      0.34      8.28      3.89     16.15
02:17:01 PM    dev8-0     59.41    137.71   2240.32     40.02      0.39      6.53      4.04     24.00
02:18:01 PM    dev8-0    122.08   2816.99   1633.44     36.45      3.84     31.46      1.21      2.88
02:19:01 PM    dev8-0    253.29   5559.84   3888.03     37.30      6.61     26.08      1.85      6.73
02:20:01 PM    dev8-0    101.74   1391.92   2786.41     41.07      1.69     16.57      3.55     36.17
[...]
# sar
[...]
02:15:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:16:01 PM     all     15.99      0.00     12.49      2.08      0.00     69.44
02:17:01 PM     all     13.67      0.00      9.45      3.15      0.00     73.73
02:18:01 PM     all     10.64      0.00      6.26     11.65      0.00     71.45
02:19:01 PM     all      3.83      0.00      2.42     24.84      0.00     68.91
02:20:01 PM     all     20.95      0.00     15.14      6.83      0.00     57.07

अधिक बार नहीं, मैं mysql धीमे लॉग में देखता हूं कि सबसे पुराना क्वेरी स्टालिंग एक बड़ी-ish (~ 10 M पंक्तियों) तालिका में एक VARCHAR प्राथमिक कुंजी और एक पूर्ण-पाठ खोज इंडेक्स के साथ है:

CREATE TABLE `files` (
  `id_files` varchar(32) NOT NULL DEFAULT '',
  `filename` varchar(100) NOT NULL DEFAULT '',
  `content` text,
  PRIMARY KEY (`id_files`),
  KEY `filename` (`filename`),
  FULLTEXT KEY `content` (`content`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

आगे की जांच (यानी SHOW इंजन INNODB STATUS) से पता चला है कि यह वास्तव में हमेशा पूर्ण-पाठ अनुक्रमणिका का उपयोग कर तालिका के लिए एक अद्यतन है जो स्टाल का कारण बन रहा है। "SHOW Engine INNODB STATUS" के संबंधित लेनदेन अनुभाग में सबसे पुराने चल रहे लेनदेन के लिए इन दोनों की तरह प्रविष्टियाँ हैं:

---TRANSACTION 162269409, ACTIVE 122 sec doing SYNC index
6 lock struct(s), heap size 1184, 0 row lock(s), undo log entries 19942
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_1" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_2" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_3" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_4" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_5" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_6" trx id 162269409 lock mode IX
---TRANSACTION 162269408, ACTIVE (PREPARED) 122 sec committing
mysql tables in use 1, locked 1
1 lock struct(s), heap size 360, 0 row lock(s), undo log entries 1
MySQL thread id 165998, OS thread handle 0x7fe0e239c700, query id 91208956 192.168.10.153 root query end
INSERT INTO files (id_files, filename, content) VALUES ('f19e63340fad44841580c0371bc51434', '1237716_File_70380a686effd6b66592bb5eeb3d9b06.doc', '[...]
TABLE LOCK table `vw`.`files` trx id 162269408 lock mode IX

तो वहाँ कुछ भारी पूरा टेक्स्ट सूचकांक कार्रवाई वहाँ चल रहा है ( doing SYNC index) को रोकने के बाद के सभी के लिए अद्यतन किसी भी तालिका।

लॉग से ऐसा लगता है कि यह undo log entriesसंख्या doing SYNC index20,000 तक पहुंचने तक ~ 150 / s पर आगे बढ़ रही है, जिस बिंदु पर ऑपरेशन किया जाता है।

इस विशिष्ट तालिका का FTS आकार काफी प्रभावशाली है:

# du -c FTS_000000000000224a_00000000000036b9_*
614404  FTS_000000000000224a_00000000000036b9_INDEX_1.ibd
2478084 FTS_000000000000224a_00000000000036b9_INDEX_2.ibd
1576964 FTS_000000000000224a_00000000000036b9_INDEX_3.ibd
1630212 FTS_000000000000224a_00000000000036b9_INDEX_4.ibd
1978372 FTS_000000000000224a_00000000000036b9_INDEX_5.ibd
1159172 FTS_000000000000224a_00000000000036b9_INDEX_6.ibd
9437208 total

यद्यपि इस मुद्दे को भी इस तरह की एक बड़ी संख्या में FTS डेटा आकार के साथ तालिकाओं द्वारा ट्रिगर किया गया है:

# du -c FTS_0000000000002467_0000000000003a21_INDEX*
49156   FTS_0000000000002467_0000000000003a21_INDEX_1.ibd
225284  FTS_0000000000002467_0000000000003a21_INDEX_2.ibd
147460  FTS_0000000000002467_0000000000003a21_INDEX_3.ibd
135172  FTS_0000000000002467_0000000000003a21_INDEX_4.ibd
155652  FTS_0000000000002467_0000000000003a21_INDEX_5.ibd
106500  FTS_0000000000002467_0000000000003a21_INDEX_6.ibd
819224  total

उन मामलों में स्टाल का समय भी लगभग एक ही है। मैंने bugs.mysql.com पर एक बग खोला है ताकि देवता इस पर गौर कर सकें।

स्टालों की प्रकृति ने मुझे पहले दोषी के रूप में लॉग इन फ्लशिंग गतिविधि पर संदेह किया और लॉग इन पर MySQL 5.5 के साथ फ्लशिंग प्रदर्शन के मुद्दों पर पेरकोना लेख बहुत समान लक्षणों का वर्णन कर रहा है, लेकिन आगे की घटनाओं से पता चला है कि इस डेटाबेस में INSERT संचालन एकल MyISAM तालिका में है स्टॉल से भी प्रभावित होते हैं, इसलिए यह केवल एक InnoDB-जैसा मुद्दा नहीं लगता है।

फिर भी, मैं के मूल्यों को ट्रैक करने का फैसला किया Log sequence numberऔर Pages flushed up toसे "लॉग" की धारा outputs SHOW ENGINE INNODB STATUSहर 10 सेकंड। यह वास्तव में ऐसा लगता है कि स्टाल के दौरान फ्लशिंग गतिविधि जारी है, क्योंकि दोनों मूल्यों के बीच प्रसार कम हो रहा है:

Mon Sep 1 14:17:08 CEST 2014 LSN: 263992263703, Pages flushed: 263973405075, Difference: 18416 K
Mon Sep 1 14:17:19 CEST 2014 LSN: 263992826715, Pages flushed: 263973811282, Difference: 18569 K
Mon Sep 1 14:17:29 CEST 2014 LSN: 263993160647, Pages flushed: 263974544320, Difference: 18180 K
Mon Sep 1 14:17:39 CEST 2014 LSN: 263993539171, Pages flushed: 263974784191, Difference: 18315 K
Mon Sep 1 14:17:49 CEST 2014 LSN: 263993785507, Pages flushed: 263975990474, Difference: 17377 K
Mon Sep 1 14:17:59 CEST 2014 LSN: 263994298172, Pages flushed: 263976855227, Difference: 17034 K
Mon Sep 1 14:18:09 CEST 2014 LSN: 263994670794, Pages flushed: 263978062309, Difference: 16219 K
Mon Sep 1 14:18:19 CEST 2014 LSN: 263995014722, Pages flushed: 263983319652, Difference: 11420 K
Mon Sep 1 14:18:30 CEST 2014 LSN: 263995404674, Pages flushed: 263986138726, Difference: 9048 K
Mon Sep 1 14:18:40 CEST 2014 LSN: 263995718244, Pages flushed: 263988558036, Difference: 6992 K
Mon Sep 1 14:18:50 CEST 2014 LSN: 263996129424, Pages flushed: 263988808179, Difference: 7149 K
Mon Sep 1 14:19:00 CEST 2014 LSN: 263996517064, Pages flushed: 263992009344, Difference: 4402 K
Mon Sep 1 14:19:11 CEST 2014 LSN: 263996979188, Pages flushed: 263993364509, Difference: 3529 K
Mon Sep 1 14:19:21 CEST 2014 LSN: 263998880477, Pages flushed: 263993558842, Difference: 5196 K
Mon Sep 1 14:19:31 CEST 2014 LSN: 264001013381, Pages flushed: 263993568285, Difference: 7270 K
Mon Sep 1 14:19:41 CEST 2014 LSN: 264001933489, Pages flushed: 263993578961, Difference: 8158 K
Mon Sep 1 14:19:51 CEST 2014 LSN: 264004225438, Pages flushed: 263993585459, Difference: 10390 K

14:19:11 पर प्रसार अपने न्यूनतम स्तर पर पहुंच गया है, इसलिए फ्लशिंग गतिविधि यहां समाप्त हो गई है, बस स्टाल के अंत के साथ मेल खाना है। लेकिन इन बिंदुओं ने मुझे कारण के रूप में निस्तब्धता लॉग इनको खारिज कर दिया:

  • फ्लशिंग ऑपरेशन के लिए डेटाबेस के सभी अपडेट को ब्लॉक करने के लिए इसे "सिंक्रोनस" होना चाहिए, जिसका अर्थ है कि लॉग स्पेस के 7/8 पर कब्जा करना होगा
  • यह एक "एसिंक्रोनस" फ्लशिंग चरण से पहले innodb_max_dirty_pages_pctभरना होगा जो फिल स्तर पर शुरू होगा - जिसे मैं नहीं देख रहा हूं
  • एलएसएन स्टाल के दौरान भी बढ़ते रहते हैं, इसलिए लॉग गतिविधि पूरी तरह से बंद नहीं होती है
  • MyISAM तालिका INSERT भी प्रभावित होते हैं
  • अनुकूली निस्तब्धता के लिए page_cleaner थ्रेड अपना काम करता है और बिना DML प्रश्नों को रोकने के लिए लॉग को फ्लश करता है:

LSN - PagesFlushed

(नंबर दिए गए हैं ([Log Sequence Number] - [Pages flushed up to]) / 1024से SHOW ENGINE INNODB STATUS)

यह समस्या कुछ हद तक innodb_adaptive_flushing_lwm=1पहले की तुलना में अधिक काम करने के लिए पेज क्लीनर को मजबूर करने से कम होती है ।

error.logकोई प्रविष्टि नहीं स्टालों के साथ मेल खाते हैं। SHOW INNODB STATUSलगभग 24 घंटे के ऑपरेशन के कुछ अंश इस तरह दिखते हैं:

SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 789330
OS WAIT ARRAY INFO: signal count 1424848
Mutex spin waits 269678, rounds 3114657, OS waits 65965
RW-shared spins 941620, rounds 20437223, OS waits 442474
RW-excl spins 451007, rounds 13254440, OS waits 215151
Spin rounds per wait: 11.55 mutex, 21.70 RW-shared, 29.39 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-09-03 10:33:55 7fe0e2e44700
[...]
--------
FILE I/O
--------
[...]
932635 OS file reads, 2117126 OS file writes, 1193633 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 17.00 writes/s, 1.20 fsyncs/s
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Main thread process no. 54745, id 140604272338688, state: sleeping
Number of rows inserted 528904, updated 1596758, deleted 99860, read 3325217158
5.40 inserts/s, 10.40 updates/s, 0.00 deletes/s, 122969.21 reads/s

तो, हाँ, डेटाबेस में गतिरोध हैं, लेकिन वे बहुत ही अनजान हैं ("नवीनतम" आँकड़े पढ़ने के लगभग 11 घंटे पहले संभाले गए हैं)।

मैंने समय-समय पर "SEMAPHORES" अनुभाग मानों पर नज़र रखने की कोशिश की, विशेष रूप से सामान्य ऑपरेशन की स्थिति में और एक स्टाल के दौरान (मैंने MySQL सर्वर की प्रक्रिया सूची की जाँच करते हुए और एक लॉग आउटपुट में नैदानिक ​​कमांड के एक जोड़े को चलाने के लिए एक छोटी स्क्रिप्ट लिखी थी। एक स्पष्ट स्टाल)। जैसा कि संख्याओं को अलग-अलग समय सीमा में लिया गया है, मैंने परिणामों को घटनाओं / सेकंड के लिए सामान्य कर दिया है:

                          normal   stall
                          1h avg  1m avg
OS WAIT ARRAY INFO: 
    reservation count      5,74    1,00
    signal count          24,43    3,17
Mutex spin waits           1,32    5,67
    rounds                 8,33   25,85
    OS waits               0,16    0,43
RW-shared spins            9,52    0,76
    rounds               140,73    13,39
    OS waits               2,60    0,27
RW-excl spins              6,36    1,08
    rounds               178,42   16,51
    OS waits               2,38    0,20

मैं इस बारे में निश्चित नहीं हूं कि मैं यहां क्या देख रहा हूं। अधिकांश संख्याएँ परिमाण के क्रम से कम हो गई हैं - शायद अपडेट किए गए अद्यतनों के कारण, "म्यूटेक्स स्पिन वेट्स" और "म्यूटेक्स स्पिन राउंड" हालांकि दोनों 4 के कारक से बढ़ गए हैं।

इसकी और जांच करते हुए, म्यूटेक्स ( SHOW ENGINE INNODB MUTEX) की सूची में ~ 480 म्यूटेक्स प्रविष्टियाँ हैं, जो सामान्य संचालन के साथ-साथ एक स्टाल के दौरान दोनों सूचीबद्ध हैं। मैंने innodb_status_output_locksयह देखने में सक्षम किया है कि क्या यह मुझे अधिक विस्तार देने जा रहा है।

कॉन्फ़िगरेशन चर

(मैंने निश्चित सफलता के बिना उनमें से अधिकांश के साथ छेड़छाड़ की है):

mysql> show global variables where variable_name like 'innodb_adaptive_flush%';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_adaptive_flushing     | ON    |
| innodb_adaptive_flushing_lwm | 1     |
+------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_max_dirty_pages_pct%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_max_dirty_pages_pct     | 50    |
| innodb_max_dirty_pages_pct_lwm | 10    |
+--------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_log_%';
+-----------------------------+-----------+
| Variable_name               | Value     |
+-----------------------------+-----------+
| innodb_log_buffer_size      | 8388608   |
| innodb_log_compressed_pages | ON        |
| innodb_log_file_size        | 268435456 |
| innodb_log_files_in_group   | 2         |
| innodb_log_group_home_dir   | ./        |
+-----------------------------+-----------+
mysql> show global variables where variable_name like 'innodb_double%';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+
mysql> show global variables where variable_name like 'innodb_buffer_pool%';
+-------------------------------------+----------------+
| Variable_name                       | Value          |
+-------------------------------------+----------------+
| innodb_buffer_pool_dump_at_shutdown | OFF            |
| innodb_buffer_pool_dump_now         | OFF            |
| innodb_buffer_pool_filename         | ib_buffer_pool |
| innodb_buffer_pool_instances        | 8              |
| innodb_buffer_pool_load_abort       | OFF            |
| innodb_buffer_pool_load_at_startup  | OFF            |
| innodb_buffer_pool_load_now         | OFF            |
| innodb_buffer_pool_size             | 29360128000    |
+-------------------------------------+----------------+
mysql> show global variables where variable_name like 'innodb_io_capacity%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| innodb_io_capacity     | 200   |
| innodb_io_capacity_max | 2000  |
+------------------------+-------+
mysql> show global variables where variable_name like 'innodb_lru_scan_depth%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024  |
+-----------------------+-------+

चीजें पहले से ही कोशिश की

  • द्वारा क्वेरी कैश को अक्षम करना SET GLOBAL query_cache_size=0
  • innodb_log_buffer_size128M तक बढ़ रहा है
  • साथ खेलना innodb_adaptive_flushing, innodb_max_dirty_pages_pctऔर संबंधित _lwmमूल्य (वे मेरे परिवर्तनों से पहले चूक के लिए निर्धारित किए गए थे)
  • बढ़ती innodb_io_capacity(2000) और innodb_io_capacity_max(4000)
  • स्थापना innodb_flush_log_at_trx_commit = 2
  • innodb_flush_method = O_DIRECT के साथ चल रहा है (हाँ, हम एक का उपयोग करते हैं SAN लगातार लेखन कैश के साथ)
  • / sys / block / sda / queue / अनुसूचक को noopया को सेट करनाdeadline
mysql  innodb  myisam  mysql-5.6 
— syneticon-dj
स्रोत
Innodb_io_capacity, innodb_io_capacity_max और innodb_lru_scan_depth के क्या मूल्य हैं? इन्हें उच्चतर (अधिक उपयुक्त) मानों पर सेट करने से लॉग स्थान खाली रखने में मदद मिलती है।
— मॉर्गन Tocker
चूक - २००, २००० और १०२०। मैंने अब उन्हें २०००, ४००० और २००० में बदल दिया है और एलएसएन और पेज फ्लश किए गए मूल्यों के बीच का प्रसार एक बार फिर घटकर १,०००,००० हो गया है। लेकिन मुझे यकीन नहीं है कि अगर यह लॉग की बात है पहली जगह में जगह।
— पर्यायवाची- dj
वास्तव में ऐसा लगता नहीं है। मैं अभी भी स्टालों को देख रहा हूं - वे घटना की अवधि या आवृत्ति में बहुत अधिक नहीं बदले हैं। मेरा LSN / चेकपॉइंट लॉगिंग काफी कम निरपेक्ष प्रसार संख्या दिखा रहा है जो 1-2 मिनट में लगभग 3 M के स्टाल के दौरान कुछ हद तक बढ़ रहा है (शायद अपूर्ण लॉग उपयोग के परिणामस्वरूप अपूर्ण लेनदेन) और बाद में LSN में फैलता हुआ शून्य-शून्य तक फ़्लश हो रहा है और उस समय से शुरू होने वाली चौकी जहां स्टॉल का समाधान किया गया है।
— सिनिटिकॉन-डीजे सेप
मुझे यकीन नहीं है कि आपके पास innodb_adaptive_flushing_lwm 1 पर सेट होना चाहिए - यह लॉग स्पेस का एक प्रतिशत है, जिस पर अनुकूली फ्लशिंग किक (डिफ़ॉल्ट: 10)।
— बजे मॉर्गन टॉकर
@ मॉर्गनटॉकर मैंने यह सुनिश्चित करने के लिए इसे निर्धारित किया है कि अनुकूली निस्तब्धता ज्यादातर समय कुछ भी बहा देती है क्योंकि मुझे संदेह था कि लॉग स्पेस उपयोग समस्या का हिस्सा था। यह समस्या 10 के डिफ़ॉल्ट मान के साथ हुई, मैंने समस्या निवारण उद्देश्यों के लिए इसे बदल दिया।
— पर्यायवाची- dj

जवाबों:

6

हम दो सर्वरों पर 5.6.12 और 5.6.16 विंडोज पर चलने वाले एक ही मुद्दे को दासों की एक जोड़ी के साथ देख रहे थे। हम लगभग दो महीने तक आप की तरह स्तब्ध थे।

समाधान :

set global binlog_order_commits = 0;

चर के विवरण के लिए https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_order_commits देखें ।

स्पष्टीकरण :

InnoDB पूर्ण-पाठ कैश का उपयोग करता है (आकार में डिफ़ॉल्ट रूप से 8M) जिसमें परिवर्तन होते हैं जिन्हें डिस्क पर वास्तविक पूर्ण-पाठ सूचकांक पर लागू करने की आवश्यकता होती है।

एक बार जब कैश भर जाता है, तो लेनदेन के एक जोड़े को कैश में निहित डेटा को मर्ज करने का काम करने के लिए बनाया जाता है - यह यादृच्छिक आईओ की एक बड़ी मात्रा है, इसलिए जब तक कि आपके पूरे पूर्ण-पाठ इंडेक्स को लोड नहीं किया जा सकता है बफ़र पूल, यह एक लंबा और धीमा लेनदेन है।

Binlog_order_commits सही पर सेट होने के साथ, आवेषण और अपडेट वाले सभी लेन-देन, जो लंबे समय से चल रहे fts_sync_index लेनदेन के बाद शुरू हुए, तब तक इंतजार करना चाहिए जब तक कि वे कमिट कर सकें।

यह केवल एक समस्या है यदि बाइनरी लॉगिंग सक्षम है

— डैनियल गोल्डिंग
स्रोत
यह बहुत अधिक लग रहा है जैसे यह उस मुद्दे के लिए संकल्प हो सकता है जो मैं देख रहा था, भी। आप वर्कअराउंड के साथ कैसे आए? इसके अलावा, मेरे मामले में पूरा टेक्स्ट इंडेक्स बफर पूल (जो आकार में ~ 30G है) में फिट होगा , लेकिन ऑपरेशन भारी विलंब-बद्ध लग रहा था। मैं इस धारणा के तहत हूं कि स्टोरेज लेटेंसी से निपटने के दौरान MySQL का I / O स्टैक बेहद अक्षम है , इसलिए यह समस्या शायद दोनों का संयोजन है - बाइनरी लॉगिंग कॉन्फ़िगरेशन के लिए एक खराब डिफ़ॉल्ट के साथ-साथ अक्षमता।
— पर्यायवाची- dj
मुझे आश्चर्य है कि यह इतने लंबे समय तक किसी का ध्यान कैसे जा सकता है। निश्चित रूप से, अधिक लोग हैं जो एफटीएस के साथ इनोबीडी चलाते हैं और गैर-एसएसडी-स्टोरेज पर बिनलॉग सक्षम हैं?
— पर्यायवाची- dj
भाग्य। मुझे आपके समान ही मिला था, जहां मैंने लॉकअप के दौरान "शो इंजन इनोडब स्टेटस" पर कब्जा करने में कामयाबी हासिल की थी। मैंने एक छोटा प्रोग्राम लिखा, जिसमें एक एफटीएस इंडेक्स के साथ एक टेबल में बहुत सी पंक्तियाँ डाली जाएंगी और दूसरी जिसमें दूसरी टेबल अपडेट की गई और अपडेट टाइम रिकॉर्ड किया गया। मैं कुछ समय के लिए अपडेट को ब्लॉक करने के लिए एफटीएस कैश फ्लश पॉज़ करने में सक्षम नहीं था, जब तक कि मैं अपने स्थानीय मशीन और लाइव सर्वर के बीच एक-एक करके सेटअप में अंतर के माध्यम से नहीं चला गया। बिनलॉग को चालू करने से समस्या फिर से उत्पन्न हो गई इसलिए मैंने सिर्फ बिनलॉग विकल्पों के माध्यम से पढ़ा।
— डेनियल गोल्डिंग
1
यह ध्यान देने योग्य है कि MySQL देव टीम अंततः (कतार में 15 महीने के बाद!) ने बग की स्थिति को "सत्यापित" करने के लिए निर्धारित किया है और कम से कम देव टीम का कोई व्यक्ति समाधान के बारे में सोच रहा है। कहने की जरूरत नहीं है, मैं MySQL के साथ किया जाता है। अच्छे के लिए, मुझे उम्मीद है।
— पर्यायवाची- dj
4

मुझे लॉग फ्लशिंग और कैसे अनुकूल निस्तब्धता काम करता है के साथ ऐतिहासिक समस्या का वर्णन करने की कोशिश करते हैं:

  • रेडो ​​लॉग एक रिंग बफर डिज़ाइन है। वे केवल कभी भी (सामान्य ऑपरेशन से पढ़े नहीं जाते) लिखे जाते हैं और क्रैश रिकवरी में प्रदान करते हैं। मुझे एक टैंक के चलने के समान एक रिंग बफर का वर्णन करना पसंद है।

  • InnoDB लॉग फ़ाइल स्थान को अधिलेखित करने में सक्षम नहीं होगा यदि इसमें ऐसे परिवर्तन हैं जो अभी तक डिस्क पर संशोधित नहीं किए गए हैं। इसलिए ऐतिहासिक रूप से, क्या होगा कि InnoDB प्रति सेकंड एक निश्चित मात्रा में काम करेगा (द्वारा कॉन्फ़िगर किया गया innodb_io_capacity) और यदि यह पर्याप्त नहीं था, तो आप पूर्ण लॉग स्पेस तक पहुंच जाएंगे। एक स्टाल के रूप में तुल्यकालिक निस्तब्धता के लिए अचानक खाली स्थान होने की आवश्यकता होगी, जो आमतौर पर एक पृष्ठभूमि कार्य अचानक अग्रभूमि बनाते हैं।

  • इस समस्या को हल करने के लिए, अनुकूली निस्तब्धता शुरू की गई थी। जहां 10% (डिफ़ॉल्ट) लॉग स्पेस की खपत होती है, पृष्ठभूमि का काम उत्तरोत्तर अधिक आक्रामक होने लगता है। इसका उद्देश्य अचानक स्टाल के बजाय, आपके पास प्रदर्शन में एक 'शॉर्ट डिप' से अधिक है।

  • अनुकूली निस्तब्धता से स्वतंत्र, आपके कार्यभार ( innodb_log_file_size4 जी के मान अब काफी सुरक्षित हैं) के लिए पर्याप्त लॉग स्थान होना महत्वपूर्ण है , और सुनिश्चित करें कि innodb_io_capacityऔर innodb_lru_scan_depthयथार्थवादी मूल्यों पर सेट हैं। अनुकूली फ्लशिंग 10% innodb_adaptive_flushing_lwmऐसी चीज है जिसे आप बहुत दूर तक नहीं खींचते हैं, यह अंतरिक्ष से बाहर के खिलाफ एक रक्षा तंत्र के अधिक है।

— मॉर्गन Tocker
स्रोत
2

बस InnoDB कुछ विवाद राहत लाने के लिए, आप के साथ खेल सकते हैं innodb_purge_threads।

MySQL 5.6 से पहले, मास्टर थ्रेड ने सभी पृष्ठ को फ्लशिंग कर दिया। MySQL 5.6 में, एक अलग थ्रेड इसे संभाल सकता है। innodb_purge_threadsMySQL 5.5 में डिफ़ॉल्ट मान अधिकतम 1 के साथ 0 था । MySQL 5.6 में, डिफ़ॉल्ट 1 अधिकतम 32 के साथ है।

innodb_purge_threadsवास्तव में सेटिंग क्या करती है?

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

मैं 4 में innodb_purge_threads सेट करके शुरू करूंगा और देखूंगा कि क्या InnoDB पेज फ्लशिंग कम हो गया है।

UPDATE 2014-09-02 12:33 EDT

मॉर्गन टॉकर ने नीचे टिप्पणी में बताया कि पेज क्लीनर पीड़ित है और MySQL 5.7 इसे संबोधित कर सकता है । इसके बावजूद, आपकी स्थिति MySQL 5.6 में है।

मैंने दूसरा रूप लिया और देखा कि आपके पास 50 पर innodb_max_dirty_pages_pct है ।

MySQL 5.5+ में innodb_max_dirty_pages_pct के लिए डिफ़ॉल्ट 75+ है। इसे कम करने से फ्लशिंग से स्टालों की घटनाओं में वृद्धि होगी। मैं तीन (3) चीजें करता

अद्यतन 2014-09-03 11:06 EDT

आपको अपने फ्लशिंग व्यवहार को बदलने की आवश्यकता हो सकती है

निम्नलिखित को गतिशील रूप से सेट करने का प्रयास करें

SET GLOBAL flush = 1;
SET GLOBAL flush_time = 10;

ये चर, फ्लश और फ्लश_टाइम , हर 10 सेकंड में टेबल पर खुले फ़ाइल हैंडल को बंद करके फ्लशिंग को और अधिक आक्रामक बना देंगे। MyISAM निश्चित रूप से इससे लाभान्वित हो सकता है क्योंकि यह डेटा कैश नहीं करता है। सभी को MyISAM के लिए लिखते हैं तालिकाओं में पूर्ण तालिका ताले की आवश्यकता होती है, इसके बाद परमाणु लिखते हैं, और डिस्क परिवर्तनों के लिए ओएस पर निर्भर करते हैं।

इस तरह से निस्तब्धता InnoDB एक mysql पुनरारंभ की आवश्यकता होगी। देखने के विकल्प innodb_flush_log_at_trx_commit और innodb_flush_method हैं ।

पुनः आरंभ करने से पहले, कृपया इन्हें जोड़ें

[mysqld]
flush = 1
flush_time = 10
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT

इस मार्ग पर जाने से पहले, आपको यह देखना चाहिए कि क्या जर्नलिंग एक मुद्दा है। मैंने देखा कि इस शांत mysqlperformanceblog पोस्ट को O_DIRECT पर कर्नेल की वजह से फेक किया जा रहा है। इसी पोस्ट में MyISAM के प्रभावित होने का भी उल्लेख है।

मैंने इस पोस्ट के बारे में पहले लिखा था: ib_logfile ने O_SYNC के साथ खोला जब innodb_flush_method = O_DSYNC

कोशिश तो करो !!!

— RolandoMySQLDBA
स्रोत
1
स्पष्ट करने के लिए: मेरा मानना ​​है कि यह कार्यभार शुद्ध धागे (ओं) के बजाय पृष्ठ क्लीनर धागे (ओं) पर जोर देता है। मल्टीपल पेज क्लीनर एक 5.7 फ़ीचर है, लेकिन आगे की कॉन्फ़िगरेशन 5.6 में भी संभव है। देखें: mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads
— Morgan Tocker
@MorganTocker @RolandoMySQLDBA sar -dआउटपुट में मेरे लिए एक बात जो सामने आई , वह awaitयह है कि स्टॉल में से एक के दौरान लगभग दस गुना अधिक हो रहा है जबकि थ्रूपुट ड्रॉप। क्या आपको लगता है कि यह संभावना है कि यहां MySQL के बाहर समस्याएं हैं, उदाहरण के लिए I / O अनुसूचक या फाइलसिस्टम जर्नलिंग?
— जेम्स एल
मैं आपके द्वारा सुझाए गए अधिकांश मापदंडों को बदलने के माध्यम से हूं, जो innodb_purge_threads (जिसे पुनरारंभ करने की आवश्यकता है) को छोड़कर। इसने मुद्दे के लिए ज्यादा कुछ नहीं किया। और मुझे विश्वास है कि यहाँ InnoDB इंजन समस्या नहीं है क्योंकि MyISAM तालिका आवेषण भी रोक रहे हैं।
— सिनिटिकॉन-डी जे
कृपया अपनी सेटिंग्स innodb_read_io_threads और innodb_write_io_threads के लिए पोस्ट करें। रनSHOW GLOBAL VARIABLES LIKE '%io_threads';
— रोलैंडमाइसीडीडीबीए
1
@ syneticon-dj MySQL के बाहर से उसी फाइलसिस्टम के बारे में कैसे लिखते हैं - क्या वे भी रुक रहे हैं?
— जेम्स एल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.