A supplement to the GC recovery optimization posting article

I remember that I wrote about the memory overflow problem of the jdk1.5 pool in my blog a while ago. This time I took advantage of the use of the new memcache client and conducted a comprehensive stress test.

JDK uses 1.5 of the stress test results. After a weekend, it cannot respond. Then, it looks at its GC output:

[Full GC [tenured: 786431 K-> 786431 K (786432 K), 3.4802480 secs] 1022399 K-> 1022399 K (1022400 K), [perm: 36711 K-> 36711 K (98304 K)], 3.4808510 secs]

 

Replace jdk1.5 with jdk1.6. I started the stress test at noon yesterday and took the log at noon today. The GC output is as follows:

[GC [psyounggen: 256608 K-> 3608 K (257792 K)] 859002 K-> 606698 K (1044224 K), 0.0562040 secs] [times: User = 0.17 sys = 0.01, real = 0.05 secs]

 

This clearly shows the difference. The former has used up all the families, out of the out of memory status. The latter is still normal GC recovery, and the recovery effect is very good. At the same time, when JBoss is started, the occupied younggen is about K, so it should be said that it is normal to run a day of stress testing.

 

Full GC is implemented only when the young generation cannot meet the memory allocation requirements. At this time, it may have been used up by the old and middle generations, the frequency of full GC is also increasing, and the server response speed is also getting slower and slower.

Therefore, for persistent stress testing, printing GC can effectively analyze the memory usage of the application itself and avoid application unavailability caused by a small amount of memory leakage during long-term operation.

 

By the way, the modified test result of the memcache client is as follows:

Test Plan:

The number of concurrent requests starts to 50. After each concurrent request is completed, the rest time is 0.1 seconds. After 10 minutes, the number of concurrent requests increases by 50. According to this rule, the number of concurrent requests increases to 500.

The new and old versions of SIP are stress tests completed in the jdk1.5 environment,

The same as before, the press is 10.2.226.40, dell1950, 8 CPU, 8 GB memory.

The press simulates the constant call request to a signed API.

 

Test conclusion:

The performance of the SIP of the old version is the same as that of the previous version. When the concurrency is 500, the TPS is close to 480, And the CPU is 68%.

The performance of the new version of SIP is much better than that of the old version. When the concurrency is 500, the TPS is close to 770, and the system pressure is very small, and the average CPU usage is only 16%.