Hoppa till innehåll 
MySQL-timeouts i hosting uppstår ofta just när frågor väntar eller anslutningar förblir öppna för länge. Jag kommer att visa dig hur du känner igen orsakerna, ställer in timeouts på ett målinriktat sätt och därmed Misslyckanden och Felmeddelanden minska.
Centrala punkter
- OrsakerInaktiva anslutningar, långsamma frågor, fördröjning
- DiagnosLångsam frågelogg, EXPLAIN, Loggar
- Inställningarwait_timeout, connect_timeout, Pool
- OptimeringIndices, joins, max_execution_time
- HostingAnslutningsgränser, DoS-skydd
Varför uppstår timeouts för MySQL-anslutningar i hosting
I hostingmiljöer körs många appar parallellt, delar resurser och genererar därmed Väntetider och Toppbelastning. Timeouts inträffar om en anslutning förblir inaktiv för länge eller om en fråga överskrider gränsen; variablerna wait_timeout (för icke-interaktiva klienter) och interactive_timeout (för konsolanslutningar) är särskilt effektiva här. Connect_timeout räknas för att upprätta en anslutning, medan net_read_timeout och net_write_timeout är relevanta för läs- och skrivprocesser. En enda långsam begäran utan ett lämpligt index kan ta flera minuter och täppa till anslutningspoolen, vilket blockerar ytterligare begäranden. Hög nätverkslatens eller långt avstånd mellan appserver och databas förvärrar problemet, vilket är anledningen till att jag alltid utvärderar timeouts tillsammans med frågekvalitet och nätverksväg.
Klassificera felmeddelanden korrekt
Jag skiljer först mellan „Connection timed out“ (installationen misslyckas) och „Command timeout“ (kommandot tar för lång tid), eftersom båda är olika. Orsaker och Lösningar har. Meddelanden som „MySQL-servern har försvunnit“ tyder ofta på tappade anslutningar, paket som är för små (max_allowed_packet) eller en hård omstart. Jag känner igen mönster i loggar: om timeouts ackumuleras vid topptider är det mer troligt att det beror på belastning eller brist på poolning; om de inträffar omedelbart kontrollerar jag nätverket, DNS eller brandväggar. För en strukturerad djupdykning använder jag den långsamma frågeloggen och tittar på de kritiska uttalandena med EXPLAIN. Jag sammanfattar en kompakt översikt över orsaker och begränsningar här: Orsaker och serverbegränsningar.
Ställ in systemvariabler specifikt
Jag justerar tidsgränserna i sessionen först och kontrollerar beteendet innan jag börjar med globala tidsgränser. Standardinställningar och Filer ändra. Jag ställer till exempel in sessionsbaserade. SET SESSION wait_timeout = 3600;, global per SET GLOBAL wait_timeout = 3600;, där globala ändringar går förlorade efter en omstart. Jag anger permanenta värden i my.cnf/my.ini, till exempel under [mysqld] med wait_timeout, interactive_timeout, connect_timeout, net_read_timeout och net_write_timeout. Sedan startar jag om tjänsten och mäter om felfrekvensen och svarstiderna förbättras. Jag undviker mycket höga timeouts eftersom öppna oanvända anslutningar binder upp resurser och kan utlösa kedjereaktioner senare.
Diagnos: Loggar, långsamma frågor och körtider
För analysen aktiverar jag den långsamma frågeloggen (slow_query_log = 1) och kontrollera vilka påståenden som regelbundet passerar tröskeln, eftersom det ofta är här som den sanna Bromsar och Lås. Jag använder EXPLAIN för att upptäcka saknade index, ogynnsamma join-sekvenser eller användning av filesort/temporary, vilket indikerar ett behov av optimering. Under rusningstid kontrollerar jag med VISA PROCESSLISTA, om anslutningar väntar på varandra, och med VISA VARIABLER LIKE '%timeout%', om sessionsinställningarna är annorlunda än förväntat. I PHP tittar jag på max_exekveringstid; Om värdet är för litet avslutas skriptet trots att databasen fortfarande beräknar. För att få en meningsfull jämförelse kör jag samma frågor lokalt mot en kopia och kontrollerar om cachelagring, mindre datamängder eller andra buffertar förvränger bilden.
Tydlig avgränsning av timeouts för webbserver, proxy och klient
Jag separerar strikt MySQL-timeouts från webb/proxy- och klientgränser så att de inte blir vridna på fel ställe. I Nginx, till exempel. proxy_read_timeout, fastcgi_read_timeout och keepalive_timeout väntetiderna för uppströmsflöden; i Apache Tidsgräns och ProxyTimeout relevant. PHP-FPM avslutar förfrågningar via begäran_avsluta_timeout, även om MySQL fortfarande är beräknande. I HAProxy inflytande timeout klient, timeout server och timeout tunnel långa anslutningar. På klientsidan ställer jag uttryckligen in tidsgränser så att de inte ärvs implicit:
// PHP PDO
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_TIMEOUT => 5, // sekunder för att upprätta en anslutning
PDO::ATTR_PERSISTENT => false
]);
// mysqli
$mysqli = mysqli_init();
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5); // connect_timeout
$mysqli->options(MYSQLI_OPT_READ_TIMEOUT, 10); // net_read_timeout (klientsidan)
$mysqli->real_connect($host, $user, $pass, $db);
// Node.js (mysql2)
const pool = createPool({
host, användare, lösenord, databas,
connectionLimit: 20, waitForConnections: true, queueLimit: 100,
connectTimeout: 7000, acquireTimeout: 10000, enableKeepAlive: true
});
Viktigt: Summan av timeout för webbserver, app och DB får inte resultera i en „sandwich“ där det yttre lagret (t.ex. Nginx) avslutas tidigare än de inre lagren (app/DB). Jag justerar värdena så att felen kan tilldelas på ett tydligt sätt.
Riktad användning av prestandaschema och sys-schema
Prestandaschemat och sys-schemat ger mig reproducerbara insikter utöver den långsamma frågeloggen. Jag aktiverar de relevanta instrumenten och analyserar hotspots via digest:
-- Topputlåtanden enligt 95:e percentilen
SELECT * FROM sys.uttalanden_med_körtider_i_95:e_percentilen
ORDER BY avg_timer_wait DESC LIMIT 20;
-- Aktiva väntehändelser (lås, I/O, mutex)
VÄLJ HÄNDELSENAMN, SUMMA_TIMER_WAIT, ANTAL_STJÄRNOR
FROM performance_schema.events_waits_summary_global_by_event_name
ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
-- Aktuella „hängande“ uttalanden
SELECT THREAD_ID, DIGEST_TEXT, TIMER_WAIT, AKTUELLT_SCHEMA
FROM performance_schema.events_statements_current
DÄR TIMER_WAIT INTE ÄR NULL;
På så sätt kan jag se om timeouts snarare beror på I/O-väntetider, låskedjor eller CPU-intensiva planer. Jag kontrollerar också sys.användare_sammanfattning och sys.host_sammanfattning, för att begränsa igenkännliga outliers efter konto / värd. Detta hindrar mig från att symptomatiskt „förlänga“ timeouts, även om lås eller I/O faktiskt är flaskhalsen.
Optimala timeout-värden per scenario
Jag anpassar timeouts till den avsedda användningen eftersom interaktivitet, jobbkörtider och Fördröjning och datamängd varierar kraftigt. Webbapplikationer med många korta förfrågningar gynnas av mindre tidsgränser för inaktivitet så att poolen rensas och nya användare får anslutningar omedelbart. Databehandling med timslånga rapporter behöver mer generösa gränser, annars hamnar viktiga jobb i timeout. Vid hög latens ökar jag connect_timeout måttligt så att tiden för att upprätta en anslutning inte felaktigt visas som fel. Följande tabell ger stabila startvärden, som jag sedan finjusterar med hjälp av verkliga uppmätta värden.
| Inställning | Webbappar med hög trafik | Databehandling | Ledtråd |
|---|---|---|---|
| vänta_timeout | 60–300 s | 3600-7200 s | Kortare för många användare, längre för batchjobb |
| interaktiv_timeout | 1800 s | 7200 s | För CLI/konsol, sällan kritiskt för webb |
| anslut_timeout | 5-10 s | 10-20 s | Ökar måttligt med hög latens |
| innodb_lock_wait_timeout | 10-30 s | 50-120 s | Beroende på transaktionens varaktighet |
Anslutningspoolning och inaktiva tider
En korrekt konfigurerad pool förhindrar oanvända anslutningar och ser till att förfrågningar snabbare vidarebefordras till en ledig anslutning. Resurs och Anslutning kommer. Jag ställde in poolens timeout för inaktivitet till cirka 10-15 % under MySQL:s wait_timeout så att sessioner stängs på ett ordnat sätt innan de löper ut. Poolen begränsar också samtidiga anslutningar, vilket förhindrar överbelastning på delade servrar. För WordPress, Nextcloud och liknande verktyg övervakar jag inaktiviteten efter inloggningsfaser och ställer in poolade anslutningar så att de inte dör för tidigt. Här har jag sammanfattat mer bakgrundsinformation och praktiska exempel: Poolning av anslutningar i hosting.
Håll lås, deadlocks och transaktioner korta och tydliga
Många timeouts orsakas av långa transaktioner och låskedjor. Jag håller transaktionerna små, läser data utan lås först och öppnar bara skrivtransaktionen omedelbart före uppdateringen/insättningen. Om det uppstår problem med väntan kontrollerar jag innodb_lock_wait_timeout och framför allt dödlägen:
-- Deadlocks och InnoDB-status
VISA MOTOR INNODB STATUS\G
-- Visa aktiva lås (MySQL 8+)
SELECT * FROM prestanda_schema.data_locks\G
SELECT * FROM prestanda_schema.data_lock_waits\G
Jag undviker mönster som är ogynnsamma för autocommit (t.ex. långa öppna sessioner med „bortglömda“ cursorer). Jag ser till att isolerings- och skrivmönster matchar varandra (t.ex. REPEATABLE READ vs. READ COMMITTED) och att sekundära processer (rapporter, export) inte har onödigt långa låsningar. Jag löser dödlägen med hjälp av omprövningslogik i appen, men aldrig genom att blint öka tidsgränserna.
Gör sökningar snabbare: Index och sammanfogningar
Jag accelererar frågor först med lämpliga Index och smalare Anslutningar, innan jag ökar tidsgränserna. I EXPLAIN förväntar jag mig indexanvändning för filter och sortering; om inte, lägger jag till nyckeln specifikt eller ändrar villkoret. För stora tabeller lagrar jag inte breda TEXT/BLOB-fält i samma åtkomstväg om de är irrelevanta för frågan. Jag kontrollerar också om en LEFT JOIN verkligen är nödvändig eller om en INNER JOIN är tillräcklig, eftersom detta minskar resultatuppsättningen. Dessa steg minskar körtiden märkbart och poolen förblir tillgänglig.
PHP-, Node- och WordPress-tuning i praktiken
I PHP, för långa rapporter, ökar jag max_exekveringstid måttligt och förhindra avbrott som ser ut som databasfel men som orsakas av skriptet. ligga. Där det är möjligt aktiverar jag automatiska återanslutningar i drivrutinen eller hanterar fel så att ett nytt anslutningsförsök startar på ett snyggt sätt. I Node.js upprätthåller jag keep-alive, poolstorlekar och tomgångstider baserat på verkliga latens- och genomströmningsmätningar. Med WordPress är jag uppmärksam på cachelagring, magra plugins och cron-jobb utanför topptider. Detta håller MySQL-belastningen låg och timeouts är sällsynta.
Hålla ett öga på nätverkssökvägen, DNS och TLS
Jag kontrollerar hela vägen mellan appen och databasen: DNS-upplösning, routing, brandväggar, NAT och TLS-handskakningar. Om möjligt använder jag stabila IP-adresser eller intern DNS med korta men inte alltför aggressiva TTL. Förhindras på serversidan skip_name_resolve dyra omvända uppslagningar (försiktighet i delade miljöer). Med TLS är jag uppmärksam på återupptagande av sessioner och håller handskakningsoverhead låg. TCP-Keepalive hjälper till att snabbare känna igen döda anslutningar; på OS-nivå keepalive_tid och keepalive_intvl Jag aktiverar Keep-Alive i drivrutinen i appen. I molnkonfigurationer tar jag hänsyn till NAT:s tidsgränser för inaktivitet så att poolade anslutningar inte „tyst“ kasseras medan appen fortfarande anser att de är aktiva.
Begränsningar och anslutningsnummer i hosting
Delad hosting begränsar ofta samtidiga anslutningar, vilket innebär att trots korta körtider i Ledtrådar eller . Fel kör. Jag konfigurerar apppoolen så att den respekterar dessa övre gränser och upptäcker överskridanden tidigt i övervakningen. Om 500-felen ökar kontrollerar jag förhållandet mellan max_connections, poolstorlek och timeouts. Om optimering inte hjälper pratar jag med leverantören om lämpliga gränser eller överväger större planer (vServer, dedikerad DB). Du hittar en kompakt felsökningsguide här: Anslutningsgränser och 500-fel.
Välj resursbudget och max_connections på ett realistiskt sätt
Varje anslutning kostar RAM-minne: sorterings-, join- och läsbuffertar används per tråd. Jag planerar därför att max_anslutningar inte efter högsta begäran, utan efter tillgängligt minne. För många samtidiga trådar genererar kontextbyten och I/O-tryck, vilket tenderar att uppmuntra timeouts. Jag håller tråd_cache_storlek och tabell_öppen_cache så att anslutnings- och tabellbyten inte blir onödigt dyra. Stor max_tillåtet_paket-Jag sätter bara höga värden där export/uppladdning behöver det - globalt för stora paket förbrukar RAM och kan i kombination med många anslutningar orsaka flaskhalsar.
Replikering, failover och lässkalning
I replikerade konfigurationer kontrollerar jag om appen reagerar på lämpligt sätt vid failover eller replikfördröjning. Jag använder läsrepliker för läsbelastningar, men är uppmärksam på fördröjningar: en för liten net_read_timeout eller app timeout kan tolka långa replikeringssvar som fel. Jag implementerar hälsokontroller och en backoff på frånkopplingar istället för aggressiv omprövning. För uppdelning av läsning/skrivning ser jag till att transaktionsmässigt konsekventa läsförfrågningar inte felaktigt går till försenade repliker - annars uppstår uppenbara „timeouts“ som faktiskt beror på att man väntar på ny data.
Underhåll, säkerhetskopiering och DDL utan överraskningar
Säkerhetskopiering, DDL online och indexuppbyggnad kan öka I/O och låsningar. Jag schemalägger sådant arbete utanför rusningstid och använder onlinealgoritmer där det är möjligt. Under DDL kontrollerar jag innodb_lock_wait_timeout konservativt så att produktionstransaktioner inte blockeras för evigt. Jag mäter I/O-användningen under säkerhetskopieringarna; om läshastigheten och buffertpoolens genomströmning kolliderar ökar svarstiderna och timeoutfrekvensen nedströms. Dessutom SPOLA TABELLER MED LÄSLÅS Jag använder det bara selektivt, eftersom det kan blockera globalt.
Uppföljning av nyckeltal och målvärden
Jag definierar SLO:er och mäter dem konsekvent: p95/p99-latens för de viktigaste frågorna, felfrekvens per typ (connect vs. command timeout) och utnyttjande. Viktiga mätvärden inkluderar. Trådar_löpande (håll kort), Trådar_anslutna (justering av poolstorlek), Avbrutna_anslutningar och Anslutning_fel_* (problem med nätverk/autentisering), och Handläggare_läs_* (indexutnyttjande). En konstant hög andel „full table scans“ korrelerar ofta med timeout-toppar. Jag använder också en sammanställning för att visa de största förbrukarna i CPU, I/O och väntetid för att kunna tillämpa optimeringar där de verkligen minskar timeoutfrekvensen.
Säkra tidsgränser kontra DoS-risk
Jag balanserar timeouts mellan användarvänlighet och skydd så att varken Övergrepp fortfarande avbrott dominerar. Med hög nätverkslatens ökar jag connect_timeout försiktigt så att anslutningarna inte bryts för tidigt. I sårbara konfigurationer sänker jag samma värde så att attacker med långa handskakningar får mindre effekt. För uppladdningar eller stora resultatuppsättningar ökar jag max_allowed_packet så att överföringarna inte bryts. Jag genomför alltid dessa åtgärder genom att övervaka felfrekvensen och svarstiderna så att jag omedelbart kan se effekterna och biverkningarna.
Undvik vanliga misstag
Jag ökar aldrig timeouts blint eftersom förlängda väntefönster öppnas Möten och Lås ackumuleras. Istället åtgärdar jag långsamma frågor först och justerar sedan gränsvärdena minimalt. Jag separerar långa transaktioner, sätter förnuftiga kontrollpunkter och kontrollerar om innodb_lock_wait_timeout matchar skrivmönstret. Om det krävs stora paket ökar jag max_allowed_packet bara så långt det behövs och testar uppladdnings-, export- och importvägar på ett realistiskt sätt. Med kontinuerlig övervakning upptäcker jag återfall tidigt och kan hålla systemet tillförlitligt.
Sammanfattning: Hur man håller anslutningarna tillförlitliga
Jag börjar med en tydlig diagnostik, separerar anslutningsfel från timeouts för kommandon och kontrollerar Loggar och Frågor i den långsamma frågeloggen. Jag optimerar sedan index och joins, ställer in poolens inaktivitetstid till strax under wait_timeout och ställer in realistiska timeouts för anslutning, läsning och skrivning. Jag väljer korta tomgångsvärden för webbtrafik och längre gränser för batchjobb; jag testar båda varianterna under belastning. Jag harmoniserar PHP/nodgränser och MySQL-parametrar så att appen och databasen andas under samma tidsperiod. Detta minskar felfrekvensen, förfrågningar förblir snabba och MySQL-timeouts förlorar sin skräck.
