508 Resource Limit Is Reached: пълна диагностика и решение
508 не е грешка на WordPress. Идва от сървъра, преди PHP изобщо да е тръгнал. Ето кой лимит я причинява, как да го докажете с команди и реален изход, и какво да правите, когато цял сървър започне да я връща.
Сайтът ви работеше нормално, а в един момент започва да връща бяла страница с надпис 508 Resource Limit Is Reached. След пет минути се оправя сам. След час се появява отново.
Ако потърсите какво да направите, ще намерите десетки статии, които ви съветват да деактивирате плъгините един по един или да смените темата. Понякога това наистина помага — но по-често не помага, защото 508 изобщо не идва от WordPress. Идва от сървъра, при това преди PHP да е стартирал. Каквото и да пише в плъгините ви, то дори не е било прочетено, когато е върнат отговорът.
Тази статия минава през реалната диагностика: кой лимит точно причинява 508, как да го докажете с конкретни команди вместо да гадаете, и какво да правите в редкия, но много неприятен случай, когато грешката се появи едновременно на всички сайтове на сървъра.
Какво всъщност означава 508
Повечето споделени хостинги работят с CloudLinux. Идеята му е проста: всеки хостинг акаунт живее в собствен контейнер, наречен LVE (Lightweight Virtual Environment), със собствени лимити за памет, процесор и брой процеси. Така един акаунт, който изведнъж започне да изяжда сървъра, не поваля останалите петдесет.
Модулът на уеб сървъра, който налага това, се казва mod_hostinglimits. При всяка заявка той се опитва да постави процеса в LVE-то на съответния акаунт. Когато не успее — най-често защото акаунтът вече е достигнал лимита си за едновременни заявки — уеб сървърът връща 508 и приключва. PHP не се стартира, WordPress не се зарежда, базата не се пита.
Затова изтриването на плъгин рядко променя нещо веднага. Влияе на колко дълго работи всяка заявка, а не на колко заявки има в момента.
Петте лимита и как изглежда всеки от тях
LVE не е един лимит, а няколко, и всеки се проявява по различен начин. Това е първото, което трябва да знаете, защото симптомът ви казва кой лимит е ударен:
| Лимит | Какво брои | Какво виждате при достигане |
|---|---|---|
| EP (entry processes) | Едновременните заявки, които влизат в акаунта | 508 Resource Limit Is Reached |
| NPROC | Всички процеси в акаунта — PHP, cron, MySQL, поща | Процесите не могат да се стартират, обикновено 500 |
| PMEM | Физическата памет на акаунта | Процесите биват убивани — бял екран или 500 |
| SPEED (CPU) | Процесорното време | Сайтът се бави, но не дава грешка |
| IO / IOPS | Скоростта и броят операции към диска | Сайтът “виси”, докато чака данните, без грешка |
Ако имате root достъп, точните стойности за сървъра се виждат с една команда:
lvectl list | head ID SPEED PMEM VMEM EP NPROC IO IOPS
default 200 2048M 0K 30 75 50000 2048
3220 200 4096M 0K 30 75 250000 5120Тук default е пакетът, който важи за повечето акаунти: 30 едновременни заявки, 75 процеса общо, 2 GB памет. Редът отдолу е акаунт с вдигнат лимит. Числата на вашия сървър ще са различни, но подредбата на колоните е същата.
Обърнете внимание на последните два реда в таблицата по-горе. Превишаването на IO лимита обикновено не генерира грешка — сайтът просто спира да отговаря, докато чака данните да стигнат от диска до паметта. Хора често търсят грешка, която не съществува, вместо да погледнат правилния показател.
За 508 обаче отговорът е почти винаги един: EP. Твърде много едновременни заявки към акаунта.
Първият въпрос: само вашият сайт ли е засегнат?
Тук пътищата се разделят и оттук нататък говорим за два напълно различни проблема, които показват една и съща страница.
Проверката отнема половин минута:
curl -sI https://вашият-домейн/ | head -1
curl -sI https://вашият-домейн:2083/ | head -1HTTP/1.1 508 Resource Limit Is Reached
HTTP/1.1 200 OKАко cPanel отговаря нормално, а сайтът дава 508, проблемът е в акаунта ви — продължете със следващата секция. Ако и двете дават 508, минете директно на секцията за LVE модула. Това е рядък случай, но е пълна авария и никой от обичайните съвети няма да свърши работа.
Ако нямате достъп до конзола, същото се проверява и на ръка: отворете cPanel и уебмейла си в браузъра, а ако познавате друг сайт на същия сървър — и него.
Случай А: вашият акаунт е достигнал лимита си
Погледнете фактите, преди да променяте каквото и да било
В cPanel отидете на Metrics → Resource Usage. Там има раздел с “faults” — колко пъти акаунтът е ударил всеки от лимитите и кога. Това е единственото място, което ви казва истината. Ако виждате faults по EP, значи заявките са твърде много едновременно. Ако виждате faults по PMEM, проблемът е паметта и 508 е само страничен ефект.
Ако имате root достъп до сървъра, същото се вижда по-подробно:
lveinfo --period=1h -o PMemf -d \
--show-columns=ID,From,To,uEP,lEP,EPf,uPMem,lPMem,PMemF ID | From | To | uEP | lEP | EPf | uPMem | lPMem | PMemF
------+---------------------+---------------------+-----+-----+------+-------+-------+-------
2523 | 2026-08-12 12:00:00 | 2026-08-12 13:00:00 | 1 | 30 | 0 | 2.00G | 2.00G | 1149
3012 | 2026-08-12 12:00:00 | 2026-08-12 13:00:00 | 1 | 30 | 0 | 2.00G | 2.00G | 983
2442 | 2026-08-12 12:00:00 | 2026-08-12 13:00:00 | 4 | 30 | 612 | 1.31G | 2.00G | 0Колоните се четат така: тези с малко u отпред са използваното, тези с малко l — лимитът, а тези, които завършват на f или F — броят faults, тоест колко пъти лимитът е бил ударен.
- Ред
2442е класическият случай на 508:uEP 4при лимитlEP 30в момента на снимката, но 612 EP faults за периода. Заявките идват на пикове и при всеки пик акаунтът се удря в тавана. - Редове
2523и3012изглеждат обратното: нула EP faults, ноuPMemе точно колкотоlPMem— паметта е опряла в тавана и има хиляда faults по PMEM. Тук 508 е следствие, а истинският проблем е паметта. Ще се върнем на този случай накрая, защото крие капан.
Пуснете същата команда и за едно денонощие и сравнете двете:
lveinfo --period=1d -o PMemf -d \
--show-columns=ID,From,To,uEP,lEP,EPf,uPMem,lPMem,PMemFТова е дребен трик, който спестява много време: ако числата за един час и за едно денонощие са почти еднакви, всичко се е случило в последния час — значи имате внезапно събитие, а не бавно влошаване. Обратното — високи 24-часови стойности при ниски едночасови — означава хроничен проблем, който тлее отдавна и е съвсем различен разговор.
Кой всъщност прави заявките
Faults ви казват че има проблем. Логовете за достъп казват кой го прави. От SSH в самия акаунт:
cd ~/access-logs && lsexample.com example.com-ssl_log shop.example.com shop.example.com-ssl_logФайлът без наставка е за HTTP, този със -ssl_log — за HTTPS. Реалният път на сървъра е /etc/apache2/logs/domlogs/ПОТРЕБИТЕЛ, а през панела същото се сваля от cPanel → Raw Access.
Всеки ред е една заявка, тоест един процес:
IP - - [Дата] "Заявка" Код Размер "Referer" "UserAgent"Пребройте кои адреси ви удрят най-много:
awk '{print $1}' example.com-ssl_log | sort | uniq -c | sort -rn | head 4187 203.0.113.47
3902 198.51.100.22
118 66.249.66.1
41 192.0.2.15
33 192.0.2.88Разликата между първите два реда и останалите е целият отговор. Четири хиляди заявки от един адрес не са посетител. Проверете какво точно искат:
grep 203.0.113.47 example.com-ssl_log | tail -3203.0.113.47 - - [12/Aug/2026:12:14:03 +0300] "POST /wp-login.php HTTP/1.1" 200 4021 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
203.0.113.47 - - [12/Aug/2026:12:14:03 +0300] "POST /wp-login.php HTTP/1.1" 200 4021 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
203.0.113.47 - - [12/Aug/2026:12:14:04 +0300] "POST /wp-login.php HTTP/1.1" 200 4021 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"Три опита за влизане в рамките на една секунда. Ето откъде идват заявките.
Същото за най-търсените адреси, вместо за IP-та:
awk -F'"' '{print $2}' example.com-ssl_log | awk '{print $2}' \
| sort | uniq -c | sort -rn | head -5 8214 /wp-login.php
1902 /xmlrpc.php
884 /wp-admin/admin-ajax.php
311 /
204 /wp-cron.phpАко видите тази картина, знаете точно какво да ограничите.
Какво работи в момента
Другата половина от отговора е кои процеси реално се въртят. От SSH в акаунта:
ps -u $USER -o pid,etime,%cpu,%mem,cmd --sort=-%cpu | head PID ELAPSED %CPU %MEM CMD
31402 04:11 24.6 1.9 lsphp /home/user1/public_html/wp-cron.php
31455 03:58 22.1 1.8 lsphp /home/user1/public_html/wp-admin/admin-ajax.php
31501 03:44 19.7 2.1 lsphp .../plugins/updraftplus/includes/class-backup.php
31502 03:44 18.9 2.0 lsphp .../plugins/updraftplus/includes/class-backup.php
31503 03:43 18.2 2.1 lsphp .../plugins/updraftplus/includes/class-backup.php
31504 03:41 17.4 1.9 lsphp .../plugins/updraftplus/includes/class-backup.phpТук всичко е налице: четири едновременни процеса на UpdraftPlus, всеки работил вече близо четири минути, плюс wp-cron.php и admin-ajax.php. Шест слота от трийсет са заети, без нито един реален посетител. Достатъчно е малко трафик отгоре и акаунтът е пълен.
Ако правите тази проверка като администратор на сървъра, не разчитайте на
psза процент процесор —psдава средното за целия живот на процеса, а не моментното. За моментна картина използвайтеtop. Тази подробност вече е струвала петнайсет минути в реален инцидент.
Реалните причини, подредени по честота
Ботове по wp-login.php и xmlrpc.php. Най-честата причина изобщо, точно както в примера по-горе. Всеки опит за влизане е отделна заявка, а ботовете ги правят по няколко в секунда. Акаунтът достига лимита си за секунди и сайтът пада, без реален посетител да е виновен.
Backup плъгини, които работят на партиди. UpdraftPlus е класическият пример: вместо един процес, който върви дълго, той пуска отделни процеси за плъгините, темите, качените файлове, базата, ядрото и така нататък. Ако в акаунта имате няколко сайта и бекъпите им тръгнат по едно и също време, ще видите десетки едновременни PHP процеса от нищото.
admin-ajax.php. WordPress Heartbeat и плъгини, които постоянно чукат на този файл. Всяко чукане е заявка. Отворен админ панел в няколко раздела на браузъра също се брои.
Липса на кеширане. Без кеш всяка визита минава през пълния цикъл PHP и MySQL. При кеш повечето заявки се обслужват като готов HTML и изобщо не влизат в лимита.
Бавни MySQL заявки. Заявка се смята за бавна, когато се изпълнява над три секунди. През това време процесът е зает и слотът е блокиран. Двайсет такива заявки едновременно и акаунтът е пълен, дори трафикът да е скромен.
Истински трафик. Понякога причината е приятна — публикация се е разпространила и сайтът просто е надраснал плана си.
Какво помага наистина
По ред на ефект спрямо усилието:
- Пуснете кеш. LiteSpeed Cache, ако хостингът ви е на LiteSpeed, иначе WP Rocket или еквивалент. Това е единичната промяна с най-голям ефект и почти винаги е достатъчна. Проверете, че работи, вместо да вярвате на настройката:
curl -sI https://вашият-домейн/ | grep -i 'x-litespeed-cache\|x-cache'x-litespeed-cache: hithitозначава, че страницата е дошла от кеша и PHP изобщо не е тръгнал. Ако видитеmissпри всяко презареждане, кешът е включен само на хартия. - Сложете Cloudflare пред сайта и ограничете достъпа до
wp-login.phpиxmlrpc.php. Спира ботовете, преди изобщо да стигнат до сървъра. - Преместете бекъпите извън пиковите часове и изключете режима на партиди, ако плъгинът го позволява.
- Изключете вградения WordPress cron и го заменете със системен. В
wp-config.php, преди реда/* That's all, stop editing! */:
След това добавете cron задача от хостинг панела:define('DISABLE_WP_CRON', true);
Проверката, че наистина е изключен:*/15 * * * * cd /home/user1/public_html && /usr/local/bin/php wp-cron.php >/dev/null 2>&1wp config get DISABLE_WP_CRON1 - Оптимизирайте бавните заявки. Това вече е работа за разработчик и хостингът няма да го направи вместо вас — но е и единственото решение, ако причината е там.
- Едва накрая вдигнете лимита. Ако предишните пет не са помогнали, акаунтът просто е надраснал споделения хостинг.
Какво не помага
Изтриване на плъгини наслуки. Смяна на темата. Изчакване с надеждата да мине. И трите се срещат във всяка статия по темата и трите оставят причината непокътната — сайтът пада отново при следващия пик.
Случай Б: всички сайтове на сървъра дават 508
Тук стигаме до частта, която почти никъде няма да намерите написана.
Ако всеки сайт на сървъра връща 508 — не един акаунт, а всички, включително панелът — това не е проблем с ресурси. Никой не е достигнал лимита си. Проблемът е, че LVE изобщо не работи, а щом уеб сървърът не може да постави процеса в LVE, той връща 508 по подразбиране.
Двата сигурни признака. Първо, /var/log/messages се пълни с:
grep -i 'pam_sulve' /var/log/messages | tail -3Aug 12 11:58:02 srv12 sshd[19187]: pam_sulve[19187]: Unable to initialize check LVE 2
Aug 12 11:58:14 srv12 sshd[19203]: pam_sulve[19203]: Unable to initialize check LVE 2
Aug 12 11:58:31 srv12 crond[19288]: pam_sulve[19288]: Unable to initialize check LVE 2Двойката накрая е ENOENT — PAM модулът не намира /proc/lve.
Второ, lvectl се проваля:
lvectl listerror: clcommon: get_lve_version: Can`t open file /proc/lve/listТова не е проблем с CageFS. Рестартирането или преинициализирането на CageFS няма да помогне и само добавя риск по време на авария. Не си губете времето там.
Проверките
Всичко тук е само за четене. Нищо не променя системата.
uname -r
lsmod | grep -i lve
ls -l /proc/lve/Счупено изглежда така:
5.14.0-284.1101.el8.tuxcare.11.els9.x86_64
ls: cannot access '/proc/lve/': No such file or directorylsmod не връща нито ред, а /proc/lve/ изобщо не съществува. За сравнение, на здрав сървър същите три команди дават:
4.18.0-553.144.1.lve.el8.x86_64
kmodlve 823296 310
total 0
-r--r--r-- 1 root root 0 Aug 12 14:02 listСлед това вижте кои пакети са инсталирани:
rpm -qa | grep -Ei 'kmod-?lve|^lve-'kmod-lve-2.1-69.el8.x86_64
kmod-lve-2.1-71.1.el8.x86_64
lve-utils-6.4.1-1.el8.cloudlinux.x86_64Две различни версии на kmod-lve едновременно е известен проблем — според CloudLinux трябва да присъства само една, защото старата може да се опита да се зареди вместо правилната.
Сега най-важната проверка — за кои ядра изобщо има построен модул:
find /lib/modules -name 'kmodlve*'/lib/modules/4.18.0-553.111.1.lve.el8/extra/lve-2.1-71.1/kmodlve.ko
/lib/modules/4.18.0-553.111.1.lve.el8/extra/lve-2.1-69/kmodlve.ko
/lib/modules/5.14.0-284.1101.el8.tuxcare.11.els7/weak-updates/lve-2.1-56/kmodlve.ko
/lib/modules/4.18.0-553.144.1.lve.el8/weak-updates/lve-2.1-71.1/kmodlve.koСравнете тези имена с това, което върна uname -r. Работещото ядро беше ...els9, а в списъка има ...els7 и три ядра от линията 4.18. Ядрото, което върви в момента, го няма никъде — това е причината.
Потвърдете с modprobe:
modprobe kmodlve; echo "rc=$?"modprobe: FATAL: Module kmodlve not found in directory /lib/modules/5.14.0-284.1101.el8.tuxcare.11.els9.x86_64
rc=1Ако съобщението е друго, вижте и dmesg:
dmesg | grep -i -E 'lve|module verification|signature' | tail -20Текстът на грешката ви казва в кой случай сте:
| Грешка от modprobe | Значение | Посока |
|---|---|---|
Module kmodlve not found in directory ... | Няма модул за това ядро | Смяна на ядрото, вижте по-долу |
Invalid argument / version magic | Несъответствие модул–ядро | Обновете kmod-lve |
Cannot allocate memory | Проблем с cgroup или GRUB | Статията на CloudLinux за cgroup и GRUB |
Отхвърлен подпис в dmesg | Secure Boot | Проверете mokutil --sb-state |
Как се стига дотук
Примерът по-горе е от истинска авария. Обновяване на TuxCare ELS е преместило машината от els7 на els9, а за els9 няма LVE модул. Ядрото по подразбиране също е било сменено на els9, така че състоянието е преживявало рестартите. Сървърът си е вдигал всеки път — просто без LVE, и всеки сайт на него е връщал 508.
Решението
Изберете ядро, което отговаря на трите условия едновременно: присъства в /boot, има kmodlve.ko под /lib/modules/<ядро>/, и е актуално откъм сигурност.
ls /boot/vmlinuz-*/boot/vmlinuz-0-rescue-8a3f1c
/boot/vmlinuz-4.18.0-553.111.1.lve.el8.x86_64
/boot/vmlinuz-4.18.0-553.144.1.lve.el8.x86_64
/boot/vmlinuz-5.14.0-284.1101.el8.tuxcare.11.els9.x86_64Сравнено със списъка от find, единственият смислен избор тук е 4.18.0-553.144.1.lve.el8.x86_64 — има модул и е по-новото от двете.
Две правила, които спестяват втора авария:
- Никога не избирайте
+debugядро. За debug ядрата не се строи LVE модул. - Предпочитайте по-ново. Към момента на писане
GhostLock(CVE-2026-43499) изискваkernel-4.18.0-553.141.2.lve.el8или по-ново за CloudLinux 8.
Проверете, че файлът на модула е истински, а не увиснал символен линк:
ls -lL /lib/modules/4.18.0-553.144.1.lve.el8/weak-updates/lve-2.1-71.1/kmodlve.ko-rw-r--r-- 1 root root 823296 Jul 30 09:14 /lib/modules/4.18.0-553.144.1.lve.el8/weak-updates/lve-2.1-71.1/kmodlve.koКлючът е -L — той следва линка. Реален файл с размер е добре. Ако вместо това видите:
ls: cannot access '/lib/modules/.../kmodlve.ko': No such file or directoryзначи линкът е увиснал и трябва да изберете друго ядро.
След това задайте ядрото по подразбиране. Тази стъпка променя само записа за зареждане, нищо на работещата система, и е обратима:
grubby --set-default=/boot/vmlinuz-4.18.0-553.144.1.lve.el8.x86_64
grubby --default-kernel/boot/vmlinuz-4.18.0-553.144.1.lve.el8.x86_64Втората команда трябва да ви върне точно избраното ядро. Ако все още показва старото, спрете и проверете GRUB_DEFAULT=saved и grubenv, преди да рестартирате.
И чак тогава рестартирайте — с осигурен достъп до конзолата или IPMI, преди да натиснете Enter.
Проверка след рестарта
uname -r
lsmod | grep kmodlve
lvectl list | headЗдравото състояние изглежда така:
4.18.0-553.144.1.lve.el8.x86_64
kmodlve 823296 310
ID SPEED PMEM VMEM EP NPROC IO IOPS
default 200 2048M 0K 30 75 50000 2048
3220 200 4096M 0K 30 75 250000 5120Важна подробност: lvectl list трябва да показва истински потребителски ID-та, а не само default. Ако виждате единствено default и limit, това е друг проблем — става дума за преинсталация на потребителските пакети на LVE.
Накрая проверете и от страната на посетителя:
curl -sI https://вашият-домейн/ | head -1
grep -i 'pam_sulve\|initialize check LVE' /var/log/messages | tail -5HTTP/1.1 200 OK
Aug 12 11:58:31 srv12 crond[19288]: pam_sulve[19288]: Unable to initialize check LVE 2Очаквате 2xx или 3xx, и в лога — никакви редове с pam_sulve с време след рестарта. Единственият останал ред тук е отпреди аварията, което е точно каквото трябва да видите.
Капанът: нула faults не значи, че всичко е наред
Това си струва отделна секция, защото подвежда дори опитни хора. Върнете се на редове 2523 и 3012 от изхода на lveinfo в началото — нула EP faults, а паметта опряла в тавана.
При една авария lveinfo показваше точно това: EPf 0 за акаунти, които в същия момент работеха с по 63 до 66 процеса при лимит от 30. По всички видими показатели лимитите се спазваха. Не се спазваха.
Причината е в начина на броене. LVE отчита entry process в момента, в който заявката влиза през HTTP. Но при LiteSpeed backend процесите на LSAPI се държат в пул извън това отчитане, така че EP просто никога не се задейства. В резултат единственият лимит, който реално ограничава акаунта, остава PMEM — а PMEM ограничава по съвсем различен начин: не задържа заявки на опашка, а убива процеси.
Пребройте процесите директно и сравнете с lEP от lveinfo:
for u in user1 user2 user3; do
printf "%-10s procs=%s\n" $u \
$(wc -l < /sys/fs/cgroup/memory/lve$(id -u $u)/cgroup.procs)
doneuser1 procs=66
user2 procs=63
user3 procs=64Шейсет и шест процеса при лимит трийсет. Това е нарушението, което faults не показаха.
След това вижте кои акаунти опират в тавана на паметта си:
cd /sys/fs/cgroup/memory
for d in lve*; do
echo "$(( $(cat $d/memory.usage_in_bytes) * 100 / $(cat $d/memory.limit_in_bytes) ))% $d"
done | sort -rn | head -10100% lve2523
99% lve3012
99% lve2540
99% lve2442
97% lve2425
59% lve2891
41% lve3104
38% lve2677
22% lve3390
19% lve2115Търсите точно този рязък спад — пет акаунта на тавана, а шестият изведнъж на 59 процента. Всичко над ръба е заподозряно. Ако няма такъв спад и всички стойности са умерени, проблемът е другаде.
Последната проверка казва защо това е толкова опасно:
grep -E '^(rss|cache)' /sys/fs/cgroup/memory/lve2523/memory.stat
free -h | grep -i swaprss 2127155200
cache 3313664
Swap: 0B 0B 0Brss е около 2 GB, тоест точно на лимита. cache е паднал до 3 MB — това е доказателството, че ядрото вече е опитало да освободи памет и е взело всичко, което е могло. А без swap анонимната памет не може да бъде освободена изобщо. Оттук нататък всяко ново заделяне влиза в безкраен цикъл на неуспешно освобождаване и изяжда процесор в ядрото, докато целият сървър се задавя.
Ако сте стигнали дотук, потвърждението е в dmesg:
dmesg -T | grep -i 'oom' | tail -3[Wed Aug 12 12:31:07 2026] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/lve2523,task_memcg=/lve2523,task=lsphp,pid=48211,rss=19422
[Wed Aug 12 12:31:07 2026] Memory cgroup out of memory: Killed process 48211 (lsphp) total-vm:412904kB, anon-rss:77688kB, file-rss:0kB
[Wed Aug 12 12:31:08 2026] Memory cgroup out of memory: Killed process 48219 (lsphp) total-vm:409512kB, anon-rss:76104kB, file-rss:0kBCONSTRAINT_MEMCG означава лимит на акаунта, не на сървъра — свободната памет на машината може да е 80 процента и това пак да се случва. oom_memcg=/lve2523 ви дава директно кой акаунт е. А убитите процеси са по 76–77 MB всеки, което значи, че няма един лаком процес — натискът е сборен. Не търсете теч на памет там, където го няма.
Как да не се повтори
От страната на сървъра:
- Обновявайте
kmod-lveв същия прозорец, в който обновявате ядрото. Това е инструкция на самия CloudLinux и точно този пропуск причинява аварията. - Пускайте
grubby --default-kernelслед всяко обновяване на ядро. - Дръжте само една версия на
kmod-lve:
Ако редът е повече от един, махнете старата версия в планиран прозорец с достъп до конзолата — не върху току-що възстановена машина.rpm -qa 'kmod-lve*' | sort -V - Ако на машината съжителстват TuxCare ELS ядра и стандартни CloudLinux 8 ядра, решете на коя линия оставате и изключете другата от обновяванията, за да не стане тя мълчаливо ядро по подразбиране.
От страната на сайта:
- Кеш, който наистина работи, и проверка с
curl -sI, че наистина се използва. - Cloudflare с ограничения по
wp-login.phpиxmlrpc.php. - Бекъпи в часовете с малко трафик.
- Периодичен поглед към Resource Usage, вместо да чакате сайтът да падне.
Накратко
508 не е грешка на WordPress — идва от mod_hostinglimits и почти винаги означава твърде много едновременни заявки към акаунта.
Първо проверете с curl -sI дали пада само сайтът, или и панелът. Ако е само сайтът, погледнете faults в Resource Usage или lveinfo, после логовете за достъп — те ще ви кажат кой прави заявките. Ако пада всичко, търсете LVE модула: lsmod, /proc/lve и modprobe kmodlve ще ви отговорят за минута.
И не забравяйте, че нула faults не е доказателство за здраве. Понякога лимитът, който би трябвало да ви пази, просто не се задейства.
Снимка: A view of the server room at The National Archives — The National Archives (UK), CC BY 3.0, кадрирана.
Ако сайтът ви пада редовно с 508 и не ви се занимава с диагностиката, пишете ни — правим и оптимизация на сайтове, и сървърна администрация.
