VisualVM socket.read
Поэтому я профилировал свое приложение с помощью VisualVM.
Я столкнулся с проблемой моего взаимодействия с MySQL. Мои первые мысли были о том, что горячая точка показывает время, когда мое приложение ожидает после ввода-вывода. Но в отчете о профилировании VisualVM имеет два столбца: "Время" и "Время (процессор)". Возможно, этот термин используется неправильно, но я предположил, что в столбце self-time (cpu) время IO исключено. После дополнительной отладки мы пришли к выводу, что предположение было неверным и показывало время ввода-вывода, поскольку точка доступа находилась на java.net.SocketInputStream.read() драйвера MySQL и других вещах ввода-вывода, которые не должны стоить ни одного процессора.
Итак, мой вопрос, почему visualvm сообщает SocketInputStream.read () как время процессора?
3 ответа
Собственные вызовы всегда находятся в состоянии RUNNABLE при мониторинге активности потоков, возможно потому, что JVM не может узнать, спит ли собственный вызов или что-то действительно делает. Таким образом, время, прошедшее в состоянии RUNNABLE, считается временем процессора.
Этот очень длинный поток утверждает, что причиной могут быть небольшие записи. Это стоит прочитать, но я не знаю, что вы могли бы с этим поделать. Что ты мог сделать? Вы можете убедиться, что вы не используете маленький размер выборки. Это не даст вам небольшие записи, но небольшое чтение приведет к той же проблеме. Вы можете попробовать разные платформы для клиента или сервера. В этой ошибке есть комментарий:
"Мы наблюдали совершенно различное поведение в отношении того, насколько быстро заполняются буферы ввода / вывода между Solaris и Linux (и, таким образом, количество вызовов ReadAheadInputStream.fill(), потому что он читает то, что доступно, он не блокируется, если ему не нужно читать больше, чем доступно).
SocketInputStream.read() блокируется, пока не будут доступны данные с другой стороны. Так что это может быть медленный ответ из вашей базы данных.