Nginx, Apache, PHP, MySql का अनुकूलन

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

मुझे साइट का नाम नहीं मिला - मुझे लगता है कि प्रोग्रामर को खुद पता होगा। मैं केवल यह कह सकता हूं कि यह एक सामाजिक नेटवर्क के लिए एक आवेदन है जिसमें नियमित समय पर 70-150 हजार आगंतुकों का भार होता है। सब कुछ इस तथ्य से जटिल है कि समय-समय पर एक विज्ञापन मेलिंग बनाई जाती है, जो कुछ घंटों में लगभग 200-300 हजार आगंतुकों को आकर्षित करती है।

तो, कटौती के तहत, 4 दिनों के लिए पूरे संघर्ष का वर्णन।

यह लेख लोगों के 2 समूहों के उद्देश्य से है। पहला, निश्चित रूप से, हम, प्रशासक, जिन्हें इस तरह के अपमान का सामना करना पड़ता है। कभी-कभी एक मरते हुए सर्वर को लगभग कानों से खींचना। दर्शकों का दूसरा भाग, जो मुझे आशा है कि सभी सामग्री को भी निश्चित रूप से पढ़ेगा, प्रोग्रामर है। दोस्तों, आगे देखते हुए, मैं कहता हूँ: यदि आप अपनी परियोजनाओं को सही ढंग से डिज़ाइन करते, तो इस तरह का अपमान नहीं होता, कई घटनाओं से बचा जा सकता था। खासतौर पर यह जानते हुए कि आप किस ऑडियंस को अपना प्रोजेक्ट लिख रहे हैं।

मेरे पास अपने निपटान में एक EX10 सर्वर जो कि हर्ट्ज़नर साइट पर स्थित है। जो लोग नहीं जानते हैं, उनके लिए यह 64 जीबी रैम और 6-कोर प्रोसेसर है। इसे सिस्टम का मूल कहें। 2 और सर्वर हैं, एक स्टैटिक्स के साथ, दूसरा बैकएंड बेस के साथ। एक छोटा अनुप्रयोग, InnoDB 500MB डेटाबेस।

एक निरंतर भार के साथ, जैसा कि बाद में पता चला, 70-100 ऑनलाइन सत्र, स्थिति इस प्रकार है: प्रत्येक कोर के लिए 100% का सीपीयू उपयोग। शीर्ष में, निश्चित रूप से, MySQL और Apache सिस्टम संसाधनों के लिए लड़ रहे हैं।

nginx

पहला प्रयास अपाचे आउटपुट को कैशिंग द्वारा सर्वर पर लोड को कम करने के लिए था ताकि उसमें से स्थैतिक आउटपुट को हटाया जा सके।

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

 http {
 प्रॉक्सी_कैचे_पथ / var / tmp / nginx_cache / स्तर = 1: 2 कीज़_ज़ोन = ठीक: 100 मीटर निष्क्रिय = 1 डी मैक्स_साइज़ = 1024 मीटर;
 सर्वर {
         स्थान ~ *।
                 1y समाप्त हो रहा है;
                 open_file_cache_errors बंद;
                 एरर_पेज 404 = @ लेच;
                 root / var / tmp / _fetch_ok;
                 }

         स्थान @fetch {
                 xy_store_access उपयोगकर्ता: rw समूह: rw all: r;
                 प्रॉक्सी_स्टोर पर;
                 प्रॉक्सी_पास http://127.0.0.1:80;
                 xy_temp_path / var / tmp / _fetch_ok_temp;
                 root / var / tmp / _fetch_ok;
                 }


        स्थान / {
                 छद्म_चेतना ठीक;
                 प्रॉक्सी_पास http://127.0.0.1;
                 प्रॉक्सी_चेचे_वैलिड किसी भी 10 मी;
                 xy_buffer_size 8k;
                }
 }
 }

कॉन्फ़िगरेशन पूरी तरह से नहीं दिया गया है, लेकिन केवल इस उदाहरण के लिए आवश्यक ब्लॉकों के साथ।

दुर्भाग्य से, इससे कोई परिणाम नहीं हुआ।
केवल 3 प्लस थे:

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

MySQL

यह सबसे कठिन है, क्योंकि इस समय मुझे एसक्यूएल प्रश्नों और अनुकूलन में ज्यादा अनुभव नहीं है।
MySQL प्रलेखन को पढ़कर शुरू किया।

चूँकि हमारे पास InnoDB हाथ में है - मैंने आरंभिक स्थिति के लिए मानक डिलीवरी my-innodb-Heavy-4G.cnf से कॉन्फ़िगरेशन फ़ाइल ली।

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

back_log = 5000
max_connections = 1600
पहला पैरामीटर उन कनेक्शनों की संख्या के लिए ज़िम्मेदार होता है जो तब तक कतार में हो सकते हैं जब तक कि सर्वर नए अनुरोधों का जवाब देना बंद कर देता है। दूसरा यह है कि सर्वर द्वारा कितने कनेक्शन स्वीकार किए जा सकते हैं।
मेरे लिए, ये मूल्य काफी बड़े हैं, क्योंकि औसतन 1300 प्रतिस्पर्धी सत्र हैं। आवश्यकता से अधिक सट्टेबाजी इसके लायक नहीं है, क्योंकि प्रत्येक कनेक्शन को एक निश्चित मात्रा में रैम की आवश्यकता हो सकती है। उस पर और बाद में।

max_connect_errors = 50
यहां यह सरल है - क्लाइंट की संख्या जो डिस्कनेक्ट प्राप्त करने से पहले कर सकती है। मुझे बढ़ना था, क्योंकि परियोजना विकास के अधीन है और गलत अनुरोधों की कई संभावनाएं हैं।

table_cache = 2048
तालिका खोलने के लिए कुछ संसाधनों की आवश्यकता होती है; इसलिए, यह पैरामीटर अंतिम कनेक्शन की प्रतीक्षा करने के बाद अंतिम कनेक्शन की संख्या के लिए जिम्मेदार होता है।
यह पता करें कि क्या एक चर द्वारा इसे बदलना आवश्यक है
SHOW GLOBAL STATUS LIKE 'Opened_tables';
यह जितना संभव हो उतना छोटा नहीं होना चाहिए।
यह यहाँ अच्छी तरह से लिखा गया है: http://www.mysql.ru/docs/man/Table_cache.html

max_allowed_packet = 16M
अधिकतम पैकेट का आकार। यदि हम बड़े BLOB का उपयोग नहीं करते हैं, तो इसे बदलने का कोई मतलब नहीं है।

binlog_cache_size = 1M
लेन-देन के लिए बाइनरी लॉग कैश का आकार। यदि हमारे पास बड़े लेन-देन हैं, तो आधिकारिक दस्तावेज बढ़ने की सलाह देते हैं।
dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_binlog_cache_size

max_heap_table_size = 64M
tmp_table_size = 64M
जहां तक ​​मैं समझता हूं, उनमें से छोटे को ध्यान में रखा गया है। पैरामीटर स्मृति में फिट होने वाली अस्थायी तालिका के अधिकतम आकार के लिए जिम्मेदार है। यदि तालिका उस तक पहुंचती है, तो उसे डिस्क पर रखा जाता है। इसलिए, आपको डिस्क पर संभव के रूप में कुछ तालिकाओं को बनाने का प्रयास करना चाहिए। आप अनुरोध करके डिस्क पर तालिकाओं के लिए अस्थायी तालिकाओं के वर्तमान अनुपात को देख सकते हैं
show status like '%tmp%tables';
www.mysqlperformanceblog.com/2007/01/19/tmp_table_size-and-max_heap_table_size

Sort_buffer_size = 8M
किसी को धोखा न देने के लिए, मैं अनुवाद करने का उपक्रम नहीं करूंगा। मैं केवल यह स्पष्ट करूंगा कि प्रलेखन केवल इस पैरामीटर को देखने की सिफारिश करता है यदि
'% Sort_merge_passes%' जैसी स्थिति दिखाएं; शून्य से अधिक
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_sort_buffer_size

join_buffer_size = 2M
जहां तक ​​मैं समझता हूं, एक ऑपरेशन के लिए डिज़ाइन किए गए बफर का अधिकतम आकार जो एक सूचकांक का उपयोग नहीं करता है। मैंने अभी तक छुआ नहीं है
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_join_buffer_size

thread_cache_size = 4096
क्वेरी पूरा होने के बाद पुन: उपयोग के लिए बने रहने वाले ट्रेडों की अधिकतम संख्या। यह पर्याप्त रखने के लिए उपयोगी है ताकि MySQL संभव के रूप में कुछ नए ट्रेडों को बनाए और पुराने का उपयोग करे। आप थ्रेड्स_क्रिएटेड / कनेक्शंस पैरामीटर्स के संबंध में इस पैरामीटर की प्रभावशीलता को समझ सकते हैं;
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_thread_cache_size

query_cache_size = 256M
query_cache_limit = 8M
मुझे लगता है कि मेरे सहयोगी से बेहतर है, इस अनुवाद के लेखक habrahabr.ru/post/41166 कोई नहीं कहेगा।
यह शायद सबसे महत्वपूर्ण पैरामीटर है, इसलिए इसे फिर से पढ़ना बेहतर है।

thread_stack = 192K
मैं इस पैरामीटर के उद्देश्य का वर्णन करने का प्रयास नहीं करूंगा, मैं केवल इस तथ्य पर ध्यान दूंगा कि यह रैम की खपत की मात्रा को भी प्रभावित करता है, क्योंकि यह प्रत्येक कनेक्शन के लिए भी खड़ा है। इसलिए फिर से अधिकतम कनेक्शन से गुणा करें

long_query_time = 2
log_long_format
लॉग-प्रश्नों-नहीं-using- अनुक्रमित
डेटाबेस प्रदर्शन का मूल्यांकन करने के लिए MySQL सर्वर में बहुत सुविधाजनक उपकरण है। यह एक लंबी अनुरोध लॉग फ़ाइल है। मेरे अनुभव में, ये अक्सर अयोग्य प्रश्न या गैर-सूचकांक प्रश्न हैं।
मैं आपको इस लॉग फ़ाइल के साथ प्रोग्रामर के पास जाने की सलाह देता हूं।

key_buffer_size = 1G
पैरामीटर मेमोरी में कैशिंग इंडेक्स के लिए जिम्मेदार है, इस मान को ऑप्टिमाइज़ करने के लिए, Key_read_requests, Key_reads देखें। दूसरा पैरामीटर डिस्क से रीड की संख्या और उनके बफर के लिए जिम्मेदार है।
mysqltips.blogspot.com/2007/03/key-buffer.html

read_buffer_size = 1M
boombick.org/blog/posts/3 - इस पाठ को पढ़ने के बाद, मैं कुछ भी जोड़ने का जोखिम नहीं उठाऊंगा , क्योंकि मुझे यकीन नहीं होगा कि मैं सही हूं।

read_rnd_buffer_size = 24M
पैरामीटर छँटाई के संचालन की गति को प्रभावित करता है। दुर्भाग्य से, मुझे इसकी प्रभावशीलता का मूल्यांकन करने का तरीका नहीं मिला।
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_read_rnd_buffer_size
www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size

myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
पैरामीटर छँटाई को प्रभावित करते हैं, बस उन्हें बदलने की हिम्मत नहीं हुई। पहले यह मानते हुए कि यह जटिल प्रश्नों के प्रदर्शन को बढ़ाएगा।

Sync_binlog = 0
हमारे मामले में, इसका अर्थ है कि सिस्टम फ़ंक्शन के माध्यम से डिस्क में बाइनरी लॉग को सिंक्रनाइज़ नहीं करना है। यदि पैरामीटर शून्य से अधिक है, तो सर्वर हर एन अनुरोधों को डेटा सिंक्रनाइज़ करेगा।
dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_sync_binlog

innodb_buffer_pool_size = 4G
इस सेटिंग को बढ़ाने से डिस्क संचालन कम हो जाता है। दुर्भाग्य से, मुझे यह भी नहीं पता था कि इसे बेहतर तरीके से कैसे मापना है। चूंकि आधार छोटा है, इसलिए मैंने इसे ज्यादा नहीं बढ़ाने का फैसला किया। कहीं मुझे सलाह मिली, एक बड़े डेटाबेस के मामले में, इस पैरामीटर को 70% रैम तक बढ़ाएं।
dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_buffer_pool_size

innodb_log_buffer_size = 32M
विवरण के अनुसार, यह भारी लेनदेन के दौरान डिस्क संचालन को कम करता है।
dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_log_buffer_size

innodb_log_file_size = 1024M
यदि आप दस्तावेज़ पर विश्वास करते हैं, तो लॉग फ़ाइल बढ़ाने से आईओ डिस्क संचालन पर भार कम हो जाता है, लेकिन विफलताओं के मामले में पुनर्प्राप्ति समय बढ़ जाता है।
dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_log_file_size

innodb_flush_log_at_trx_commit = 0
जब 0 पर सेट किया जाता है, तो बफ़र्स को प्रति मिनट एक बार प्रति सेकंड फ़्लश किया जाता है, और प्रत्येक इंसर्ट के बाद नहीं।
dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

innodb_thread_concurrency = 14
वे कोर की संख्या से थोड़ा अधिक लगाने की सलाह देते हैं।

innodb_sync_spin_loops = 10
जैसा कि मैं इसे समझता हूं, यह लॉक किए गए डेटा तक पहुंचने के प्रयासों की संख्या को प्रभावित करता है। इस मूल्य को बढ़ाने से हम प्रोसेसर समय खो सकते हैं, और घटते - घटते डेटाबेस में लेखन की विश्वसनीयता।
www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes
dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_sync_spin_loops

DB और RAM

एक अद्भुत पर्ल स्क्रिप्ट है जो डेटाबेस में बदलने की आवश्यकता की एक बुनियादी समझ देती है। mysqltuner.pl/mysqltuner.pl
बहुत बार, यह स्क्रिप्ट mysql सर्वर द्वारा अधिकतम मेमोरी खपत पर शपथ लेती है।
यदि आप स्रोत को देखते हैं - तो इस तरह से यह कार्यक्रम स्मृति उपयोग पर विचार करता है:

per_thread_buffers = read_buffer_size + read_rnd_buffer_size + Sort_buffer_size + thread_stack + join_buffer_size;
Total_per_thread_buffers = per_thread_buffers * max_connections;
server_buffers = key_buffer_size + max_tmp_table_size;
server_buffers + = innodb_buffer_pool_size;
server_buffers + = innodb_additional_mem_pool_size;
server_buffers + = innodb_log_buffer_size;
server_buffers + = query_cache_size;
Total_possible_used_memory = server_buffers + total_per_thread_buffers;

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

डेटाबेस संरचना अनुकूलन।

जब हमने सभी संभव सेटिंग्स कीं और फिर भी अच्छा परिणाम नहीं मिला, तो धीमी-लॉग फ़ाइल को चालू करने का समय आ गया है।
माईसकल मानक के रूप में mysqldumpslow के साथ आता है।
दौड़कर
mysqldumpslow -sc <path to slow-log फ़ाइल> प्रविष्टियों की संख्या के आधार पर सॉर्ट की गई डेटाबेस क्वेरीज़ की सूची जो बहुत लंबी थी या इंडेक्स का उपयोग नहीं करती थी। आमतौर पर सही इंडेक्स को जोड़ने से दोनों समस्याएं ठीक हो जाती हैं।

ज्यादातर मामलों में, जब आप इस प्रोग्राम के आउटपुट (काउंट चर) में बड़ी संख्या में लंबी क्वेरी देखते हैं, तो इस क्वेरी के एक टुकड़े को कॉपी करें और लॉग फ़ाइल के पाठ में इस तरह के क्वेरी का उदाहरण देखें।
इसके बाद, डेटाबेस क्लाइंट पर जाएं और इस क्वेरी को निष्पादित करें, पहले शब्द को समझाएं।
आप इसके बारे में और भी विस्तार से यहां पढ़ सकते हैं:
habrahabr.ru/post/31072

इस तरह आप देख सकते हैं कि क्वेरी इंडेक्स का उपयोग कर रही है या नहीं।
यदि तालिका में पर्याप्त अनुक्रमित नहीं हैं, तो आप उन्हें सुरक्षित रूप से जोड़ सकते हैं, हालांकि आपको इसे अधिक नहीं करना चाहिए। इंडेक्स की आवश्यकता उन कॉलमों के लिए होती है, जिनका उपयोग कहां और ऑर्डर के बाद किया जाता है। प्रत्येक स्टोबल के लिए अद्वितीय अनुक्रमित के साथ शुरू करें। अन्यथा, इंडेक्स काम नहीं कर सकता है।
यहाँ आप और अधिक विस्तार से जान सकते हैं कि ये सूचकांक कैसे काम करते हैं:
dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

सच कहूँ तो, लगभग 5 प्रमुख अनुरोधों के अनुकूलन के बाद, सर्वर 50 के बजाय 500-700 कनेक्शनों को संसाधित करने में सक्षम था, और एक php पृष्ठ जारी करने का समय 8 के बजाय 1 एस हो गया था। अधिकतम लोड पर, 50 के बजाय पृष्ठ डिलीवरी का समय 5s था। (यह अपाचे बेंचमार्क सी लगभग 1000 धागे का उपयोग करके प्रदर्शन माप को संदर्भित करता है)

नगनेक्स के बारे में थोड़ा और।

अनुकूलन के बाद, मैंने देखा कि भारी भार के तहत, नगनेक्स ही, और अपाचे नहीं, एक निश्चित राशि से अधिक अनुरोधों को नीचे फेंकता है। हालाँकि, मेमोरी और CPU लोड नहीं होते हैं।
वह समझने लगा। मैंने लॉग में देखा कि nginx सर्वर को अधिक फ़ाइलों को खोलने की कोशिश कर रहा है जो इसे होना चाहिए।
Suse में, जिसे मुझे निपटना था, फ़ाइल इस सीमा के लिए जिम्मेदार है
/etc/security/limits.conf
मैंने इन पंक्तियों को वहां जोड़ा:

 नगनेक्स सॉफ्ट नोफाइल 300000
 nginx हार्ड नोफाइल 300000

सर्वर पुनरारंभ की आवश्यकता नहीं थी।

Apache2

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

eAccelerator

यह मत भूलो कि इस ऑप्टिमाइज़र में कई पैरामीटर भी हैं जिन्हें बदला जा सकता है।

यहाँ मैंने क्या बदला है:
eaccelerator.shm_size = "2096"
मेगाबाइट में वर्चुअल मेमोरी का आकार जिसका उपयोग किया जा सकता है

eaccelerator.shm_only = "1" - केवल RAM का उपयोग करें और डिस्क का उपयोग न करें, 2 Sat डिस्क के सॉफ़्टवेयर छापे पर io के लिए लड़ाई में ऐसा करने का फैसला किया।

यहाँ और क्या पढ़ना उपयोगी होगा:

habrahabr.ru/post/41166
habrahabr.ru/post/108418
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html

मेरे दोस्त के लिए विशेष धन्यवाद जिसने लेख को पढ़ने और व्याकरणिक और शैलीगत त्रुटियों के एक पूरे पहाड़ को ठीक करने में मदद की।

एक आफ्टरवर्ड के बजाय

दोस्तों, मैं समझता हूँ कि इस लेख में दिए गए निष्कर्षों में त्रुटियों और त्रुटियों का एक पूरा समूह है।
लेख को बेहतर बनाने में मदद करने के लिए, गुरु ने अपनी टिप्पणियों के साथ एक बड़ा अनुरोध किया।

युपीडी। टिप्पणी सारांश

इतनी बड़ी रुचि के लिए धन्यवाद। मुझे उम्मीद नहीं थी।

अच्छा लिंक, मैं पढ़ने की सलाह देता हूं: www.percona.com/files/pretations/percona-live/dc-2012/PLDC2012-optimizing-mysql-configuration.pdf
धन्यवाद अल्बर्टम

Php कैशिंग सिस्टम के बारे में:
हाँ वास्तव में eAccelerator एकमात्र विकल्प नहीं है।
एपीसी भी है, और हाँ वे वास्तव में इसे PHP में एम्बेड करने जा रहे हैं।
जब तक मैं पर्याप्त परीक्षण नहीं कर लेता, तब तक मैं बेहतर करने वाला नहीं हूं।

MySQL के विकल्प भी मौजूद हैं, और कई हैं।
पाठ्यक्रम की कुंजी:
MariaDB
percona

मैंने व्यक्तिगत रूप से पर्कॉन को चुना और अब तक मैं संतुष्ट हूं।

इस तथ्य के बारे में कि यह अंतिम उज्ज्वल परिणाम नहीं है और हमें आगे बढ़ने की आवश्यकता है - जो लोग ध्यान से पढ़ते हैं वे देखेंगे कि यह केवल पैचिंग छेद है।