Сайт одатда тез ишлайди, аммо ташрифчилар кўпайган пайтда саҳифалар ўрнига база хатоси чиқа бошлайди, логда эса Too many connections ёзуви пайдо бўлади. Бу хато MySQL сервери янги уланишни қабул қила олмаётганини билдиради: барча "ўриндиқлар" банд, навбатдаги сўров эса эшик олдида рад этилади. Бу мақолада хатонинг қаердан келиб чиқишини, уни қандай текшириш ва юк остида ҳам барқарор ишлаши учун нима қилиш кераклигини кўриб чиқамиз.
1040 хатосининг механизми
MySQL серверида max_connections параметри бир вақтнинг ўзида очиқ туриши мумкин бўлган уланишларнинг умумий сонини белгилайди. Ҳар бир PHP жараёни саҳифани тайёрлаш учун базага уланади ва иш тугагунча бу уланишни ушлаб туради. Агар бир вақтда очиқ уланишлар сони лимитга етса, янги уланиш уриниши қуйидаги хато билан тугайди:
ERROR 1040 (HY000): Too many connectionsБу хато битта фойдаланувчига эмас, бутун серверга тегишли эканини ёдда тутиш муҳим. Фойдаланувчи даражасидаги лимит ошганда бошқа хато, яъни 1203 max_user_connections чиқади, соатлик квота тугаганда эса 1226. Шунинг учун логда айнан қайси код ёзилганини аниқлаш тўғри ташхиснинг асоси ҳисобланади.
Уланишлар нега тўлиб қолади
Кўпчилик бу хатони "ташрифчилар жуда кўп" деб тушунади, лекин амалда сабаб кўпинча уланишларнинг узоқ вақт банд бўлиб қолишидадир. Агар ҳар бир саҳифа 50 миллисекундда тайёрланса, юз уланиш билан секундига минглаб сўровга хизмат қилиш мумкин. Бироқ битта секин сўров жадвални қулфлаб қўйса, унга боғлиқ бошқа сўровлар навбатда кутиб туради, уларнинг ҳар бири эса ўз уланишини банд қилади. Натижада бир неча сонияда барча уланишлар тўлади.
Бошқа кенг тарқалган сабаблар орасида бир хил саҳифаларни тинимсиз сўрайдиган ботлар, кешсиз оғир категория ва фильтр саҳифалари, узоқ ишлайдиган экспорт ёки ҳисобот скриптлари бор. Шунингдек, PHP ишчилари сони базанинг уланиш лимитидан катта бўлса, юк ошганда веб-сервер базани ўзи кўтара олмайдиган даражада кўп параллел сўров билан "босиб" юборади.
Ҳолатни текшириш буйруқлари
Агар ўз VPS серверингиз бўлса ёки базага администратор ҳуқуқи билан кира олсангиз, аввал лимит ва жорий ҳолатни кўриб чиқинг. Threads_connected ҳозир очиқ уланишлар сонини, Max_used_connections эса сервер ишга тушганидан бери қайд этилган энг катта қийматни кўрсатади. Агар иккинчиси лимитга тенг бўлса, сервер ҳақиқатан ҳам чегарага бориб урилган:
SHOW VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';Кейинги қадам уланишлар нима билан бандлигини аниқлаш. SHOW FULL PROCESSLIST ҳар бир уланиш қайси фойдаланувчига тегишли эканини, қанча вақтдан бери ишлаётганини ва қайси сўровни бажараётганини чиқаради. Узоқ Time қийматига эга сўровлар ёки Waiting for table metadata lock ҳолатидаги қаторлар кўп бўлса, муаммо юкда эмас, балки аниқ бир сўровда:
SHOW FULL PROCESSLIST;
-- ilojsiz osilib qolgan so'rovni to'xtatish:
KILL 48213;MySQL лимитдан ташқари битта қўшимча уланишни юқори ҳуқуқли администратор учун сақлаб қўяди. Шу сабабли ҳамма уланишлар банд бўлганда ҳам root фойдаланувчиси одатда кириб, вазиятни кўра олади.
Лимитни ошириш ва бўш уланишларни тозалаш
Лимитни сервер ишлаб турган пайтда вақтинча ошириш мумкин, аммо бу қиймат қайта ишга туширишдан кейин йўқолади. Доимий ўзгариш учун MySQL конфигурация файлига ёзилади. Шу билан бирга wait_timeout қийматини камайтириш фойдали: стандарт ҳолатда бўш турган уланиш соатлаб очиқ қолиши мумкин, бу эса лимитни беҳуда эгаллайди:
# vaqtincha, qayta ishga tushirishgacha
SET GLOBAL max_connections = 300;
# doimiy: /etc/mysql/my.cnf yoki /etc/my.cnf, [mysqld] bo'limi
[mysqld]
max_connections = 300
wait_timeout = 120
# keyin qayta ishga tushirish (xizmat nomi tizimga qarab farq qiladi)
sudo systemctl restart mysqlЛимитни ўйламасдан катта қилиш ҳам хавфли. Ҳар бир уланиш ўз буферлари учун хотира олади, шунинг учун мингта уланишга рухсат берилган, лекин хотираси кичик серверда юк ошганда MySQL хотира етишмаслигидан тўхтаб қолиши мумкин. Лимитни сервернинг оператив хотираси ва innodb_buffer_pool_size билан бирга баҳолаш керак. Shared хостингда эса бу созламаларни фойдаланувчи ўзгартира олмайди, улар хостинг провайдери томонидан бошқарилади.
Илова томонида нима қилиш мумкин
Энг самарали ечим кўпинча базага уланишларнинг ўзини камайтиришдир. Қуйидаги чоралар ҳеч қандай сервер созламасиз ҳам сезиларли натижа беради:
- Саҳифа кешини ёқинг: кешдан берилган саҳифа базага умуман мурожаат қилмайди.
- Секин сўровлар логини таҳлил қилиб, энг оғир сўровларга индекс қўшинг, шунда уланишлар тезроқ бўшайди.
- Кераксиз ботларни сайт даражасида чекланг, айниқса фильтр ва қидирув саҳифаларини айланиб чиқадиганларини.
- Оғир экспорт ва ҳисоботларни ташрифчилар кам бўлган тунги соатларга ўтказинг.
- PHP ишчилари сонини базанинг уланиш лимитига мосланг, акс ҳолда юк ошганда улар базани босиб юборади.
Амалий мисол: имтиҳон натижалари эълон қилинган кун
Тошкентдаги хусусий мактабнинг misol.uz сайти йил давомида муаммосиз ишларди. Кириш имтиҳонлари натижалари эълон қилинган куни эса минглаб ота-оналар бир вақтда натижалар саҳифасини оча бошлади ва сайт бир неча дақиқадан кейин Too many connections хатосини бера бошлади. Текширув кўрсатдики, натижалар саҳифаси ҳар очилганда индекссиз устун бўйича бутун жадвални қидириб чиқар, ҳар бир сўров бир неча сония давом этарди.
Устунга индекс қўшилгач, сўров вақти миллисекундларга тушди, натижалар саҳифаси эса қисқа муддатли кешга олинди. Уланиш лимити ўзгармаган бўлса ҳам, хато қайтиб келмади, чунки ҳар бир уланиш энди бир зумда бўшарди. Бу мисол лимитни оширишдан олдин уланишлар нима билан банд эканини аниқлаш қанчалик муҳимлигини яхши кўрсатади. Агар сайт sayt.uz хостингида бўлса ва хато тез-тез такрорланса, вақт ва саҳифа манзилини кўрсатиб техник ёрдамга тикет очиш мумкин.
Олдиндан тайёргарлик
Уланишлар кўпинча олдиндан маълум бўлган воқеаларда тўлади: акциялар, натижалар эълон қилиниши, реклама кампаниялари. Бундай кунлардан олдин энг кўп очиладиган саҳифаларни оддий юк тести билан синаб кўриш, кеш ишлаётганини текшириш ва секин сўровларни тузатиб қўйиш сайт айнан энг керакли пайтда ишдан чиқмаслигини таъминлайди.