"max_connections_per_hour" хатоси: сайт Database Error беради

Кеча яхши ишлаган сайт бирдан "Database Error" ёки "Error establishing a database connection" деган ёзувни кўрсатиб қўйди, орадан бир соат ўтгач эса ўз-ўзидан тикланди. Кейинги куни яна ўша ҳолат. Бундай "келиб-кетадиган" хатонинг кўп учрайдиган сабабларидан бири MySQL фойдаланувчисига қўйилган соатлик уланишлар лимитидир. Хато логларида бу ҳолат max_connections_per_hour номи билан кўринади ва уни бир марта тушуниб олсангиз, кейинги сафар бир неча дақиқада аниқлай оласиз.

1226 хатоси аслида нима дейди

MySQL ҳар бир фойдаланувчига ресурс лимитлари қўйиш имконини беради: соатига нечта сўров, нечта ўзгартириш ва нечта янги уланиш очиши мумкинлиги. Агар фойдаланувчи бир соат ичида рухсат этилган уланишлар сонидан ошиб кетса, сервер янги уланишни рад этади ва қуйидаги хабарни қайтаради:

ERROR 1226 (42000): User 'shop_user' has exceeded the
'max_connections_per_hour' resource (current value: 50)

Бу ерда муҳим жиҳат шундаки, лимит бир вақтдаги уланишларни эмас, балки бир соат давомида очилган барча уланишларни санайди. PHP сайтларида одатда ҳар бир саҳифа очилиши базага янги уланиш очади. Демак, соатлик лимит 50 бўлса, сайт соатига тахминан 50 та саҳифа кўришдан кейин ишлашдан тўхтайди. Ҳисоблагич соат тугагач нолга тушади, шунинг учун хато ўз-ўзидан йўқолгандек туюлади, лекин трафик қайтиб келиши билан яна пайдо бўлади.

Уни бошқа уланиш хатоларидан қандай ажратиш мумкин

MySQL уланиш билан боғлиқ бир нечта ўхшаш хато беради ва уларни адаштирмаслик керак, чунки ечимлари ҳар хил. 1226 соатлик квота тугаганини билдиради. 1203 хатоси, яъни max_user_connections, фойдаланувчининг бир вақтдаги очиқ уланишлари лимитдан ошганини кўрсатади. 1040 Too many connections эса бутун сервернинг умумий уланиш лимити тўлганини англатади ва одатда битта фойдаланувчига боғлиқ бўлмайди. Нотўғри парол ёки фойдаланувчи номи учун эса 1045 Access denied чиқади.

Сайт фойдаланувчига кўпинча фақат умумий "база хатоси" саҳифасини кўрсатади, аниқ код эса PHP хато логида ёки сайтнинг ўз логида ёзилади. Хостинг панелидаги логлар бўлимини ёки сайт папкасидаги error_log файлини очиб, хато кодини топиб олиш ташхиснинг биринчи қадамидир.

Жорий лимитларни текшириш

Агар сизда MySQL'га администратор даражасида кириш имкони бўлса, масалан ўз VPS серверингизда, фойдаланувчига қандай лимитлар қўйилганини mysql.user жадвалидан кўриш мумкин. Бу жадвалда max_connections устуни айнан соатлик уланишлар лимитини сақлайди, max_user_connections эса бир вақтдаги уланишлар учун жавоб беради. Қиймат 0 бўлса, лимит қўйилмаган бўлади:

SELECT user, host, max_questions, max_updates,
       max_connections, max_user_connections
FROM mysql.user
WHERE user = 'shop_user';

Shared хостингда бу жадвалга оддий фойдаланувчи кира олмайди. Бундай ҳолатда лимит қийматини ва уни ўзгартириш мумкинлигини хостинг техник ёрдамидан сўраш керак бўлади.

Лимитни ошириш ва ҳисоблагични тозалаш

Сервер администратори лимитни ALTER USER буйруғи билан ўзгартиради. Замонавий сайтлар учун соатига 50 та уланиш жуда кам қиймат, шунинг учун уни минглаб уланишгача кўтариш ёки умуман олиб ташлаш одатий амалиёт. Ўзгаришдан кейин ҳисоблагични дарҳол нолга тушириш учун FLUSH USER_RESOURCES ишлатилади, акс ҳолда жорий соат тугашини кутишга тўғри келади:

ALTER USER 'shop_user'@'localhost'
  WITH MAX_CONNECTIONS_PER_HOUR 20000;
FLUSH USER_RESOURCES;

Лимитни бутунлай олиб ташлаш учун қиймат сифатида 0 берилади. Лекин shared хостингда лимитлар бир мижоз бутун серверни банд қилиб қўймаслиги учун ҳам керак, шунинг учун кўпинча чексиз эмас, балки сайтнинг реал трафигига етадиган юқори қиймат танланади. Ўз VPS серверингизда эса бу қарорни ўзингиз қабул қиласиз.

Уланишлар сонини камайтириш

Лимитни ошириш тезкор ечим, аммо сайт бир соатда минглаб уланиш очаётган бўлса, унинг сабабини ҳам билиш фойдали. Кўпинча уланишларнинг катта қисмини реал ташрифчилар эмас, балки ботлар, тез-тез ишлайдиган режалаштирилган вазифалар ёки кешсиз оғир саҳифалар келтириб чиқаради. Қуйидаги нуқталарни текшириб чиқинг:

Саҳифа кеши ёқилганми: кешдан берилган саҳифа базага умуман уланмайди, шунинг учун уланишлар сони кескин камаяди.
Кириш логида бир хил саҳифаларни тинимсиз сўраётган қидирув ва таҳлил ботлари борми, уларни сайт даражасида чеклаш мумкин.
cron вазифалари ҳар дақиқада ишга тушмаяптими, кўп ҳолатда беш ёки ўн беш дақиқалик оралиқ етарли.
WordPress сайтларида администратор панелидаги admin-ajax.php сўровлари очиқ қолдирилган браузер ойнасидан ҳам мунтазам юборилиб туради.

Амалий мисол: клиника сайтининг тушки узилишлари

Самарқанддаги хусусий клиниканинг example.uz сайти ҳар куни тушга яқин бир соатча ишламай қоларди. Шифокорлар қабул жадвали ва онлайн ёзилиш шакли айнан шу вақтда энг кўп ишлатилар, администратор эса муаммони хостинг секинлигидан деб ўйларди. PHP хато логида кетма-кет 1226 кодли ёзувлар топилди, кириш логи эса бир соатда бир неча юз саҳифа очилганини кўрсатди, бу эса 50 лик лимитдан анча кўп эди.

Техник ёрдам фойдаланувчи лимитини сайт ҳажмига мос қийматга кўтариб, ҳисоблагични тозалади. Сайт эгаси эса саҳифа кешини ёқди ва қабул жадвалини янгилайдиган режалаштирилган вазифани ҳар дақиқадан ҳар ўн дақиқага ўтказди. Натижада хато бутунлай йўқолди, саҳифалар эса аввалгидан тезроқ очила бошлади. sayt.uz хостингида бундай ҳолатда хато кодини кўрсатиб, кабинет орқали тикет очиш кифоя.

Муаммо қайтмаслиги учун

Соатлик лимит муаммоси кўпинча сайт ўсиб, трафик ошган пайтда биринчи марта намоён бўлади. Шунинг учун реклама кампанияси ёки мавсумий акция олдидан базага уланиш лимитлари сайтнинг кутилаётган юкига етишини олдиндан аниқлаб олиш фойдали. Хато логини ҳафтасига бир марта кўздан кечириш, кеш ишлаётганини текшириш ва кераксиз ботларни чеклаш сайтни бундай кутилмаган узилишлардан ҳимоя қилади.