de recursos no disponibles Mysql

Question

que estoy viendo algunos de estos errores durante el tiempo de carga temporalmente altas:

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) 

De lo que puedo decir al servidor MySQL no está alcanzando su límite de conexiones máximo, pero hay algo más que detener de servir la consulta. ¿Qué otros límites alcanzaría MySQL?

estoy corriendo RHEL 6.2 de 64 bits con MySQL 5.5.21

Answer 1

Todavía no he encontrado los límites que estaba pegando, pero me las arreglé para solucionar el problema. Hubo un problema con nuestra tabla de sesiones (en vbulletin) que utiliza el motor MEMORY. Los índices de esta tabla eran HASH y, por lo tanto, cuando vbulletin purgaba esta tabla una vez por hora bloqueaba la tabla el tiempo suficiente para contener otras consultas y empujaba mysql al límite de sus recursos.

Al cambiar los índices a BTREE, esto permitió a MySQL eliminar las filas de la tabla de sesiones mucho más rápido y evitar los límites que se habían alcanzado previamente. Los errores solo comenzaron cuando actualizamos nuestro servidor master db a MySQL 5.5, así que supongo que las tablas MEMORY se manejan de manera diferente en la última versión.

Consulte http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/ para obtener información sobre los aumentos de velocidad del uso de índices BTREE sobre HASH para MEMORIA.

Answer 2

Supongamos que su sistema está actualmente basado en UNIX (como se da en el planteamiento del problema). Si esto es correcto, aquí está el conjunto de los problemas que puede estar ejecutando en:

1. se le han acabado de memory disponible para MySQL.

   Este es el problema más probable que enfrenta. Cada conexión en el grupo de conexiones de MySQL requiere memoria para funcionar, y si este recurso se agota, no se pueden hacer más conexiones. Por supuesto, las huellas de memoria y los tamaños máximos de paquetes de varias operaciones se pueden sintonizar en your equivalent to my.cnf si descubres que esto es un problema.

   Here's an additional thread that can help there, pero también puede considerar el uso de herramientas de creación de perfiles más simples como top para obtener una buena estimación aproximada de lo que está sucediendo.

2. Se ha quedado sin file descriptors disponible para su cuenta de usuario de MySQL.

   Otro problema común: si intenta atender solicitudes que requieren un archivo IO por encima del límite de 1.024 (de forma predeterminada), se encontrará con casos donde la operación simplemente falla. Esto se debe a que la mayoría de los sistemas especifican un límite suave y rígido para la cantidad de descriptores de archivos abiertos que cada usuario puede tener disponibles a la vez, y caminar por encima de este umbral puede causar problemas.

   Esto generalmente tendrá una serie de signos evidentemente obvios expresados ​​en sus archivos de registro. Compruebe /var/log/messages y sus directorios comparables (por ejemplo, /var/log/mysql para ver si puede encontrar algo interesante.

3. le han acabado en un escenario livelock or deadlock donde el hilo es insaciable.

   Corolario a la memoria y el descriptor de archivo agotamiento , los hilos pueden agotar el tiempo de espera si ha excedido la carga computacional que su sistema es capaz de manejar. No arrojará este mensaje de error, pero esto es algo a lo que debe prestar atención en el futuro

4. Su sistema se está ejecutando de los PID disponibles para fork.

   Otro escenario común: fork solo tiene tantos PID disponibles para su uso en un momento dado. Si su sistema es simplemente overforked, dejará de poder atender las solicitudes.

   El control más fácil para esto es ver si otros servicios se pueden conectar a la máquina. Por ejemplo, intentar introducir SSH en el cuadro y descubrir que no se puede obtener es una gran pista.

5. Un proxy ascendente o administrador de conexión se ha quedado sin recursos y ha dejado de atender las solicitudes.

   Si tiene alguna capa de servicio entre su cliente y MySQL, debe inspeccionar para ver si se ha bloqueado, bloqueado o de alguna otra manera se ha vuelto inestable. El consejo anterior aplica.

6. Su mapeador de puertos se ha agotado after 65,536 connections.

   Poco probable, pero de nuevo, un posible caso de agotamiento. Comprobar la conexión de servicio trivial como se indica arriba es, ehm, también el mejor puerto de escala aquí.

En resumen: este es un escenario de agotamiento de los recursos, incluido el servidor simplemente estar "abajo". Tendrás que perfilar más tu sistema para ver qué estás bloqueando. Todo el mensaje de error que nos da en este caso es el hecho de que el recurso no está disponible para el cliente; necesitaríamos ver más información sobre el servidor para determinar un remedio más adecuado.

Answer 3

Caray, esto podría ser tantas cosas. Podría ser que el espacio del búfer de socket se haya agotado. Podría ser que mysql no acepte conexiones tan rápido como están entrando y que se haya alcanzado el límite de retraso acumulado (aunque espero que eso le proporcione un error de "Conexión rechazada", no estoy seguro de que sea eso lo que ll obtener para un socket de dominio Unix). Podría ser cualquiera de las cosas que señaló @MrGomez.

Dado que está ejecutando Apache y MySQL en el mismo servidor y este es un problema con mucha carga, bien podría ser que Apache está privando al sistema de algún recurso y simplemente no está viendo (¿notando?) La caída/conexiones/solicitudes entrantes fallidas en sus registros.

¿Está utilizando la agrupación de conexiones? Si no, comenzaría allí.

También buscaría errores en los registros de Apache y syslog al mismo tiempo que el error mysql_connect y veré qué más aparece. Recomiendo encarecidamente llevar MySQL a su propio servidor dedicado.