risorse Mysql temporaneamente non disponibile

Question

sto vedendo alcuni di questi errori durante i periodi di carico elevato:

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) 

Da quello che posso dire al server MySQL non è colpire il suo limite massimo di connessioni, ma c'è qualcos'altro arresto dal servire la query. Quali altri limiti potrebbe colpire MySQL?

Io corro RHEL 6.2 a 64 bit con MySQL 5.5.21

Answer 1

Non ho ancora trovato i limiti che ha colpito, ma sono riuscito a risolvere il problema. Si è verificato un problema con la nostra tabella di sessione (in vbulletin) che utilizza il motore MEMORY. Gli indici per questa tabella erano HASH e quindi, quando vbulletin ha eliminato questa tabella una volta all'ora, bloccherebbe la tabella per il tempo sufficiente a contenere altre query e spingerebbe mysql al limite delle sue risorse.

Cambiando gli indici in BTREE questo ha permesso a MySQL di cancellare le righe dalla tabella di sessione molto più rapidamente ed evitare qualsiasi limite ci fosse stato raggiunto in precedenza. Gli errori sono iniziati solo quando abbiamo aggiornato il nostro server master db su MySQL 5.5, quindi suppongo che le tabelle MEMORY siano gestite diversamente nell'ultima versione.

Vedere http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/ per informazioni sugli aumenti di velocità dall'utilizzo degli indici BTREE su HASH Per MEMORY.

Answer 2

Supponiamo che il sistema è attualmente basata su Unix (come indicato nella sua dichiarazione problema). Se questo è corretto, ecco la serie di problemi che si possono eseguire in:

1. si è a corto di memory disponibili a MySQL.

   Questo è il problema più probabile che stai affrontando. Ogni connessione nel pool di connessioni di MySQL richiede memoria per funzionare, e se questa risorsa è esaurita, non è possibile effettuare ulteriori connessioni. Naturalmente, le impronte di memoria e le dimensioni massime dei pacchetti di varie operazioni possono essere regolate in your equivalent to my.cnf se si scopre che si tratta di un problema.

   Here's an additional thread that can help there, ma si può anche prendere in considerazione l'utilizzo di strumenti di profiling più semplici come top per ottenere una buona stima del ballpark di cosa sta succedendo.

2. Hai esaurito file descriptors disponibile per l'account utente MySQL.

   Un altro problema comune: se si sta tentando di soddisfare richieste che richiedono file IO sopra il limite di 1.024 (per impostazione predefinita), si verificheranno casi in cui l'operazione semplicemente fallisce. Questo perché la maggior parte dei sistemi specifica un limite flessibile e rigido sul numero di descrittori di file aperti che ciascun utente può avere contemporaneamente e il superamento di questa soglia può causare problemi.

   Questo di solito contiene una serie di segni evidentemente evidenti espressi nei file di registro. Controllare /var/log/messages e le directory comparabili (ad esempio, /var/log/mysql per vedere se si può trovare qualcosa di interessante.

3. aver eseguito in uno scenario in cui il vostro livelock or deadlock thread è inappagabile.

   corollario alla memoria e descrittore di file esaurimento i thread possono scadere se hai superato il carico di calcolo che il tuo sistema è in grado di gestire Non invierà questo messaggio di errore, ma questo è qualcosa a cui fare attenzione in futuro

4. Il sistema è in esecuzione di PID disponibili per fork.

   Un altro scenario comune: fork ha solo così tanti PID disponibili per il suo utilizzo in qualsiasi momento. Se il tuo sistema è semplicemente overforked, smetterà di essere in grado di servire le richieste.

   Il controllo più semplice per questo è vedere se altri servizi possono connettersi alla macchina. Ad esempio, provare SSH nella casella e scoprire che non è possibile è un grande indizio.

5. Un proxy o gestore di connessione upstream ha esaurito le risorse e ha interrotto le richieste di assistenza.

   Se si dispone di un livello di servizio tra il client e MySQL, è necessario verificare se si è arrestato in modo anomalo, bloccato o altrimenti instabile. Il consiglio sopra si applica.

6. Il tuo mappatore di porte si è esaurito after 65,536 connections.

   Improbabile, ma ancora, un possibile caso di esaurimento. Controllare la connessione di servizio banale come sopra è, ehm, anche il miglior porto di scalo qui.

In breve: questo è uno scenario esaurimento delle risorse, comprensivo del server di essere semplicemente "giù". Dovrai profilare ulteriormente il tuo sistema per vedere cosa stai bloccando. Tutto ciò che il messaggio di errore ci dà in questo caso è il fatto che la risorsa non è disponibile per il client - avremmo bisogno di vedere più informazioni sul server per determinare un rimedio più adeguato.

Answer 3

Accidenti, questo potrebbe essere così tante cose. Potrebbe essere che lo spazio del buffer del socket sia esaurito. Potrebbe essere che mysql non accetti le connessioni tanto velocemente quanto stanno arrivando e il limite del backlog sia stato raggiunto (anche se mi aspetterei che per darti un errore "Connessione rifiutata", non so per certo che è quello che tu " Prenderò un socket di dominio Unix). Potrebbe essere una delle cose che @MrGomez ha sottolineato.

Dato che si esegue Apache e MySQL sullo stesso server e questo è un problema con carico elevato, potrebbe essere che Apache stia morendo di fame nel sistema di alcune risorse e non si veda (notando?) La caduta/mancate connessioni/richieste in entrata nei tuoi log.

Si sta utilizzando il pool di connessioni? Altrimenti, inizierei lì.

Cercherei anche gli errori nei log di Apache e syslog all'incirca nello stesso momento dell'errore mysql_connect e vedere cos'altro si presenta. In particolare, consiglio di far trasferire MySQL sul proprio server dedicato separato.