সমস্যা
মাইএসকিউএল 5.6.20 চলার উদাহরণ (বেশিরভাগই স্রেফ) ইনোডিবি টেবিল সহ একটি ডাটাবেস "কোয়েরি এন্ড" অবস্থায় থাকা সমস্ত INSERT, আপডেট এবং ডিলিট ক্যোরিয়াস সহ 1-4 মিনিটের সময়কালের জন্য সমস্ত আপডেট ক্রিয়াকলাপের মাঝে মাঝে স্টল প্রদর্শন করছে। এটি অবশ্যই সবচেয়ে দুর্ভাগ্যজনক। মাইএসকিউএল স্লো ক্যোয়ারী লগ অত্যন্ত উন্মত্ত ক্যোয়ারী লগইন করছে পাগল ক্যোয়ারির সময়গুলির সাথে, শত শত একই টাইমস্ট্যাম্পের সাথে একই সময়ে যেখানে স্টলটি সমাধান করা হয়েছে ঠিক তার পয়েন্টের সাথে সম্পর্কিত:
# 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');এবং এই সময়সীমার অতিরিক্ত আই / ও লোড না হলেও ডিভাইসের পরিসংখ্যানগুলি বৃদ্ধি দেখানো হচ্ছে (এক্ষেত্রে আপডেটগুলি উপরের স্টেটমেন্টের টাইমস্ট্যাম্প অনুসারে 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প্রায়শই না, আমি মাইএসকিএল ধীর লগে লক্ষ্য করেছি যে সর্বাধিক প্রাচীন ক্যোয়ারী স্টলিং একটি ভিশারআর প্রাথমিক কী এবং একটি পূর্ণ-পাঠ্য অনুসন্ধান সূচী সহ একটি বৃহত-ইস্ (10 ডলার সারি) সারণিতে একটি INSERT IN
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আরও তদন্ত (অর্থাত্ ইঞ্জিন ইনোডব স্ট্যাটাস দেখায়) প্রমাণিত হয়েছে যে এটি সর্বদা পুরো টেক্সট সূচী ব্যবহার করে একটি টেবিলের আপডেট যা স্টলের কারণ হয়ে উঠছে। "শো ইঞ্জিন ইনোডব স্ট্যাটাস" এর স্বতন্ত্র লেনদেন বিভাগে প্রাচীনতম চলমান লেনদেনের জন্য এই দুটিয়ের মতো এন্ট্রি রয়েছে:
---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 index~ 150 এ এগিয়ে যাচ্ছে / s পর্যন্ত এটি 20,000, এই স্থিতিতে অপারেশন সম্পন্ন করা হয় বাতলান ছুঁয়েছে।
এই নির্দিষ্ট সারণির 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যদিও ইস্যুটি টেবিলগুলির দ্বারাও এটির মতো উল্লেখযোগ্যভাবে কম বিশাল এফটিএস ডেটা আকারের সাথে ট্রিগার করা হয়েছে:
# 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 এ একটি বাগ খুলেছি যাতে ডেভসরা এটি দেখতে পারে।
স্টলের প্রকৃতিটি আমাকে প্রথমে সন্দেহ করেছিল লগ ফ্লাশিং কার্যকলাপটিকে অপরাধী হিসাবে চিহ্নিত করেছে এবং মাইএসকিউএল 5.5 এর সাথে লগ ফ্লাশিং পারফরম্যান্স ইস্যু সম্পর্কিত এই পারকোনা নিবন্ধটি খুব অনুরূপ লক্ষণ বর্ণনা করছে, তবে আরও ঘটনা প্রমাণ করেছে যে এই ডাটাবেসে সিঙ্গেল মাইএসএএম টেবিলটিতে ইনসার্ট অপারেশনগুলি রয়েছে। এছাড়াও স্টল দ্বারা প্রভাবিত হয়, সুতরাং এটি কোনও InnoDB- ইস্যু বলে মনে হয় না।
তা সত্ত্বেও, আমি মান ট্র্যাক করার সিদ্ধান্ত নিয়েছে Log sequence numberএবং Pages flushed up toথেকে "লগ" বিভাগে আউটপুট 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 এ বিস্তারটি সর্বনিম্নে পৌঁছেছে, সুতরাং ফ্লাশিং ক্রিয়াকলাপটি এখানে স্টলটির শেষের সাথে মিলে যায় বলে মনে হচ্ছে। তবে এই পয়েন্টগুলি আমাকে কারণ হিসাবে InnoDB লগ ফ্লাশিংকে বরখাস্ত করতে বাধ্য করেছে:
- ফ্ল্যাশিং অপারেশনের জন্য ডাটাবেসে সমস্ত আপডেট ব্লক করার জন্য এটি "সিঙ্ক্রোনাস" হওয়া দরকার, যার অর্থ লগের //৮ অংশ দখল করতে হবে
- এটির পূর্বে একটি "অ্যাসিনক্রোনাস" ফ্লাশিং পর্বটি
innodb_max_dirty_pages_pctফিল ফিল থেকে শুরু হবে - যা আমি দেখছি না - স্টল চলাকালীনও এলএসএনগুলি বাড়তে থাকে, সুতরাং লগ কার্যকলাপ সম্পূর্ণভাবে বন্ধ হয় না
- মাইআইএসএএম টেবিল INSERT গুলি পাশাপাশি প্রভাবিত হয়
- অভিযোজিত ফ্লাশিংয়ের জন্য পৃষ্ঠার_সামান্য থ্রেডটি তার কাজ করে মনে হচ্ছে এবং ডিএমএল প্রশ্নগুলি বন্ধ না করে লগগুলিকে ফ্লাশ করছে:
(সংখ্যাগুলি ([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 ঘন্টা আগে পরিচালনা করা হয়েছে)।
আমি একটি নির্দিষ্ট সময়ের মধ্যে "বিশেষত" বিভাগের মানগুলি ট্র্যাক করার চেষ্টা করেছি, বিশেষত স্বাভাবিক ক্রিয়াকলাপের একটি পরিস্থিতিতে এবং স্টলের সময় (আমি একটি ছোট স্ক্রিপ্ট লিখেছিলাম মাইএসকিউএল সার্ভারের প্রসেসলিস্টটি পরীক্ষা করেছিলাম এবং লগ আউটপুটে একাধিক ডায়াগনস্টিক কমান্ড চালিয়ে যাচ্ছিলাম) একটি স্পষ্ট স্টল)। যেহেতু নম্বরগুলি বিভিন্ন সময়ের ফ্রেমের উপরে নেওয়া হয়েছে, তাই ফলাফলগুলিকে ইভেন্ট / সেকেন্ডে আমি স্বাভাবিক করে তুলেছি:
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 - ইনোডাব_ফ্লুশ_মোথোড = ও_ডিআরসিটি দিয়ে চলছে (হ্যাঁ, আমরা অবিচ্ছিন্ন রচনা ক্যাশে একটি সান ব্যবহার করি না)
- / sys / block / sda / قطار / সময়সূচী নির্ধারণ
noopবাdeadline