Mysql Ressource vorübergehend nicht verfügbar

Question

ich ein paar dieser Fehler während des Hochlastzeiten zu sehen:

mysql_connect() [<a 
href='function.mysql-connect'>function.mysql-connect</a>]: [2002] Resource 
temporarily unavailable (trying to connect via 
unix:///var/lib/mysql/mysql.sock) 

Von dem, was ich den MySQL-Server sagen kann, ist nicht seine max connections Grenze trifft, aber es ist etwas anderes zu stoppen es von der Abfrage dienen. Welche anderen Beschränkungen würde MySQL treffen?

Ich bin mit RHEL 6.2 64bit mit MySQL 5.5.21

Answer 1

Ich habe immer noch nicht gefunden, welche Grenzen es schlug, aber ich habe es geschafft, das Problem zu umgehen. Es gab ein Problem mit unserer Sitzungstabelle (in vbulletin), die die MEMORY-Engine verwendet. Die Indizes für diese Tabelle waren HASH, und wenn vbulletin diese Tabelle einmal pro Stunde löschte, würde sie die Tabelle gerade lange genug sperren, um andere Abfragen zu halten und mysql an die Grenze ihrer Ressourcen zu schieben.

Durch die Änderung der Indizes zu BTREE konnte MySQL die Zeilen aus der Sitzungstabelle viel schneller löschen und die zuvor erreichten Grenzen vermeiden. Die Fehler haben erst begonnen, als wir unseren Master-DB-Server auf MySQL 5.5 aktualisiert haben. Ich nehme an, dass MEMORY-Tabellen in der neuesten Version anders behandelt werden.

Informationen zur Geschwindigkeitssteigerung bei der Verwendung von BTREE-Indizes über HASH For MEMORY finden Sie unter http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/.

Answer 2

Nehmen wir an, Ihr System ist derzeit auf Unix-Basis (wie in Ihrer Problemstellung gegeben). Wenn dies richtig ist, hier ist die Menge der Punkte, die Sie in laufen können:

1. Sie haben aus memory zur Verfügung zu MySQL laufen.

   Dies ist das wahrscheinlichste Problem Sie konfrontiert. Jede Verbindung im Verbindungspool von MySQL benötigt Speicher, um zu funktionieren, und wenn diese Ressource erschöpft ist, können keine weiteren Verbindungen hergestellt werden. Natürlich können die Speicher Fußspuren und maximale Paketgrößen von verschiedenen Operationen in your equivalent to my.cnf abgestimmt werden, wenn Sie feststellen, das ein Problem zu sein.

   Here's an additional thread that can help there, aber Sie können auch in Betracht ziehen, einfachere Profiling-Tools wie top zu verwenden, um einen guten Überblick über das, was vor sich geht, zu erhalten.

2. Sie haben aus file descriptors Verfügung, um Ihre MySQL-Benutzerkonto ausgeführt werden.

   Ein weiteres häufiges Problem: Wenn Sie auf Service-Anfragen sind versucht, die Datei IO über der 1.024 Grenze erfordern (Standardeinstellung), werden Sie in Fällen laufen, wo der Betrieb einfach ausfällt. Dies liegt daran, dass die meisten Systeme eine weiche und harte Grenze für die Anzahl der offenen Dateideskriptoren angeben, die jeder Benutzer gleichzeitig verfügbar haben kann, und das Überschreiten dieses Schwellenwerts kann zu Problemen führen.

   Diese haben in der Regel eine Reihe von eklatant Zeichen in Ihren Log-Dateien zum Ausdruck gebracht. Überprüfen Sie /var/log/messages und Ihre vergleichbare Verzeichnisse (zB /var/log/mysql, um zu sehen, wenn Sie interessant alles finden kann.

3. Sie haben laufen in ein livelock or deadlock Szenario, in dem Thread unerfüllbar ist.

   Corollary in den Speicher und Dateideskriptors Erschöpfung , Threads können eine Zeitüberschreitung haben, wenn Sie die Rechenlast überschritten haben, die Ihr System verarbeiten kann.Es wird diese Fehlermeldung nicht ausgeben, aber das ist etwas, auf das Sie in Zukunft achten sollten:

4. Ihr System läuft von PIDs zur Verfügung fork.

   Ein anderes häufiges Szenario: fork hat nur so viele PIDs für seine Verwendung zu jeder beliebigen Zeit zur Verfügung. Wenn Ihr System einfach overforked ist, wird es nicht mehr in der Lage sein, Anfragen zu bearbeiten.

   Am einfachsten prüfen Sie, ob sich andere Dienste über das System verbinden können. Zum Beispiel ist es ein großer Hinweis, SSH in die Box zu stecken und zu entdecken, dass das nicht möglich ist.

5. Ein Upstream-Proxy oder Verbindungsmanager hat keine Ressourcen mehr und Serviceanfragen wurden abgebrochen.

   Wenn zwischen Ihrem Client und MySQL ein Service-Layer vorhanden ist, muss geprüft werden, ob er abgestürzt, blockiert oder anderweitig instabil geworden ist. Der oben genannte Hinweis gilt.

6. Ihr Port Mapper hat sich after 65,536 connections erschöpft.

   Unwahrscheinlich, aber wieder ein möglicher Erschöpfungsfall. Das Überprüfen der trivialen Dienstverbindung wie oben ist, äh, auch hier die beste Anlaufstelle.

Kurz: dies ist eine Ressource Erschöpfung Szenario, einschließlich des Servers einfach „down“ zu sein. Sie müssen Ihr System weiter profilieren, um zu sehen, auf was Sie blockieren. Die ganze Fehlermeldung gibt uns in diesem Fall die Tatsache, dass die Ressource für den Client nicht verfügbar ist - wir müssten mehr Informationen über den Server sehen, um eine adäquatere Abhilfe zu finden.

Answer 3

Meine Güte, das könnte so viele Dinge sein. Es könnte sein, dass der Socket-Pufferspeicher erschöpft ist. Es könnte sein, dass mysql Verbindungen nicht so schnell annimmt, wie sie hereinkommen und das Rückstandlimit erreicht ist (obwohl ich erwarten würde, dass Ihnen ein "Connection Refused" Fehler gibt, weiß ich nicht genau das ist, was Sie ' lch bekomme für einen Unix Domain Socket). Es könnte eines der Dinge sein, auf die @MrGomez hingewiesen hat.

Da Sie Apache und MySQL auf dem gleichen Server laufen und dies ein Problem unter hoher Last ist, könnte es gut sein, dass Apache das System von einigen Ressourcen verhungert und Sie einfach nicht sehen (bemerkt?)/gescheitert eingehende Verbindungen/Anfragen in Ihren Protokollen.

Verwenden Sie Verbindungspooling? Wenn nicht, würde ich dort anfangen.

Ich würde auch nach Fehlern in den Apache-Protokollen und Syslog etwa zur gleichen Zeit wie der mysql_connect-Fehler suchen und sehen, was sonst noch auftaucht. Ich würde besonders empfehlen, MySQL auf einen eigenen dedizierten Server zu verschieben.