rmi.transport.tcp.tcptransport Обработчик соединений потребляет много ресурсов ЦП

я запускаю стороннее приложение RMI-Server, предоставляющее только один метод ("getImage()" returns an image as byte[]). Реализация этого метода (получение изображения через SOAP-WS) предоставлена ​​мной.

Проблема при запуске этого RMI-сервера заключается в высоком потреблении процессора (измерено с помощью jvisualvm): 65% времени процессора уходит на "sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run()", а на втором месте с 15% находится "sun.net.www.http.KeepAliveCache.run()". «Настоящая» работа (масштабирование изображения) стоит на 4 месте. Сервер работает на Win 2003 Server. Я предполагаю, что что-то не так с обработкой ресурсов/соединений?? но это проблема реализации или проблема конфигурации Windows?

другое наблюдение: если загрузка процессора высока, использование памяти также увеличивается - вопрос в том, связано ли это с тем, что сборщик мусора не может выполнять свою работу или многие изображения ожидают доставки. все, что я могу сказать, память используется для byte[].

так есть идеи что делать?

спасибо заранее


windows java network-programming rmi
person dermoritz    schedule 08.03.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() — это метод, который вызывает ваши удаленные реализации на сервере после сортировки аргументов и до сортировки результата. Тайминги, вероятно, означают, что для возврата изображения по сети в качестве результата RMI требуется больше времени, чем для масштабирования изображения.

person user207421    schedule 22.03.2011

arrow_upward
0
arrow_downward

Я могу только предположить, что массив байтов может быть изображением, но это может быть что угодно.

Кстати, вы используете многоядерную машину? У меня также возникла эта проблема, и я обнаружил, что VisualVM указал на того же виновника примерно на 50% загрузки ЦП на четырехъядерном компьютере с Win7 и на 100% на одноядерном WinXP. Я использую Jetty для сервера.

Извините, я пока не могу ответить на настоящий вопрос, но надеюсь услышать решение здесь или иметь возможность поделиться им здесь в ближайшее время. Поскольку вы столкнулись с этим несколько месяцев назад, возможно, вы уже нашли его и можете поделиться?

person CodeboyUp    schedule 17.05.2011