SysBench का उपयोग करके MySQL और MariaDB के प्रदर्शन को बेंचमार्क कैसे करें

SysBench क्या है? यदि आप नियमित रूप से MySQL के साथ काम करते हैं, तो आपने शायद इसके बारे में सुना होगा। SysBench लंबे समय से MySQL इकोसिस्टम में है। यह मूल रूप से पीटर जैतसेव द्वारा 2004 में लिखा गया था। इसका उद्देश्य MySQL के सिंथेटिक बेंचमार्क और उस पर चलने वाले हार्डवेयर को चलाने के लिए एक उपकरण प्रदान करना था। इसे CPU, मेमोरी और I/O परीक्षण चलाने के लिए डिज़ाइन किया गया था। इसमें एक MySQL डेटाबेस पर OLTP वर्कलोड निष्पादित करने का विकल्प भी था। OLTP का अर्थ ऑनलाइन लेनदेन प्रसंस्करण, ई-कॉमर्स, ऑर्डर प्रविष्टि या वित्तीय लेनदेन प्रणाली जैसे ऑनलाइन अनुप्रयोगों के लिए विशिष्ट कार्यभार है।

इस ब्लॉग पोस्ट में, हम SQL बेंचमार्क सुविधा पर ध्यान केंद्रित करेंगे लेकिन ध्यान रखें कि हार्डवेयर बेंचमार्क डेटाबेस सर्वर पर समस्याओं की पहचान करने में भी बहुत उपयोगी हो सकते हैं। उदाहरण के लिए, I/O बेंचमार्क का उद्देश्य InnoDB I/O वर्कलोड का अनुकरण करना था, जबकि CPU परीक्षणों में म्यूटेक्स विवादों के परीक्षण के साथ-साथ अत्यधिक समवर्ती, बहु-ट्रेडेड वातावरण का अनुकरण शामिल होता है - कुछ ऐसा जो डेटाबेस प्रकार के वर्कलोड जैसा भी होता है।

SysBench इतिहास और वास्तुकला

जैसा कि उल्लेख किया गया है, SysBench मूल रूप से 2004 में पीटर ज़ैतसेव द्वारा बनाया गया था। इसके तुरंत बाद, एलेक्सी कोपितोव ने इसके विकास को संभाला। यह संस्करण 0.4.12 पर पहुंच गया और विकास रुक गया। एक लंबे ब्रेक के बाद एलेक्सी ने 2016 में फिर से SysBench पर काम करना शुरू किया। जल्द ही संस्करण 0.5 को OLTP बेंचमार्क के साथ LUA-आधारित स्क्रिप्ट का उपयोग करने के लिए फिर से लिखा गया है। फिर, 2017 में, SysBench 1.0 जारी किया गया। यह पुराने, 0.4.12 संस्करण की तुलना में दिन और रात जैसा था। सबसे पहले और सबसे महत्वपूर्ण, हार्डकोडेड स्क्रिप्ट के बजाय, अब हमारे पास LUA का उपयोग करके बेंचमार्क को अनुकूलित करने की क्षमता है। उदाहरण के लिए, Percona ने TPCC जैसा बेंचमार्क बनाया जिसे SysBench का उपयोग करके निष्पादित किया जा सकता है। आइए वर्तमान SysBench आर्किटेक्चर पर एक नज़र डालें।

SysBench एक C बाइनरी है जो बेंचमार्क निष्पादित करने के लिए LUA स्क्रिप्ट का उपयोग करता है। उन लिपियों को यह करना होगा:

कमांड लाइन पैरामीटर से इनपुट हैंडल करें
उन सभी तरीकों को परिभाषित करें जिनका उपयोग बेंचमार्क द्वारा किया जाना चाहिए (तैयार करें, चलाएं, सफाई करें)
सारा डेटा तैयार करें
परिभाषित करें कि बेंचमार्क कैसे क्रियान्वित किया जाएगा (क्वेरी कैसी दिखेगी आदि)

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

SysBench क्यों?

SysBench के लोकप्रिय होने का मुख्य कारण यह है कि इसका उपयोग करना आसान है। पूर्व ज्ञान के बिना कोई व्यक्ति मिनटों में इसका उपयोग करना शुरू कर सकता है। यह डिफ़ॉल्ट रूप से, बेंचमार्क भी प्रदान करता है जो अधिकांश मामलों को कवर करता है - OLTP वर्कलोड, रीड-ओनली या रीड-राइट, प्राइमरी की लुकअप और प्राइमरी की अपडेट। वह सब जो MySQL 8.0 तक, MySQL के लिए अधिकांश समस्याओं का कारण बना। यह भी एक कारण था कि SysBench इंटरनेट पर प्रकाशित विभिन्न बेंचमार्क और तुलनाओं में इतना लोकप्रिय था। उन पोस्ट ने इस टूल को बढ़ावा देने में मदद की और इसे MySQL के लिए सिंथेटिक बेंचमार्क में शामिल किया।

SysBench के बारे में एक और अच्छी बात यह है कि, संस्करण 0.5 और LUA के समावेश के बाद से, कोई भी किसी भी प्रकार का बेंचमार्क तैयार कर सकता है। हमने पहले ही टीपीसीसी जैसे बेंचमार्क का उल्लेख किया है लेकिन कोई भी कुछ ऐसा तैयार कर सकता है जो उसके उत्पादन कार्यभार के समान हो। हम यह नहीं कह रहे हैं कि यह आसान है, यह सबसे अधिक समय लेने वाली प्रक्रिया होगी, लेकिन यदि आपको एक कस्टम बेंचमार्क तैयार करने की आवश्यकता है तो यह क्षमता होना फायदेमंद है।

सिंथेटिक बेंचमार्क होने के नाते, SysBench एक ऐसा टूल नहीं है जिसका उपयोग आप अपने MySQL सर्वर के कॉन्फ़िगरेशन को ट्यून करने के लिए कर सकते हैं (जब तक कि आप कस्टम वर्कलोड के साथ LUA स्क्रिप्ट तैयार नहीं करते हैं या आपका वर्कलोड बेंचमार्क वर्कलोड के समान होता है जो SysBench के साथ आता है)। विभिन्न हार्डवेयर के प्रदर्शन की तुलना करना इसके लिए बहुत अच्छा है। आप आसानी से अपने क्लाउड प्रदाता द्वारा पेश किए गए विभिन्न प्रकार के नोड्स और उनके द्वारा प्रदान किए जाने वाले अधिकतम क्यूपीएस (क्वेरी प्रति सेकंड) के प्रदर्शन की तुलना आसानी से कर सकते हैं। उस मीट्रिक को जानने और दिए गए नोड के लिए आप क्या भुगतान करते हैं, यह जानने के बाद, आप और भी महत्वपूर्ण मीट्रिक - QP$ (प्रति डॉलर क्वेरी) की गणना कर सकते हैं। यह आपको यह पहचानने की अनुमति देगा कि लागत-कुशल वातावरण का निर्माण करते समय किस प्रकार के नोड का उपयोग करना है। बेशक, SysBench का उपयोग किसी दिए गए डिज़ाइन की प्रारंभिक ट्यूनिंग और व्यवहार्यता का आकलन करने के लिए भी किया जा सकता है। मान लें कि हम दुनिया भर में फैले गैलेरा क्लस्टर का निर्माण करते हैं - उत्तरी अमेरिका, यूरोपीय संघ, एशिया। ऐसा सेटअप हैंडल प्रति सेकंड कितने इंसर्ट कर सकता है? प्रतिबद्ध विलंबता क्या होगी? क्या अवधारणा का सबूत करने का कोई मतलब है या हो सकता है कि नेटवर्क विलंबता इतनी अधिक हो कि एक साधारण कार्यभार भी काम नहीं करता जैसा आप उम्मीद करेंगे।

तनाव-परीक्षण के बारे में क्या? हर कोई क्लाउड पर नहीं गया है, अभी भी ऐसी कंपनियां हैं जो अपना बुनियादी ढांचा बनाना पसंद करती हैं। अधिग्रहीत प्रत्येक नए सर्वर को वार्म-अप अवधि से गुजरना चाहिए, जिसके दौरान आप संभावित हार्डवेयर दोषों को इंगित करने के लिए उस पर जोर देंगे। ऐसे में SysBench भी मदद कर सकता है। या तो OLTP वर्कलोड निष्पादित करके जो सर्वर को ओवरलोड करता है, या आप CPU, डिस्क और मेमोरी के लिए समर्पित बेंचमार्क का भी उपयोग कर सकते हैं।

जैसा कि आप देख सकते हैं, ऐसे कई मामले हैं जिनमें एक साधारण, सिंथेटिक बेंचमार्क भी बहुत उपयोगी हो सकता है। अगले पैराग्राफ में हम देखेंगे कि हम SysBench के साथ क्या कर सकते हैं।

SysBench आपके लिए क्या कर सकता है?

आप कौन से परीक्षण चला सकते हैं?

जैसा कि शुरुआत में उल्लेख किया गया है, हम OLTP बेंचमार्क पर ध्यान केंद्रित करेंगे और एक अनुस्मारक के रूप में हम दोहराएंगे कि SysBench का उपयोग I / O, CPU और मेमोरी परीक्षण करने के लिए भी किया जा सकता है। आइए एक नज़र डालते हैं उन बेंचमार्क पर जो SysBench 1.0 के साथ आता है (हमने इस सूची से कुछ सहायक LUA फ़ाइलें और गैर-डेटाबेस LUA स्क्रिप्ट हटा दी हैं)।

-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.lua

आइए एक-एक करके उनके बारे में जानें।

सबसे पहले, बल्क_इन्सर्ट.लुआ। इस परीक्षण का उपयोग बहु-पंक्ति सम्मिलन करने के लिए MySQL की क्षमता को बेंचमार्क करने के लिए किया जा सकता है। यह जाँच करते समय काफी उपयोगी हो सकता है, उदाहरण के लिए, प्रतिकृति या गैलेरा क्लस्टर का प्रदर्शन। पहले मामले में, यह आपको एक प्रश्न का उत्तर देने में मदद कर सकता है:"प्रतिकृति अंतराल शुरू होने से पहले मैं कितनी तेजी से सम्मिलित कर सकता हूं?"। बाद के मामले में, यह आपको बताएगा कि वर्तमान नेटवर्क विलंबता को देखते हुए गैलेरा क्लस्टर में कितनी तेजी से डेटा डाला जा सकता है।

सभी oltp_* स्क्रिप्ट एक सामान्य तालिका संरचना साझा करते हैं। उनमें से पहले दो (oltp_delete.lua और oltp_insert.lua) एकल DELETE और INSERT कथन निष्पादित करते हैं। दोबारा, यह प्रतिकृति या गैलेरा क्लस्टर के लिए एक परीक्षण हो सकता है - इसे सीमा तक धक्का दें और देखें कि यह कितनी मात्रा में डालने या शुद्ध करने में सक्षम है। हमारे पास विशेष कार्यक्षमता पर केंद्रित अन्य बेंचमार्क भी हैं - oltp_point_select, oltp_update_index और oltp_update_non_index। ये प्रश्नों का एक सबसेट निष्पादित करेंगे - प्राथमिक कुंजी-आधारित चयन, अनुक्रमणिका-आधारित अद्यतन और गैर-सूचकांक-आधारित अद्यतन। यदि आप इनमें से कुछ कार्यात्मकताओं का परीक्षण करना चाहते हैं, तो परीक्षण हैं। हमारे पास अधिक जटिल बेंचमार्क भी हैं जो OLTP वर्कलोड पर आधारित हैं:oltp_read_only, oltp_read_write और oltp_write_only। आप या तो केवल-पढ़ने के लिए वर्कलोड चला सकते हैं, जिसमें विभिन्न प्रकार के SELECT क्वेरीज़ शामिल होंगे, आप केवल राइट्स (DELETE, INSERT और UPDATE का मिश्रण) चला सकते हैं या आप उन दोनों का मिश्रण चला सकते हैं। अंत में, select_random_points और select_random_ranges का उपयोग करके आप IN() सूची में यादृच्छिक बिंदुओं का उपयोग करके या BETWEEN का उपयोग करके यादृच्छिक श्रेणियों का उपयोग करके कुछ यादृच्छिक चयन चला सकते हैं।

आप बेंचमार्क कैसे कॉन्फ़िगर कर सकते हैं?

क्या महत्वपूर्ण है, बेंचमार्क कॉन्फ़िगर करने योग्य हैं - आप एक ही बेंचमार्क का उपयोग करके विभिन्न वर्कलोड पैटर्न चला सकते हैं। आइए निष्पादित करने के लिए दो सबसे सामान्य बेंचमार्क देखें। हम OLTP read_only और OLTP read_write बेंचमार्क के बारे में गहराई से जानेंगे। सबसे पहले, SysBench के पास कुछ सामान्य कॉन्फ़िगरेशन विकल्प हैं। हम यहां केवल सबसे महत्वपूर्ण चर्चा करेंगे, आप उन सभी को चलाकर देख सकते हैं:

sysbench --help

आइए उन पर एक नजर डालते हैं।

  --threads=N                     number of threads to use [1]

आप परिभाषित कर सकते हैं कि आप SysBench को किस प्रकार की समवर्ती बनाना चाहते हैं। MySQL, प्रत्येक सॉफ़्टवेयर के रूप में, कुछ मापनीयता सीमाएँ हैं और इसका प्रदर्शन समवर्ती के कुछ स्तर पर चरम पर होगा। यह सेटिंग किसी दिए गए कार्यभार के लिए अलग-अलग समरूपताओं को अनुकरण करने में मदद करती है और यह जांचती है कि क्या यह पहले से ही मधुर स्थान को पार कर चुका है।

  --events=N                      limit for total number of events [0]
  --time=N                        limit for total execution time in seconds [10]

वे दो सेटिंग्स नियंत्रित करती हैं कि SysBench को कितने समय तक चलते रहना चाहिए। यह या तो कुछ प्रश्नों को निष्पादित कर सकता है या यह पूर्वनिर्धारित समय तक चलता रह सकता है।

  --warmup-time=N                 execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]

यह स्व-व्याख्यात्मक है। SysBench परीक्षणों से सांख्यिकीय परिणाम उत्पन्न करता है और यदि MySQL ठंडे राज्य में है तो वे परिणाम प्रभावित हो सकते हैं। वार्मअप एक पूर्वनिर्धारित समय के लिए बेंचमार्क निष्पादित करके "नियमित" थ्रूपुट की पहचान करने में मदद करता है, जिससे कैशे, बफर पूल आदि को गर्म किया जा सकता है।

  --rate=N                        average transactions rate. 0 for unlimited rate [0]

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

  --report-interval=N             periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]

डिफ़ॉल्ट रूप से SysBench अपना रन पूरा करने के बाद एक रिपोर्ट तैयार करता है और बेंचमार्क के चलने के दौरान कोई प्रगति रिपोर्ट नहीं की जाती है। इस विकल्प का उपयोग करके आप SysBench को और अधिक वर्बोज़ बना सकते हैं जबकि बेंचमार्क अभी भी चल रहा है।

  --rand-type=STRING   random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]

SysBench आपको विभिन्न प्रकार के डेटा वितरण उत्पन्न करने की क्षमता देता है। उन सभी के अपने-अपने उद्देश्य हो सकते हैं। डिफ़ॉल्ट विकल्प, 'विशेष', डेटा में कई (यह विन्यास योग्य) हॉट-स्पॉट को परिभाषित करता है, कुछ ऐसा जो वेब अनुप्रयोगों में काफी सामान्य है। यदि आपका डेटा भिन्न तरीके से व्यवहार करता है, तो आप अन्य वितरणों का भी उपयोग कर सकते हैं। यहां एक अलग विकल्प बनाकर आप अपने डेटाबेस के तनावग्रस्त होने के तरीके को भी बदल सकते हैं। उदाहरण के लिए, एकसमान वितरण, जहां सभी पंक्तियों तक पहुँचने की समान संभावना है, बहुत अधिक मेमोरी-इंटेंसिव ऑपरेशन है। यह सभी डेटा को संग्रहीत करने के लिए अधिक बफर पूल का उपयोग करेगा और यदि आपका डेटा सेट मेमोरी में फिट नहीं होगा तो यह बहुत अधिक डिस्क-गहन होगा। दूसरी ओर, कुछ हॉट-स्पॉट के साथ विशेष वितरण डिस्क पर कम तनाव डालेगा क्योंकि बफर पूल में गर्म पंक्तियों को रखने की संभावना अधिक होती है और डिस्क पर संग्रहीत पंक्तियों तक पहुंच की संभावना बहुत कम होती है। कुछ डेटा वितरण प्रकारों के लिए, SysBench आपको अधिक बदलाव देता है। आपको यह जानकारी 'sysbench --help' आउटपुट में मिल सकती है।

  --db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]

इस सेटिंग का उपयोग करके आप तय कर सकते हैं कि SysBench को तैयार बयानों का उपयोग करना चाहिए (जब तक वे दिए गए डेटास्टोर में उपलब्ध हैं - MySQL के लिए इसका मतलब है कि PS डिफ़ॉल्ट रूप से सक्षम होगा) या नहीं। प्रॉक्सीएसक्यूएल या मैक्सस्केल जैसे प्रॉक्सी के साथ काम करते समय इससे फर्क पड़ सकता है - उन्हें तैयार किए गए बयानों को एक विशेष तरीके से मानना चाहिए और उन सभी को एक होस्ट पर भेज दिया जाना चाहिए जिससे प्रॉक्सी की मापनीयता का परीक्षण करना असंभव हो।

सामान्य कॉन्फ़िगरेशन विकल्पों के अतिरिक्त, प्रत्येक परीक्षण का अपना कॉन्फ़िगरेशन हो सकता है। आप चलकर जांच सकते हैं कि क्या संभव है:

[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua  help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)

oltp_read_only.lua options:
  --distinct_ranges=N           Number of SELECT DISTINCT queries per transaction [1]
  --sum_ranges=N                Number of SELECT SUM() queries per transaction [1]
  --skip_trx[=on|off]           Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
  --secondary[=on|off]          Use a secondary index in place of the PRIMARY KEY [off]
  --create_secondary[=on|off]   Create a secondary index in addition to the PRIMARY KEY [on]
  --index_updates=N             Number of UPDATE index queries per transaction [1]
  --range_size=N                Range size for range SELECT queries [100]
  --auto_inc[=on|off]           Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
  --delete_inserts=N            Number of DELETE/INSERT combinations per transaction [1]
  --tables=N                    Number of tables [1]
  --mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
  --non_index_updates=N         Number of UPDATE non-index queries per transaction [1]
  --table_size=N                Number of rows per table [10000]
  --pgsql_variant=STRING        Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
  --simple_ranges=N             Number of simple range SELECT queries per transaction [1]
  --order_ranges=N              Number of SELECT ORDER BY queries per transaction [1]
  --range_selects[=on|off]      Enable/disable all range SELECT queries [on]
  --point_selects=N             Number of point SELECT queries per transaction [10]

फिर से, हम यहां से सबसे महत्वपूर्ण विकल्पों पर चर्चा करेंगे। सबसे पहले, आपके पास इस बात का नियंत्रण है कि लेनदेन वास्तव में कैसा दिखेगा। आम तौर पर, इसमें विभिन्न प्रकार के प्रश्न होते हैं - INSERT, DELETE, विभिन्न प्रकार के चयन (बिंदु लुकअप, श्रेणी, एकत्रीकरण) और अद्यतन (अनुक्रमित, गैर-अनुक्रमित)। चरों का उपयोग करना जैसे:

  --distinct_ranges=N           Number of SELECT DISTINCT queries per transaction [1]
  --sum_ranges=N                Number of SELECT SUM() queries per transaction [1]
  --index_updates=N             Number of UPDATE index queries per transaction [1]
  --delete_inserts=N            Number of DELETE/INSERT combinations per transaction [1]
  --non_index_updates=N         Number of UPDATE non-index queries per transaction [1]
  --simple_ranges=N             Number of simple range SELECT queries per transaction [1]
  --order_ranges=N              Number of SELECT ORDER BY queries per transaction [1]
  --point_selects=N             Number of point SELECT queries per transaction [10]
  --range_selects[=on|off]      Enable/disable all range SELECT queries [on]

आप परिभाषित कर सकते हैं कि लेन-देन कैसा दिखना चाहिए। जैसा कि आप डिफ़ॉल्ट मानों को देखकर देख सकते हैं, अधिकांश प्रश्न चयन हैं - मुख्य रूप से बिंदु चयन लेकिन विभिन्न प्रकार के श्रेणी चयन भी (आप उन सभी को रेंज_सेलेक्ट को बंद करके अक्षम कर सकते हैं)। आप अद्यतनों की संख्या या INSERT/DELETE प्रश्नों को बढ़ाकर कार्यभार को अधिक लेखन-भारी कार्यभार की ओर मोड़ सकते हैं। सेकेंडरी इंडेक्स, ऑटो इंक्रीमेंट, लेकिन डेटा सेट साइज (टेबल की संख्या और उनमें से प्रत्येक को कितनी पंक्तियों में होना चाहिए) से संबंधित सेटिंग्स को ट्विक करना भी संभव है। इससे आप अपने कार्यभार को अच्छी तरह से अनुकूलित कर सकते हैं।

  --skip_trx[=on|off]           Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]

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

  --mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]

यह सेटिंग आपको MySQL से त्रुटि कोड निर्दिष्ट करने की अनुमति देती है जिसे SysBench को अनदेखा करना चाहिए (और कनेक्शन को नहीं मारना चाहिए)। उदाहरण के लिए, त्रुटियों को अनदेखा करने के लिए जैसे:त्रुटि 1062 (कुंजी 'प्राथमिक' के लिए डुप्लिकेट प्रविष्टि '6') आपको यह त्रुटि कोड पास करना चाहिए:--mysql-ignore-errors=1062

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

उदाहरण

इस खंड में हम कुछ उदाहरणों से गुजरेंगे कि SysBench का क्या उपयोग किया जा सकता है। जैसा कि पहले उल्लेख किया गया है, हम दो सबसे लोकप्रिय बेंचमार्क पर ध्यान केंद्रित करेंगे - OLTP रीड ओनली और OLTP रीड/राइट। कभी-कभी अन्य बेंचमार्क का उपयोग करना समझ में आता है, लेकिन कम से कम हम आपको यह दिखाने में सक्षम होंगे कि उन दोनों को कैसे अनुकूलित किया जा सकता है।

प्राथमिक कुंजी लुकअप

सबसे पहले हमें यह तय करना होगा कि हम कौन सा बेंचमार्क चलाएंगे, रीड-ओनली या रीड-राइट। तकनीकी रूप से बोलने से कोई फर्क नहीं पड़ता क्योंकि हम R/W बेंचमार्क से राइट्स हटा सकते हैं। आइए केवल पढ़ने के लिए एक पर ध्यान दें।

पहले चरण के रूप में, हमें एक डेटा सेट तैयार करना होगा। हमें यह तय करना होगा कि यह कितना बड़ा होना चाहिए। इस विशेष बेंचमार्क के लिए, डिफ़ॉल्ट सेटिंग्स का उपयोग करके (इसलिए, सेकेंडरी इंडेक्स बनाए जाते हैं), 1 मिलियन पंक्तियों के परिणामस्वरूप ~ 240 एमबी डेटा होगा। दस टेबल, 1000 000 पंक्तियाँ प्रत्येक 2.4GB के बराबर:

[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G    /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun  1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun  1 12:10 ..
-rw-r----- 1 mysql mysql   65 Jun  1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun  1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun  1 12:12 sbtest9.ibd

इससे आपको अंदाजा हो जाएगा कि आपको कितनी टेबल चाहिए और कितनी बड़ी होनी चाहिए। मान लीजिए कि हम इन-मेमोरी वर्कलोड का परीक्षण करना चाहते हैं, इसलिए हम टेबल बनाना चाहते हैं जो इनो डीबी बफर पूल में फिट होंगे। दूसरी ओर, हम यह भी सुनिश्चित करना चाहते हैं कि एक अड़चन न बनने के लिए पर्याप्त तालिकाएँ हैं (या, तालिकाओं की मात्रा आपके उत्पादन सेटअप में आपकी अपेक्षा से मेल खाती है)। आइए अपना डेटासेट तैयार करें। कृपया ध्यान रखें कि, डिफ़ॉल्ट रूप से, SysBench 'sbtest' स्कीमा की तलाश करता है जो आपके द्वारा डेटा सेट तैयार करने से पहले मौजूद होना चाहिए। आपको इसे मैन्युअल रूप से बनाना पड़ सकता है।

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)

Initializing worker threads...

Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...

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

sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 run

हमने यहाँ क्या किया? हमने थ्रेड्स की संख्या 16 पर सेट की। हमने तय किया कि हम चाहते हैं कि हमारा बेंचमार्क 300 सेकंड तक चले, बिना निष्पादित प्रश्नों की सीमा के। हमने डेटाबेस से कनेक्टिविटी, तालिकाओं की संख्या और उनके आकार को परिभाषित किया है। हमने सभी श्रेणी के चयनों को भी अक्षम कर दिया है, हमने तैयार किए गए बयानों को भी अक्षम कर दिया है। अंत में, हम रिपोर्ट अंतराल को एक सेकंड पर सेट करते हैं। नमूना आउटपुट इस तरह दिख सकता है:

[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00

हर सेकंड हम कार्यभार के आँकड़ों का एक स्नैपशॉट देखते हैं। यह ट्रैक और प्लॉट करने के लिए काफी उपयोगी है - अंतिम रिपोर्ट आपको केवल औसत देगी। इंटरमीडिएट के परिणाम दूसरे आधार पर प्रदर्शन को ट्रैक करना संभव बना देंगे। अंतिम रिपोर्ट नीचे की तरह दिख सकती है:

SQL statistics:
    queries performed:
        read:                            614660
        write:                           0
        other:                           122932
        total:                           737592
    transactions:                        61466  (204.84 per sec.)
    queries:                             737592 (2458.08 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

Throughput:
    events/s (eps):                      204.8403
    time elapsed:                        300.0679s
    total number of events:              61466

Latency (ms):
         min:                                   24.91
         avg:                                   78.10
         max:                                  331.91
         95th percentile:                      137.35
         sum:                              4800234.60

Threads fairness:
    events (avg/stddev):           3841.6250/20.87
    execution time (avg/stddev):   300.0147/0.02

आपको यहां निष्पादित प्रश्नों और अन्य (BEGIN/COMMIT) कथनों के बारे में जानकारी मिलेगी। आप सीखेंगे कि कितने लेन-देन निष्पादित किए गए, कितनी त्रुटियां हुईं, थ्रूपुट क्या था और कुल बीता हुआ समय क्या था। आप विलंबता मीट्रिक और थ्रेड में क्वेरी वितरण भी देख सकते हैं।

यदि हम विलंबता वितरण में रुचि रखते हैं, तो हम SysBench को '--हिस्टोग्राम' तर्क भी दे सकते हैं। इसके परिणामस्वरूप नीचे जैसा अतिरिक्त आउटपुट मिलता है:

Latency histogram (values are in milliseconds)
       value  ------------- distribution ------------- count
      29.194 |******                                   1
      30.815 |******                                   1
      31.945 |***********                              2
      33.718 |******                                   1
      34.954 |***********                              2
      35.589 |******                                   1
      37.565 |***********************                  4
      38.247 |******                                   1
      38.942 |******                                   1
      39.650 |***********                              2
      40.370 |***********                              2
      41.104 |*****************                        3
      41.851 |*****************************            5
      42.611 |*****************                        3
      43.385 |*****************                        3
      44.173 |***********                              2
      44.976 |**************************************** 7
      45.793 |***********************                  4
      46.625 |***********                              2
      47.472 |*****************************            5
      48.335 |**************************************** 7
      49.213 |***********                              2
      50.107 |**********************************       6
      51.018 |***********************                  4
      51.945 |**************************************** 7
      52.889 |*****************                        3
      53.850 |*****************                        3
      54.828 |***********************                  4
      55.824 |***********                              2
      57.871 |***********                              2
      58.923 |***********                              2
      59.993 |******                                   1
      61.083 |******                                   1
      63.323 |***********                              2
      66.838 |******                                   1
      71.830 |******                                   1

एक बार जब हम अपने परिणामों के साथ अच्छे होते हैं, तो हम डेटा को साफ कर सकते हैं:

sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanup

लेखन-भारी ट्रैफ़िक

आइए यहां कल्पना करें कि हम एक लेखन-भारी (लेकिन केवल-लिखने के लिए नहीं) कार्यभार निष्पादित करना चाहते हैं, उदाहरण के लिए, I/O सबसिस्टम के प्रदर्शन का परीक्षण करें। सबसे पहले, हमें यह तय करना होगा कि डेटासेट कितना बड़ा होना चाहिए। हम ~ 48GB डेटा (प्रत्येक 20 टेबल, 10 000 000 पंक्तियाँ) मानेंगे। हमें इसे तैयार करने की जरूरत है। इस बार हम रीड-राइट बेंचमार्क का उपयोग करेंगे।

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepare

एक बार यह हो जाने के बाद, हम क्वेरी मिक्स में और अधिक लिखने के लिए बाध्य करने के लिए डिफ़ॉल्ट को बदल सकते हैं:

[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 run

जैसा कि आप मध्यवर्ती परिणामों से देख सकते हैं, लेन-देन अब एक भारी पक्ष पर हैं:

[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00

परिणामों को समझना

जैसा कि हमने ऊपर दिखाया, SysBench एक बेहतरीन टूल है जो MySQL या MariaDB के कुछ प्रदर्शन मुद्दों को इंगित करने में मदद कर सकता है। इसका उपयोग आपके डेटाबेस कॉन्फ़िगरेशन की प्रारंभिक ट्यूनिंग के लिए भी किया जा सकता है। बेशक, आपको यह ध्यान रखना होगा कि, अपने बेंचमार्क से सर्वोत्तम प्राप्त करने के लिए, आपको यह समझना होगा कि परिणाम उनके जैसे क्यों दिखते हैं। इसके लिए मॉनिटरिंग टूल का उपयोग करके MySQL आंतरिक मेट्रिक्स में अंतर्दृष्टि की आवश्यकता होगी, उदाहरण के लिए, ClusterControl। यह याद रखना काफी महत्वपूर्ण है - यदि आप यह नहीं समझते हैं कि प्रदर्शन ऐसा क्यों था, तो आप बेंचमार्क से गलत निष्कर्ष निकाल सकते हैं। हमेशा एक अड़चन होती है, और SysBench प्रदर्शन के मुद्दों को उठाने में मदद कर सकता है, जिसे आपको तब पहचानना होगा।