ডেবিয়ানে একক মাইএসকিউএল প্রশ্নের জন্য একাধিক কোর ব্যবহার করা


10

অতিথি ওএস হিসাবে ডেবিয়ানকে দিয়ে ভিএম (ভিএমওয়্যার) পরীক্ষার জন্য আমি মাইএসকিউএল সার্ভার চালাচ্ছি। অতিথির চারটি এমুলেটেড সিপিইউ কোর রয়েছে, তাই আমি থ্রেড_কনক্রিয়েন্সিকে চারটিতে সেট করেছি।

আমি বড় টেবিলগুলিতে ব্যয়বহুল যোগদান করি, যা কয়েক মিনিট সময় নিতে পারে তবে আমি অতিথি ওএস-তে দেখতে পাই যে একবারে কেবল একটি কোর ব্যবহৃত হয়। এতে জড়িত সারণিগুলির জন্য স্টোরেজ ইঞ্জিন ব্যবহার না করেই ঘটে (মাইআইএসএএম এবং ইনোডিবি দিয়ে পরীক্ষা করা)। অতিরিক্তভাবে, এই বড় প্রশ্নগুলি করার সময় পুরো ডাটাবেসটি অবরুদ্ধ বলে মনে হয়, আমি সমান্তরালে কোনও অতিরিক্ত অনুসন্ধান করতে পারি না। আশ্চর্যজনকভাবে হটোপ শোগুলি দেখায় যে ক্যোরির রানটাইম চলাকালীন কোয়েরির জন্য ব্যবহৃত কোরটি পরিবর্তিত হয়!

কেন এমন হয়?

এটি থেকে প্রাসঙ্গিক এন্ট্রি SHOW FULL PROCESSLIST;(অন্য কোনও প্রশ্ন নেই):

| 153 | root       | localhost | pulse_stocks  | Query   |   50 | Copying to tmp table | 
SELECT DISTINCT * FROM 
`pulse_stocks`.`stocks` sto,
`pulse_new`.`security` sec
WHERE
(sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
sto.id
LIMIT 0, 30 

অন্য কোনও প্রশ্ন মুলতুবি নেই। আর একটি আকর্ষণীয় পর্যবেক্ষণ হ'ল, মাইএসকিউএল এই সন্ধানটির এক সেকেন্ডে উত্তর দেবে, যদি আমি ORDER BYঅংশটি ছেড়ে যাই ।

এটি কি SHOW ENGINE INNODB STATUS;দেখায়:

=====================================
120316  9:55:56 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 49 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 47258, signal count 47258
Mutex spin waits 0, rounds 10260, OS waits 39
RW-shared spins 94442, OS waits 47210; RW-excl spins 1, OS waits 1
------------
TRANSACTIONS
------------
Trx id counter 0 5381
Purge done for trx's n:o < 0 1810 undo n:o < 0 0
History list length 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 7503, OS thread id 140316748777216
MySQL thread id 154, query id 654 localhost root
SHOW ENGINE INNODB STATUS
---TRANSACTION 0 5380, ACTIVE 105 sec, process no 7503, OS thread id 140316748977920
 fetching rows, thread declared inside InnoDB 429
mysql tables in use 2, locked 0
MySQL thread id 153, query id 623 localhost root Copying to tmp table
SELECT DISTINCT * FROM 
    `pulse_stocks`.`stocks` sto,
    `pulse_new`.`security` sec
WHERE
    (sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
    ( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
    sto.id
LIMIT 0, 30

Trx read view will not see trx with id >= 0 5381, sees < 0 5381
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
116089 OS file reads, 7 OS file writes, 7 OS fsyncs
1063.16 reads/s, 117085 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 5, seg size 7,
0 inserts, 0 merged recs, 0 merges
Hash table size 17393, node heap has 1 buffer(s)
0.00 hash searches/s, 14.73 non-hash searches/s
---
LOG
---
Log sequence number 0 38201270
Log flushed up to   0 38201270
Last checkpoint at  0 38201270
0 pending log writes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 20638760; in additional pool allocated 994816
Dictionary memory allocated 162680
Buffer pool size   512
Free buffers       0
Database pages     511
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 816631, created 0, written 1
7597.72 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 964 / 1000
--------------
ROW OPERATIONS
--------------
1 queries inside InnoDB, 0 queries in queue
2 read views open inside InnoDB
Main thread process no. 7503, id 140316711446272, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 160338394
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 1495933.31 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

"পুরো ডাটাবেস" কেন লক করা হয়েছে তা নির্ণয় করতে সহায়তা করতে দয়া করে শো ফুল প্রসেসলিস্ট (সম্ভবত স্যানিটাইজড) এবং শোধ ইঞ্জিন ইননোডব পরিস্থিতি পোস্ট করুন।
অ্যারন ব্রাউন

ধন্যবাদ, অনুরোধ করা তথ্য দিয়ে আমি প্রশ্নটি আপডেট করেছি।
থমাস

1
যদি অন্য কোনও জিজ্ঞাসা চলমান না থাকে, তবে পুরো ডাটাবেসটি লক রয়েছে এমন কোনও প্রমাণ নেই। দীর্ঘস্থায়ী ক্যোয়ারী যখন অন্যদের বাইরে লুকিয়ে রেখেছিল তখন আপনি কি এই অবস্থার পুনরুত্পাদন করতে এবং পোস্ট করতে পারেন?
ব্যারন শোয়ার্জ

ঠিক আছে, আমি এটি পরীক্ষা করে দেখেছি বৃহত্তর ক্যোয়ারী চলমান থাকা সত্ত্বেও, মাইএসকিএল কনসোলে অন্যান্য প্রশ্নগুলি করা সম্ভব। যাইহোক, পিএইপিপিএমএডমিন এমনকি লগইন প্রচেষ্টা সহজ করার জন্য এমনকি কোয়েরিটি কার্যকর করা হচ্ছে এমন সময় মোটেও সাড়া দিচ্ছে না। মৃত্যুদন্ড কার্যকর করার সময় নিজেই প্রায়শই 10 সেকেন্ডেরও কম হয়, তবে ক্যোয়ারী কয়েক মিনিটের জন্য "ডেটা প্রেরণ" অবস্থায় থাকে।
টমাস

উত্তর:


10

আপনি এটি অবাক করে দেখতে পারেন, তবে আপনার ইন্নাডব_থ্রেড_কন্ট্রেন্সি 0 তে নির্ধারণ করা উচিত (যা অসীম সম্মতি)। এটি ইনোডিবি স্টোরেজ ইঞ্জিনকে কতটা সম্মতিযুক্ত টিকিট ইস্যু করবে তা সিদ্ধান্ত নিতে দেয়।

আমি মে 26, 2011-এ ইনোডিবি'র মাল্টিকোর এনগেজমেন্ট (মাইএসকিউএল 5.5, মাইএসকিউএল 5.1.38 ইনোডিবি প্লাগইন) সম্পর্কে একটি পোস্ট লিখেছি

মাইএসকিউএল ডকুমেন্টেশন অনুসারে, থ্রেড_কোঙ্ক্রেন্সি ভেরিয়েবলটি কেবল সোলারিসের জন্য কাজ করে

আমার আরও একটি উদ্বেগ রয়েছে: আপনার জয়নগুলি কি মাইআইএসএএম এবং ইনোডিবি একসাথে জড়িত? মাইআইএসএএম এর পূর্ণ-টেবিল লক করা আচরণ ইনোডিবি'র সারি-স্তরের লকিং এবং এমভিসিসি বাতিল করে

যদি আপনি মাইএসকিউএল 5.5 ব্যবহার না করে থাকেন তবে দয়া করে ইনোডিবি'র মাল্টিকোর সংযুক্তি বিকল্পগুলি সেটআপ করতে ASAP আপগ্রেড করুন

আপডেট 2012-03-19 08:30 ইডিটি

মাইএসকিউএল 5.1.38 দিয়ে শুরু করে আপনি মাল্টিকোর ব্যস্ততার জন্য নতুন সেটিংস ব্যবহার করতে InnoDB প্লাগইন ইনস্টল করতে পারেন। তবে আপনাকে সেটিংসটি সঠিকভাবে টিউন করতে হবে।

আসলে, অরক্ষিত বাম


আপনাকে অনেক ধন্যবাদ. আপনার উত্তরটি কি বোঝায় যে একাধিক কোর ব্যবহার 5.1.X সংস্করণে প্রয়োগ করা হয়নি?
থমাস

হ্যা এবং না. আমি বলছি হ্যাঁ ইনোডিবি 5.1.x কে ছাড়ার পরে মাল্টিকোর সেটিংস নেই। আমি বলছি আপনি এই নতুন সেটিংসের জন্য InnoDB প্লাগইন ইনস্টল করতে পারবেন না তবে এটি কেবল মাইএসকিউএল 5.1.38 এবং তারপরের জন্য উপলব্ধ।
রোল্যান্ডোমাইএসকিউএলডিবিএ 12

@ রোল্যান্ডোমাইএসকিউএলডিবিএ: দুঃখিত, আমি জানি এই পোস্টটি পুরানো, তবে আমি দেখতে পেলাম যে আমার সার্ভারে মাইএসকিএল (যার 24 টি কোর রয়েছে) কেবল 1 টি কোর ব্যবহার করছে। innodb_thread_cuncurrencyআপনার উল্লেখ অনুসারে আমি যাচাই করেছি এবং এটি 0 তে সেট করা আছে, তাই আমি ভাবছিলাম কেন মাইএসকিএল বেশি কোর ব্যবহার করে না?
মনমোনা

1
@ মোমনোমনা এটিই কেবল খেলতে হবে না। আপনাকে অবশ্যই ইনোডাব_ড্রেড_ও_থ্রেড এবং ইনোডাব_রাইট_আইও_থ্রেড আরও উচ্চতর সেট করতে হবে (8, 16, 32 এবং 64 চেষ্টা করুন)।
RolandoMySQLDBA

@ মোমনোনা দয়া করে আমার পুরাতন পোস্টটি ডিবিএস্ট্যাকেক্সেঞ্জিং
কোয়েশনস

2

মাইএসকিউএল, যে কোনও সংস্করণ, একক সংযোগে একাধিক কোর ব্যবহার করার জন্য কোনও কোড নেই ।

পারকোনা তার এক্সট্রাডবিতে একাধিক সংযোগ জুড়ে একাধিক কোর ব্যবহারের জন্য আরও ভাল কাজ করে । ইনোডিবি প্রায় 8 কোরে বাষ্পের বাইরে চলে গেছে; এক্সট্রাডব 32 বা ততোধিক স্থানে ফ্ল্যাট আপ করে।

একটি "বৃহত ক্যোয়ারী" সারণীটি লক করা হতে পারে (বা টেবিলের সারিগুলি) যা অন্য কোনও সংযোগের প্রয়োজন। আসুন কোয়েরিটি এবং শো তৈরি টেবিলটি দেখুন at

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.