पिनबा के साथ PHP कोड प्रदर्शन की निगरानी करना

आइए एक विशिष्ट स्टार्टअप की कल्पना करें, लोकप्रियता प्राप्त करना, उदाहरण के लिए, PHP या पायथन। सबसे पहले सब कुछ एक सर्वर पर है - PHP (या पायथन), Apache, MySQL। फिर आप MySQL को एक अलग सर्वर पर ले जाते हैं, सामग्री वितरित करने के लिए nginx स्थापित करते हैं, शायद कैशिंग और कुछ अन्य एप्लिकेशन एप्लिकेशन के लिए मेमेकैच्ड जोड़ते हैं ...

समय के साथ, सर्वरों की संख्या बढ़ती जाएगी, और जितनी जल्दी या बाद में आप सोच रहे होंगे
"अब सिस्टम के साथ क्या हो रहा है?" यह या उस स्क्रिप्ट को कितनी बार निष्पादित किया गया है और कब तक? संचालन में सबसे अधिक समय लगता है? ”ज़ैबिक्स-प्रकार की निगरानी प्रणाली आवेदन की स्थिति का केवल एक सामान्य, सतही चित्र प्रदान करती है।

इन सवालों के जवाब पाने के लिए, Badba ने एक वास्तविक समय की निगरानी और सांख्यिकी सेवा - Pinba विकसित की है । इस लेख में हम अपने सिस्टम की निगरानी और रूपरेखा के लिए इसका उपयोग करने के अपने अनुभव के बारे में बात करेंगे।

Badoo के बारे में कुछ शब्द

कार्य के कठिनाई स्तर का आकलन करने के लिए, हम कुछ शब्दों में बताएंगे कि लिटर क्या है। आज, हमारे पास 2 डेटा सेंटर हैं, एक अमेरिका में और एक यूरोप में। सैकड़ों PHP-सर्वर, MySQL- सर्वर, दर्जनों मेमकास्टेड और C / C ++ में लिखी गई "स्व-लिखित" सेवाएं डेटा केंद्रों में स्थापित हैं। Badoo के अपने उपप्रोजेक्ट हैं (उदाहरण के लिए, एक वेबसाइट, मोबाइल उपकरणों और डेस्कटॉप के लिए अनुप्रयोग), लोड के कार्यान्वयन और प्रकृति जिस पर बहुत भिन्नता है। एक PHP अनुरोध में, दर्जनों विभिन्न डेटा स्रोतों (डेटाबेस, कैश, सेवा) के साथ बातचीत हो सकती है। यह प्रदर्शन के लिए बुरा है, लेकिन व्यावसायिक कार्यों को हल करने के लिए आवश्यक है। और इसके अलावा, हम एक सप्ताह में 2 से 5 बार एक नया कोड पोस्ट करते हैं। ऐसी प्रणाली के प्रदर्शन की निगरानी करना कोई आसान काम नहीं है। पिनबा ने PHP स्क्रिप्ट के प्रदर्शन की निगरानी से संबंधित समस्याओं की एक बड़ी परत को हल करने में मदद की। यह सेवा सभी संसाधित PHP अनुरोधों के बारे में जानकारी एकत्र करती है और इस डेटा पर विस्तृत रिपोर्ट तैयार करती है।

यह कैसे काम करता है

पिनाबा के साथ काम करना शुरू करने के बारे में हबराब्र में पहले से ही एक लेख था: " पिनबा - वास्तविक समय में php की निगरानी करें ।" इसमें, लेखक ने वर्णित किया कि पिनाबा को कैसे स्थापित और कॉन्फ़िगर किया जाए, इसलिए अब हम अधिक दिलचस्प चीजों पर ध्यान केंद्रित करेंगे: यह कैसे काम करता है और क्या जानकारी प्राप्त की जा सकती है।

पिनबा के साथ काम करने की सामान्य योजना को आरेख में दिखाया गया है:



पिनबा में एक PHP मॉड्यूल (अंग्रेजी PHP एक्सटेंशन ) और एक सर्वर होता है। पिनबा मॉड्यूल स्वचालित रूप से सर्वर को सभी संसाधित अनुरोधों के बारे में डेटा भेजता है। पिनबा सर्वर C में लिखी गई एक सेवा है:

• यूडीपी के माध्यम से संसाधित अनुरोधों पर डेटा एकत्र करता है;
• यह सारा डेटा मेमोरी में स्टोर करता है और उस पर रिपोर्ट बनाता है;
• MySQL प्रोटोकॉल का उपयोग करके कच्चे डेटा और रिपोर्ट तक पहुंच प्रदान करता है, अर्थात यह वास्तव में एक MySQL इंजन है।

वर्तमान में सिस्टम के साथ क्या हो रहा है, यह जानने के लिए, बस किसी भी MySQL क्लाइंट के साथ सर्वर से कनेक्ट करें और रिपोर्ट टेबल से कुछ क्वेरी करें। उदाहरण के लिए, आप प्रत्येक PHP स्क्रिप्ट के लिए अनुरोधों पर आंकड़े देख सकते हैं (पिनबा में सबसे अधिक उपयोग की जाने वाली रिपोर्ट में से एक):

mysql> SELECT * FROM report_by_script_name; 

नीचे हम अधिक विस्तार से वर्णन करते हैं कि पिनबा में रिपोर्ट के साथ कैसे काम किया जाए।

पिनबा के लिए PHP मॉड्यूल कैसे काम करता है

यहां तक ​​कि पिनबा सेवा के पहले संस्करण के नियोजन चरण में, PHP कोड में बदलाव किए बिना सामान्य आंकड़ों के संग्रह को व्यवस्थित करने का विचार तुरंत दिखाई दिया। जिन लोगों के पास PHP मॉड्यूल लिखने का अनुभव है, वे जानते हैं कि बाद वाले के पास प्रत्येक अनुरोध (चरण PHP_RINIT) से पहले और इसे संसाधित करने के बाद (चरण PHP_RSHUTDOWN) संसाधित करने की क्षमता है। उदाहरण के लिए, PHP_RINIT चरण में, एक मॉड्यूल अपने आंतरिक संसाधनों को शुरू कर सकता है, और RSHUTDOWN में यह उन्हें मुक्त कर सकता है। पिनबा के लिए PHP मॉड्यूल इन दोनों चरणों का उपयोग करता है। RINIT में, यह आरंभीट में आरंभीकृत किया गया है, यह गणना करता है कि अनुरोध को संसाधित करने में कितने संसाधन खर्च किए गए थे, और फिर सभी डेटा को यूडीपी पैकेट द्वारा पिनबा सर्वर को भेजा जाता है।

सी के लिए एक यूडीपी पैकेट भेजना काफी तेज है, इसलिए पिनबा मॉड्यूल PHP प्रक्रिया में अतिरिक्त भार नहीं जोड़ता है। और इस तथ्य के कारण कि पिनबा एक मॉड्यूल के रूप में काम करता है, इसे स्थापित करने और कॉन्फ़िगर करने के लिए पर्याप्त है, और तुरंत, PHP कोड में बदलाव किए बिना, आप अपने सिस्टम के ऐसे मापदंडों का पता लगाने में सक्षम होंगे, क्योंकि प्रत्येक स्क्रिप्ट के लिए अनुरोधों की संख्या, औसत समय। और भी बहुत कुछ।

दुर्भाग्य से, यदि आपके पास एक जटिल प्रणाली है, तो सामान्य पैरामीटर पर्याप्त नहीं होंगे।

टाइमर

प्रारंभ में, पिनबा के पहले संस्करण में कोई टाइमर नहीं थे (चलो इसे पिनबा v0.1 कहते हैं)। यह संस्करण हमें बता सकता है कि किसी विशेष स्क्रिप्ट को कितनी बार कहा जाता है, औसत प्रतिक्रिया समय क्या है, बाइट्स में औसत प्रतिक्रिया आकार क्या है, और पसंद है। MySQL, memcached, या अन्य सेवाओं के लिए प्रश्नों की आवृत्ति का पता लगाना असंभव था। यह आपके लिए बहुत महत्वपूर्ण नहीं लग सकता है, लेकिन हमारे सिस्टम में, MySQL और मेमकास्ट के अलावा, C / C ++ में दर्जन भर अलग-अलग सेवाएँ लिखी गई हैं।

यदि सिस्टम में कोई समस्या दिखाई दी (उदाहरण के लिए, कुछ "धीमा" होने लगा), तो पिनबा v0.1 ने हमें दिखाया कि कोई समस्या थी, लेकिन वास्तव में यह समझना संभव नहीं था कि वास्तव में यह क्या था। सबसे अधिक बार, ऐसी स्थितियों में, उन सेवाओं में से एक, जिनके लिए PHP ने प्रश्न किए थे (MySQL, memcached, और अन्य) दोषी थे।

इस तरह के समस्या क्षेत्रों को जल्दी से जानने के लिए सीखने के लिए, पिनबा के अगले संस्करण में टाइमर पेश किए गए थे।

वास्तव में, हमने mysql_connect / mysql_query / memcache_connect कॉल्स आदि के ऑपरेटिंग समय को मापने का फैसला किया, इस समय को पिनबा सर्वर को भेजें और टाइमर रिपोर्ट बनाएं। छद्म-PHP कोड पर, यह कुछ इस तरह दिखता है:

 pinba_timer_start(array('type'=>'db::connect', 'host'=>'users.sql')); $conn = mysql_connect(...); pinba_timer_stop(); 

यहां हम mysql_connect कॉल के रनिंग समय को मापते हैं और टाइमर को 2 टैग संलग्न करते हैं, जिसके द्वारा हम बाद में रिपोर्ट बना सकते हैं।

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

तालिकाओं के साथ शुरुआत करना

यहां उन तालिकाओं की सूची दी गई है, जिन्हें पिनबा निम्नलिखित के लिए उपयोग करता है:

 mysql> SHOW TABLES FROM pinba; +--------------------------------------+ | Tables_in_pinba | +--------------------------------------+ | info | | report_by_hostname | | report_by_hostname_and_script | | report_by_hostname_and_server | | report_by_hostname_server_and_script | | report_by_script_name | | report_by_server_and_script | | report_by_server_name | | report_by_status | | request | | tag | | timer | | timertag | +--------------------------------------+ 13 rows in set (0.00 sec) 

परंपरागत रूप से, सभी तालिकाओं को 2 प्रकारों में विभाजित किया जा सकता है: कच्चे डेटा और रिपोर्ट वाली तालिकाएं।
कच्चे डेटा के साथ 4 टेबल हैं: अनुरोध, टैग, टाइमर, टाइमटेग। इन तालिकाओं में स्क्रिप्ट, टाइमर और अंतिम कुछ मिनटों में प्रत्येक कॉल का रिकॉर्ड होता है। अत्यधिक भरी हुई प्रणालियों में, इन तालिकाओं में लाखों रिकॉर्ड हो सकते हैं, इसलिए हम उन्हें सीधे उपयोग करने की अनुशंसा नहीं करते हैं। इसके बजाय, रिपोर्ट तालिकाओं का उपयोग करना बेहतर होता है जिसमें सिस्टम प्रदर्शन का विश्लेषण करने के लिए पर्याप्त उपयोगी डेटा होता है।

टेबल्स की रिपोर्ट करें

Report_by_script_name - सबसे अधिक उपयोग की जाने वाली रिपोर्ट में से एक; प्रत्येक स्क्रिप्ट को कितनी बार कॉल किया गया, इसके निष्पादन के लिए औसत समय, इसके सीपीयू उपयोग, इसके कारण ट्रैफ़िक की मात्रा के बारे में जानकारी शामिल है।

 mysql> DESC report_by_script_name; +------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+--------------+------+-----+---------+-------+ | req_count | int(11) | YES | | NULL | | | req_per_sec | float | YES | | NULL | | | req_time_total | float | YES | | NULL | | | req_time_percent | float | YES | | NULL | | | req_time_per_sec | float | YES | | NULL | | | ru_utime_total | float | YES | | NULL | | | ru_utime_percent | float | YES | | NULL | | | ru_utime_per_sec | float | YES | | NULL | | | ru_stime_total | float | YES | | NULL | | | ru_stime_percent | float | YES | | NULL | | | ru_stime_per_sec | float | YES | | NULL | | | traffic_total | float | YES | | NULL | | | traffic_percent | float | YES | | NULL | | | traffic_per_sec | float | YES | | NULL | | | script_name | varchar(128) | YES | | NULL | | +------------------+--------------+------+-----+---------+-------+ 15 rows in set (0.00 sec) 

प्रत्यय के साथ फ़ील्ड _total अंतिम 5 मिनट में सभी अनुरोधों के लिए संबंधित मानों का योग है। यही है, उदाहरण के लिए, req_time_total पिछले 5 मिनट में संबंधित स्क्रिप्ट के लिए सभी अनुरोधों के निष्पादन समय का योग है। और req_time_total / req_count स्क्रिप्ट का औसत निष्पादन समय है। Req_utime_ * और req_stime_ * फ़ील्ड क्रमशः उपयोगकर्ता मोड और सिस्टम मोड में CPU उपयोग को इंगित करते हैं।

हमारी कंपनी में, इन आंकड़ों के अनुसार, हम एक विशेष स्क्रिप्ट और स्क्रिप्ट द्वारा सीपीयू खपत के ग्राफ के लिए अनुरोधों की संख्या का ग्राफ बनाते हैं (रेखांकन 1, 2):

चार्ट 1।


चार्ट 2।


Report_by_hostname : यह रिपोर्ट बताती है कि किसी विशिष्ट सर्वर पर कितने अनुरोध हैं। इसमें लगभग समान फ़ील्ड्स की सूची है, लेकिन script_name फ़ील्ड के बजाय तालिका में होस्टनाम फ़ील्ड है।

 mysql> DESC report_by_hostname; +------------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+-------------+------+-----+---------+-------+ | req_count | int(11) | YES | | NULL | | ......... | hostname | varchar(32) | YES | | NULL | | +------------------+-------------+------+-----+---------+-------+ 15 rows in set (0.00 sec) 

कुछ को शायद होस्टनाम वैरिएबल में होस्ट हेडर में पारित डोमेन देखने की उम्मीद है। लेकिन वास्तव में होस्टनाम चर $ _ENV ['HOSTNAME'] की सामग्री है और इसमें मशीन का नाम शामिल है।

इस रिपोर्ट का मुख्य सार किसी विशिष्ट सर्वर के लिए अनुरोधों की संख्या के बारे में जानकारी प्राप्त करना है और क्या पड़ोसी लोगों की तुलना में कुछ सर्वरों के लिए अधिक अनुरोध हैं।

Report_by_server_name : इस रिपोर्ट में, डेटा को उस डोमेन द्वारा समूहीकृत किया जाता है जिसके लिए अनुरोध आया था। यह किसी विशेष डोमेन में जाने वाले अनुरोधों की संख्या दर्शाता है। तालिका संरचना पिछले दो के समान है, केवल डेटा अब server_name फ़ील्ड द्वारा समूहीकृत है।

Report_by_status : इस रिपोर्ट का उपयोग उन HTTP स्थितियों को देखने के लिए किया जाता है जिनके साथ हमारी स्क्रिप्ट समाप्त होती है:

 mysql> SELECT req_count, status FROM report_by_status; +-----------+--------+ | req_count | status | +-----------+--------+ | 540622 | 200 | | 2578 | 301 | | 21955 | 302 | | 296 | 403 | | 2090 | 404 | +-----------+--------+ 5 rows in set (0.14 sec) 

यदि रिपोर्ट में 500 की स्थिति है, तो इसका मतलब है कि कहीं न कहीं हमारे पास PHP कोड में "घातक त्रुटि" है।

टाइमर और टैग

ऊपर चर्चा की गई रिपोर्ट सामान्य प्रणाली विश्लेषण के लिए उपयोगी हैं। लेकिन अधिक विस्तृत विश्लेषण के लिए, हम टाइमर और टैग का उपयोग करते हैं।

एक टाइमर कोड के एक टुकड़े का निष्पादन समय है। आप एक टाइमर में कई टैग संलग्न कर सकते हैं। एक टैग में एक कुंजी और एक मूल्य होता है। उदाहरण के लिए, ऊपर दिखाए गए टाइमर कोड में,

 pinba_timer_start(array('group'=>'db::connect', 'host'=>'users.sql')); $conn = mysql_connect(...); pinba_timer_stop(); 

हम mysql_connect फ़ंक्शन के निष्पादन समय को मापते हैं और 2 टैग - समूह और होस्ट संलग्न करते हैं।

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

सबसे पहले, हम विभिन्न डेटा स्रोतों के अनुरोधों पर आंकड़े प्राप्त करने के लिए टाइमर का उपयोग करते हैं: MySQL, मेमकाटेड, सी / सी ++ में लिखी गई सेवाएं। हम दो टैग्स के साथ पिनबा टाइमर के साथ ऐसे सभी अनुरोधों को "लिपटे" करते हैं: समूह और मेजबान (होस्ट डेटाबेस या सेवा का पता है, समूह सेवा पर संचालन है)।

इसलिए, यदि हमने अपने सिस्टम में एक टैग लागू किया है, जो पिनबा को भेजा जाता है, तो हम कई रिपोर्ट बना सकते हैं। सबसे पहले, यह सभी टैग मूल्यों पर एक पूरी रिपोर्ट होगी। समूह टैग के साथ हमारे उदाहरण में, हम इस पर एक रिपोर्ट बना सकते हैं कि यह या उस ऑपरेशन को कितनी बार कहा जाता है और कुल कितना समय लगता है। ऐसा करने के लिए, एक तालिका बनाएं:

 CREATE TABLE `tag_info_group` ( `tag_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag_info:group' 

तालिका का नाम मनमाना है और कुछ भी प्रभावित नहीं करता है। यह महत्वपूर्ण है कि फील्ड ऑर्डर बिल्कुल उसी तरह है जैसे उदाहरण में, साथ ही इंजन और COMMENT = 'tag_info: group' के लिए मान। टिप्पणी में, समूह उस टैग का नाम है जिसके द्वारा हम रिपोर्ट बनाते हैं। और tag_info एक प्रकार की रिपोर्ट है (इसमें tag_report भी है, जिसके बारे में नीचे चर्चा की जाएगी)।

तालिका बनाने के बाद, पिनबा स्वचालित रूप से वहां डेटा दर्ज करना शुरू कर देगा। यह रिपोर्ट कुछ इस तरह दिखाई देगी:

 mysql> SELECT * FROM tag_info_group ORDER BY timer_value; +--------------------+-----------+-------------+-----------+-------------+-------------+ | tag_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +--------------------+-----------+-------------+-----------+-------------+-------------+ | curl_request | 56216 | 281.08 | 56710 | 283.55 | 11977.3 | | memcache_get | 2563499 | 12817.5 | 11462991 | 57315 | 6823.04 | | hsc_connect | 2319186 | 11595.9 | 2870366 | 14351.8 | 6140.5 | | hsc_open_index | 2319158 | 11595.8 | 3285335 | 16426.7 | 5805.61 | | hsc_select | 2312567 | 11562.8 | 3158465 | 15792.3 | 5778.57 | | memcache_connect | 2563064 | 12815.3 | 4007451 | 20037.3 | 2389.65 | | memcache_set | 917102 | 4585.51 | 1616016 | 8080.08 | 1059.08 | | memcache_delete | 600720 | 3003.6 | 2451872 | 12259.4 | 785.702 | | scribe_receive | 382881 | 1914.41 | 975892 | 4879.46 | 382.522 | | hsc_update | 84877 | 424.385 | 85287 | 426.435 | 317.637 | | hsc_insert | 41564 | 207.82 | 41574 | 207.87 | 280.468 | | scribe_send | 382894 | 1914.47 | 975892 | 4879.46 | 174.156 | | memcache_increment | 60817 | 304.085 | 88734 | 443.67 | 30.9102 | | memcache_add | 14818 | 74.09 | 16281 | 81.405 | 4.71686 | | memcache_multi_get | 2543 | 12.715 | 2543 | 12.715 | 1.59621 | | hsc_delete | 4 | 0.02 | 9 | 0.045 | 0.003373 | +--------------------+-----------+-------------+-----------+-------------+-------------+ 16 rows in set (0.00 sec) 

उदाहरण के लिए, यह रिपोर्ट बताती है कि हमारे पास कुछ बहुत ही धीमी गति से कर्ल_रेक्वेस्ट हैं ।

Tag_info प्रकार की रिपोर्ट सिस्टम में इसके उपयोग की एक सामान्य तस्वीर देती है। अधिक विस्तार से अध्ययन करने के लिए जहां कुछ संचालन कहा जाता है, आपको उसी रिपोर्ट का निर्माण करने की आवश्यकता है, लेकिन स्क्रिप्ट के नाम से समूहीकरण के साथ। ऐसा करने के लिए, Pinba में एक तालिका बनाएं:

 CREATE TABLE `tag_report_group` ( `script_name` varchar(128) DEFAULT NULL, `tag_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag_report:group' 

तालिका संरचना कई तरह से पिछली टैग_इनफ्रेम_ग्रुप रिपोर्ट के समान है। कृपया ध्यान दें कि script_name फ़ील्ड दिखाई दी , और COMMENT फ़ील्ड में हमने tag_report प्रकार की रिपोर्ट बनाई। इस तालिका से हम पिछले एक से सभी डेटा प्राप्त कर सकते हैं, लेकिन script_name द्वारा समूहीकृत है।

आप देख सकते हैं कि किसी विशेष स्क्रिप्ट में कौन से ऑपरेशन किए जाते हैं:

 mysql> SELECT tag_value, req_count, hit_count, timer_value, hit_count/req_count FROM tag_report_group WHERE script_name='/admin/messages/all.phtml' ORDER BY timer_value DESC; +--------------------+-----------+-----------+-------------+---------------------+ | tag_value | req_count | hit_count | timer_value | hit_count/req_count | +--------------------+-----------+-----------+-------------+---------------------+ | memcache_get | 107439 | 3227537 | 1060.68 | 30.0406 | | memcache_connect | 107439 | 887789 | 270.919 | 8.2632 | | scribe_receive | 107573 | 283478 | 68.9106 | 2.6352 | | memcache_set | 34339 | 153080 | 50.6079 | 4.4579 | | scribe_send | 107573 | 283478 | 39.7583 | 2.6352 | | memcache_delete | 18236 | 21306 | 4.54436 | 1.1683 | | curl_request | 15 | 15 | 0.514396 | 1.0000 | | memcache_decrement | 1250 | 1250 | 0.251141 | 1.0000 | | memcache_multi_get | 125 | 125 | 0.066473 | 1.0000 | | memcache_increment | 2 | 2 | 0.000336 | 1.0000 | +--------------------+-----------+-----------+-------------+---------------------+ 10 rows in set (0.03 sec) 

यह उदाहरण Hit_count और req_count फ़ील्ड्स के बीच अंतर दिखाता है। Req_count HTTP अनुरोधों की संख्या है जिसके दौरान निर्दिष्ट tag_value के साथ टाइमर को कम से कम एक बार कहा जाता था। Hit_count - निर्दिष्ट tag_value के साथ टाइमर को कितनी बार कहा गया।

ऊपर दिए गए उदाहरण से पता चलता है कि हमारी स्क्रिप्ट /admin/messages/all.phtml, memcache_get को 30 बार कॉल किया जाता है। सबसे अधिक संभावना है कि यह एक प्रोग्रामर त्रुटि है, और पृष्ठ को अनुकूलित करने की आवश्यकता है।

यदि आपके पास बहुत सारे डेटाबेस सर्वर, मेमकाटेड और अन्य सेवाएं हैं, तो ऐसे मामले हो सकते हैं जब केवल एक सर्वर "धीमा" होता है। और सामान्य पृष्ठभूमि के खिलाफ इसका "निषेध" स्पष्ट नहीं हो सकता है। इन उद्देश्यों के लिए, हमने सर्वर नामक एक और टैग बनाया। इसके लिए, आप एक सामान्य रिपोर्ट tag_info: सर्वर बना सकते हैं और प्रत्येक होस्ट के लिए सामान्य आँकड़े देख सकते हैं। मेमकेड किए गए आंकड़ों के लिए नमूना डेटा यहां दिया गया है:

 mysql> SELECT * FROM tag_info_server WHERE tag_value LIKE 'memcache%' ORDER BY timer_value; +------------------+-----------+-------------+-----------+-------------+-------------+ | tag_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +------------------+-----------+-------------+-----------+-------------+-------------+ | memcached7.mlan | 350702 | 1753.51 | 1767513 | 8837.57 | 781.644 | | memcached3.mlan | 336217 | 1681.08 | 1734430 | 8672.15 | 871.633 | | memcached1.mlan | 350082 | 1750.41 | 1823910 | 9119.55 | 883.52 | | memcached8.mlan | 357798 | 1788.99 | 1793808 | 8969.04 | 908.848 | | memcached10.mlan | 343287 | 1716.44 | 1757085 | 8785.42 | 909.042 | | memcached5.mlan | 398042 | 1990.21 | 1861729 | 9308.64 | 914.772 | | memcached4.mlan | 401584 | 2007.92 | 1877775 | 9388.88 | 937.53 | | memcached2.mlan | 459912 | 2299.56 | 2028406 | 10142 | 971.189 | | memcached6.mlan | 399768 | 1998.84 | 1912571 | 9562.86 | 975.094 | | memcached9.mlan | 425276 | 2126.38 | 1939575 | 9697.88 | 1008.29 | +------------------+-----------+-------------+-----------+-------------+-------------+ 10 rows in set (0.00 sec) 

होस्ट टैग के लिए सामान्य रिपोर्ट पर्याप्त जानकारीपूर्ण नहीं है। यह एक या किसी अन्य होस्ट के साथ टाइमर कॉल करने की आवृत्ति को दर्शाता है, लेकिन प्रदर्शन किए गए कार्यों की जानकारी के बिना। सौभाग्य से, Pinba 2 टैग के समूह के साथ tag_info और tag_report जैसी रिपोर्ट बना सकता है:

 CREATE TABLE `tag_info_group_server` ( `group_value` varchar(64) DEFAULT NULL, `server_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag2_info:group,server' 

यह रिपोर्ट आपको प्रत्येक होस्ट के संचालन के आंकड़े प्राप्त करने की अनुमति देती है। उदाहरण के लिए, आप किसी विशिष्ट होस्ट पर परिचालनों के आँकड़े देख सकते हैं:

 mysql> SELECT * FROM tag_info_group_server WHERE server_value = 'dbs101.mlan' ORDER BY timer_value; +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ | group_value | server_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ | db::replace | dbs101.mlan | 154 | 0.77 | 154 | 0.77 | 0.257526 | | db::delete | dbs101.mlan | 1340 | 6.7 | 1340 | 6.7 | 1.84398 | | db::begin | dbs101.mlan | 6437 | 32.185 | 6589 | 32.945 | 2.96375 | | db::commit | dbs101.mlan | 6437 | 32.185 | 6589 | 32.945 | 3.04067 | | db::insert | dbs101.mlan | 4674 | 23.37 | 11171 | 55.855 | 13.9457 | | db::update | dbs101.mlan | 6358 | 31.79 | 10399 | 51.995 | 18.197 | | db::connect | dbs101.mlan | 16826 | 84.13 | 16826 | 84.13 | 22.1383 | | db::select | dbs101.mlan | 14372 | 71.86 | 47106 | 235.53 | 180.235 | +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ 8 rows in set (0.01 sec) 

स्पष्ट कारणों के लिए, यह सही है कि ज्यादातर समय पर कब्जा है।

इसके अलावा, उदाहरण के लिए, आप अलग-अलग मेजबानों पर एक ही ऑपरेशन के आंकड़ों की तुलना कर सकते हैं। Memcache_connect के लिए उदाहरण:

 mysql> SELECT server_value, req_count, hit_count, timer_value FROM tag_info_group_server WHERE group_value='memcache_connect' ORDER BY timer_value; +------------------+-----------+-----------+-------------+ | server_value | req_count | hit_count | timer_value | +------------------+-----------+-----------+-------------+ | memcached1.mlan | 366138 | 365061 | 191.808 | | memcached3.mlan | 354688 | 353760 | 192.184 | | memcached10.mlan | 365358 | 364341 | 197.353 | | memcached8.mlan | 368912 | 367839 | 213.768 | | memcached7.mlan | 374160 | 373152 | 215.914 | | memcached5.mlan | 415444 | 414434 | 217.855 | | memcached4.mlan | 423394 | 422242 | 252.416 | | memcached2.mlan | 478949 | 477641 | 272.346 | | memcached6.mlan | 414088 | 413003 | 279.038 | | memcached9.mlan | 441589 | 440481 | 377.952 | +------------------+-----------+-----------+-------------+ 10 rows in set (0.01 sec) 

आप tag2_report प्रकार की रिपोर्ट भी बना सकते हैं, जिसमें 2 टैग्स की जानकारी स्क्रिप्ट द्वारा टूट जाती है:

 CREATE TABLE `tag_report_group_server` ( `sc0ript_name` varchar(128) DEFAULT NULL, `tag1_value` varchar(64) DEFAULT NULL, `tag2_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag2_report:group,server' 

हम एक उदाहरण देते हैं जहां यह तालिका उपयोगी हो सकती है। हमारे सिस्टम में, सभी उपयोगकर्ताओं को सैकड़ों MySQL सर्वरों के बीच वितरित किया जाता है। इसे शेरिंग कहा जाता है। विशिष्ट कार्यों के लिए कुछ निश्चित केंद्रीय MySQL सर्वर भी हैं। सिद्धांत रूप में, सभी वेब स्क्रिप्ट को केवल "शार्क" को क्वेरी करना चाहिए और केंद्रीय डेटाबेस को क्वेरी नहीं करना चाहिए। हमारे "शार्क" का होस्टनाम dbs * या dbb * से शुरू होता है। यदि आप ऐसी स्क्रिप्ट्स की जांच कर सकते हैं जो इस अनुरोध का उपयोग करके अन्य MySQL सर्वर से कनेक्शन बनाती हैं:

 mysql> SELECT * FROM tag_report_group_server WHERE tag1_value='db::connect' AND tag2_value NOT LIKE 'dbs%' AND tag2_value NOT LIKE 'dbb%'; 

यह दिखाएगा कि कौन सी स्क्रिप्ट केंद्रीय डेटाबेस पर प्रश्न बनाती है।

नग्नेक्स + पिनबा

लेकिन यह सब भी हमारे लिए पर्याप्त नहीं था। जब क्लाइंट हमें एक HTTP अनुरोध भेजता है, तो बाद वाला पहले nginx में जाता है और फिर PHP में प्रॉक्सी करता है। यदि इस समय PHP प्रक्रिया स्वीकार नहीं करती है और अनुरोध को संसाधित नहीं करता है तो क्या होगा? उदाहरण के लिए, यदि सर्वर ओवरलोड है, या नेटवर्क समस्याओं के कारण, nginx php-fpm प्रक्रिया से संपर्क नहीं कर पाएगा? इस मामले में, उपयोगकर्ता को एक त्रुटि दिखाई देगी, लेकिन हम इसके बारे में PHP में नहीं जान पाएंगे (हालांकि यह नगनेक्स लॉग्स में होगा)।

इस बात का अंदाजा लगाने के लिए कि हम क्लाइंट को कौन सी प्रतिक्रियाएँ (जो HTTP स्टेटस) देते हैं, पिनबा डेवलपर एंटोन डोवाल ने नगीनेक्स के लिए एक मॉड्यूल बनाया। Nginx के लिए मॉड्यूल PHP मॉड्यूल के समान ही काम करता है, लेकिन स्पष्ट कारणों से इसमें टाइमर नहीं होते हैं। वह जो सबसे उपयोगी रिपोर्ट बनाता है, वह रिपोर्ट_बी_स्क्रिप्ट_और_स्टैटस और रिपोर्ट_बीए_स्टैटस है ।

प्लॉटिंग

Pinba पिछले कुछ मिनटों के लिए डेटा संग्रहीत करता है। इस समय को सेटिंग में बदला जा सकता है। लेकिन यह पर्याप्त नहीं है यदि आप मॉनिटर करना चाहते हैं कि सिस्टम का प्रदर्शन समय के साथ कैसे बदलता है। ऐसा करने के लिए, आपको लंबे समय तक पिनबा रिपोर्ट डेटा (जरूरी नहीं कि सभी) को संग्रहीत करने और उन पर रेखांकन बनाने की आवश्यकता है। इस प्रकार, आप सिस्टम और इसकी व्यक्तिगत स्क्रिप्ट पर लोड की गतिशीलता का निरीक्षण कर सकते हैं, साथ ही साथ यह भी देख सकते हैं कि आपका PHP कोड डेटाबेस, मेमकास्ट और अन्य डेटा स्रोतों को कैसे लोड करता है।

पिनबा को पता नहीं है कि लंबी अवधि में डेटा को कैसे प्लॉट और स्टोर किया जाए। इसके लिए आपको अलग-अलग उपयोगिताओं का उपयोग करने की आवश्यकता है। आप पिनबा पर नज़र रखने और उसके कुछ मूल्यों के आधार पर ग्राफ़ बनाने के लिए ज़ैबिक्स को कॉन्फ़िगर कर सकते हैं। आप रिंग (चक्रीय) डेटाबेस जैसे RRDtool या ग्रेफाइट का उपयोग कर सकते हैं। हमारी कंपनी में हम RRDtool का उपयोग करते हैं।

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

परिणाम

पिनबा ने हमें क्या दिया? इसके क्रियान्वयन से पहले अधिकांश प्रदर्शन समस्याओं का तेजी से पता लगाया जाने लगा। यदि कोई स्क्रिप्ट उपयोगकर्ताओं द्वारा बहुत बार अनुरोध की गई है, तो इसे आसानी से पिनबा में पाया जा सकता है। यदि अचानक सेवाओं में से एक (MySQL, memcached, आदि) काम करने के लिए धीमी हो गई है, तो पिनबा में सही रिपोर्ट के साथ आप आसानी से इस सेवा को स्थानीय कर सकते हैं। और अगर यह अनुरोध की उच्च आवृत्ति के कारण "धीमा" करना शुरू कर दिया, तो पिनाबा के लिए धन्यवाद कभी-कभी उन लिपियों को स्थानीयकृत करना संभव होता है जो अक्सर एक विशिष्ट समस्या सेवा का अनुरोध करते हैं।

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

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

PHP मॉड्यूल के अलावा, Pinba किसी भी तरह से PHP से बंधा हुआ नहीं है और इसका उपयोग अन्य भाषाओं में लिखे सिस्टम की निगरानी के लिए किया जा सकता है। GitHub में पहले से ही Python और Ruby में Pinba का उपयोग करने वाले प्रोजेक्ट हैं।

मैक्सिम max_m Matyukhin, डेवलपर
badoo कंपनी

उपयोगी लिंक

• आधिकारिक पिनबा प्रोजेक्ट पेज
• Pinba Engine development list — Google- Pinba
• Pinba Engine development list (in Russian) — Google- Pinba
• Pinba — php — Pinba
• RRDtool
• Graphite
• — wikipedia.org
• Nginx module for pinba
• Python WSGI middleware for pinba