Lad os antage, at dit system i øjeblikket er Unix-baseret (som angivet i din problemformulering). Hvis dette er korrekt, er her de problemer, du muligvis støder på:
-
Du er løbet tør for hukommelse tilgængelig for MySQL.
Dette er det mest sandsynlige problem, du står over for. Hver forbindelse i MySQL's forbindelsespulje kræver hukommelse for at fungere, og hvis denne ressource er opbrugt, kan der ikke oprettes yderligere forbindelser. Selvfølgelig kan hukommelsesfodsporene og maksimale pakkestørrelser for forskellige operationer indstilles i dit svarer til
my.cnf
hvis du opdager, at dette er et problem.Her er en ekstra tråd, der kan hjælpe der , men du kan også overveje at bruge enklere profileringsværktøjer som
top
for at få et godt skøn over, hvad der foregår. -
Du er løbet tør for filbeskrivelser tilgængelig for din MySQL-brugerkonto.
Et andet almindeligt problem:Hvis du forsøger at servicere anmodninger, der kræver fil-IO over 1.024-grænsen (som standard), vil du løbe ind i tilfælde, hvor operationen simpelthen mislykkes. Dette skyldes, at de fleste systemer angiver en blød og hård grænse for antallet af åbne filbeskrivelser, som hver bruger kan have til rådighed på én gang, og at gå over denne grænse kan forårsage problemer.
Dette vil normalt have en række åbenlyse tegn udtrykt i dine logfiler. Tjek
/var/log/messages
og dine sammenlignelige mapper (for eksempel/var/log/mysql
for at se, om du kan finde noget interessant. -
Du er stødt på en livelock eller deadlock scenarie, hvor din tråd er utilfredsstillende.
Som følge af udmattelse af hukommelse og filbeskrivelser kan tråde time-out, hvis du har overskredet den beregningsmæssige belastning, dit system er i stand til at håndtere. Det sender ikke denne fejlmeddelelse, men det er noget, du skal være opmærksom på i fremtiden.
-
Dit system er ved at løbe tør for PID'er, der er tilgængelige for
fork
.Et andet almindeligt scenarie:
fork
har kun så mange PID'er til rådighed til dets brug på et givet tidspunkt. Hvis dit system simpelthen er overforked , vil den ophøre med at kunne servicere anmodninger.Den nemmeste kontrol for dette er at se, om andre tjenester kan oprette forbindelse til maskinen. For eksempel at prøve at SSH ind i boksen og opdage, at du ikke kan, er et stort fingerpeg.
-
En upstream proxy eller forbindelsesadministrator er løbet tør for ressourcer og ophørte med at servicere anmodninger.
Hvis du har et servicelag mellem din klient og MySQL, er det nødvendigt at inspicere for at se, om det er gået ned, hængt eller på anden måde er blevet ustabilt. Rådene ovenfor gælder.
-
Din portmapper er opbrugt efter 65.536 forbindelser .
Usandsynligt, men igen en mulig udmattelsessag. At tjekke den trivielle serviceforbindelse som ovenfor er, ehm, også den bedste anløbshavn her.
Kort sagt:dette er et scenarie for udmattelse af ressourcer, inklusive serveren, der blot er "nede". Du bliver nødt til at profilere dit system yderligere for at se, hvad du blokerer på. Det eneste, fejlmeddelelsen giver os i dette tilfælde, er det faktum, at ressourcen ikke er tilgængelig for klienten – vi bliver nødt til at se flere oplysninger om serveren at bestemme et mere passende middel.