504 Gateway Timeout: mit jelent, és hogyan javítsa

Mit jelent a hiba

A 504 az, amikor az elöl álló webszerver (nginx, Apache, terheléselosztó, CDN) feladja a mögötte lévő alkalmazást. A kérést továbbadták, a háttér dolgozni kezdett, és az eleje időzítője lejárt, mielőtt válasz érkezett volna. A 502 Bad Gateway hibától az a különbség, hogy a háttér elérhető; csak túl lassú. A tipikus időzítők: 60 másodperc nginxben (fastcgi_read_timeout, proxy_read_timeout), 60 másodperc Apache-ban (ProxyTimeout) és 100 másodperc a Cloudflare-nél, amelyet az ingyenes csomagban nem módosíthat.

Az időtúllépés emelése ritkán a megoldás. Valami túl sokáig tart, és ezt a valamit kell megtalálnia.

Gyakori okok

1. Lassú adatbázis-lekérdezés. Egy WordPress-bővítmény, amely minden oldalbetöltésnél megszámolja egy hatalmas tábla sorait, egy hiányzó index, egy wp_options tábla tele lejárt tranziensekkel. Minden kérés vár, és terhelés alatt a várakozások összeadódnak.
2. Egy külső hívás, amely elakad. Az alkalmazás egy fizetési szolgáltatót, egy levelezőszolgáltatást, egy időjárás-API-t vagy egy licencszervert hív, és az a szolgáltatás lassú vagy leállt. Ha a hívásnak nincs időtúllépése, az oldala vár rá.
3. Túl kevés worker. Minden PHP-FPM-worker lassú kérésekkel van elfoglalva; az újak sorban állnak, amíg az eleje feladja. Kívülről ez időtúllépésnek néz ki, noha minden egyes kérés gyors lenne.
4. Előtérben futó cron vagy mentés. Egy mentésbővítmény, egy importálás, egy 50 000 URL-es oldaltérkép: webes kérésen belül előállítva minden időtúllépést túlléphetnek.
5. Lemez-I/O vagy swap. A szerver kifogy a memóriából, és swapel; minden tizedére lassul. Magas terhelésként látszik alacsony CPU-használat mellett.
6. Hálózat az eleje és a háta között. Egy terheléselosztó az egyik adatközpontban, a háttér egy másikban, egy tűzfal, amely csendben eldobja a csomagokat. Ritka, de egy minden kérésnél jelentkező 504 tétlen háttér mellett erre utal.

Ha látogató

Töltse újra egy perc múlva. Ha az oldal inkább lassú, mint leállt, próbáljon egy másik oldalt; az időtúllépés egyetlen nehéz oldalhoz kötődhet.

Ha a saját oldala: először ellenőrizze

Futtassa a weboldal-leállás ellenőrzőt: kívülről jelenti az állapotkódot és a válaszidőt. Egy oldal, amely ma 30 másodperc alatt válaszol, holnap terhelés alatt 504-et fog mutatni.

Saját szerveren derítse ki, hová megy az idő:

# halmozódnak-e a workerek?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# mit csinál a PHP éppen most? (a poolban pm.status_path kell)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: mely lekérdezések futnak, és mióta?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# memória és swap
free -m
vmstat 1 5

Egy ugyanazzal a lekérdezéssel teli folyamatlista, vagy a vmstat nem nulla si/so oszlopai megnevezik az okot.

Javítások a saját szerveren

1. Kapcsolja be a lassú lekérdezések naplóját, és javítsa a lekérdezést

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Néhány perc után a sudo mysqldumpslow -s t /var/log/mysql/slow.log | head felsorolja a legrosszabb lekérdezéseket. Adja hozzá a hiányzó indexet, vagy keresse meg a lekérdezést futtató bővítményt, és cserélje le. WordPressben a felpuffadt options tábla klasszikus eset:

wp transient delete --all
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Bármi, ami több száz kilobájtos, és minden kérésnél automatikusan betöltődik, eltávolítási jelölt.

2. Tegyen időtúllépést a külső hívásokra

Az alkalmazás minden HTTP-hívásának saját időtúllépés kell, amely rövidebb a webszerverénél. PHP-ben cURL-lel: CURLOPT_CONNECTTIMEOUT 5 és CURLOPT_TIMEOUT 10. WordPressben a wp_remote_get() timeout argumentumot fogad; sok bővítmény az alapértéken hagyja, és a végtelenségig vár. Ha egy harmadik fél szolgáltatása leáll, az oldalnak veszíteni kell a működéséből (az űrlapot az élő szállítási díj nélkül mutassa), nem pedig meghalni.

3. Vigye ki a hosszú munkát a kérésből

A mentések, importok, exportok, nagy oldaltérképek és a levélküldés cron jobba vagy sorba valók, nem egy oldalmegtekintésbe. WordPressnél kapcsolja ki a pszeudo-cront, és futtassa a valódit:

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

4. Gondosan állítsa az időtúllépéseket

Ha egyetlen oldalnak jogosan több idő kell (egy admin-export, egy jelentés), az időtúllépést csak annál a helynél emelje, ne globálisan:

location = /wp-admin/export.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
}

Apache PHP-FPM-mel: ProxyTimeout 300 egy <Location> blokkon belül. Magának a PHP-nek van max_execution_time értéke; állítsa ugyanarra, különben a PHP áll meg előbb, és 500-ast kap. Majd sudo nginx -t && sudo systemctl reload nginx.

5. Szüntesse meg a swapelést

ps aux --sort=-%mem | head

Ha a PHP-FPM-workerek egyenként 150 MB-ot használnak, és 30-at futtat egy 4 GB-os szerveren, a számítás nem jön ki. Csökkentse a pm.max_children értékét, növelje a memóriát, vagy javítsa a memóriát használó bővítményt. Az a szerver, amely nem swapel, olyan szerver, amelynek a 504-esei többnyire eltűnnek.

6. Gyorsítótár

A teljes oldalas gyorsítótár (nginx FastCGI-gyorsítótár, WordPress-gyorsítótár-bővítmény, Varnish) a visszatérő látogatókat a PHP vagy az adatbázis érintése nélkül szolgálja ki. A terhelés alatti 504-esek többsége eltűnik, amint a főoldal és a legnépszerűbb oldalak a gyorsítótárból jönnek.

Ha a tárhelyszolgáltató problémája

Megosztott tárhelyen a lassú lekérdezéseket és bővítményeket meg tudja javítani, de a szerver időtúllépéseit és a szomszédok terhelését nem. Küldje el a tárhelyszolgáltatójának:

Üdvözlöm! Az example.com weboldalam kb. 16:00 UTC óta „504 Gateway Timeout” hibát ad. Az oldalak, amelyek korábban két másodperc alatt betöltöttek, most időtúllépést kapnak. Nem módosítottam semmit. Megnéznék, hogy az adatbázis-szerver vagy a fiókom PHP-poolja túlterhelt-e, vagy egy másik fiók okoz-e magas terhelést a szerveren, és megírnák, mit találtak?

A következő megelőzése

A 504 egy lassú oldal, amely lassabb lett, és a válaszidő jóval az időtúllépés előtt mérhető. A weboldal-ellenőrzések rögzítik minden ellenőrzés válaszidejét; állítson be rá riasztást, és hetekkel azelőtt látni fogja a trendet, hogy a látogatók hibát látnának. A szerverügynök belülről hozzáadja a terhelést, a memóriát és a swapet. Saját szerveren a Deep Fix megtalálja a lassú lekérdezést vagy az elakadt hívást, és megjavítja, 15 perces blokkokban elszámolva, az árat rendelés előtt látja.