इस लेख में हम Manticore Search में क्वेरीज़ के प्रोफाइलिंग के लिए उपलब्ध उपकरणों पर चर्चा करते हैं।
SHOW META
डिफ़ॉल्ट रूप से SHOW META आदेश मिलान में उपयोग किए गए कीवर्ड के बारे में आँकड़े प्रदान करता है। प्रत्येक कीवर्ड के लिए हमें उन दस्तावेज़ों की संख्या मिलती है जिनमें कीवर्ड पाया गया था और कुल हिट्स की संख्या। उच्च मान - उदाहरण के लिए दस्तावेज़ लगभग इंडेक्स में कुल दस्तावेज़ों के उच्च के रूप में - यह संकेत कर सकते हैं कि कीवर्ड एक स्टॉपवर्ड होने के लिए एक उम्मीदवार है।
SHOW META आउटपुट को
-cpustats –iostats
के साथ सर्चडी डेमॉन शुरू करके समृद्ध किया जा सकता है। यह क्वेरी को निष्पादित करने के लिए आवश्यक IO और CPU प्रयास के बारे में क्वेरी मैट्रिक्स को इकट्ठा करने की अनुमति देता है।
mysql> SELECT * FROM myindex WHERE MATCH('search engine*');SHOW META;
....
+-----------------------+---------+
| Variable_name | Value |
+-----------------------+---------+
| total | 1000 |
| total_found | 3994 |
| time | 0.090 |
| cpu_time | 42.950 |
| agents_cpu_time | 0.000 |
| io_read_time | 82.276 |
| io_read_ops | 1633 |
| io_read_kbytes | 1264.5 |
| io_write_time | 0.000 |
| io_write_ops | 0 |
| io_write_kbytes | 0.0 |
| agent_io_read_time | 0.000 |
| agent_io_read_ops | 0 |
| agent_io_read_kbytes | 0.0 |
| agent_io_write_time | 0.000 |
| agent_io_write_ops | 0 |
| agent_io_write_kbytes | 0.0 |
| keyword[0] | engine* |
| docs[0] | 55037 |
| hits[0] | 135095 |
| keyword[1] | search |
| docs[1] | 32768 |
| hits[1] | 53800 |
+-----------------------+---------+
23 rows in set (0.00 sec)
iostats हमें बता देते हैं कि डिस्क से कितनी डेटा पढ़ी गई थी, कितने I/O ऑप बनाए गए और समय कितना व्यतीत हुआ। बड़ा io डेटा पढ़े जाने का मतलब है कि क्वेरी में बहुत सारे हिट वाले कीवर्ड हैं जिन्हें रैंकिंग स्कोर बनाने के लिए पढ़ा जाना आवश्यक है। यदि डेटा बड़ा नहीं है, लेकिन हम उच्च समय का अनुभव कर रहे हैं, तो हमारा संग्रहण धीमा या अधिभारित हो सकता है। यह उच्च ट्रैफ़िक के कारण हो सकता है, लेकिन यह यह भी संकेत दे सकता है कि संग्रहण में एक समस्या है जिसे जांचना आवश्यक है।
cpustats प्रोसेसिंग करने के लिए उपयोग किए गए CPU समय प्रदान करता है। यदि iostats कम हैं और cpu उच्च है, तो हमारी क्वेरी CPU बाउंड पर पहुँच रही है। सामान्यत: CPU बाउंड को इंडेक्स को कई शार्ड में विभाजित करके और dist_threads > 0 का उपयोग करके स्थानीय क्लस्टर खोज करने से हल किया जाता है। लंबे CPU समय यह भी सूचित कर सकते हैं कि सर्वर अधिभारित हो रहा है। उच्च CPU समय व्यतीत होने के विभिन्न कारण हो सकते हैं, एक सामान्य कारण वाइल्डकार्ड खोजों के मामले में विस्तार के कारण होता है (डिफ़ॉल्ट dict=keywords के साथ)।
agent_ मैट्रिक्स में मान होते हैं यदि इंडेक्स एक वितरित हो और यह मास्टर इंडेक्स और इसके नोड्स के बीच कितनी डेटा पढ़ी/लिखी गई है, यह प्रदान करता है।
SHOW PROFILE
प्रोफाइलिंग को प्रति सत्र
SET
PROFILING=1 (या HTTP API के मामले में profile:true सेट करके) सक्षम किया जा सकता है।
SHOW PROFILE
को क्वेरी के तुरंत बाद चलाना चाहिए। यह नेत्रण के विभिन्न चरणों में व्यतीत समय प्रदान करता है। स्विचेस कॉलम तार्किक इंजन स्थिति स्विचों की संख्या प्रदान करता है (OS स्तर के संदर्भ स्विच नहीं)। चरण समय यह समझने में मदद कर सकते हैं कि क्वेरी धीमी क्यों है। नीचे दिए गए उदाहरण में, पढ़ाई की_ * चरणों पर बहुत अधिक समय व्यतीत होता है क्योंकि क्वेरी ठीक उस समय निष्पादित की गई थी जब इंडेक्स लोड किया गया था, इसलिए इसे डिस्क से पढ़ाई करनी होती है। दूरस्थ नोड्स के साथ वितरित इंडेक्स की प्रोफाइलिंग करने से एजेंट से कनेक्ट होने और दूरस्थ परिणामों के लिए प्रतीक्षा समय के लिए चरण जोड़े जाएंगे।
mysql> SHOW PROFILE;
+--------------+----------+----------+---------+
| Status | Duration | Switches | Percent |
+--------------+----------+----------+---------+
| unknown | 0.000827 | 4 | 0.91 |
| local_search | 0.000011 | 1 | 0.01 |
| sql_parse | 0.000019 | 1 | 0.02 |
| dict_setup | 0.000001 | 1 | 0.00 |
| parse | 0.000029 | 1 | 0.03 |
| transforms | 0.000104 | 1 | 0.11 |
| init | 0.000668 | 1169 | 0.73 |
| read_docs | 0.069948 | 1348 | 76.58 |
| read_hits | 0.012602 | 285 | 13.80 |
| get_docs | 0.004021 | 804 | 4.40 |
| get_hits | 0.002276 | 704 | 2.49 |
| filter | 0.000069 | 258 | 0.08 |
| rank | 0.000252 | 791 | 0.28 |
| sort | 0.000266 | 8 | 0.29 |
| finalize | 0.000234 | 1 | 0.26 |
| aggregate | 0.000014 | 2 | 0.02 |
| eval_post | 0.000000 | 1 | 0.00 |
| total | 0.091341 | 5380 | 0 |
+--------------+----------+----------+---------+
18 rows in set (0.00 sec)
SHOW PLAN
SHOW PLAN दिखाता है कि पूर्ण टेक्स्ट मिलान का मूल्यांकन किए गए क्वेरी पेड़ कैसा है। यह समझने में सहायक है कि कैसे इनपुट खोज को रूपांतरित और निष्पादित किया जाता है। कीवर्ड को उनके क्वेरी में स्थिति के साथ दिखाया जाता है और यदि वे वाइल्डकार्ड शब्द से आने वाले विस्तारित कीवर्ड हैं। वाइल्डकार्ड के साथ खोजों के मामले में, आदेश उपयोगी है क्योंकि हम विस्तार की पूरी सूची देख सकते हैं।
mysql> SHOW PLAN\G
*************************** 1. row ***************************
Variable: transformed_tree
Value: AND(
AND(KEYWORD(search, querypos=1)),
OR(
OR(
AND(KEYWORD(engineer, querypos=2, expanded)),
OR(
AND(KEYWORD(engineering, querypos=2, expanded)),
OR(
AND(KEYWORD(engineers, querypos=2, expanded)),
AND(KEYWORD(engines, querypos=2, expanded)))),
AND(KEYWORD(engineered, querypos=2, expanded))),
OR(
AND(KEYWORD(engine's, querypos=2, expanded)),
OR(
AND(KEYWORD(engine_power, querypos=2, expanded)),
AND(KEYWORD(engined, querypos=2, expanded)))),
AND(KEYWORD(engine, querypos=2, expanded)),
OR(KEYWORD(engine*, querypos=2, expanded))))
1 row in set (0.00 sec)
SHOW PLAN भी प्रोफाइलिंग सक्षम करने की आवश्यकता है और इसे SHOW META से पहले चलाना चाहिए।
अंततः, सिस्टम संसाधनों की निगरानी भी की जानी चाहिए। यदि आप Manticore के अलावा अन्य सक्रिय सेवाएँ चला रहे हैं (जैसे डेटाबेस या एप्लिकेशन कोड), तो उनके प्रभाव की निगरानी की जानी चाहिए। जबकि Manticore अन्य सेवाओं के साथ रह सकता है, चूंकि यह CPU और IO दोनों के लिए गहन हो सकता है, उच्च यातायात सेटअप के लिए बेहतर है कि Manticore स्वतंत्र हो ताकि यह दूसरों द्वारा प्रभावित न हो (या प्रभावित न करे)।