504 Gateway Timeout -virhe tarkoittaa, että yhdyskäytävänä tai välityspalvelimena toimiva palvelin odotti vastausta takanaan olevalta palvelimelta ja luovutti. Pyyntö saapui CDN:ään, kuormantasaajaan tai web-palvelimeen, se välitettiin sovellukselle, eikä sovellus vastannut ennen kuin aikaraja umpeutui.
Välityspalvelimen takana oleva palvelin on usein yhä käynnissä. Se on vain liian hidas, tai jokin, jota se odottaa, on. Siksi 504 eroaa useimmista katkoista: uudelleenkäynnistys korjaa sen harvoin pitkäksi aikaa. Tässä oppaassa näytämme, miten löydät lauenneen aikakatkaisun, mikä pyynnöistä yleensä tekee hitaita ja miten korjaat syyn oireen sijaan.
Mitä 504 kertoo
Pyyntö nykyaikaiselle verkkosivustolle kulkee usean kerroksen läpi, ja jokaisella on oma rajansa sille, kuinka kauan se odottaa seuraavaa:
CDN, kuten Cloudflare, odottaa alkuperäispalvelinta kiinteän ajan.
Kuormantasaajalla on kohdekohtainen joutoaika- tai vastausaikakatkaisu.
nginx odottaa taustapalvelinta asetuksen proxy_read_timeout tai fastcgi_read_timeout mukaan, oletuksena 60 sekuntia.
Sovelluksella on omat rajansa, kuten PHP:n max_execution_time tai Gunicornin worker-aikakatkaisu.
504 tulee ensimmäiseltä kerrokselta, jonka raja umpeutuu. Lähisukulaiset tarkoittavat muuta: 502 Bad Gateway tarkoittaa, että taustapalvelin vastasi virheellisesti tai ei lainkaan, ja 503 Service Unavailable tarkoittaa, että palvelu torjui pyynnön, koska se on ylikuormittunut tai huoltotilassa.
Etsi aikakatkaisu, joka laukesi
Mittaa pyynnön kesto. Jos 504 tulee aina saman sekuntimäärän jälkeen, se osoittaa yhteen tiettyyn rajaan:
curl -s -o /dev/null -w ”status %{http_code} after %{time_total}s\n” https://www.example.com/reports
status 504 after 60.04s
Katso sitten vastauksen otsakkeista ja virhesivusta, mikä kerros vastasi, kuten minkä tahansa 5xx-virheen kohdalla. Pelkistetty nginx-sivu ja otsake server: nginx tarkoittavat, että oma web-palvelimesi aikakatkaisi. CDN:n brändäämä sivu, jossa mainitaan palvelimesi nimi, tarkoittaa, että CDN aikakatkaisi odottaessaan alkuperäispalvelintasi.
nginx kirjaa aikakatkaisun lokiin yhdessä osoitteen kanssa, jota se odotti:
upstream timed out (110: Connection timed out) while reading response header from upstream,
upstream: ”fastcgi://unix:/run/php/php8.3-fpm.sock”, request: ”GET /reports HTTP/2.0”
Nyt tiedät, mikä sivu on hidas ja mikä osa pinoa piti sitä odottamassa. Seuraavaksi selvitetään, miksi.
Yleiset syyt ja niiden korjaaminen
Hitaat tietokantakyselyt
Yleisin syy. Kysely, joka kesti 50 millisekuntia tuhannella rivillä, kestää 40 sekuntia miljoonalla, koska se käy läpi koko taulun. Ota hitaiden kyselyjen loki käyttöön ja etsi sivun kyselyt:
# MySQL / MariaDB
SET GLOBAL slow_query_log = ’ON’;
SET GLOBAL long_query_time = 1;
# PostgreSQL, in postgresql.conf
log_min_duration_statement = 1000
Aja hitain kysely komennolla EXPLAIN ja etsi kokonaisia taulun läpikäyntejä. Puuttuva indeksi on tavallinen korjaus. Toinen tavallinen epäilty on lukitus: pitkä transaktio tai migraatio voi pitää taulua lukossa, kun jokainen sitä tarvitseva pyyntö odottaa.
Hitaat ulkoiset API:t
Sivut kutsuvat usein muita palveluja samalla, kun niitä rakennetaan: maksupalvelua, toimituskululaskuria, hakukonetta tai CRM:ää. Jos se palvelu on hidas, sivusi on hidas ja välityspalvelimesi aikakatkaisee. Aseta jokaiselle lähtevälle kutsulle lyhyt aikakatkaisu, muutama sekunti kirjaston oletuksen sijaan, ja päätä, mitä sivu näyttää, kun kutsu epäonnistuu. Toimitusarvio, jossa lukee ”lasketaan kassalla”, on parempi kuin 504.
Pidä silmällä palveluja, joista olet riippuvainen. Uptimecheckin kolmansien osapuolten valvonta seuraa 31 palvelun, kuten Klarnan, Shopifyn ja Cloudflaren, tilasivuja, joten hidas palveluntarjoaja näkyy omien tarkistustesi rinnalla.
Liian vähän workereita liikenteeseen nähden
Kun jokainen worker on varattu, uudet pyynnöt odottavat jonossa. Ne eivät itse ole hitaita, ne odottavat vuoroaan, ja välityspalvelimen kello käy koko ajan. PHP-FPM kertoo tästä lokissaan viestillä server reached pm.max_children. Lisää workereita auttaa vain, jos palvelimella on niille muistia ja suoritinta. Usein parempi korjaus on lyhentää jokaista pyyntöä, jotta samat workerit palvelevat useampia, ja välimuistittaa sivut, jotka eivät muutu kävijän mukaan.
Pitkät työt web-pyynnön sisällä
Viennit, tuonnit, raporttien luonti, kuvankäsittely ja satojen sähköpostien lähettäminen eivät kuulu web-pyyntöön. Ne kestävät sen, minkä kestävät, ja ennemmin tai myöhemmin jokin niistä ylittää aikakatkaisun. Siirrä ne taustajonoon: pyyntö käynnistää työn ja palaa heti, ja sivu kyselee tulosta tai käyttäjä saa sähköpostin, kun työ on valmis.
Palvelin itse on ylikuormittunut
Korkea suoritinkuorma, muistipaine, joka ajaa palvelimen swapille, tai levy, joka ei pysy perässä, hidastavat kaikkea kerralla. Tähän viittaa 504 jokaisella sivulla eikä vain yhdellä. Katso suoritin, muisti, swap ja levyn odotusaika samalta ajanjaksolta:
uptime
free -m
iostat -x 5 3
Palvelinvalvonta tallentaa tämän historian, joten näet, mitä palvelin teki sillä minuutilla, kun 504-virheet alkoivat, eikä sinun tarvitse arvailla jälkikäteen.
Verkko-ongelmat kerrosten välillä
Jos välityspalvelin ei tavoita taustapalvelinta lainkaan, esimerkiksi koska palomuuri pudottaa paketit hylkäämisen sijaan, yhteys jää roikkumaan, kunnes se aikakatkaistaan. Tuloksena on 504 eikä 502. Tarkista, että välityspalvelin saa samalta koneelta avattua yhteyden taustapalvelimen osoitteeseen ja porttiin.
Milloin aikakatkaisun pidentäminen on oikein
Joskus pyyntö on aidosti pitkä: suuri lataus tai raportti, jonka ylläpitäjä pyytää kerran kuussa. Pidennä silloin rajaa vain sille polulle ja pidä kerrokset järjestyksessä niin, että ulommat odottavat pidempään kuin sisemmät:
location /admin/exports/ {
proxy_read_timeout 300s;
proxy_pass http://app;
}
Koko sivuston rajan nostaminen ei korjaa hitaita sivuja. Kävijät vain odottavat pidempään ennen kuin näkevät virheen, ja hitaat pyynnöt varaavat workereita pidempään, mikä pidentää jonoa kaikille muille.
Näin valvonta havaitsee 504-virheet
504 tulee harvoin tyhjästä. Sivu hidastui viikko viikolta datan kasvaessa, kunnes eräänä päivänä se ylitti rajan. Se on hyvä uutinen, koska se tarkoittaa, että voit nähdä sen tulevan.
Seuraa vasteaikaa, ei vain tilaa. Uptimecheck tallentaa jokaisen tarkistuksen vasteajan jaoteltuna DNS:ään, yhteyden muodostukseen, TLS:ään, palvelimeen ja lataukseen, joten näet, hidastuiko palvelin vai verkko. Hitaan vasteen hälytys kertoo, kun sivu ylittää asettamasi rajan, jo kauan ennen välityspalvelimen aikakatkaisua. Oppaamme hyvästä vasteajasta auttaa valitsemaan rajan.
Varmista häiriöt ennen hälyttämistä. Tarkistukset tehdään jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista, ja jokainen häiriö varmistetaan toisesta sijainnista, joten yksi hidas pyyntö ei herätä ketään.
Valvo hitaita sivuja suoraan. Haku, kassa, tilisivut ja raportit ovat paikkoja, joissa 504-virheet syntyvät, ja ne ovat harvoin etusivu. Lisää niille käytettävyysvalvonnat aikakatkaisulla, joka vastaa sitä, mitä kävijä jaksaa odottaa.
504-tarkistuslista
Mittaa pyynnön kesto: tasainen sekuntimäärä kertoo, mikä raja laukesi.
Lue otsakkeet ja virhesivu nähdäksesi, mikä kerros aikakatkaisi.
Etsi hidas sivu välityspalvelimen virhelokista.
Etsi sivun hitaat kyselyt, lukitukset ja hitaat ulkoiset kutsut.
Tarkista workerit, suoritin, muisti, swap ja levy samoilta minuuteilta.
Korjaa hidas osa, välimuistita se tai siirrä se taustatyöksi.
Pidennä aikakatkaisuja vain aidosti pitkille poluille, ulommat kerrokset pidemmiksi kuin sisemmät.
Hälytä hitaista vasteista, jotta seuraava 504 huomataan, kun se on vielä hidastuma.