Memory Growth
I've got a simple OCI program that processes a very large number of rows. As it runs, I'm seeing the memory footprint of the application grow and grow, even though I only keep one row around at a time. Ultimately, the system is starved of memory and bad things happen.
I'm not doing anything fancy in my OCI code: just a simple prepare/execute/fetch.
Thanks,
Brad
null
This could be related to session timeout values. The default is 30 mins...
Monitor the console memory after the transactions, does it start to decrease after
the 30 mins is up and the sessions expire?
"Njsingh" <[email protected]> wrote:
>
Try using Performasure made by the same coimpany that made JProbe. It
is a multi-jvm
profiler that works with lower overhead under high load. It is a pretty
good tool
that let's you profile the complete system and then export information
to Jprobe
for detailed profiling.
Guru <[email protected]> wrote:
Hi
I am using Weblogic 7.0 SP1 on Solaris 2.8, Sun JVM 1.4.1_01 64 bit.
After about 1000 txns, the memory grows and does not come down at all.
I ran JPRobe on Windows machine and could not reproduce the problem
Would be very grateful if someone could shed some light on this
Similar Messages
-
How to diagnose rapid memory growth in Solaris 10 java server application
Hi,
We have a production java based server that experienced large memory growth recently and we are looking for help in diagnosing what might be the cause. The memory footprint of this java server application is limited to 120M using the jvm -Xmx switch. The server process size held consistently at around 180M until an event happened that caused the process size to rapidly increase to aprox 3G. We used the java jstat command to check the application heap usage within the jvm was within the specified limits.
This application can be performs java Runtime exec's to run simple shell scripts from a variety of java threads in the server app.
We have attempted to search for a cause by analysing the output of the pmap, pfiles, and pstack commands but have been unsuccessfull at this. We have also attempted to run the libumem.so library with the application in the hopes of using mdb to find out where the heap usage is. Unfortunately when we followed the instruction on using limumem the application stopped working due an ELF error.
The following are what we used for libumem:
LD_PRELOAD=/usr/lib/libumem.so
UMEM_DEBUG=default
UMEM_LOGGING=transaction
export LD_PRELOAD UMEM_DEBUG UMEM_LOGGING
<run the application>
The error we got is:
ld.so.1: nohup: fatal: /usr/lib/libumem.so: wrong ELF class: ELFCLASS32
We are looking for advice on how to proceed in finding the cause for this growth. In addition to the diag info below we have captured the core file for the application from gcore. The following is the output from pfiles, pmap, pstack, and the showrev command.
Any help/suggestions appreciated.
Steve
java version information:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)
pmap:
24584: /export/home/sonusComm/jre/bin/java -Dname=agent -Xmx120M -DAGENT_HOME
Address Kbytes RSS Anon Locked Mode Mapped File
00010000 64 8 - - r-x-- java
0002E000 16 8 8 - rwx-- java
00032000 3896 2648 1400 - rwx-- [ heap ]
00400000 3579904 717400 591704 - rwx-- [ heap ]
E50F6000 32 32 24 - rw--R [ anon ]
E50FE000 8 8 8 - rw--R [ stack tid=189562 ]
E52F6000 32 32 16 - rw--R [ anon ]
E52FE000 8 8 8 - rw--R [ stack tid=180717 ]
E5CF6000 32 32 16 - rw--R [ anon ]
E5CFE000 8 8 8 - rw--R [ stack tid=170864 ]
E6DF6000 40 40 40 - rw--R [ stack tid=220763 ]
E6EF6000 40 40 40 - rw--R [ anon ]
E6FF6000 8 8 - - rw--R [ anon ]
E6FF8000 32 32 32 - rw--R [ stack tid=220225 ]
E71F6000 40 40 40 - rw--R [ anon ]
E72F6000 40 40 40 - rw--R [ anon ]
E73F8000 24 24 - - rw--R [ anon ]
E73FE000 8 8 8 - rw--R [ stack tid=193659 ]
E74F6000 40 40 40 - rw--R [ stack tid=220762 ]
E75F6000 40 40 40 - rw--R [ stack tid=215672 ]
E76F6000 8 8 - - rw--R [ anon ]
E76F8000 32 32 32 - rw--R [ stack tid=211403 ]
E77F8000 8 8 - - rw--R [ anon ]
E77FA000 24 24 24 - rw--R [ stack tid=206975 ]
E78F6000 40 40 40 - rw--R [ anon ]
E79F8000 32 32 32 - rw--R [ stack tid=220760 ]
E7AF6000 40 40 40 - rw--R [ anon ]
E7CF6000 40 40 40 - rw--R [ stack tid=220764 ]
E7EF6000 32 32 8 - rw--R [ anon ]
E7EFE000 8 8 8 - rw--R [ stack tid=185268 ]
E7FF6000 16 16 16 - rw--R [ anon ]
E7FFC000 16 16 16 - rw--R [ stack tid=140567 ]
E80F6000 8 8 8 - rw--R [ anon ]
E80FE000 8 8 8 - rw--R [ stack tid=145776 ]
E81FC000 16 16 16 - rw--R [ stack tid=124964 ]
E82F6000 40 40 40 - rw--R [ anon ]
E83F8000 32 32 32 - rw--R [ stack tid=1512 ]
E84F6000 8 8 8 - rw--R [ anon ]
E84FA000 8 8 8 - rw--R [ anon ]
E84FE000 8 8 8 - rw--R [ stack tid=119761 ]
E85F6000 32 32 8 - rw--R [ anon ]
E85FE000 8 8 8 - rw--R [ stack tid=202234 ]
E86F6000 16 16 8 - rw--R [ anon ]
E86FA000 24 24 24 - rw--R [ stack tid=197719 ]
E87F8000 32 32 32 - rw--R [ stack tid=1518 ]
E88F8000 8 8 8 - rw--R [ anon ]
E88FC000 16 16 16 - rw--R [ stack tid=173 ]
E89FA000 24 24 24 - rw--R [ stack tid=161359 ]
E8AF8000 32 32 32 - rw--R [ stack tid=34505 ]
E8BFE000 8 8 8 - rw--R [ stack tid=135384 ]
E8CF8000 8 8 8 - rw--R [ anon ]
E8CFC000 16 16 16 - rw--R [ stack tid=172 ]
E8DF6000 8 8 8 - rw--R [ anon ]
E8DFC000 16 16 16 - rw--R [ stack tid=150966 ]
E8EFA000 8 8 8 - rw--R [ anon ]
E8EFE000 8 8 8 - rw--R [ stack tid=130168 ]
E8FFA000 8 8 8 - rw--R [ anon ]
E8FFE000 8 8 8 - rw--R [ stack tid=166557 ]
E90FE000 8 8 8 - rw--R [ stack tid=44270 ]
E91F8000 32 32 32 - rw--R [ stack tid=368 ]
E92FA000 8 8 - - rw--R [ anon ]
E92FE000 8 8 8 - rw--R [ stack tid=156163 ]
E93F8000 32 32 32 - rw--R [ stack tid=82 ]
E94F8000 8 8 8 - rw--R [ anon ]
E94FC000 16 16 16 - rw--R [ stack tid=72 ]
E95F8000 16 16 8 - rw--R [ anon ]
E95FC000 16 16 16 - rw--R [ stack tid=175828 ]
E96FE000 8 8 8 - rw--R [ stack tid=67 ]
E97F8000 32 32 32 - rw--R [ stack tid=62 ]
E98FE000 8 8 8 - rw--R [ stack tid=65 ]
E99FE000 8 8 8 - rw--R [ stack tid=51517 ]
E9AF8000 32 32 32 - rw--R [ stack tid=59 ]
E9BF8000 32 32 32 - rw--R [ stack tid=56 ]
E9CF8000 8 8 8 - rw--R [ anon ]
E9CFC000 16 16 16 - rw--R [ stack tid=57 ]
E9DF8000 16 16 8 - rw--R [ anon ]
E9DFC000 16 16 16 - rw--R [ stack tid=58 ]
E9EF8000 32 32 32 - rw--R [ stack tid=52 ]
E9FF8000 32 32 32 - rw--R [ stack tid=51 ]
EA0F8000 32 32 32 - rw--R [ stack tid=50 ]
EA1F8000 32 32 32 - rw--R [ stack tid=49 ]
EA2F8000 32 32 32 - rw--R [ stack tid=48 ]
EA3F8000 32 32 32 - rw--R [ stack tid=46 ]
EA4F8000 32 32 32 - rw--R [ stack tid=45 ]
EA5F8000 8 8 8 - rw--R [ anon ]
EA5FC000 8 8 - - rw--R [ anon ]
EA5FE000 8 8 8 - rw--R [ stack tid=44 ]
EA6FE000 8 8 8 - rw--R [ stack tid=43 ]
EA7FE000 8 8 8 - rw--R [ stack tid=42 ]
EA8F6000 40 40 40 - rw--R [ stack tid=41 ]
EA9F8000 32 32 32 - rw--R [ stack tid=38 ]
EAAF8000 32 32 32 - rw--R [ stack tid=40 ]
EABFE000 8 8 8 - rw--R [ stack tid=39 ]
EACFE000 8 8 8 - rw--R [ stack tid=31 ]
EADFE000 8 8 8 - rw--R [ stack tid=30 ]
EAEF8000 32 32 32 - rw--R [ stack tid=33 ]
EAFF8000 32 32 32 - rw--R [ stack tid=28 ]
EB0F8000 32 32 32 - rw--R [ stack tid=27 ]
EB1F8000 8 8 8 - rw--R [ anon ]
EB1FE000 8 8 8 - rw--R [ stack tid=26 ]
EB2F8000 8 8 - - rw--R [ anon ]
EB2FA000 24 24 24 - rw--R [ stack tid=25 ]
EB3F8000 8 8 8 - rw--R [ anon ]
EB3FE000 8 8 8 - rw--R [ stack tid=24 ]
EB4F8000 8 8 8 - rw--R [ anon ]
EB4FC000 16 16 16 - rw--R [ stack tid=21 ]
EB580000 816 - - - r--s- dev:32,24 ino:716444
EB680000 760 - - - r--s- dev:32,24 ino:716443
EB780000 1160 - - - r--s- dev:32,24 ino:716441
EB900000 816 - - - r--s- dev:32,24 ino:728313
EBA00000 760 - - - r--s- dev:32,24 ino:728312
EBB00000 1160 - - - r--s- dev:32,24 ino:728310
EBC80000 1120 - - - r--s- dev:32,24 ino:728308
EBE7E000 8 8 8 - rw--R [ stack tid=20 ]
EBF78000 32 32 32 - rw--R [ stack tid=19 ]
EC07E000 8 8 8 - rw--R [ stack tid=18 ]
EC17E000 8 8 8 - rw--R [ stack tid=17 ]
EC27E000 8 8 8 - rw--R [ stack tid=16 ]
EC378000 32 32 32 - rw--R [ stack tid=15 ]
EC400000 6880 - - - r--s- dev:32,24 ino:716451
ECB78000 32 32 32 - rw--R [ stack tid=14 ]
ECC00000 808 - - - r--s- dev:32,24 ino:716464
ECD00000 592 - - - r--s- dev:32,24 ino:716465
ECE78000 16 16 8 - rw--R [ anon ]
ECE7C000 16 16 16 - rw--R [ stack tid=83 ]
ECF00000 784 - - - r--s- dev:32,24 ino:716758
ED07E000 8 8 8 - rw--R [ stack tid=12 ]
ED27C000 16 16 16 - rw--R [ stack tid=10 ]
ED37E000 8 8 8 - rw--R [ stack tid=9 ]
ED3D0000 128 64 64 - rwx-- [ anon ]
ED400000 16384 15424 15232 - rwx-- [ anon ]
F1400000 1408 1408 1408 - rwx-- [ anon ]
F1560000 3264 3264 3136 - rwx-- [ anon ]
F1890000 5568 5568 5504 - rwx-- [ anon ]
F1E00000 7424 768 704 - rwx-- [ anon ]
F6400000 4096 4096 3968 - rwx-- [ anon ]
F6800000 3072 3072 3072 - rwx-- [ anon ]
F6B00000 1408 1408 1408 - rwx-- [ anon ]
F6C60000 448 448 448 - rwx-- [ anon ]
F6CD0000 1344 1344 1344 - rwx-- [ anon ]
F6E20000 512 512 512 - rwx-- [ anon ]
F6EA0000 832 832 832 - rwx-- [ anon ]
F6F70000 128 128 128 - rwx-- [ anon ]
F6F90000 1344 1344 1344 - rwx-- [ anon ]
F70E0000 448 448 448 - rwx-- [ anon ]
F7150000 384 384 384 - rwx-- [ anon ]
F71B0000 128 128 128 - rwx-- [ anon ]
F71D0000 192 192 192 - rwx-- [ anon ]
F7200000 128 128 128 - rwx-- [ anon ]
F7220000 128 128 128 - rwx-- [ anon ]
F7240000 128 128 128 - rwx-- [ anon ]
F7260000 192 192 192 - rwx-- [ anon ]
F7290000 128 128 128 - rwx-- [ anon ]
F72B0000 64 64 64 - rwx-- [ anon ]
F72C0000 384 384 384 - rwx-- [ anon ]
F7320000 448 448 448 - rwx-- [ anon ]
F7390000 896 896 896 - rwx-- [ anon ]
F7470000 768 768 768 - rwx-- [ anon ]
F7530000 704 704 704 - rwx-- [ anon ]
F75E0000 576 576 576 - rwx-- [ anon ]
F7670000 576 576 576 - rwx-- [ anon ]
F7700000 448 448 448 - rwx-- [ anon ]
F7770000 384 384 384 - rwx-- [ anon ]
F77D0000 128 128 128 - rwx-- [ anon ]
F77F0000 192 192 192 - rwx-- [ anon ]
F7820000 320 320 320 - rwx-- [ anon ]
F7870000 128 128 128 - rwx-- [ anon ]
F7890000 128 128 128 - rwx-- [ anon ]
F78B0000 448 448 448 - rwx-- [ anon ]
F7920000 896 896 896 - rwx-- [ anon ]
F7A00000 768 768 768 - rwx-- [ anon ]
F7AC0000 704 704 704 - rwx-- [ anon ]
F7B70000 832 832 640 - rwx-- [ anon ]
F7C40000 704 704 384 - rwx-- [ anon ]
F7CF0000 448 448 384 - rwx-- [ anon ]
F7D60000 704 704 384 - rwx-- [ anon ]
F7E10000 384 384 192 - rwx-- [ anon ]
F7E70000 384 384 192 - rwx-- [ anon ]
F7ED0000 320 320 256 - rwx-- [ anon ]
F7F20000 256 256 192 - rwx-- [ anon ]
F7F60000 256 256 192 - rwx-- [ anon ]
F7FA0000 128 128 128 - rwx-- [ anon ]
F7FC0000 192 192 128 - rwx-- [ anon ]
F7FF0000 192 192 128 - rwx-- [ anon ]
F8020000 256 256 128 - rwx-- [ anon ]
F8060000 128 128 128 - rwx-- [ anon ]
F8080000 128 128 64 - rwx-- [ anon ]
F80A0000 192 192 192 - rwx-- [ anon ]
F80D0000 384 384 192 - rwx-- [ anon ]
F8130000 64 64 64 - rwx-- [ anon ]
F8140000 64 64 - - rwx-- [ anon ]
F8150000 128 128 128 - rwx-- [ anon ]
F8170000 128 128 128 - rwx-- [ anon ]
F8190000 128 128 128 - rwx-- [ anon ]
F81B0000 128 128 64 - rwx-- [ anon ]
F81D0000 1600 1600 768 - rwx-- [ anon ]
F8360000 1152 1152 384 - rwx-- [ anon ]
F8480000 960 472 - - rwx-- [ anon ]
F8570000 832 80 - - rwx-- [ anon ]
F8640000 128 8 - - rwx-- [ anon ]
F8660000 832 16 - - rwx-- [ anon ]
F8730000 576 - - - rwx-- [ anon ]
F87C0000 448 - - - rwx-- [ anon ]
F8830000 256 - - - rwx-- [ anon ]
F8870000 320 - - - rwx-- [ anon ]
F88C0000 256 - - - rwx-- [ anon ]
F8900000 256 - - - rwx-- [ anon ]
F8940000 256 - - - rwx-- [ anon ]
F8980000 192 - - - rwx-- [ anon ]
F89B0000 384 - - - rwx-- [ anon ]
F8A10000 320 - - - rwx-- [ anon ]
F8A60000 192 - - - rwx-- [ anon ]
F8A90000 256 - - - rwx-- [ anon ]
F8AD0000 256 - - - rwx-- [ anon ]
F8B10000 192 128 64 - rwx-- [ anon ]
F8B40000 128 128 128 - rwx-- [ anon ]
F8B60000 64 64 64 - rwx-- [ anon ]
F8B70000 192 192 128 - rwx-- [ anon ]
F8BA0000 128 128 64 - rwx-- [ anon ]
F8BC0000 128 - - - rwx-- [ anon ]
F8C10000 64 - - - rwx-- [ anon ]
F8C30000 8 8 - - r-x-- librmi.so
F8C40000 8 8 8 - rwx-- librmi.so
F8C60000 64 - - - r--s- dev:32,24 ino:728318
F8C80000 376 144 - - r-x-- pkcs11_softtoken.so.1
F8CEE000 16 - - - rwx-- pkcs11_softtoken.so.1
F8D7E000 8 8 8 - rw--R [ stack tid=8 ]
F8D90000 16 - - - r--s- dev:32,24 ino:728317
F8DA0000 232 - - - r--s- dev:32,24 ino:728316
F8DE0000 88 - - - r--s- dev:32,24 ino:716445
F8E90000 16 - - - r--s- dev:32,24 ino:728315
F8EA0000 136 - - - r--s- dev:32,24 ino:728309
F8ED0000 136 - - - r--s- dev:32,24 ino:728307
F8F78000 32 32 32 - rw--R [ stack tid=6 ]
F8F90000 88 - - - r--s- dev:32,24 ino:728314
F8FB0000 8 8 8 - rwx-- [ anon ]
F8FC0000 88 88 - - r-x-- libpkcs11.so.1
F8FE6000 24 16 8 - rwx-- libpkcs11.so.1
F8FEC000 8 - - - rwx-- libpkcs11.so.1
F9000000 4096 4096 4096 - rwx-- [ anon ]
F9400000 4096 4096 4096 - rwx-- [ anon ]
FB010000 24 24 - - r-x-- libcryptoutil.so.1
FB026000 8 8 - - rwx-- libcryptoutil.so.1
FB030000 56 8 - - r-x-- libj2pkcs11.so
FB04C000 8 - - - rwx-- libj2pkcs11.so
FB060000 352 - - - r--s- dev:32,24 ino:716547
FB0C0000 184 - - - r--s- dev:32,24 ino:716545
FB178000 8 8 8 - rw--R [ anon ]
FB17E000 8 8 8 - rw--R [ stack tid=5 ]
FB190000 8 - - - r---- [ anon ]
FB1A0000 160 - - - r--s- dev:32,24 ino:716544
FB1D0000 72 64 - - r-x-- libnet.so
FB1F0000 8 8 8 - rwx-- libnet.so
FB27E000 8 8 8 - rw--R [ stack tid=4 ]
FB290000 24 8 - - r-x-- libmanagement.so
FB2A4000 8 8 - - rwx-- libmanagement.so
FB2B0000 256 - - - r--s- dev:32,24 ino:716466
FB37E000 8 8 8 - rw--R [ stack tid=3 ]
FB390000 32 - - - r--s- dev:32,24 ino:716442
FB3A0000 120 - - - r--s- dev:32,24 ino:716467
FB3D0000 176 - - - r--s- dev:32,24 ino:716455
FB400000 8520 - - - r--s- dev:32,24 ino:717379
FBC60000 32 - - - r--s- dev:32,24 ino:728311
FBC70000 40 - - - r--s- dev:32,24 ino:716546
FBC80000 304 - - - r--s- dev:32,24 ino:716456
FBCD0000 176 - - - r--s- dev:32,24 ino:716759
FBD7E000 8 8 8 - rw--R [ stack tid=2 ]
FBD90000 32 - - - r--s- dev:32,24 ino:716463
FBDA0000 8 - - - r--s- dev:32,24 ino:716757
FBDB0000 160 - - - r--s- dev:32,24 ino:716756
FBDE0000 64 64 64 - rw--- [ anon ]
FBE00000 64 40 40 - rw--- [ anon ]
FBE20000 32 32 32 - rwx-- [ anon ]
FBE50000 8 8 8 - rwx-- [ anon ]
FBE52000 8 8 8 - rwx-- [ anon ]
FBE54000 8 8 8 - rwx-- [ anon ]
FBE56000 16 16 16 - rwx-- [ anon ]
FBE80000 24 24 24 - rwx-- [ anon ]
FBE86000 8 8 - - rwx-- [ anon ]
FBE88000 8 8 8 - rwx-- [ anon ]
FBE8A000 8 8 8 - rwx-- [ anon ]
FBE8C000 8 8 8 - rwx-- [ anon ]
FBE8E000 8 8 8 - rwx-- [ anon ]
FBE90000 8 8 8 - rwx-- [ anon ]
FBE92000 8 8 8 - rwx-- [ anon ]
FBE94000 8 8 8 - rwx-- [ anon ]
FBE96000 8 8 8 - rwx-- [ anon ]
FBE98000 8 8 8 - rwx-- [ anon ]
FBE9A000 8 8 8 - rwx-- [ anon ]
FBE9C000 8 8 - - rwx-- [ anon ]
FBF10000 32 32 32 - rwx-- [ anon ]
FBF30000 8 8 8 - rwx-- [ anon ]
FBF32000 8 8 8 - rwx-- [ anon ]
FBF34000 8 8 8 - rwx-- [ anon ]
FBF36000 16 16 16 - rwx-- [ anon ]
FBF58000 8 8 8 - rwx-- [ anon ]
FBF5A000 8 8 8 - rwx-- [ anon ]
FBF5C000 8 8 8 - rwx-- [ anon ]
FBF5E000 8 8 8 - rwx-- [ anon ]
FBF60000 8 8 8 - rwx-- [ anon ]
FBF62000 8 8 8 - rwx-- [ anon ]
FBF64000 8 8 8 - rwx-- [ anon ]
FBF66000 8 8 8 - rwx-- [ anon ]
FBF68000 8 8 - - rwx-- [ anon ]
FBF6A000 8 8 8 - rwx-- [ anon ]
FBF6C000 8 - - - rwx-- [ anon ]
FBF80000 480 - - - r--s- dev:32,24 ino:716808
FC000000 35016 - - - r--s- dev:32,24 ino:716764
FE240000 64 64 64 - rwx-- [ anon ]
FE260000 88 - - - r--s- dev:32,24 ino:716807
FE280000 1184 - - - r--s- dev:32,24 ino:716460
FE3B0000 8 - - - r--s- dev:32,24 ino:716468
FE3C0000 200 - - - r--s- dev:32,24 ino:716461
FE400000 1744 - - - r--s- dev:32,24 ino:716459
FE5C0000 64 - - - r--s- dev:32,24 ino:716458
FE5E0000 8 8 8 - rwx-- [ anon ]
FE5F0000 64 24 - - r-x-- libzip.so
FE600000 8 8 8 - rwx-- libzip.so
FE610000 144 96 - - r-x-- libjava.so
FE644000 8 8 8 - rwx-- libjava.so
FE650000 56 16 - - r-x-- libverify.so
FE66E000 8 8 8 - rwx-- libverify.so
FE680000 40 - - - r--s- dev:32,24 ino:716397
FE692000 8 8 - - rwxs- [ anon ]
FE6A0000 32 16 - - rw-s- dev:295,2 ino:5858787
FE6B0000 32 8 - - r-x-- libhpi.so
FE6C8000 8 8 8 - rwx-- libhpi.so
FE6CA000 8 - - - rwx-- libhpi.so
FE6E0000 16 16 - - r-x-- libmp.so.2
FE6F4000 8 8 - - rwx-- libmp.so.2
FE700000 680 160 - - r-x-- libm.so.2
FE7B8000 32 32 - - rwx-- libm.so.2
FE7D0000 8 8 8 - rwx-- [ anon ]
FE7E0000 8 8 - - r-x-- libmd5_psr.so.1
FE7F2000 8 8 - - rwx-- libmd5_psr.so.1
FE800000 7984 4696 - - r-x-- libjvm.so
FEFDC000 408 392 320 - rwx-- libjvm.so
FF042000 56 48 48 - rwx-- libjvm.so
FF060000 8 8 8 - rwx-- [ anon ]
FF070000 8 8 - - r-x-- libmd5.so.1
FF082000 8 8 - - rwx-- libmd5.so.1
FF090000 32 24 - - r-x-- libuutil.so.1
FF0A8000 8 8 - - rwx-- libuutil.so.1
FF0B0000 8 8 - - r-x-- libdoor.so.1
FF0C2000 8 8 - - rwx-- libdoor.so.1
FF0D0000 96 88 - - r-x-- libscf.so.1
FF0F8000 8 8 - - rwx-- libscf.so.1
FF100000 584 584 - - r-x-- libnsl.so.1
FF1A2000 40 40 8 - rwx-- libnsl.so.1
FF1AC000 24 - - - rwx-- libnsl.so.1
FF1C0000 8 8 8 - rwx-- [ anon ]
FF1D0000 16 16 - - r-x-- libm.so.1
FF1E2000 8 8 - - rwx-- libm.so.1
FF1F0000 48 48 - - r-x-- libCrun.so.1
FF20A000 8 8 8 - rwx-- libCrun.so.1
FF20C000 16 - - - rwx-- libCrun.so.1
FF220000 8 8 - - r---- [ anon ]
FF230000 48 48 - - r-x-- libsocket.so.1
FF24C000 8 8 8 - rwx-- libsocket.so.1
FF260000 8 8 - - r-x-- libsched.so.1
FF270000 8 8 - - r-x-- libc_psr.so.1
FF280000 864 864 - - r-x-- libc.so.1
FF368000 32 32 24 - rwx-- libc.so.1
FF370000 8 8 8 - rwx-- libc.so.1
FF380000 8 8 8 - rwx-- [ anon ]
FF390000 24 24 24 - rwx-- [ anon ]
FF3A0000 8 8 - - r-x-- libdl.so.1
FF3B0000 184 184 - - r-x-- ld.so.1
FF3EE000 8 8 8 - rwx-- ld.so.1
FF3F0000 8 8 8 - rwx-- ld.so.1
FF3F8000 16 16 - - r-x-- libthread.so.1
FFB80000 24 - - - ----- [ anon ]
FFBF4000 48 8 8 - rw--- [ stack ]
pfiles:
24584: /export/home/sonusComm/jre/bin/java -Dname=agent -Xmx120M -DAGENT_HOME
Current rlimit: 65536 file descriptors
0: S_IFCHR mode:0666 dev:291,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDONLY|O_LARGEFILE
/devices/pseudo/mm@0:null
1: S_IFREG mode:0644 dev:32,24 ino:716359 uid:50004 gid:6003 size:36526979
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
/export/home/sonusComm/logs/console.log
2: S_IFREG mode:0644 dev:32,24 ino:716359 uid:50004 gid:6003 size:36526979
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
/export/home/sonusComm/logs/console.log
3: S_IFCHR mode:0666 dev:291,0 ino:6815772 uid:0 gid:3 rdev:13,12
O_RDWR FD_CLOEXEC
/devices/pseudo/mm@0:zero
4: S_IFDOOR mode:0444 dev:300,0 ino:58 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[104]
/var/run/name_service_door
5: S_IFCHR mode:0644 dev:291,0 ino:99614724 uid:0 gid:3 rdev:190,0
O_RDONLY|O_LARGEFILE
/devices/pseudo/random@0:random
6: S_IFCHR mode:0644 dev:291,0 ino:99614726 uid:0 gid:3 rdev:190,1
O_RDONLY|O_LARGEFILE
/devices/pseudo/random@0:urandom
7: S_IFREG mode:0644 dev:32,24 ino:716361 uid:50004 gid:6003 size:323022
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
/export/home/sonusComm/server/communicator/log/server.log
8: S_IFIFO mode:0000 dev:299,0 ino:47868548 uid:50004 gid:6003 size:0
O_RDWR
9: S_IFSOCK mode:0666 dev:297,0 ino:4151 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 6098
10: S_IFSOCK mode:0666 dev:297,0 ino:4155 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 42405
12: S_IFSOCK mode:0666 dev:297,0 ino:19198 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 6099
14: S_IFIFO mode:0000 dev:299,0 ino:47865419 uid:50004 gid:6003 size:0
O_RDWR
15: S_IFCHR mode:0644 dev:291,0 ino:99614724 uid:0 gid:3 rdev:190,0
O_RDONLY|O_LARGEFILE
/devices/pseudo/random@0:random
16: S_IFSOCK mode:0666 dev:297,0 ino:48720 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 127.0.0.1 port: 2371
17: S_IFIFO mode:0000 dev:299,0 ino:47865419 uid:50004 gid:6003 size:0
O_RDWR
18: S_IFSOCK mode:0666 dev:297,0 ino:37454 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 9991
19: S_IFREG mode:0644 dev:32,24 ino:717406 uid:50004 gid:6003 size:23436
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/export/home/sonusComm/logs/application.monitor.audit
20: S_IFSOCK mode:0666 dev:297,0 ino:3896 uid:0 gid:0 size:0
O_RDWR
SOCK_DGRAM
SO_BROADCAST,SO_SNDBUF(57344),SO_RCVBUF(57344),IP_NEXTHOP(0.0.224.0)
sockname: AF_INET 0.0.0.0 port: 161
21: S_IFSOCK mode:0666 dev:297,0 ino:3897 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 7788
22: S_IFSOCK mode:0666 dev:297,0 ino:22116 uid:0 gid:0 size:0
O_RDWR
SOCK_DGRAM
SO_BROADCAST,SO_SNDBUF(57344),SO_RCVBUF(57344),IP_NEXTHOP(0.0.224.0)
sockname: AF_INET 0.0.0.0 port: 9993
23: S_IFSOCK mode:0666 dev:297,0 ino:64893 uid:0 gid:0 size:0
O_RDWR
SOCK_DGRAM
SO_BROADCAST,SO_SNDBUF(57344),SO_RCVBUF(57344),IP_NEXTHOP(0.0.224.0)
sockname: AF_INET 0.0.0.0 port: 5200
24: S_IFSOCK mode:0666 dev:297,0 ino:26901 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 2020
26: S_IFREG mode:0644 dev:32,24 ino:716364 uid:50004 gid:6003 size:658924
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/export/home/sonusComm/logs/EventMgr.audit
27: S_IFSOCK mode:0666 dev:297,0 ino:4149 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 127.0.0.1 port: 7788
peername: AF_INET 127.0.0.1 port: 42407
29: S_IFREG mode:0644 dev:32,24 ino:716365 uid:50004 gid:6003 size:49140
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/export/home/sonusComm/logs/EventMgrLog.audit
30: S_IFSOCK mode:0666 dev:297,0 ino:4150 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 19991
31: S_IFSOCK mode:0666 dev:297,0 ino:3714 uid:0 gid:0 size:0
O_RDWR
SOCK_DGRAMI was finally able to reproduce this problem where I observed that within a 5 minute time span the jvm process grew from around 180M (VS) / 100M (RSS) to 2G (VS) / 1G (RSS). Here are some samplings at the end of my dtrace run showing the largest allocations that were made. We suspect this might be a JVM bug (since jstat reports our heap is well below the 120M limit we specified). Do you have any suggestions on how we might resolve this issue ?
Thanks,
Steve
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0xdc
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x31c
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
2352344
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0x90
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x5d0
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
2807672
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFChunk2n6FII_pv_+0xd4
libjvm.so`__1cFArenaIArealloc6MpvII_1_+0xc4
libjvm.so`__1cKNode_ArrayEgrow6MI_v_+0x7c
libjvm.so`__1cMPhaseChaitinbApost_allocate_copy_removal6M_v_+0x544
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x1488
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
2817016
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFChunk2n6FII_pv_+0xd4
libjvm.so`__1cFArenaIArealloc6MpvII_1_+0xc4
libjvm.so`__1cKNode_ArrayEgrow6MI_v_+0x7c
libjvm.so`__1cMPhaseChaitinbApost_allocate_copy_removal6M_v_+0x518
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x1488
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
3013552
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cMPhaseChaitinFSplit6MI_I_+0x2a8
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x100c
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
3341112
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0xdc
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x5d0
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
3402976
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0x90
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x8b8
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
3952576
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cMPhaseChaitinFSplit6MI_I_+0x2a8
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x720
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
4782376
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0xdc
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x8b8
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
4881328
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cHMatcherFxform6MpnENode_i_2_+0xac
libjvm.so`__1cHMatcherFmatch6M_v_+0x644
libjvm.so`__1cHCompileICode_Gen6M_v_+0xd4
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
5090648
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cOPhaseIdealLoopKDominators6M_v_+0xb4
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0x7fc
libjvm.so`__1cHCompileIOptimize6M_v_+0x200
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
5252816
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0x90
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x1180
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
5820336
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cOPhaseIdealLoopKDominators6M_v_+0xb4
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0x7fc
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
5822560
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cMPhaseChaitinFSplit6MI_I_+0x2c0
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x720
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
6747736
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0xdc
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x1180
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
7129056
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cOPhaseIdealLoopKDominators6M_v_+0xb4
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0x7fc
libjvm.so`__1cHCompileIOptimize6M_v_+0x47c
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
16349616
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFChunk2n6FII_pv_+0x244
libjvm.so`__1cFArenaIArealloc6MpvII_1_+0xc4
libjvm.so`__1cENodeIout_grow6MI_v_+0x150
libjvm.so`__1cENodeFclone6kM_p0_+0x1f0
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0x8c8
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
134217736
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFChunk2n6FII_pv_+0x244
libjvm.so`__1cFArenaIArealloc6MpvII_1_+0xc4
libjvm.so`__1cKNode_ArrayEgrow6MI_v_+0x7c
libjvm.so`__1cMPhaseIterGVNWadd_users_to_worklist06MpnENode__v_+0xa4
libjvm.so`__1cMPhaseIterGVNVadd_users_to_worklist6MpnENode__v_+0x8
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x3c
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
134217736
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cENodeIout_grow6MI_v_+0xac
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0xacc
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
165122996
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cENodeFclone6kM_p0_+0xb0
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0x8c8
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
165122996
libumem.so.1`malloc
libjava.so`JNU_GetStringPlatformChars+0xd8
libnet.so`Java_java_net_Inet4AddressImpl_lookupAllHostAddr+0x54
0xf8c0c280
0xf8c0c224
0xf8c05d3c
0xf8c05d3c
0xf8c05874
0xf8c05874
0xf8c05764
0xf8c05c2c
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
-4294966636 -
Hi,
We have a production java based server that experienced large memory growth recently and we are looking for help in diagnosing what might be the cause. The memory footprint of this java server application is limited to 120M using the jvm -Xmx switch. The server process size held consistently at around 180M until an event happened that caused the process size to increase rapidly to aprox 3G within a 4 minute period. We used the java jstat command to check the application heap usage within the jvm and it was within the specified limits.
We have collected a variety of diagnostic information (pmap, pstack, pfiles, etc - available on request) as well as output from dtrace using a script that is used to count the number of memory allocations. The dtrace script and tail end of this message.
Any help in interpreting the dtrace output in the hopes of pinpointing a cause for the large memory allocations would be greatly appreciated.
Steve
java version information:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)
dtrace script:
#!/usr/sbin/dtrace -d -F
pid$target::malloc:entry
@totalbytes[ ustack() ] = sum( arg0 );
pid$target::valloc:entry
@totalbytes[ ustack() ] = sum( arg0 );
pldd information:
8348: /export/home/sonusComm/jre/bin/java -Dname=agent -Xmx120M -DAGENT_HOME
/lib/libumem.so.1
/lib/libthread.so.1
/lib/libdl.so.1
/lib/libc.so.1
/platform/sun4u-us3/lib/libc_psr.so.1
/export/home/sonusComm/jre/lib/sparc/server/libjvm.so
/lib/libsocket.so.1
/usr/lib/libsched.so.1
/usr/lib/libCrun.so.1
/lib/libm.so.1
/lib/libnsl.so.1
/lib/libm.so.2
/lib/libscf.so.1
/lib/libdoor.so.1
/lib/libuutil.so.1
/lib/libmd5.so.1
/platform/sun4u/lib/libmd5_psr.so.1
/lib/libmp.so.2
/export/home/sonusComm/jre/lib/sparc/native_threads/libhpi.so
/export/home/sonusComm/jre/lib/sparc/libverify.so
/export/home/sonusComm/jre/lib/sparc/libjava.so
/export/home/sonusComm/jre/lib/sparc/libzip.so
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3
/export/home/sonusComm/jre/lib/sparc/libnet.so
/export/home/sonusComm/jre/lib/sparc/libmanagement.so
/export/home/sonusComm/jre/lib/sparc/libj2pkcs11.so
/usr/lib/libpkcs11.so.1
/usr/lib/libcryptoutil.so.1
/usr/lib/security/pkcs11_softtoken.so.1
/export/home/sonusComm/jre/lib/sparc/librmi.so
dtrace output snippet (the numeric value at the end of each stack is the number of bytes allocated)
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cMPhaseChaitinFSplit6MI_I_+0x2a8
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x720
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
9269948
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cHMatcherFxform6MpnENode_i_2_+0xac
libjvm.so`__1cHMatcherFmatch6M_v_+0x644
libjvm.so`__1cHCompileICode_Gen6M_v_+0xd4
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
10008720
libumem.so.1`malloc
libc.so.1`_real_gettext_u+0x98
libc.so.1`dgettext+0x98
libhpi.so`0xff0623d0
libjava.so`JNU_ThrowIOExceptionWithLastError+0x28
libjava.so`Java_java_lang_UNIXProcess_forkAndExec+0x714
0xf8f4f250
0xf90dd264
0xf90e6cdc
0xf9101be0
0xf8ed8078
0xf8c05c2c
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
10313472
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cIPhaseIFGEinit6MI_v_+0xdc
libjvm.so`__1cMPhaseChaitinRRegister_Allocate6M_v_+0x1180
libjvm.so`__1cHCompileICode_Gen6M_v_+0x2b0
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xc08
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
10371104
libumem.so.1`malloc
libnet.so`Java_java_net_SocketInputStream_socketRead0+0xcc
0xf8c668ec
0xf8f01088
0xf8c76344
0xf8c058b8
0xf8c05764
0xf8c595b4
0xf8e7e594
0xf8c96238
0xf8c05c2c
0xf8c05d3c
0xf8c05d3c
0xf8c05d3c
0xf8c05c2c
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
10469376
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cICHeapObj2n6FI_pv_+0x1c
libjvm.so`__1cKJavaThreadKinitialize6M_v_+0xc0
libjvm.so`__1cKJavaThread2t5B6MpFp0pnGThread__vI_v_+0x60
libjvm.so`JVM_StartThread+0x1c0
0xf8c0c280
0xf8c0c224
0xf8f40c7c
0xf9065edc
0xf913a744
0xf9132638
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
10552560
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cICHeapObj2n6FI_pv_+0x1c
libjvm.so`__1cFMutex2t5B6Mipkci_v_+0x20
libjvm.so`__1cHMonitor2t5B6Mipkci_v_+0x10
libjvm.so`__1cGThread2t5B6M_v_+0x118
libjvm.so`__1cKJavaThread2t5B6MpFp0pnGThread__vI_v_+0x34
libjvm.so`JVM_StartThread+0x1c0
0xf8c0c280
0xf8c0c224
0xf8f40c7c
0xf9065edc
0xf913a744
0xf9132638
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
11607816
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cOPhaseIdealLoopKDominators6M_v_+0xb4
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0x7fc
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
12653032
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cJOopMapSetGall_do6FpknFframe_pnICodeBlob_pknLRegisterMap_pnKOopClosure_pFppnHoopDesc_9E_v9B9B_v_+0x5a0
libjvm.so`__1cJOopMapSetHoops_do6FpknFframe_pnICodeBlob_pknLRegisterMap_pnKOopClosure__v_+0x44
libjvm.so`__1cFframeRoops_code_blob_do6MpnKOopClosure_pknLRegisterMap__v_+0x28
libjvm.so`__1cKJavaThreadHoops_do6MpnKOopClosure__v_+0x19c
libjvm.so`__1cPThreadRootsTaskFdo_it6MpnNGCTaskManager_I_v_+0x50
libjvm.so`__1cMGCTaskThreadDrun6M_v_+0x1e0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
18146824
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cOPhaseIdealLoopKDominators6M_v_+0xb4
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0x7fc
libjvm.so`__1cHCompileIOptimize6M_v_+0x47c
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
20415552
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`jni_GetByteArrayElements+0x144
libjava.so`Java_java_lang_UNIXProcess_forkAndExec+0x58
0xf8f4f250
0xf90dd264
0xf90e6cdc
0xf9101be0
0xf8ed8078
0xf8c05c2c
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
38030987
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cICHeapObj2n6FI_pv_+0x1c
libjvm.so`JVM_StartThread+0x1a0
0xf8c0c280
0xf8c0c224
0xf8f40c7c
0xf9065edc
0xf913a744
0xf9132638
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
59094336
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cHThreadsZcreate_thread_roots_tasks6FpnLGCTaskQdDueue__v_+0x4c
libjvm.so`__1cKPSScavengeQinvoke_no_policy6Fpi_i_+0x7d0
libjvm.so`__1cKPSScavengeGinvoke6Fpi_v_+0x5c
libjvm.so`__1cUParallelScavengeHeapTfailed_mem_allocate6MpiIii_pnIHeapWord__+0xbc
libjvm.so`__1cbDVM_ParallelGCFailedAllocationEdoit6M_v_+0xa4
libjvm.so`__1cMVM_OperationIevaluate6M_v_+0x80
libjvm.so`__1cIVMThreadDrun6M_v_+0x6e0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
60336552
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cENodeIout_grow6MI_v_+0xac
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0xacc
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
100790212
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0xd4
libjvm.so`__1cENodeFclone6kM_p0_+0xb0
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0x8c8
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
101445332
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFChunk2n6FII_pv_+0x244
libjvm.so`__1cFArenaIArealloc6MpvII_1_+0xc4
libjvm.so`__1cMPhaseIterGVNJtransform6MpnENode__2_+0x98
libjvm.so`__1cHAddNodeFIdeal6MpnIPhaseGVN_i_pnENode__+0xa3c
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x28
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
268435464
libumem.so.1`malloc
libjvm.so`__1cCosGmalloc6FI_pv_+0x28
libjvm.so`__1cFArenaEgrow6MI_pv_+0x214
libjvm.so`__1cINodeHashEgrow6M_v_+0x74
libjvm.so`__1cINodeHashQhash_find_insert6MpnENode__2_+0x1ac
libjvm.so`__1cMPhaseIterGVNNtransform_old6MpnENode__2_+0x2f8
libjvm.so`__1cMPhaseIterGVNIoptimize6M_v_+0xac
libjvm.so`__1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_+0xc34
libjvm.so`__1cHCompileIOptimize6M_v_+0x174
libjvm.so`__1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_+0xbdc
libjvm.so`__1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb0
libjvm.so`__1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4cc
libjvm.so`__1cNCompileBrokerUcompiler_thread_loop6F_v_+0x44c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
536936472
libumem.so.1`malloc
libjava.so`JNU_GetStringPlatformChars+0xd8
libjava.so`Java_java_io_UnixFileSystem_getBooleanAttributes0+0x80
0xf8c0c280
0xf8c0c224
0xf8c058b8
0xf8c36cf8
0xf8f83678
0xf8fd515c
0xf8c96238
0xf8c05764
0xf8c05764
0xf8c05764
0xf8c00218
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a0
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
libjvm.so`__1cKJavaThreadDrun6M_v_+0x2b0
libjvm.so`__1cG_start6Fpv_0_+0x208
libc.so.1`_lwp_start
-8588966992This isn't a heap space issue with the java application though, which is what these tools you mentioned would be used to diagnose. The heap space usage of our java app is remaining constant and below the specified limit of 120M but the process continues to grow as we speak.
I can only conclude that this is most likely a jvm memory leak. I should have probably made this clearer in the subject heading.
Anyone know how to file a bug against the solaris jvm ? -
We have a multi-master Sun DS setup , wherein we are observing a huge memory growth on only one of them. Memory growth started after third party plug-ins were installed on them, the issue should have been seen on both as plug-in were installed on both of them. We have esclated it to plug-in OEM.
Have you faced any such issue in the past or do u know any tools preferably command to pull out these extra memory consumption?
FYI, the plug-in being used is CP metadirectory for Sun Directory Syncronisations with other databases.
TIAHi Ludovic,
Obviously, The first though was to hit 3rd party vendor for this cause, but they have a point " Plug-ins should have cause memory growth on both of them", whereas this is not the case. On the otherhand, We have the same plug-ins installed on our Dev & Stg environment, we dont see any similar issue there"
Is there any way to list out memory consumptions specifically by connections, lib etc?
TIA,
Nawaz -
Agent resident memory utilization and Agent Virtual Memory Growth is HIGH
I have been receiving many alerts from EM on agents resident memory and virtual memory growth is high. Every time the agent is getting restarted by watchdog.
I am wondering where exactly the problem is ...!
anilWhat platform and what Agent version are you using?
Regards
Rob
For more Tips and Tricks on OEM GC see: http://oemgc.wordpress.com -
I have tried all the turnarounds as I can find from the NI website, such as
1) Setting the NI-MinimumBufferSize to 10,000, or
2) Using the TDMS Advanced Synchronous Write along with other Advanced TDMS functions instead of standard TDMS write
However, the RT free memory still diminishes gradually when a DMS file is written. It is also noted that the drive space available on the /C/ is reduced as well. Due to the reduced free RT memory, a FPGA memory Full error occurs after recording 4~5 several large TDMS files (100 to 200 MB). Can anyone help on this issue?
More details on the system and the program I am working on:
1) LabVIEW 2014 Professional Developement
2) cRIO 9068 + 2 NI 9234 modules for triggered Sound & Vibration measuement
3) 8 Channels at 51200 S/s
4) FPGA buffer size 8191
5) RT buffer depth 5*8*51200
6) LabVIEW Code is simply beased on the LabVIEW sample project: LabVIEW FPGA Wavefrom Acquisition and Logging on CompactRIO
Regards,
JJDFRDHi Kyle,
Thank you for the work you've done on this.
I'm not 100% sure where we should be putting the TDMS Flush function? I've attached a modified cRIO Waveform Acquisition and Logging on CompactRIO Sample project based on a cRIO 9068 and 9234 as JJDFRD is using, and I still see the physcial memory declining with each TDMS write until it gets down to about 4M (reserved for the system) - Funnily enough it seems to work fine and continue to log and write even after it reaches this bottom threshold. If I change the Free Space constant to delete files when the disk space reaches say 30% rather thean the default value of 70%, I can see the Physcial Memory bounces back after a TDMS write and older tdms files are deleted.
If you could pelase confirm where we should put the TDMS Flush function this would be very helpful, and JJDFRD can try this out to see if it fixes his problem.
Kind Regards,
Stuart Little
Applications Engineering -
Help me understanding server memory usage
I am trying to determine how much memory our weblogic server needs and
am seeing what seems to me to be strange memory growth patterns in the
server. I am running weblogic6.1sp4(with CR093850) on solaris 2.7.
I have written an emulator for testing performance and stability of
our system. The emulator has sleeps in it between actions so it is
emulating a real end user interaction with the system, it is not
trying to emulate a super heavy load.
I configured weblogic server to have a high max heap to begin with(1.5
gig) and thought I could turn 10 emulators on and let them run for a
while to get all my entity bean cached filled up, then I could see
what the size of my server was at that point and expect that to be
close to what it will need. Is this an appropriate way to determine
size?
However, when I do this and try to let my emulators run for 24 hours,
I never make it past 13 hours. The weblogic server never stops
growing and of course I eventually end up with all the emulators
exiting with 'out of memory' errors from the server.
The process grows slowly at first, even seems pretty well behaved for
the first 2-4 hours. Then the process size starts to grow a little
more rapidly, then there is some drastic up and downs then eventually
it just stays high. During the spikes the CPU usage spikes as well
even though the load from my emulators has not increased.
If our code had a small memory leak I would expect to see a steady,
constant slow growth problem, but that is not whats happening, it
starts out small growth but then becomes more spiky.
I have max-beans-in-cache and max-beans-in-free-pool said reasonably
low on my entity beans that are used in this test. There are only 8
entity bean types being used in this test run. 1 stateful session
bean type and 3 stateless session beans.
Has anyone else seen this odd behavior? Has anyone had success in
setting a reasonable heap size?
any insight would be greatly appreciated!
KellyHi Kelly,
That looks pretty much like a memory leak. You could use a memory
profiler like OptimizeIt, or at least search though the code for
appearances of static public Hashtable
- that's where ever-growing "caches" live.
Regards,
Slava Imeshev
"Kelly Kingdon" <[email protected]> wrote in message
news:[email protected]...
I am trying to determine how much memory our weblogic server needs and
am seeing what seems to me to be strange memory growth patterns in the
server. I am running weblogic6.1sp4(with CR093850) on solaris 2.7.
I have written an emulator for testing performance and stability of
our system. The emulator has sleeps in it between actions so it is
emulating a real end user interaction with the system, it is not
trying to emulate a super heavy load.
I configured weblogic server to have a high max heap to begin with(1.5
gig) and thought I could turn 10 emulators on and let them run for a
while to get all my entity bean cached filled up, then I could see
what the size of my server was at that point and expect that to be
close to what it will need. Is this an appropriate way to determine
size?
However, when I do this and try to let my emulators run for 24 hours,
I never make it past 13 hours. The weblogic server never stops
growing and of course I eventually end up with all the emulators
exiting with 'out of memory' errors from the server.
The process grows slowly at first, even seems pretty well behaved for
the first 2-4 hours. Then the process size starts to grow a little
more rapidly, then there is some drastic up and downs then eventually
it just stays high. During the spikes the CPU usage spikes as well
even though the load from my emulators has not increased.
If our code had a small memory leak I would expect to see a steady,
constant slow growth problem, but that is not whats happening, it
starts out small growth but then becomes more spiky.
I have max-beans-in-cache and max-beans-in-free-pool said reasonably
low on my entity beans that are used in this test. There are only 8
entity bean types being used in this test run. 1 stateful session
bean type and 3 stateless session beans.
Has anyone else seen this odd behavior? Has anyone had success in
setting a reasonable heap size?
any insight would be greatly appreciated!
Kelly -
Oracle 9i running out of memory
Folks !
I have a simple 3 table schema with a few thousand entries each. After dedicating gigabytes of hard disk space and 50% of my 1+ GB memory, I do a few simple Oracle Text "contains" searches (see below) on these tables and oracle seems to grow some 25 MB after each query (which typically return less than a dozen rows each) till it eventually runs out of memory and I have to reboot the system (Sun Solaris).
This is on Solaris 9/Sparc with Oracle 9.2 . My query is simple right outer join. I think the memory growth is related to Oracle Text index/caching since memory utilization seems pretty stable with simple like '%xx%' queries.
"top" shows a dozen or so processes each with about 400MB RSS/SIZE. It has been a while since I did Oracle DBA work but I am nothing special here. Databse has all the default settings that you get when you create an Oracle database.
I have played with SGA sizes and no matter how large or small the size of SGA/PGA, Oracle runs out of memory and crashes the system. Pretty stupid to an Enterprise databas to die like that.
Any clue on how to arrest the fatal growth of memory for Oracle 9i r2?
thanks a lot.
-Sanjay
PS: The query is:
SELECT substr(sdn_name,1,32) as name, substr(alt_name,1,32) as alt_name, sdn.ent_num, alt_num, score(1), score(2)
FROM sdn, alt
where sdn.ent_num = alt.ent_num(+)
and (contains(sdn_name,'$BIN, $LADEN',1) > 0 or
contains(alt_name,'$BIN, $LADEN',2) > 0)
order by ent_num, score(1), score(2) desc;
There are following two indexes on the two tables:
create index sdn_name on sdn(sdn_name) indextype is ctxsys.context;
create index alt_name on alt(alt_name) indextype is ctxsys.context;I am already using MTS.
Atached is the init.ora file below.
may be I should repost this article with subject "memory leak in Oracle" to catch developer attention. I posted this a few weeks back in Oracle Text groiup and no response there either.
Thanks for you help.
-Sanjay
# Copyright (c) 1991, 2001, 2002 by Oracle Corporation
# Cache and I/O
db_block_size=8192
db_cache_size=33554432
db_file_multiblock_read_count=16
# Cursors and Library Cache
open_cursors=300
# Database Identification
db_domain=""
db_name=ofac
# Diagnostics and Statistics
background_dump_dest=/space/oracle/admin/ofac/bdump
core_dump_dest=/space/oracle/admin/ofac/cdump
timed_statistics=TRUE
user_dump_dest=/space/oracle/admin/ofac/udump
# File Configuration
control_files=("/space/oracle/oradata/ofac/control01.ctl", "/space/oracle/oradata/ofac/control02.ctl", "/space/oracle/oradata/ofac/control03.ctl")
# Instance Identification
instance_name=ofac
# Job Queues
job_queue_processes=10
# MTS
dispatchers="(PROTOCOL=TCP) (SERVICE=ofacXDB)"
# Miscellaneous
aq_tm_processes=1
compatible=9.2.0.0.0
# Optimizer
hash_join_enabled=TRUE
query_rewrite_enabled=FALSE
star_transformation_enabled=FALSE
# Pools
java_pool_size=117440512
large_pool_size=16777216
shared_pool_size=117440512
# Processes and Sessions
processes=150
# Redo Log and Recovery
fast_start_mttr_target=300
# Security and Auditing
remote_login_passwordfile=EXCLUSIVE
# Sort, Hash Joins, Bitmap Indexes
pga_aggregate_target=25165824
sort_area_size=524288
# System Managed Undo and Rollback Segments
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS1 -
Memory leak on SunOne Web Server 6.1 on application reload
Hi!
I am pretty sure that i have found a memory management problem in
SunOne Web Server 6.1 .
It started with an OutOfMemory error we got under heavy load . After
some profiling with Jprofiler i didn't find any memory leaks in the
application.Even under heavy load (generated by myself) i can't find
anything ,more, i can't reproduce the error! The memory usage is
about 20Mb and does not go up .
However it is pretty simple to see the following behavior:
[1] Restart the server (to have a clear picture) and wait a little for
memory usage to stabilize.
[2] In the application dir. touch .reload or one of the classes:
The memory usage goes up by another 50Mb (huge amount of mem. taking
into account the fact that it used only 20Mb under any load befor).
Do this another time and another 20Mb gone etc..
The JProfiler marks the memory used by classes . And it can be
clearly seen the GC can't release most of it.
I AM sure this is not the application that takes all the memory.
Another hint : after making the server to reload application i can see
that the number of threads ON EVERY RELOAD is going up by ~10-20
threads .The # of threads goes lower over time but not the mem usage.
My system:
Sparc Solaris 9 ,Java 1.4.2_04-b05, Sun ONE Web Server 6.1SP5
Evgenymy guess is that - because of '.reload' , web container tries to
recompile all the classes that you use within your web application and
hence the memory growth is spiking up.What do you mean by "tries to recompile"?The classes in
Web-inf are already compiled! And i have only ~5 jsp's .
(the most part of the applic. is a complicated business logic)
If you are talking about reloading them ,yes,that's the purpose of .reload,
isn't it? :).But it seems that container uses the memory for it's own
classes: the usage of memory for my classes don't really grow
that much (if at all) after reload (according to profiler)
Also the real problem is that the memory usage grows to much for
too long (neither seen it going down) and thus ends with OutOfMemory.
if you are seeing the memory growth to be flat in stress environment,
then I am not sure that why do you think that there is a memory leak ?There is no memory leak in stress environment.
There is memory leak while reloading the application.
It is a memory hog for sure (~20-30Mb for every reload).
Memory leak?It seems that way because i can't see memory usage go
down and after a lot of reloads OutOfMemory is thrown.
also, what is jvm heap that you use ? did you try jvm tune options like -
XX:+AggressiveHeap ?256Mb.I can set it bigger ,but how do i know that it will not just delay
the problem ?
Thanks for response.
Evgeny -
Memory leak with ThreadStackTrace in libjvm.so (jdk 1.5.0_11)
I posted this initially in "Desktop > Runtime Environment > Java Runtime Environment (JRE)", but am reposting here since this may be a more appropriate place. Here's a link to the original post:
http://forum.java.sun.com/thread.jspa?threadID=5156031&tstart=0
I'm trying to track down the cause of some memory growth in a java application. In my tests, the java heap appears to remain stable, but the overall memory footprint of the jvm process continues to grow (observed with pmap).
I've run my application with libumem and have found what appears to be the culprit, but the memory allocation is in libjvm.so and I'm looking for ideas what might cause it.
uname -a for my host
SunOS thehost 5.10 Generic_118822-18 sun4u sparc SUNW,Netra-440
and I'm using Java 1.5.0_11
Here is the trace from libumem:
1f81c4c0::bufctl_auditADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
1f81c4c0 1f81a470 ac018b4577a0 7
1f43f188 8cda6a4 0
libumem.so.1`umem_cache_alloc+0x210
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x28
libjvm.so`void*os::malloc+0x28
libjvm.so`void*ResourceObj::operator new+0x38
libjvm.so`ThreadStackTrace::ThreadStackTrace #Nvariant 1+0x34
libjvm.so`void VM_ThreadDump::doit+0xcc
libjvm.so`void VM_Operation::evaluate+0x80
libjvm.so`void VMThread::run+0x6e0
libjvm.so`void*_start+0x208
libc.so.1`_lwp_start
It looks like this leak occurrs when getStackTrace() is called on a Thread.
I've found that the included program will continually allocate memory on the process heap until the JVM cannot allocate memory and it exits with the following exception.
Exception java.lang.OutOfMemoryError: requested 16 bytes for C_Heap: ResourceOBJ. Out of swap space?
import java.lang.StackTraceElement;
import java.lang.Thread;
public class TraceIt {
public static void main(String[] args) {
System.out.println("Starting trace");
int i = 0;
while (true)
if (i%100 == 0) System.out.println(i);
StackTraceElement[] se = Thread.currentThread().getStackTrace();
i++;
} Any ideas what would cause this? Is it a JVM bug?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469701
BTW, when you register to post on this site why isn't Cuba in the list of countries? -
Hi,
I am investigating a problem where we experience continual growth of our JVM process. The overall process size and native heap size of the JVM process continually grow at the same rate. I am monitoring these using the commands 'ps - o pid,vsz,rss' and 'pmap -x' respectively. The increases are in multiples of 8Kb.
I have checked our java application using Optimizeit and it is not leaking memory. I have also monitored the size of the VM java heap using the '-verbose:gc' garbage collection debugging option. Garbage collection appears normal and the VM heap size remains below that specified by the '-Xmx' option.
It appears that the memory growth is occurring in native code of the JVM process but I am at a loss on how to determine what is causing this. Can anyone advise me what may be causing this JVM process growth or ways in which I may be able to find this out?
I am using JRE 1.4.2 SE (1.4.2_08_b03) on Solaris 8. Within the JVM we are running our web app in Tomcat 4.1.
The shared libraries loaded by the JVM (as shown by pldd) are:
/usr/lib/libthread.so.1
/usr/lib/libdl.so.1
/usr/lib/libc.so.1
/usr/platform/sun4u/lib/libc_psr.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/client/libjvm.so
/usr/lib/libCrun.so.1
/usr/lib/libsocket.so.1
/usr/lib/libnsl.so.1
/usr/lib/libm.so.1
/usr/lib/libsched.so.1
/usr/lib/libmp.so.2
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/native_threads/libhpi.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libverify.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjava.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libzip.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjdwp.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdt_socket.so
/usr/lib/nss_files.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnet.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvj.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcmq.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcm.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvft.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrv.so
/usr/lib/libpthread.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnio.so
/usr/lib/librt.so.1
/usr/lib/libaio.so.1
/usr/lib/libsendfile.so.1
/vob/ntg/dev/resources/lib/sol8gcc/libjavaperljni.so
/vob/ntg/dev/thirdparty/perl-5.8.0-gcc-thread/lib/libperl.so
/usr/lib/libw.so.1
/vob/ntg/dev/resources/lib/sol8gcc/libstdc++.so.2.10.0
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libioser12.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libawt.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libmlib_image.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/headless/libmawt.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libcmm.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libfontmanager.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdcpr.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjpeg.so
Any Help is much appreciated.Hi
If u can, use 1.4.2_10 (latest as of now). There is a bug 6250517, fixed in _09. Not sure if u r making any calls to NetworkInterface.getNetworkInterfaces.
Also noticed that you are using tibco. How about putting -Xcheck:jni and see if it picks up anything.
Unfortunately Solaris 8 didnt have libumem for tracking memory allocation. If u have any Solaris 9/10 boxes, you can use libumem to track it down.
http://access1.sun.com/techarticles/libumem.html -
JVM 1.5.0_11 and libumem -- need stack trace help for memory leak
I'm trying to track down the cause of some memory growth in a java application. In my tests, the java heap appears to remain stable, but the overall memory footprint of the jvm process continues to grow (observed with pmap).
I've run my application with libumem and have found what appears to be the culprit, but the memory allocation is in libjvm.so and I'm looking for ideas what might cause it.
uname -a for my host
SunOS thehost 5.10 Generic_118822-18 sun4u sparc SUNW,Netra-440
Here is the trace from libumem:
1f81c4c0::bufctl_auditADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
1f81c4c0 1f81a470 ac018b4577a0 7
1f43f188 8cda6a4 0
libumem.so.1`umem_cache_alloc+0x210
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x28
libjvm.so`void*os::malloc+0x28
libjvm.so`void*ResourceObj::operator new+0x38
libjvm.so`ThreadStackTrace::ThreadStackTrace #Nvariant 1+0x34
libjvm.so`void VM_ThreadDump::doit+0xcc
libjvm.so`void VM_Operation::evaluate+0x80
libjvm.so`void VMThread::run+0x6e0
libjvm.so`void*_start+0x208
libc.so.1`_lwp_start
What causes this invocation in the JVM? Is there a known memory leak associated with this?
Thanks in advance for the assistance.More on this issue. The included program will continually allocate memory on the process heap until the JVM cannot allocate memory and it exits with the following exception.
Exception java.lang.OutOfMemoryError: requested 16 bytes for C_Heap: ResourceOBJ. Out of swap space?
import java.lang.StackTraceElement;
import java.lang.Thread;
public class TraceIt {
public static void main(String[] args) {
System.out.println("Starting trace");
int i = 0;
while (true)
if (i%100 == 0) System.out.println(i);
StackTraceElement[] se = Thread.currentThread().getStackTrace();
i++;
} -
JSF (RI) app hot-deploy memory leak
I have a standard JSF (RI) based web app that appears to be working just fine in terms of functionality. However, I believe that there is a memory leak associated with the sort of frequent hot-deploy cycles that are typical during a normal development cycle. I have been monitoring the app via the jvmstat 3.0 tools and have witnessed NO memory growth in the young or old generation areas - regardless of useage pattern. All of the growth seems to happen in the perm area of memory and be directly coincidental with the occurence of a deploy. Eventually, continued hot-deply cycles will result in an OutOfMemory error on the container - please note that continued and extensive use of the app WITHOUT the aforementioned hot-deploys does NOT result in the OutOfMemory error.
From my research so far, I have discovered the following thread:
http://forum.hibernate.org/viewtopic.php?t=935948&postdays=0&postorder=asc&start=75
It refers to a similar problem with hiberate (which I am NOT using) as well as a commons-logging and several others. From the looks of it, I strongly suspect that there may be an issue with JSF when it's implementation is bundled inside the WEB-INF/lib dir - i.e. inside the specific web app's ClassLoader.
Based on the above, I have implemented a SessionContextListener that invokes the org.apache.commons.logging.LogFactory.release() inside the contextDestroyed( ServletContextEvent e ) method. This does appear to free up some perm memory but there is still large growth that appears to be directly related to the FacesServlet initialization (navigation handlers, etc). I looked into calling the FacesContext.release() method which seems to have purpose similar to that of the LogFactory.release() method. However, at the time of the contextDestroyed() invocation, FacesContext.getCurrentInstance() always returns null, so I do not ever have an opportunity to invoke the release method that I am aware of. If my suspicions are correct, than I would likely be able to avoid this problem entirely by simply placing the JSF implementation jars in the conatiner's shared lib dir - instead of bundling it inside WEB-INF/lib. However, this is not an option for this container as multiple web apps (which require the flexibility to use differing JSF implementations and versions - i.e. RI vs MyFaces, etc) will run on this container.
I don't believe it is at all related to the problem at hand, but my container is JBoss 4.0.2.
Any and all assistance and suggestion will be greatly appreciated! Has anyone else seen this sort of behavior? Are there any work arounds or corrective actions?
TIAHas anyone else run into this? I'd greatly appreciate any assistance as I cannot seem to resolve this hot-deploy related leak.
-
Memory continually growing in JS AIR app
Hi -
We're currently developing an HTML/Javascript AIR application, and I've been trying to pay pretty close attention to memory. One of the things I'm noticing is that memory never seems to come back down, even after objects have been nullified and events have been unbound. ...And I can't quite figure out why that is.
As far as I understand, any objects that are no longer referenced should be picked up by garbage collector, but I don't see that happening.
So for now my question is pretty simple: how do you go about profiling your memory usage on Adobe AIR? I've seen some tools that were available with Aptana, but that was back for AIR 2.0. Are there more up-to-date processes for this? Does anyone have any recommendations for how to deal with memory growth in AIR?
Thanks,
ZachQuick follow up here.
I went ahead and modified my source to run within Google Chrome so I could take advantage of Chrome's dev tools, which include some pretty solid memory profiling tools. What I discovered is that Chrome is garbage collecting as expected, and my memory footprint is remaining relatively consistent. But unfortunately that does not look like the case for AIR. I'll continue to post on here as I discover things, so perhaps others can benefit from what I might find. -
Memory leak running 32bit app in Windows 7 64bit
I have an app that does not show signs of memory leakage (I'm queuing up 10mb arrays, and dequeuing them to file) under a standard 32bit operating system. I've since tried running it in Windows 7 64 bit (as a 32 bit process using Labview 32-bit runtime engine) and noticed memory is incrementing.
Program takes 300Mb of memory. If I save 100Mb of data to a file, will windows 7 64bit show this as 400Mb of memory (under windows on windows 32 bit)? I don't think it would, but you never know...
Are there any bugs in Labview 2010 with regards to queuing and windows 64 bit? I'm tracking my Queue usage and it isn't increasing, thus no real reason for it to increase in memory allocation.
Solved!
Go to Solution.So this is something you observed.....by chance?
Why is the memory "growth" a concern for you?
As 32bit can allocate up to 2(3) GB of RAM per application process, memory is very limited, hence any application has to work very restrictive with memory.
64-bit can allocate several TB of RAM (possibly reduced limited provided by the OS, but still more likely in the TB range rather than GB), an application doesn't need to be conservative.
So it is possible that the OS Task Manager shows increased memory consuption, but as long as performance is not affected, it doesn't hurt anyone.
Norbert
EDIT: This might be also be induced by the funcions you are using to handle the data, in your case the file IO functions. Which functions are you using?
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Maybe you are looking for
-
Issues with Arch 2009.02 in VMware Workstation [SOLVED]
I installed Arch Linux 2009.02 i686 as a guest in VMware Workstation 6.5.1, my host is Vista x64. The installation of Arch itself and Xorg wasn't a problem although from this point I've had several issues. I was unable to 'startx' or 'xinit' without
-
Help! Javascript not working when object moved from one page to another!
Hello all: I am new to Adobe Livecycle Designer (version 8.0). I have created a 3 page interactive pdf form with numerous objects (text fields, radio buttons, drop-down boxes, etc.), that our business wants to begin using soon. I am having difficulty
-
PP Scenario Mapping help Needed
Hi Guys Can anyone please help to map the following scenario? <b>Scenario:</b> SAP PP <b>Product:</b> Ingot <b>Size:</b> Ingot 100 X 100, Ingot 125 X 125, Ingot 160 X160 <b>Grade:</b> A, B, C, <b>Saleable Item:</b> Ingot100 X100 Grade A, Ingot100 X
-
Can't Access Public Folders Within Outlook, But Can Through Web Access
Hi all, I have an Exchange 2010 Server (V14.02.0387.000) with clients using Outlook 2007-2013. Until recently all users could access all public folders without issue. However, since moving the location of the public and private mailboxes on the serve
-
Hi all I want to extract data, for division 01, material with reorder point >0 with text desc and list price sorted by product hierarchy. can anybody help me how can I do this. regards AJ