Високе навантаження створювана WordPress-блогом на сервер і вкрай безглузде рішення цієї проблеми
Привіт, шановні читачі блогу KtoNaNovenkogo.ru. C настане Вас святами!
У цей проміжок часу (десь близько півгодини) админка видає 502 помилку, а для відвідувачів сайт хоч і доступний, але сторінки відкриваються досить повільно (від 5 до 15 секунд). Якби кешування на блозі не використовувалося, то і вони б видавали 502 помилку. Допомагає тільки або дворазова перезавантаження сервера, або тупе очікування поки все само собою розсмокчеться.
Загалом, підтримку Інфобокс я замучив за ці місяці грунтовно (можна невелику брошуру з листуванням видавати). Нижче наведу ті варіанти виходу з ситуації, що неприємній ситуації, які були випробувані, ну і опишу той безглуздий випадок, що допоміг від цієї капосної ситуації ніби як позбутися (у всякому разі, останні три дні її не спостерігаю, але якщо все ж вилізе, то відпишу потім про катастрофу надій).
Епізодично надмірне навантаження WordPress на сервер
З чого все почалося вже точно не пам'ятаю. Пам'ятаю тільки, що якихось прив'язок або логічних висновків тоді зробити не вдалося. Загалом, почалося все раптово і причини виявити не вдалося. Бо ж не за довго до цього я боровся з вірусами на ряді своїх сайтів. то в перший час після виникнення проблеми грішив саме на злом (або на не до кінця вичищені Шели та іншу гидоту). Тому з цього віртуального виділеного сервера були перенесені всі сайти крім двох, але ситуація не змінилася.
Видимої причини не було, тому вирішив, що, можливо, ДДОС хтось. Сам в адмініструванні серверів я ні бум-бум (боюся цієї справи навіть), тому попросив техподдержу Інфобокс на цю тему мені що-небудь відповісти, хоча вони не зобов'язані в це влазити, бо в мене не звичайний віртуальний хостинг, а віртуальний виділений сервер, де я вже сам собі пан, а техпідтримка хіба що тільки за хост-машину відповідає, де цей сервер фізично розташовується.
Однак, після традиційного «ми це робити не повинні, але все ж зробимо» хлопці з техпідтримки сказали, що судячи з усього ДДОС немає (хоча якусь фільтрацію агресивних IP вони все ж налаштували на всякий пожежний). Навантаження ж, на їхню думку, генерує сам сайт. Правда, через кілька років мене все ж по справжньому атакували і захиститися допоміг лише CloudFlare (спасибі йому за це).
Я ж їм відповідав, що в звичайному режимі навантаження вкрай низька, бо на обох WordPress блогах встановлений плагін Hyper Cache з 10 денним періодом відновлення закеширувалася сторінок. Власне, в Parallels, який використовується в Інфобокс. є панелька, де навантаження на сервер по процесору і пам'яті можна відстежувати в реальному часі. Зазвичай там досить ідеалістична картинка відображається:
Але кілька разів за добу ці значення виростають до 100% (самий затикаючи починається, коли пам'ять забивається на всі 100) і сайт навіть з боку відвідувачів починає ледве перевертатися. Техпідтримка протягом усього періоду моїх звернень до них щось намагалася запропонувати, моніторили сервер в перебігу декількох діб і нічого особливо не помічали такого, на що можна було б вплинути і «зробити всім нам добре».
З того, що запам'яталося перерахую:
- Міняли на всі боки значення максимального числа підключень (так і не зрозумів чого це таке), але все без толку. По-моєму, навіть при збільшенні цього числа сайт з боку відвідувачів в момент високого навантаження тупив ще сильніше.
- Підвищували тарифний план (на пару тижнів в тестовому режимі - без доплати) з мого Linux VPS-2048 до 4 гигов оперативки і подвійного збільшення процесорної продуктивності. Як ні парадоксально, але баги зі 100% навантаженням не тільки залишилися, але і приводили практично до повної недоступності сайту для відвідувачів (не дивлячись на кешування), бо сторінки відкривалися по хвилині. Тому екстрено все повернули назад.
- Переводили з звичайного віртуального сервера (типу контейнер) в хмару. Нічого не змінилося, хіба що перевантажуватися сервер в цьому режимі став істотно довше. Тому повернули знову ж все взад.
Я вже сам своїм куцим розумом став думати, що може служити причиною цієї неприємності. Пробував гратися з налаштувань Хіпер Кеша - відключав кешування на льоту, ще з якимись незрозумілими мені галочками експерименти проводив. До речі, по ходу справи зробив чуйний дизайн для блогу і зумів таки добити техпідтримку Інфобокс, щоб вони мені в nginx кешування статичних елементів в браузерах користувачів налаштували. Але все це очікувано не принесло зовсім ніяких зрушень у вирішенні проблеми з епізодично високим навантаженням на сервер.
Блін, поки писав попередній абзац згадав, що в цю сторону я вже думав - Як захистити адмінку свого сайту від злому? і тоді це теж очікуваного результату не принесло. Виходить, що я вже по другому колу пішов. До речі, наймати спеца я чомусь боюся, бо доведеться надавати йому доступ до сайту, а це стрьомно. Хлопці з хостингу кажуть, що їм ніколи, навіть якщо я їм оплачує витрачений час і сили.
Власне, в силу того, що перепробувано було вже все, що тільки могло прийти в голову мені або тим, хто писав на цю тему в інтернеті (в міру моїх скромних розумових здібностей, звичайно ж), вірити в «диво» я вже перестав і воно, як водиться, прийшло зовсім несподіваним.
Як вдалося вирішити проблему (сподіваюся, що остаточно)
Все почалося з того, що кілька днів тому щось спонукало мене подивитися на вихідний код одній зі сторінок свого блога. Справа ця вельми корисна, бо в шапці (між тегами Head) WordPress має погану звичку пхати абсолютно зайві метатеги і службові гіперпосилання link. які можуть погіршувати ставлення пошукових систем до сайту.
За прикладами довго ходити не треба - зовсім недавно виявив там таку гидоту, що волосся стало дибки. Про її виявленні і видаленні навіть окремий пост написав (хоча тема вже спливала досить давно, але я її не сприйняв тоді серйозно) - Проблема з All in One SEO Pack і її рішення.
Загалом, за WordPress потрібне око та око. Так, движок безкоштовний, при цьому професійний і просто чумний, але надмірності всякі нехороші ні-ні та й проскакують. Ось. Цього разу погляд теж зачепився за «щось новеньке». Це були три рядки коду (а точніше три службових гіперпосилання) знову ж в шапці сторінки формованої WordPress:
Крім цього у вихідному коді був ще і сильно кидається в очі блок:
Це варіант самого повного відключення підтримки емодзі в WordPress. Хочете в адмінці залиште. Все, після цього настав приємне відчуття чистоти коду від всяко різного.
Все, отримав задоволення хоча б від часткового вирішення проблеми з чистотою вихідного коду і продовжив займатися рутиною (написанням статей та іншими дурницями).
Як прийшло усвідомлення
Однак, на наступний день закрався сумнів - щось давно багів не було. Начебто вже довго з сайтом працюю, а 502 в адмінки не виникає. Вірити в диво було не з руки, бо вже раз десять починав святкувати перемогу, а черговий завісон повертав мене на землю.
Однак, почекавши ще трохи по ходу згадав, що при пошуку рішення з видалення підтримки емодзі запам'яталося, що цей код з'явився в WordPress починаючи з версії 4.2, але ж вона вийшла якраз навесні, коли у мене і почалися трабли. Цілком ймовірно, що саме це оновлення WordPress до чергової версії і стало причиною появи бага з епізодично високим навантаженням.
У всякому разі за термінами і по тому, що проблема не проявляється після видалення коду підтримки емодзі, можна було зробити певні висновки. Я їх зробив і написав цей пост. Якщо проблема вилізе знову, то трохи нижче з'явиться P.S. з жалем з приводу марно витраченого часу (вами на читання, а мною на написання).
Рішення вийшло дійсно безглуздим, принаймні дивлячись з моєї, вкрай невисокою в розумовому плані, дзвіниці. Де логіка? Не знаю, але все одно приємно, що нехай і випадково, але мучило мене досить довго технічний казус більш-менш вдало вирішилося. За сім дозвольте відкланятися. Дякую за увагу і ще раз з настало свято.
Удачі вам! До швидких зустрічей на сторінках блогу KtoNaNovenkogo.ru