Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[Unix] [Java] кто-нибудь оптимизировал крупное приложение ? как искать места, где больше всего теряется ресурсов системы ? 29.05.03 22:20
Автор: tdes <jin> Статус: Member
|
|
|
|
[Unix] [Java] кто-нибудь оптимизировал крупное приложение ? как искать места, где больше всего теряется ресурсов системы ? 30.05.03 01:16
Автор: tatar_0x4e Статус: Member
|
|
Для оптимизации по памяти я использовал методы Runtime.freeMemory(), Runtime.totalMemory(), собирал статистику, анализировал, графики строил, GC тюнил :) Статистику использования памяти можно также получить запуская VM с ключиком -verbose:gc...Кроме того имеется много профайлеров - те же JProbe, Borland OptimizeIt. Пока по моим наблюдениям самые большие проблемы у Java c памятью - жрет она ее не просто помногу, а ОЧЕНЬ помногу, - так что оптимизацией по скорости заниматься не довелось :)
|
| |
[Unix] [Java] кто-нибудь оптимизировал крупное приложение ? как искать места, где больше всего теряется ресурсов системы ? 30.05.03 02:16
Автор: tdes <jin> Статус: Member
|
У нас сервер, который, если повезет :)), будет обслуживать много запросов одновременно.
А есть ли какие-то бесплатные тулзы ? вот например нашёл HPROF ot SUN ...
|
| | |
[Unix] [Java] кто-нибудь оптимизировал крупное приложение ? как искать места, где больше всего теряется ресурсов системы ? 30.05.03 12:19
Автор: tatar_0x4e Статус: Member
|
> А есть ли какие-то бесплатные тулзы ? вот например нашёл
> HPROF ot SUN ...
А я даже этого не нашел, хотя и искал долго :)
По поводу сервера. В моем случае замечена интересная особенность - при правильно подобранных параметрах JVM, потребление памяти снижается где-то в три раза. Если с дефолтными настройками это чудо жрет порядка 150 MB сразу, а потом еще, и еще, и отдавать не собирается, то с incremental garbage collector и индивидуально подобранными опциями -Xmx, -XX:MaxPermSize, -XX:MaxHeapFreeRatio, -XX:NewRatio, не меняя ни строчки в исходном коде, получим порядка 50 MB сразу и гораздо меньшую скорость роста. Впрочем, ожидать, что оно отдаст ту память, которую уже скушало, не приходится:) Лучшая комбинация сборщиков мусора у меня получилась: -XX:+UseParallelGC, -Xincgc. Так что, прежде чем править код, имеет смысл поиграться с ключиками java VM и договориться с GC. Выигрыш, скорее всего, будет гораздо больше. Оптимизируя код в соответствии с рекомендациями Sun получилось выцарапать у него всего ~2 MB, да и то большой кровью.
Вот неплохие линки по теме:
http://java.sun.com/docs/hotspot/gc/index.html
http://java.sun.com/docs/hotspot/index.html
http://java.sun.com/docs/hotspot/gc1.4.2/index.html
А это просто забавная статейка про то, как Java работает с памятью по сравнению с С:
http://www.aceshardware.com/Spades/read.php?article_id=153
В частности, автор пришел к выводу, что с динамически выделяемой памятью JVM работает лучше, чем MSVC...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
