Tu latencia en el percentil 99 tiene picos que el código de la aplicación no explica. ¿Cómo compruebas si la recolección de basura es la responsable?

Activa el logging de recolección de basura y alinea las marcas de tiempo de las pausas con las peticiones lentas. Si los picos coinciden con pausas, mira la tasa de asignación, la promoción y el margen del heap antes de tocar ningún flag, ya que la mayoría de las pausas vienen de asignar demasiado o de un heap demasiado pequeño. Si no coinciden, revisa el tiempo hasta safepoint, porque un safepoint largo detiene a todos los hilos y se parece exactamente a una pausa de recolección.

Quiero dos líneas temporales. El logging unificado me da cada pausa con su causa y su duración, y mis trazas me dan las peticiones lentas, así que la primera pregunta es simplemente si se alinean. Si lo hacen, me resisto a cambiar flags y miro por qué. Normalmente el servicio asigna enormemente por petición, algo como construir listas intermedias en un bucle o loguear un payload serializado en cada llamada, así que el arreglo es asignar menos. A veces el heap está demasiado justo y las recolecciones corren sin parar, o en G1 el código asigna arrays grandes que se convierten en objetos humongous y se portan mal. Solo después de eso consideraría pasar a un recolector de pausa baja, y lo trataría como un compromiso y no como una ganancia gratis. Si las pausas no correlacionan, miro en otra parte: el tiempo hasta safepoint puede ser largo aunque la recolección en sí sea corta, así que un hilo en un bucle contado deja parados a todos. También he perseguido un caso que resultó ser throttling de CPU del contenedor, donde el proceso quedaba desplanificado del todo y ningún ajuste de la JVM habría ayudado.