El problema de hoy me ha preocupado y no sé cuántas noches. Para solucionar este problema, mi equipo y yo dedicamos mucho tiempo, ¡pero al final valió la pena!
Al principio, el problema no era: la conexión no está disponible, la solicitud agotó el tiempo de espera después de 5000 ms. En ese momento, nuestro grupo de conexiones de base de datos todavía era C3P0, descubrí que algunas ejecuciones de SQL empresarial también eran muy lentas, el 90% de SQL estaría en 10 ms Interna (no SQL lento), pero de vez en cuando siempre habrá alguna ejecución que demore miles de milisegundos. Todos los fenómenos anteriores se observan a través de un punto.
Después de pensarlo, creo que puede deberse a que el grupo de conexiones es demasiado antiguo. Verifiqué el java. Utiliza grupos de conexiones cada vez más populares como c3p0, dbcp, druid y hikaricp. También vi una comparación de ellos en Internet. C3P0 es de hecho De ninguna manera, hikaricp es lo mejor. Da la casualidad de que la unidad también está presionando a hikaric, así que cambiamos a hikaricp. Pensé que el problema debería resolverse, pero no ayudó. Después de abrir pinpint, sigue siendo el mismo
El execute () todavía se ejecuta durante mucho tiempo, pero hay una diferencia. Pinpoint no rastrea el método getConnection () cuando se usa C3P0. Esta vez hay un método getConnection () adicional y, a veces, el tiempo de getConnection será muy largo. Al final, es un método que tiene un tiempo de ejecución corto, uno es que el tiempo de ejecución es relativamente largo y el otro es que el tiempo de getConnection es relativamente largo.
Debido a que esta falta de efectivo al principio no tuvo ningún impacto en el negocio, no se realizaron más investigaciones posteriormente. Pero a medida que pasaba el tiempo, se producían nuevos problemas y el log comenzó a reportar algunos errores de la base de datos, que eran los mismos que el título:
org.springframework.jdbc.CannotGetJdbcConnectionException: No se pudo obtener la conexión JDBC; La excepción anidada es java.sql.SQLTransientConnectionException: XXPool: la conexión no está disponible, la solicitud agotó el tiempo de espera después de 5000 ms.
La ejecución de sql informó un error, this. . . Comenzó a afectar el negocio. No puedo soportarlo más, continúa comprobando. Juega al pinpoint para ver:
En correspondencia con el registro, más tarde este error se hizo cada vez más. Echamos un vistazo a la configuración del grupo de conexiones.
Llegue a la conclusión: la conexión en el grupo de conexiones no es suficiente, porque se agotó el tiempo debido a la espera de la conexión, y también es correcto con el método getConnection () que dije anteriormente (también hay un consumo de execute () sin solución duración).
Comenzamos a pensar en formas de verificar nuestras conclusiones. Al acceder a hikaricp, almacenamos algunos de los datos del grupo de conexiones de hikaricp en la biblioteca a través de MBean (JMX) Monitoring , Idle Connection, Active Connections, Total Connection, Waiting Connection. También hay muchos en espera e inactivos. No parece que el grupo de conexiones esté lleno. ¿Será una pérdida de conexión? Agregamos el parámetro de grupo de conexiones fugaDetecciónThreshold para observar. Se encontró que no había pérdida de conexión, pero esta vez a través del registro, encontramos un nuevo error:
La aparición del problema de la conexión está muerta, ¡hagamos una serie de pensamientos! ! ! ¿Por qué está muerto?
Debido a que las conexiones obtenidas del grupo de conexiones están muertas y toda connnection () toma mucho tiempo, miramos el código fuente. Al obtener la conexión, hikaripc probará la conexión, por lo que agregamos la configuración al grupo de conexiones.
Los parámetros son demasiado grandes y el nuevo error está aquí nuevamente: java.sql.SQLTimeoutException: ORA-01013: el usuario solicitó la cancelación de la operación actual
Revisé ORA-01013 en línea, y la explicación se debió principalmente a bloqueos de la mesa. Le pregunté a mi viejo amigo Ping An oracle Daniel, y me pregunté si había un problema de bloqueo de la mesa, y la fijación de la mesa causará este problema, pero este problema es cierto No necesariamente causado por bloqueos de mesa, resulta que no son bloqueos de mesa, jaja. En ese momento, busqué dba y no encontré la tabla de bloqueo.
Si no lo juego, realmente no puedo verificarlo más. Han pasado casi dos semanas desde que lo verifiqué. Tengo algunas versiones y no puedo jugar más. ¡Ve a lo grande! Esta vez, hemos reunido a todos los peces gordos en 5 campos de dba, middleware, host, red y operación y mantenimiento, y hemos convocado a Shenlong. Es realmente una conclusión que hay mucha gente y poder: ¡hay un gran retraso en la aplicación a la base de datos!
El resto de la historia no será así, solo cambie la tarjeta de red, el cable de red, etc. . . Resolvió el problema de la demora, ¡esta vez el problema estaba realmente resuelto!
He aquí un resumen: el software es algo complejo y la tecnología aplicada es aún más extensa. Como desarrollador, el pensamiento y la capacidad técnica solo pueden quedarse en la capa de aplicación. Nunca pensé que pensaría hacia abajo (afuera), y habrá problemas en la capa de red o hardware. Esto también plantea grandes exigencias a nuestra tecnología de desarrollo.
Además, realmente no hay nada que temer cuando hay un problema (error). Una vez resuelto el problema, el conocimiento y el crecimiento que el error le brinde será un valor futuro.
Finalmente, agradecer a mi equipo y colegas. ¡Trabajaremos duro juntos en el futuro! Trabaja duro, independientemente del resultado . También espero que este artículo sea útil para todos.