Laten we eerst de mysql-eigenschappen begrijpen.
interactive_timeout:interactieve time-out voor mysql-shell-sessies in seconden, zoals mysqldump of mysql-opdrachtregelprogramma's. verbindingen zijn in de slaapstand. Meestal is dit ingesteld op een hogere waarde omdat je niet wilt dat de verbinding wordt verbroken terwijl je iets doet op mysql cli.wait_timeout:het aantal seconden tijdens inactiviteit dat MySQL zal wachten voordat het een verbinding op een niet-interactieve verbinding in seconden sluit. voorbeeld:verbonden vanuit java. verbindingen zijn in de slaapstand.
Laten we nu de c3po-eigenschappen en de relatie met DB-rekwisieten begrijpen. (Ik ga gewoon kopiëren van uw vraag)
Dit verwijst naar hoe lang een verbindingsobject bruikbaar kan zijn en beschikbaar zal zijn in de pool. Zodra de time-out voorbij is, zal c3po het vernietigen of recyclen.
Nu komt het probleem wanneer je maxIdleTime . hebt hoger dan de wait_timeout .laten we zeggen dat de mxIdleTime : 50 seconden en wait_timeout : 40 s dan is er een kans dat u Connection time out exception: Broken Pipe . krijgt als u in de afgelopen 10 seconden een bewerking probeert uit te voeren. Dus maxIdelTime moet altijd kleiner zijn dan wait_timeout .
In plaats van maxIdleTime kunt u de volgende eigenschappen gebruiken.
idleConnectionTestPeriodstelt een limiet in voor hoe lang een verbinding inactief blijft voordat deze wordt getest. ZonderpreferredTestQuery, de standaardinstelling isDatabaseMetaData.getTables()- wat database-agnostisch is, en hoewel het een relatief dure aanroep is, is het waarschijnlijk prima voor een relatief kleine database. Als je paranoïde bent over prestaties, gebruik dan een specifieke query voor je database(i.e. preferredTestQuery="SELECT 1")maxIdleTimeExcessConnectionszal de backdown van connectieCount terugbrengen naar minPoolSize na een piek in activiteit.
Houd er rekening mee dat alle eigendommen van het zwembad (bijv. maxIdleTime ) is alleen van invloed op verbindingen die in pool zijn d.w.z. als de slaapstand een verbinding heeft verkregen en deze langer dan maxIdleTime inactief houdt en vervolgens een bewerking probeert uit te voeren, krijgt u "Broken Pipe"
Het is goed om een lagere wait_timeout te hebben op mysql, maar het is niet altijd goed als je al een applicatie hebt gebouwd. Je moet ervoor zorgen voordat je het reduceert dat je in je applicatie de verbinding niet langer open houdt dan wait_time uit.
Je moet er ook rekening mee houden dat het verkrijgen van een verbinding een dure taak is en als de wachttijd te laag is, is het beter dan het hele doel van het hebben van een verbindingspool, omdat het vaak zal proberen verbindingen te verkrijgen.
Dit is vooral belangrijk wanneer u het verbindingsbeheer niet handmatig uitvoert, bijvoorbeeld wanneer u Spring transnationale API gebruikt. Spring start de transactie wanneer u een @Transaction . invoert geannoteerde methode zodat het een verbinding van pool verwerft. Als u een webservice-oproep doet of een bestand leest dat meer tijd kost dan wait_time out, dan krijgt u een uitzondering.
Ik heb dit probleem een keer meegemaakt.
In een van mijn projecten had ik een cron die de orderverwerking voor klanten zou doen. Om het sneller te maken heb ik batchverwerking gebruikt. Nu, zodra ik een batch klanten ophaal en wat verwerking doe (geen db-oproepen). Wanneer ik alle bestellingen probeer op te slaan, kreeg ik een uitzondering voor een gebroken pijp. Het probleem was dat mijn wait_timeout 1 minuut was en dat de orderverwerking meer tijd in beslag nam. Dus moesten we het verhogen tot 2 minuten. Ik had de batchgrootte kunnen verkleinen, maar dat maakte de algehele verwerking langzamer.