MySQL "Too many connections" (kļūda 1040): kā tikt iekšā un novērst problēmu

MySQL "Too many connections" ir viena no tām kļūdām, kas izskatās vienkārša, bet parasti tāda nav. Lietotnes žurnāli pildās ar ERROR 1040 (HY000): Too many connections, vietne sāk rādīt kļūdas, un, kad mēģināt pieslēgties, lai saprastu, kas notiek, MySQL atraida arī jūs. Ātrais risinājums, pēc kura visi sniedzas, ir lielāks max_connections. Dažreiz tas ir pareizi. Biežāk limits ir tikai vieta, kur kļūst redzama īstā problēma: kaut kas augšpus datubāzes tur savienojumus daudz ilgāk, nekā vajadzētu.

Ko šī kļūda patiesībā nozīmē

MySQL ir fiksēts vienlaicīgu klientu savienojumu griesti, ko nosaka max_connections. Kad visas vietas ir aizņemtas, jauni savienojumi tiek noraidīti, un serveris palielina statusa skaitītāju Connection_errors_max_connections. Noklusējuma vērtība MySQL 8.4 ir 151, diapazons no 1 līdz 100 000. Faktisko vērtību ierobežo arī operētājsistēma: tā ir mazākā no jūsu iestatītās un open_files_limit mīnus 810. Tātad, ja palielināt max_connections, bet failu deskriptoru limits paliek zems, MySQL var klusi izmantot mazāku skaitli nekā konfigurācijā.

Pārvaldītajos servisos noklusējums ir cits. Amazon RDS for MySQL to aprēķina no instances atmiņas, aptuveni viens savienojums uz 12 MB. Pēc AWS datiem tas ir ap 60 uz db.t3.micro un ap 630 uz 8 GiB klases.

1. solis: iegūstiet sev sesiju

Nevar salabot datubāzi, kurai nevar piekļūt. MySQL to paredz, ja vien tas ir pareizi iestatīts:

• Rezervētā vieta. mysqld patiesībā atļauj max_connections + 1 savienojumu. Papildu vieta ir paredzēta kontiem ar privilēģiju CONNECTION_ADMIN (vai novecojušo SUPER). Tas darbojas tikai tad, ja jūsu lietotnes lietotājam šīs privilēģijas nav. Ja lietotne pieslēdzas ar administratora līmeņa kontu, tā aizņems arī rezerves vietu, un jūs paliksiet ārpusē kopā ar visiem pārējiem.
• Administratīvā saskarne. Kopš MySQL 8.0.14 var iestatīt admin_address un admin_port (noklusējuma ports 33062). Saskarne pastāv tikai tad, ja admin_address ir iestatīts startēšanas brīdī, tāpēc incidenta vidū to ieslēgt nevar. Kad tā ir ieslēgta, tai nav savienojumu limita, un tā pieņem tikai lietotājus ar SERVICE_CONNECTION_ADMIN. Ja uzturat MySQL paši, konfigurējiet to tagad, kamēr viss ir mierīgi.

Ja nav pieejams ne viens, ne otrs, iespējas kļūst rupjākas: apturēt lietotnes slāni, kas pārpludina serveri, vai pārstartēt MySQL. Pārstartēšana izmet visu procesā esošo darbu un pierādījumus par to, kas notika, tāpēc tā ir pēdējais līdzeklis, nevis pirmais solis.

2. solis: paskatieties, pirms pārtraucat

Kad esat iekšā, nesāciet pārtraukt pavedienus pa vienam no SHOW PROCESSLIST. Vispirms tos sagrupējiet, lai aina būtu redzama dažās rindās:

SELECT user, SUBSTRING_INDEX(host, ':', 1) AS client,
       command, state, COUNT(*) AS conns, MAX(time) AS max_sec
FROM information_schema.processlist
GROUP BY user, client, command, state
ORDER BY conns DESC;

Rezultāts parasti norāda uz kādu no dažiem scenārijiem:

• Simtiem Sleep savienojumu ar lielu max_sec. Lietotne atver savienojumus un neatdod tos atpakaļ. Tā ir savienojumu noplūde vai pārāk lieli savienojumu pūli. Noklusējuma wait_timeout ir 28 800 sekundes, tātad MySQL neaktīvu savienojumu tur atvērtu 8 stundas, pirms pats to aizver.
• Daudz sesiju stāvoklī Waiting for table metadata lock. Viena sesija tur bloķējumu (bieži ALTER TABLE, kas gaida aiz garas transakcijas, vai atvērta transakcija, ko kāds aizmirsa apstiprināt), un viss pārējais stāv rindā aiz tās. Rinda aizpilda savienojumu limitu. Skats sys.schema_table_lock_waits parāda, kurš bloķē kuru.
• Daudz sesiju aktīvi izpilda vienu un to pašu vaicājumu. Lēns vaicājums pēc izlaišanas, trūkstošs indekss vai tikko beidzies kešs. Katrs pieprasījums ilgst ilgāk, tāpēc vienlaikus to ir vairāk, un vietas beidzas. Salabojiet vaicājumu, un savienojumu skaits kritīsies pats.
• Vienam klienta hostam pieder lielākā daļa savienojumu. Pakešuzdevums, nevaldāms darbinieka process vai atkārtošanas cilpa. Apturiet to avotā.

3. solis: atbrīvojiet vietas, nepasliktinot situāciju

Pārtrauciet selektīvi, sākot ar neaktīvajām sesijām, kas pieder lietotnei. Ja vispirms ģenerējat komandas, sarakstu var pārbaudīt pirms izpildes:

SELECT CONCAT('KILL ', id, ';')
FROM information_schema.processlist
WHERE user = 'app_user'
  AND command = 'Sleep'
  AND time > 300;

Ja sesijas gaida bloķējumu, pārtrauciet bloķētāju, nevis rindu. Simts gaidošu sesiju pārtraukšana tikai atbrīvo vietu simts jaunām, kas gaidīs tieši tāpat. Esiet uzmanīgi ar sesijām, kas veic garus ierakstus: to pārtraukšana atritina transakciju, un liela atritināšana var ilgt tikpat ilgi kā darbs, ko tā atceļ.

Pēc tam tieciet galā ar avotu. Ja lietotne atkārto pieprasījumus uzreiz un paralēli, tā dažās sekundēs atkal aizpildīs katru atbrīvoto vietu. Lietotnes samazināšana vai trokšņaina darbinieka izslēgšana uz dažām minūtēm bieži ir ātrākais risinājums.

Cik lielam jābūt max_connections?

Maģiska skaitļa nav. MySQL rokasgrāmata norāda, ka praktiskais maksimums ir atkarīgs no pavedienu bibliotēkas, pieejamās RAM, atmiņas uz vienu savienojumu, slodzes un vēlamā atbildes laika. Tajā minēts, ka Linux parasti bez problēmām apkalpo 500 līdz 1000 vienlaicīgu savienojumu, bet ar daudziem gigabaitiem RAM un vieglu slodzi uz savienojumu līdz pat 10 000.

Noderīgāk ir rēķināt no lietotnes puses. Saskaitiet katru procesu, kam ir savienojumu pūls: lietotnes serverus, podus, darbiniekus, cron uzdevumus, administrēšanas rīkus. Reiziniet katru ar tā pūla izmēru, pieskaitiet rezervi izlaišanām, kad vecās un jaunās instances darbojas vienlaikus, un salīdziniet ar limitu. Kubernetes komandas te bieži tiek pārsteigtas: 40 podi ar pūlu 20 ir 800 iespējamu savienojumu, un automātiskā mērogošana to var divkāršot dažās minūtēs.

Ja godīgā summa ir krietni virs tā, ko serveris spēj apkalpot, atbilde ir mazāk savienojumu, nevis lielāks limits: mazāki pūli vai starpniekserveris, kas daudzus klientu savienojumus apvieno mazākā skaitā servera savienojumu (ProxySQL pašu uzturētam MySQL, RDS Proxy AWS vidē). Tā ir tā pati ideja, ko PostgreSQL gadījumā aprakstām mūsu ceļvedī par savienojumu pūliem.

Iestatījumi, ko vērts pārbaudīt pēc tam

• wait_timeout: 8 stundas neaktīvam savienojumam ir ilgs laiks. Samazinot to, paliek mazāk noplūdušu sesiju, taču iestatiet to lielāku par pūla paša neaktivitātes taimautu, citādi lietotne saskarsies ar savienojumiem, ko serveris jau aizvēris.
• max_user_connections vai konta limits ar ALTER USER ... WITH MAX_USER_CONNECTIONS n: neļauj vienam servisam aizņemt visas vietas un atstāt pārējos bez tām. Globālais noklusējums ir 0, kas nozīmē bez limita.
• open_files_limit un systemd LimitNOFILE: pārliecinieties, ka operētājsistēma atļauj jūsu konfigurēto skaitu.
• thread_cache_size: pēc noklusējuma automātiski 8 + max_connections/100, ne vairāk par 100. Ja Threads_created aug strauji salīdzinājumā ar Connections, daudzi savienojumi saņem jaunus pavedienus, nevis atkārtoti izmantotus.
• Privilēģijas: noņemiet CONNECTION_ADMIN un SUPER lietotņu kontiem, lai rezervētā vieta paliktu rezervēta.

Sekojiet tam, pirms tas salūzt

"Too many connections" gandrīz nekad nerodas no zila gaisa. Visi rādītāji, kam sekot, ir vienuviet:

SHOW GLOBAL STATUS WHERE Variable_name IN
  ('Threads_connected', 'Max_used_connections',
   'Connection_errors_max_connections', 'Threads_created', 'Connections');

1. Brīdiniet par Threads_connected procentos no max_connections, piemēram, pie 80%, lai būtu laiks rīkoties.
2. Sekojiet Max_used_connections. Ja tas ir tuvu limitam, jūs jau esat bijuši tuvu dīkstāvei.
3. Brīdiniet par jebkuru Connection_errors_max_connections pieaugumu. Katrs pieaugums ir atraidīts klients.
4. Kopā ar savienojumu skaitu sekojiet vaicājumu latentumam un bloķējumu gaidīšanai. Augošs latentums parasti ir tas, kas dzen savienojumu skaitu uz augšu.