CDV ❯ Out of Memory and then death
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Cannot Reproduce
-
Sample Apps
-
-
drb
-
Reporter: ari
-
July 03, 2007
-
0
-
Watchers: 1
-
May 08, 2009
-
May 08, 2009
Attachments
Description
While running an edited version of the inventory app, I come across an L1 OOME only once 2 L1’s are present. I am running everything on 1 computer, and I am pretty sure this doesn’t reproduce when I run a separe L2.
I will attach the stack trace of the eventually “hung” L1 that eats 100% of CPU from the time it OOME’s till I kill -9 it.
I also have the edited inventory demo attached as a zip. And, FYI, I edited the -Xmx and -Xms on the L2 to 750MB and on the L1s to 128MB
Comments
Tim Eck 2007-07-04
Tim Eck 2007-07-05
The only way I can get this to fail in a similar fashion is too suspend (ctrl-Z) one of the clients. The heap is 80% byte arrays at that time. The L2 heap settins aren’t that important – the test updates a single field of a single object in a tight loop. The code looks like it wants to produce 10 changes per transaction, but it is effectively 1 since we optimize the case of changing the same field in the scope of a txn (good thing we don’t optimize the case where the value doesn’t actually change, then we’d really see some perf numbers).
Steps to reproduce: 1) get a 2.4 kit 2) Unpack the attached source in samples/pojo/inventory 3) run ant clean compile there 4) Change run.sh to use -Xmx128m -Xms128m 5) Start two clients, in each type “L” followed by enter 6) Suspend one of the clients, the other will OOME
Tim Eck 2007-07-05
ah ha. Another way to get the issue – only run the L command in one of the clients, let the other side idle just receiving broadcasts (thanks saro)
Ari Zilka 2007-07-06
you shouldn’t suspend one of the clients. And, if you set the L2 to 750MB of heap, the 2nd L1 won’t OOME when just sitting there getting broadcasts.
Ari Zilka 2007-07-06
BTW,
I have a version with cyclicbarrier to get the 2 L1’s to pound at once. With the barrier ensuring they start together, there is no longer an OOME.
From the thread dump, the 100% cpu prob is almost certainly DEV-113
To get a better picture of the heap, the clients should be run with -XX:+HeapDumpOnOutOfMemoryError (don’t know if that works on a mac)