🤙🏼 ✌🏿 💠 PHP को लड़ाई में स्थिर करें - वेब सर्वर क्या और क्यों गिरता है 🛏️ ☎️ ☀️

आप PHP में वेब प्रोजेक्ट की स्थिरता के लिए जिम्मेदार हैं। लोड लगातार बढ़ रहा है, सुविधाओं को जोड़ा जाता है, ग्राहक संतुष्ट होते हैं। एक ठीक दिन रहस्यमय त्रुटियां दिखाई देने लगती हैं ...

सर्वर सॉफ्टवेयर त्रुटियां

... कौन से प्रोग्रामर को पता नहीं है कि कैसे ठीक करना है, क्योंकि सर्वर सॉफ़्टवेयर "ब्रेक डाउन", उदाहरण के लिए, अपाचे-PHP का एक गुच्छा - और ग्राहक अनुरोध के जवाब में नियमित रखरखाव पर एक पृष्ठ प्राप्त करता है। वेब डेवलपर को अक्सर यूनिक्स / लिनक्स में सी प्रोग्रामिंग का गहरा ज्ञान नहीं होता है, और सिस्टम प्रशासक अक्सर, दुर्भाग्य से, सिस्टम में बैश की तुलना में अधिक गहरा गोता नहीं लगाता है। असली कट्टर :-)

सर्वर स्क्रिप्ट का अस्थिर संचालन

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

व्यवहार में, मुझे अक्सर ऐसी परियोजनाएँ आती हैं जो सर्वर सॉफ़्टवेयर त्रुटियों की एक समान श्रेणी का सामना करती हैं, और टीम को हमेशा नहीं पता होता है कि क्या करना है। अपकेशन लॉग में अक्सर सेगमेंटेशन फ़ॉल्ट संदेश दिखाई देते हैं, क्लाइंट को एक एरर पेज मिलता है, और एक वेब डेवलपर जो अपने दिमाग को रैक के साथ जोड़ते हैं, PHP / Apache / precompiler के विभिन्न संस्करणों के साथ खेलते हैं, बार-बार अलग-अलग विकल्पों के साथ स्रोत से PHP इकट्ठा करते हैं। बग के बारे में लिखें, और उन्हें यह साबित किया जाता है कि ये PHP बग नहीं हैं, लेकिन उनके कोड, और इसी तरह अनन्तता ...

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

हम वेब सर्वर त्रुटि लॉग में देखते हैं

यदि आप अपाचे त्रुटि लॉग में कुछ इस तरह से देखते हैं, तो लेख आपके लिए है:

[Mon Oct 01 12:32:09 2012] [notice] child pid 27120 exit signal Segmentation fault (11)

इस मामले में, PHP त्रुटि लॉग में विस्तृत जानकारी देखने के लिए बेकार है - क्योंकि प्रक्रिया ही दुर्घटनाग्रस्त हो गई, स्क्रिप्ट नहीं। यदि आप पहले से नग्नेक्स पर नियमित रखरखाव पर एक अच्छा पृष्ठ नहीं बनाते हैं, तो क्लाइंट को तपस्वी त्रुटि "50 *" दिखाई देगी।

मैं किसी को चेहरे पर देना चाहता हूं, लेकिन किसको? :-) विनाशकारी निर्णयों से ध्यान हटाने के लिए, हम सिद्धांत को याद करते हैं।

एक संकेत क्या है? यह, आप कह सकते हैं, वह उपकरण है जो ऑपरेटिंग सिस्टम प्रक्रिया को यह बताने के लिए उपयोग करता है कि यह, उदाहरण के लिए, गलत है :-) यह लेता है और, गणित के नियमों का उल्लंघन करते हुए, 0 ... या मजबूर कार्यों द्वारा एक स्टैक अतिप्रवाह का कारण बनता है। इस मामले में, हम 11 नंबर और "SIGSEGV" नाम के साथ एक संकेत देखते हैं। "किल-एल" निष्पादित करके संकेतों की सूची देखी जा सकती है:

...
11) SIGSEGV
...

कुछ संकेत, उदाहरण के लिए, SIGSEGV को इंटरसेप्ट नहीं किया जा सकता है, इसलिए आपकी अपाचे-पीएचपी प्रक्रिया निर्दयतापूर्वक ट्रायल के बिना कर्नेल द्वारा मार दी जाएगी। यह उसे अवरोधन करने के लिए ठीक निकलता है - यह संभव है, लेकिन आपको स्रोत में चढ़ने की आवश्यकता है :-)

और उन्होंने उसे क्यों मारा?

अब आइए इसका कारण जानें कि अपाचे-पीएचपी प्रक्रिया क्यों मारी गई? ऐसा करने के लिए, मार :-) या coredump के समय प्रक्रिया मेमोरी के डंप को कॉन्फ़िगर करें। हां, हां - अब तक, एक अप्रचलित 50-वर्षीय शब्द का उपयोग किया गया है, जिसका अर्थ है चुंबकीय कोर से डेटा का भंडारण। जैसे ही अगली बार प्रक्रिया को ऑपरेटिंग सिस्टम द्वारा मार दिया जाता है, कर्नेल द्वारा एक फ़ाइल बनाई जाती है - जगह और उसका नाम कॉन्फ़िगर किया जा सकता है । यदि आप कंसोल में हैं, तो "मैन 5 कोर" टाइप करें।

उदाहरण के लिए, आप इस तरह से डैडी में फाइल रख सकते हैं:
इको "/tmp/httpd-core.%p"> / proc / sys / कर्नेल / core_pattern

यदि कुछ भी सेट नहीं किया गया है, तो सिस्टम प्रक्रिया की कार्यशील निर्देशिका में "core। # Process_number #" नामक एक फाइल बनाएगा।

बस सुनिश्चित करें कि Apache-PHP प्रक्रिया ने वहां अनुमतियाँ लिखी हैं।

वह सब नहीं है। डिफ़ॉल्ट रूप से, सबसे अधिक संभावना है, आपके सिस्टम पर coredump फ़ाइलों की पीढ़ी अक्षम है। आप वेब सर्वर स्टार्टअप स्क्रिप्ट के शीर्ष पर लाइन डालकर इसे सक्षम कर सकते हैं:
ulimit - unlimited
या, सेटिंग को स्थायी बनाने के लिए, फ़ाइल "/etc/security/limits.conf" संपादित करें। आप वहां सम्मिलित कर सकते हैं:

apache - core -1

फ़ाइल प्रारूप पर विवरण "मैन लिमिट्स.कॉन्फ़" हैं।

हालाँकि, जब तक मैं अपाचे के लिए coredump फ़ाइलों के लिए एक फ़ोल्डर सेट नहीं करता, तब तक कुछ भी काम नहीं करता ("/etc/httpd/conf/httpd.conf"):

CoreDumpDirectory /tmp

अब अपाचे को पुनः आरंभ करें:

service httpd restart

हम परीक्षण कर रहे हैं। प्रक्रिया को मैन्युअल रूप से मारें:
ps aux | grep httpd
...
मार -11 12345

हम "/ var / log / httpd / error_log" में देखते हैं:

[Mon Oct 01 16:12:08 2012] [notice] child pid 22596 exit signal Segmentation fault (11), possible coredump in /tmp

"/ Tmp" में अब हमें "/tmp/httpd-core.296/3" नाम से एक फ़ाइल मिलेगी

आपने सीखा कि एक मारे गए प्रक्रिया की मेमोरी डंप कैसे प्राप्त करें। अब हम स्वाभाविक रूप से मारे जाने की प्रक्रिया का इंतजार कर रहे हैं।

अपराध स्थल पर - कोरपम्प की व्याख्या करें

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

कोरपम्प कैसे खोलें? बेशक, पुरानी और "बहुत दयालु" उपयोगिता - जीडीबी , मूल रूप से ~~मुफ्त~~ सॉफ्टवेयर आंदोलन के उच्च प्रेषित रिचर्ड रिचर्डमैन द्वारा लिखी गई है।
डिबगर कैसे काम करता है यह समझने में ज्यादा समय नहीं लगता है। आप कुछ घंटों में सबसे मनोरंजक पाठ्य पुस्तकों में से एक को अवशोषित कर सकते हैं, या आप सिस्टम प्रशासक से ऐसा करने के लिए कह सकते हैं;;

आमतौर पर इस तरह से खुला coredump:
gdb path_to_ निष्पादन योग्य_file_web सर्वर path_to_coredump

यूनिक्स पर सभी स्वाभिमानी सी डेवलपर्स निश्चित रूप से जानते हैं कि इस डिबगर का उपयोग कैसे किया जाता है, वे शायद हर दिन ऐसा करते हैं, लेकिन, दुर्भाग्य से, वे आपकी टीम में नहीं हो सकते हैं। और एक और अप्रिय BUT है ...

Gdb में PHP डिबगिंग - काला जादू

तथ्य यह है कि एक PHP स्क्रिप्ट को बाईटेकोड में संकलित किया जाता है ... काफी सी प्रोग्राम नहीं है;;
ज़ेंड इंजन के इनसाइड को समझें - और आप बहुत जल्दी समझ जाएंगे । अर्थात्, आपको ट्रेस में फ़ंक्शन निष्पादित करने के लिए अंतिम कॉल खोजने की आवश्यकता है, स्टैक के इस फ्रेम पर जाएं और स्थानीय चर (op_array) की जांच करें, साथ ही Zend इंजन के वैश्विक चर को देखें:

 (gdb) frame 3 #3 0x080f1cc4 in execute (op_array=0x816c670) at ./zend_execute.c:1605 (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $14 = 0x80fa6fa "pg_result_error" (gdb) print (char *)executor_globals.active_op_array->function_name $15 = 0x816cfc4 "result_error" (gdb) print (char *)executor_globals.active_op_array->filename $16 = 0x816afbc "/home/yohgaki/php/DEV/segfault.php"

आप op_array के साथ भ्रमित हो सकते हैं, इसलिए यह संरचना जैसी लुकअप कमांड उपयोगी है:

 (gdb) ptype op_array type = struct _zend_op_array { zend_uchar type; char *function_name; zend_class_entry *scope; zend_uint fn_flags; union _zend_function *prototype; zend_uint num_args; zend_uint required_num_args; zend_arg_info *arg_info; zend_bool pass_rest_by_reference; unsigned char return_reference; zend_uint *refcount; zend_op *opcodes; zend_uint last; zend_uint size; zend_compiled_variable *vars; int last_var; int size_var; zend_uint T; zend_brk_cont_element *brk_cont_array; zend_uint last_brk_cont; zend_uint current_brk_cont; zend_try_catch_element *try_catch_array; int last_try_catch; HashTable *static_variables; zend_op *start_op; int backpatch_count; zend_bool done_pass_two; zend_bool uses_this; char *filename; zend_uint line_start; zend_uint line_end; char *doc_comment; zend_uint doc_comment_len; void *reserved[4]; } *

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

 (gdb) frame ## (gdb) print op_array.function_name $1 = 0x2aaab7ca0c10 "myFunction" (gdb) print op_array.filename $2 = 0x2aaab7ca0c20 "/var/www/file.php"

और इसी तरह ...

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

त्रुटियों के सामान्य कारण

Coredump फ़ाइलों को ब्राउज़ करना शुरू करें (या इसे सिस्टम एडमिनिस्ट्रेटर को असाइन करें) और आप तेज़ी से सीखेंगे कि समूहों में त्रुटियों को कैसे वर्गीकृत किया जाए:
1) PHP एक्सटेंशन में समस्याएं। इस स्थिति में, या तो एक्सटेंशन को अक्षम करें, या इसकी सेटिंग्स के साथ खेलने का प्रयास करें। आप जानते हैं कि समस्या इसमें है, मामला छोटा है।
2) पुनरावृत्ति, स्टैक के साथ समस्या। आप एक त्रुटि का सामना कर सकते हैं जिसमें एक पुस्तकालय समारोह, जैसे कि पीसीआर, पुनरावृत्ति में प्रवेश करता है और खुद को बीस हजार बार कॉल करता है। आप या तो लाइब्रेरी सेटिंग्स को कॉन्फ़िगर कर सकते हैं या, यदि आप बहुत आलसी हैं, तो प्रक्रिया में एक बड़ा स्टैक जोड़ें ("/etc/init.d/httpd"):

ulimit -s "अधिक मूल्य निर्धारित करें"

और वर्तमान मूल्य को कमांड के साथ देखा जा सकता है: "अलिमित-ए" (आदमी अलिमिट, फिर "अलिमेट" देखें)।
3) PHP कोर में समस्याएँ - यहाँ आपको PHP डेवलपर्स को लिखने की आवश्यकता है :-)

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

चल रही प्रक्रिया को डीबग करना

वह सब नहीं है। यदि आप coredump प्राप्त नहीं कर सकते हैं, तो आप रनिंग प्रक्रिया से जुड़ सकते हैं और उस पर चल सकते हैं। जब आप प्रक्रिया के अंदर होते हैं, तो इसका निष्पादन रोक दिया जाता है ("ps aux | grep apache | grep 'T'" - यह अनुरेखण की स्थिति में होगा)। जब आप उसे छोड़ देंगे, तो वह फिर से निष्पादित किया जाएगा। आप निम्नानुसार कनेक्ट कर सकते हैं:
gdb -p प्रक्रिया आई.डी.

परिणाम

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

अब आप रहस्यमय सर्वर त्रुटियों से निपटने के लिए प्रबंधक के लिए एक चेकलिस्ट बना सकते हैं जो न तो वेब डेवलपर्स और न ही सिस्टम एडमिनिस्ट्रेटर समझ सकते हैं:

सर्वर (sysadmin) पर coredump फ़ाइलों का संग्रह सक्षम करें
यदि आवश्यक हो, डिबगिंग प्रतीकों (sysadmin) के साथ Apache-PHP का पुनर्निर्माण करें
Gdb (इसे पढ़ने के लिए सप्ताहांत) का उपयोग करते हुए, त्रुटि के कारण की जांच करें (सिस्टम डेवलपर एक वेब डेवलपर के साथ)
इसे खत्म करने या घटना की आवृत्ति को कम करने के लिए उपाय करें: सेटिंग्स बदलें, सॉफ़्टवेयर अपडेट करें, बगट्रैकर पर लिखें, PHP एक्सटेंशन को अक्षम करें, आदि।

अंत में, मैं सभी को हमारी बिट्रिक्स 24 क्लाउड सेवा में आमंत्रित करता हूं, जिसमें हम लेख में वर्णित सभी तकनीकों का प्रभावी ढंग से उपयोग करते हैं।

सभी को शुभकामनाएँ और वेब परियोजनाओं के स्थिर काम!

PHP को लड़ाई में स्थिर करें - वेब सर्वर क्या और क्यों गिरता है