Ga naar de inhoud 
MySQL timeouts bij hosting treden vaak juist op wanneer queries staan te wachten of verbindingen te lang open blijven staan. Ik zal u laten zien hoe u de oorzaken kunt herkennen, timeouts gericht kunt instellen en zo Storingen en Foutmeldingen verminderen.
Centrale punten
- OorzakenInactieve verbindingen, langzame query's, latentie
- DiagnoseSlow Query Log, EXPLAIN, Logboeken
- Instellingenwacht_timeout, verbind_timeout, Pool
- OptimalisatieIndices, joins, max_uitvoering_tijd
- HostingVerbindingslimieten, DoS-bescherming
Waarom MySQL verbinding timeouts optreden bij hosting
In hostingomgevingen draaien veel apps parallel, delen bronnen en genereren zo Wachttijden en Piekbelasting. Timeouts treden op als een verbinding te lang inactief blijft of als een query de limiet overschrijdt; de variabelen wait_timeout (voor niet-interactieve clients) en interactive_timeout (voor consoleverbindingen) zijn hier bijzonder effectief. Connect_timeout telt voor het maken van een verbinding, terwijl net_read_timeout en net_write_timeout relevant zijn voor lees- en schrijfprocessen. Een enkel traag verzoek zonder een geschikte index kan minuten duren en de verbindingspool verstoppen, waardoor verdere verzoeken geblokkeerd worden. Een hoge netwerklatentie of een grote afstand tussen de app-server en de database verergert het probleem. Daarom evalueer ik timeouts altijd samen met de kwaliteit van de query en het netwerkpad.
Foutmeldingen correct classificeren
Ik maak eerst onderscheid tussen „Connection timed out“ (setup mislukt) en „Command timeout“ (commando loopt te lang), omdat beide verschillend zijn. Oorzaken en Oplossingen hebben. Berichten zoals „MySQL server is weggegaan“ duiden vaak op verbroken verbindingen, pakketten die te klein zijn (max_allowed_packet) of een harde herstart. Ik herken patronen in logs: als timeouts zich opstapelen op piekmomenten, is het waarschijnlijker dat dit komt door belasting of een gebrek aan pooling; als ze direct optreden, controleer ik het netwerk, DNS of firewalls. Voor een gestructureerde diepe duik gebruik ik het logboek van langzame query's en bekijk ik de kritieke verklaringen met EXPLAIN. Een compact overzicht van oorzaken en beperkingen vat ik hier samen: Oorzaken en serverbeperkingen.
Systeemvariabelen specifiek instellen
Ik pas eerst de timeouts in de sessie aan en controleer het gedrag voordat ik globale timeouts begin. Standaard en Bestanden veranderen. Ik stel bijvoorbeeld sessie-gebaseerd. SET SESSION wait_timeout = 3600;, wereldwijd per SET GLOBAL wait_timeout = 3600;, waarbij globale wijzigingen verloren gaan na een herstart. Ik voer permanente waarden in my.cnf/my.ini in, bijvoorbeeld onder [mysqld] met wait_timeout, interactive_timeout, connect_timeout, net_read_timeout en net_write_timeout. Vervolgens herstart ik de service en meet ik of de foutpercentages en responstijden verbeteren. Ik vermijd erg hoge timeouts omdat open ongebruikte verbindingen bronnen vastzetten en later kettingreacties kunnen veroorzaken.
Diagnose: Logboeken, trage query's en runtimes
Voor de analyse activeer ik het logboek voor langzame query's (slow_query_log = 1) en controleer welke verklaringen regelmatig de drempel overschrijden, want dit is vaak waar de ware Remmen en Sloten. Ik gebruik EXPLAIN om ontbrekende indices, ongunstige join-sequenties of het gebruik van filesort/temporary te detecteren, wat aangeeft dat optimalisatie nodig is. Tijdens piekuren controleer ik met PROCESLIJST TONEN, of verbindingen op elkaar wachten en met SHOW VARIABLES LIKE '%timeout%'.', of sessie-instellingen anders zijn dan verwacht. In PHP kijk ik naar max_uitvoering_tijd; Als de waarde te klein is, wordt het script beëindigd, ook al is de database nog steeds aan het rekenen. Voor een zinvolle vergelijking voer ik dezelfde queries lokaal uit tegen een kopie en controleer ik of caching, kleinere hoeveelheden gegevens of andere buffers het beeld vertekenen.
Duidelijke afbakening van time-outs voor webserver, proxy en client
Ik heb de MySQL timeouts strikt gescheiden van de web/proxy en client limieten zodat ze niet op de verkeerde plaats in de war raken. In Nginx, bijvoorbeeld. proxy_read_timeout, fastcgi_read_timeout en keepalive_timeout de wachttijden voor upstreams; in Apache Time-out en ProxyTimeout relevant. PHP-FPM beëindigt verzoeken via verzoek_terminate_timeout, zelfs als MySQL nog steeds aan het rekenen is. In HAProxy beïnvloeden time-out klant, time-out server en time-out tunnel lange verbindingen. Aan de kant van de client stel ik expliciet tijdslimieten in zodat deze niet impliciet worden overgenomen:
// PHP PDO
$pdo = nieuwe PDO($dsn, $user, $pass, [
PDO::ATTR_TIMEOUT => 5, // seconden voor verbindingsopbouw
PDO::ATTR_PERSISTENT => false
]);
// mysqli
$mysqli = mysqli_init();
$mysqli->opties(MYSQLI_OPT_CONNECT_TIMEOUT, 5); // connect_timeout
$mysqli->options(MYSQLI_OPT_READ_TIMEOUT, 10); // net_read_timeout (client-side)
$mysqli->real_connect($host, $user, $pass, $db);
// Node.js (mysql2)
const pool = createPool({
host, gebruiker, wachtwoord, database,
connectionLimit: 20, waitForConnections: true, queueLimit: 100,
connectTimeout: 7000, acquireTimeout: 10000, enableKeepAlive: true
});
Belangrijk: De som van de webserver, app en DB timeout mag niet resulteren in een „sandwich“ waarbij de buitenste laag (bijv. Nginx) eerder eindigt dan de binnenste lagen (app/DB). Ik pas de waarden aan zodat fouten duidelijk kunnen worden toegewezen.
Gericht gebruik van prestatieschema en systeemschema
Het prestatieschema en het sys-schema geven me reproduceerbare inzichten die verder gaan dan het trage querylogboek. Ik activeer de relevante instrumenten en analyseer hotspots via digest:
-- Top verklaringen volgens 95ste percentiel
SELECT * FROM sys.statements_with_runtimes_in_95th_percentile
ORDER BY avg_timer_wait DESC LIMIT 20;
-- Actieve wachtgebeurtenissen (sloten, I/O, mutex)
SELECTEER GEBEURTENIS_NAAM, SOM_TIMER_WACHT, TELLING_STER
FROM performance_schema.events_waits_summary_global_by_event_name
ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
-- Huidige „hangende“ verklaringen
SELECTEER THREAD_ID, DIGEST_TEXT, TIMER_WAIT, HUIDIG_SCHEMA
FROM performance_schema.events_statements_current
WAAR TIMER_WAIT NIET NUL IS;
Hierdoor kan ik herkennen of timeouts eerder het gevolg zijn van I/O-wachttijden, lock chains of CPU-intensieve plannen. Ik controleer ook sys.user_summary en sys.host_summary, om herkenbare uitschieters per account/host te beperken. Dit voorkomt dat ik symptomatisch timeouts „verleng“, ook al zijn sloten of I/O eigenlijk het knelpunt.
Optimale time-outwaarden per scenario
Ik pas timeouts aan aan het bedoelde gebruik omdat interactiviteit, job runtimes en Latency en hoeveelheid gegevens sterk variëren. Webapplicaties met veel korte verzoeken hebben baat bij kleinere idle timeouts zodat de pool wordt leeggemaakt en nieuwe gebruikers onmiddellijk verbindingen ontvangen. Gegevensverwerking met urenlange rapporten hebben ruimere limieten nodig, anders komen belangrijke taken in timeouts terecht. Voor hoge latency verhoog ik connect_timeout gematigd zodat verbinding setup tijden niet ten onrechte als fouten verschijnen. De volgende tabel geeft stabiele beginwaarden, die ik vervolgens verfijn met behulp van echt gemeten waarden.
| Instelling | Drukbezochte webapps | Gegevensverwerking | Tip |
|---|---|---|---|
| wacht_timeout | 60–300 s | 3600-7200 s | Korter voor veel gebruikers, langer voor batchtaken |
| interactieve_time-out | 1800 s | 7200 s | Voor CLI/console, zelden kritisch voor web |
| connect_timeout | 5-10 s | 10-20 s | Matige toename bij hoge latentie |
| innodb_lock_wait_timeout | 10-30 s | 50-120 s | Afhankelijk van de duur van de transactie |
Pooling van verbindingen en inactieve tijden
Een goed geconfigureerde pool voorkomt inactieve verbindingen en zorgt ervoor dat verzoeken sneller worden doorgestuurd naar een vrije verbinding. Bron en Aansluiting komen. Ik heb de idle timeout van de pool ingesteld op ongeveer 10-15 % onder de MySQL wait_timeout zodat sessies op een ordelijke manier sluiten voordat ze verlopen. De pool beperkt ook gelijktijdige verbindingen, wat overstromingen op gedeelde servers voorkomt. Voor WordPress, Nextcloud en vergelijkbare tools monitor ik de inactiviteit na inlogfasen en stel ik gepoolde verbindingen in zodat ze niet te vroeg afsterven. Meer achtergrondinformatie en praktische voorbeelden heb ik hier samengevat: Connection pooling in hosting.
Houd vergrendelingen, deadlocks en transacties kort en bondig
Veel timeouts worden veroorzaakt door lange transacties en lock chains. Ik houd transacties klein, lees eerst gegevens zonder lock en open alleen de schrijftransactie direct voor de update/insert. Bij wachtproblemen controleer ik innodb_lock_wait_timeout en vooral impasses:
-- Deadlocks en InnoDB status
SHOW ENGINE INNODB STATUS
-- Bekijk actieve sloten (MySQL 8+)
SELECT * FROM prestatie_schema.gegevens_blokkades
SELECT * FROM prestatie_schema.data_lock_wachttijden
Ik vermijd autocommit-onvriendelijke patronen (bijvoorbeeld lange open sessies met „vergeten“ cursors). Ik zorg ervoor dat isolatie- en schrijfpatronen overeenkomen (bijv. REPEATABLE READ vs. READ COMMITTED) en dat secundaire processen (rapporten, exports) geen onnodig lange locks vasthouden. Ik los deadlocks op met behulp van retry logica in de app, maar nooit door blindelings de timeouts te verhogen.
Maak query's sneller: Indexen en joins
Ik versnel query's eerst met geschikte Indices en slanker Sluit zich aan bij, voordat ik de time-outs verhoog. In EXPLAIN verwacht ik indexgebruik voor filters en sorteren; zo niet, dan voeg ik de sleutel specifiek toe of verander de voorwaarde. Voor grote tabellen sla ik geen brede TEXT/BLOB velden op in hetzelfde toegangspad als ze irrelevant zijn voor de query. Ik controleer ook of een LEFT JOIN echt nodig is of dat een INNER JOIN voldoende is, omdat dit de result set verkleint. Deze stappen verminderen de runtime aanzienlijk en de pool blijft beschikbaar.
PHP, Node en WordPress tuning in de praktijk
In PHP verhoog ik voor lange rapporten de max_uitvoering_tijd matig en voorkomt annuleringen die lijken op databasefouten, maar worden veroorzaakt door het script. leugen. Waar mogelijk activeer ik automatische herverbindingen in het stuurprogramma of behandel ik fouten zodat een nieuwe verbindingspoging netjes begint. In Node.js handhaaf ik keep-alive, poolgroottes en idle-tijden op basis van echte latency- en doorvoermetingen. Bij WordPress let ik op caching, slanke plugins en cron jobs buiten piektijden. Dit houdt de MySQL belasting laag en timeouts zijn zeldzaam.
Het netwerkpad, DNS en TLS in de gaten houden
Ik controleer het hele pad tussen de app en de database: DNS-resolutie, routering, firewalls, NAT en TLS-handshakes. Indien mogelijk gebruik ik stabiele IP's of interne DNS met korte maar niet te agressieve TTL's. Voorkomen aan de serverkant skip_name_resolve dure reverse lookups (wees voorzichtig in gedeelde omgevingen). Met TLS let ik op sessiehervatting en houd ik de handshake overhead laag. TCP-Keepalive helpt om dode verbindingen sneller te herkennen; op OS-niveau keepalive_tijd en keepalive_intvl In de app activeer ik Keep-Alive in het stuurprogramma. In cloudopstellingen houd ik rekening met NAT idle timeouts zodat gepoolde verbindingen niet „stilletjes“ worden verwijderd terwijl de app ze nog steeds als actief beschouwt.
Limieten en verbindingsnummers in hosting
Gedeelde hosting beperkt vaak gelijktijdige verbindingen, wat betekent dat ondanks korte looptijden in Cues of Fout uitvoeren. Ik stel de app pool zo in dat het deze bovengrenzen respecteert en overflows vroeg in de monitoring herkent. Als het aantal 500 fouten toeneemt, controleer ik de relatie tussen max_connections, poolgrootte en time-outs. Als optimalisatie weinig zin heeft, praat ik met de provider over geschikte limieten of overweeg ik grotere plannen (vServer, dedicated DB). Je kunt hier een compacte probleemoplossingsgids vinden: Verbindingslimieten en 500-fouten.
Kies een realistisch resourcebudget en max_connections
Elke verbinding kost RAM: sort, join en read buffers worden gebruikt per thread. Ik ben daarom van plan om max_verbindingen niet door piekaanvragen, maar door beschikbaar geheugen. Te veel gelijktijdige threads genereren context-switches en I/O druk, wat timeouts in de hand werkt. Ik houd thread_cache_grootte en tabel_open_cache zodat het wijzigen van verbindingen en tabellen niet onnodig duur is. Grote max_toegestaan_packet-Ik stel alleen hoge waarden in waar exports/uploads dat nodig hebben -Algemeen te grote pakketten verbruiken RAM en kunnen, in combinatie met veel verbindingen, knelpunten veroorzaken.
Replicatie, failover en lees-schaling
In gerepliceerde opstellingen controleer ik of de app op de juiste manier reageert in het geval van failover of replica lag. Ik gebruik leesreplica's voor leesladingen, maar let op vertragingen: een te kleine net_read_timeout of app timeout kan lange replicatiereacties interpreteren als fouten. Ik implementeer gezondheidscontroles en een backoff bij disconnects in plaats van agressief opnieuw proberen. Voor het splitsen van lezen en schrijven zorg ik ervoor dat transactieconsistente leesverzoeken niet per ongeluk naar vertraagde replicas gaan - anders verschijnen er ogenschijnlijke „timeouts“ die eigenlijk het gevolg zijn van het wachten op verse gegevens.
Onderhoud, back-ups en DDL zonder verrassingen
Back-ups, online DDL en index builds kunnen I/O en locks verhogen. Ik plan dergelijk werk buiten piektijden en gebruik waar mogelijk online algoritmen. Tijdens DDL controleer ik innodb_lock_wait_timeout conservatief zodat productietransacties niet eindeloos blokkeren. Ik meet het I/O-gebruik tijdens back-ups; als de leessnelheid en de doorvoer van de bufferpool botsen, nemen de responstijden en de downstream time-out toe. Ook TABELLEN SPOELEN MET LEESSLOT Ik gebruik het alleen selectief, omdat het wereldwijd kan blokkeren.
Belangrijke cijfers en streefwaarden bewaken
Ik definieer SLO's en meet ze consequent: p95/p99 latency van de belangrijkste queries, foutpercentage per type (connect vs. command timeout) en gebruik. Belangrijke meetgegevens zijn. Draden_lopen (even vasthouden), Draden_verbonden (aanpassing zwembadgrootte), Afgebroken_verbindingen en Verbinding_fouten_* (netwerk-/auth-problemen), en Handler_lezen_* (indexgebruik). Een constant hoog aandeel „volledige tabelscans“ correleert vaak met time-outpieken. Ik gebruik ook een digest om de topverbruikers in CPU, I/O en wachttijd weer te geven, zodat ik optimalisaties kan toepassen waar ze het time-outpercentage echt verlagen.
Veilige timeouts vs. DoS-risico
Ik balanceer timeouts tussen gebruikersvriendelijkheid en bescherming, zodat geen van beide Misbruik nog steeds Afbrekingen overheersen. Bij hoge netwerklatentie verhoog ik voorzichtig connect_timeout zodat verbindingen niet te vroeg mislukken. In kwetsbare opstellingen verlaag ik dezelfde waarde zodat aanvallen met lange handshakes minder effect hebben. Voor uploads of grote resultatensets verhoog ik max_allowed_packet zodat overdrachten niet afbreken. Ik implementeer deze ingrepen altijd door de foutmarge en responstijden te monitoren zodat ik de effecten en neveneffecten direct kan zien.
Veelgemaakte fouten vermijden
Ik verhoog de time-outs nooit blindelings omdat er verlengde wachtvensters openstaan Vergaderingen en Sloten accumuleren. In plaats daarvan repareer ik trage queries eerst en pas dan de limietwaarden minimaal aan. Ik scheid lange transacties, stel verstandige controlepunten in en controleer of innodb_lock_wait_timeout overeenkomt met het schrijfpatroon. Als er grote pakketten nodig zijn, verhoog ik max_allowed_packet alleen voor zover nodig en test ik upload-, export- en importpaden realistisch. Met continue monitoring herken ik terugvallen vroegtijdig en houd ik het systeem betrouwbaar.
Samenvatting: Hoe je verbindingen betrouwbaar houdt
Ik begin met duidelijke diagnostiek, scheid verbindingsfouten van commandotime-outs en controleer Logboeken en Query's in het langzame querylogboek. Vervolgens optimaliseer ik indices en joins, stel ik de idle tijd van de pool in op net onder wait_timeout en stel ik realistische connectie-, lees- en schrijftimeouts in. Ik kies korte idle waarden voor webverkeer en langere limieten voor batchtaken; ik test beide varianten onder belasting. Ik harmoniseer PHP/node limieten en MySQL parameters zodat de app en de database even lang ademen. Dit vermindert het aantal fouten, query's blijven snel en MySQL timeouts verliezen hun horror.
