VisualVM socket.read

Question

Così stavo profilando la mia applicazione con VisualVM.

Ho colpito un hotspot sulla mia interazione MySQL. Il mio primo pensiero è che l'hot spot mostrava il tempo che la mia applicazione stava aspettando dopo l'IO. Ma nel report di profilazione, VisualVM ha due colonne "Time" e "Time (cpu)". Forse il termine è erroneamente usato, ma ho pensato che la colonna di auto-tempo (cpu) escludesse il tempo di IO. Dopo ulteriori debug, abbiamo concluso che l'ipotesi era sbagliata e mostrava il tempo di attesa perché l'hotspot era su java.net.SocketInputStream.read() del driver MySQL e altre cose di IO che non dovrebbero costare alcuna CPU.

Quindi, la mia domanda è perché visualvm segnala SocketInputStream.read() come tempo di cpu?

Answer 1

le chiamate native sono sempre nello stato RUNNABLE durante il monitoraggio dell'attività del thread, probabilmente perché la JVM non ha modo di sapere se la chiamata nativa sta dormendo o sta effettivamente facendo qualcosa. Quindi, il tempo trascorso nello stato RUNNABLE conta come tempo della CPU.

Answer 2

SocketInputStream.read() blocca finché ci sono dati disponibili dal lato opposto. Quindi potrebbe essere una risposta lenta dal tuo database.

Answer 3

This very long thread afferma che piccole scritture potrebbero causare il problema. Vale la pena leggere, ma non so cosa potresti fare al riguardo. Cosa potresti fare? Potresti essere sicuro di non utilizzare un piccolo fetch size. Questo non ti darà piccole scritture, ma letture di piccole dimensioni che portano allo stesso problema. Potresti provare diverse piattaforme per il client o il server. C'è un commento in this bug che recita:

"Abbiamo visto enormemente comportamento diverso da quanto velocemente I/O buffer di riempirsi tra Solaris e Linux (e quindi il numero di chiamate al ReadAheadInputStream.fill(), perché legge ciò che è disponibile, non blocca se non ha bisogno di leggere più di quello che è disponibile). "