7.0.0-beta6 memory issues (regression)
See original GitHub issueA test task runs over 310,000 independent test executions. In 6.14.3
this completes in about 2.5 minutes. In 7.0.0-beta6
this slows down to a crawl at 200k tests, appearing to GC thrash as small batches of tests complete.
In the past, I’ve seen this occur due to reporting keeping parameters in-memory. The project uses a workaround to replace test parameters with their toString
version, as these are too heavy for a large run. I suspect there is some similar per-test memory grab by the reporter.
The next step is probably to take a heap dump and determine what is held. Before running too far into this, do you know what changes were made that might hint at what to look for?
./gradlew :caffeine:strongKeysAndStrongValuesAsyncCaffeineTest
Issue Analytics
- State:
- Created 4 years ago
- Comments:25 (17 by maintainers)
Top Results From Across the Web
Memory loss: When to seek help - Mayo Clinic
A number of conditions — not only Alzheimer's disease — can cause memory loss in older adults. Getting a prompt diagnosis and appropriate...
Read more >What Causes Memory Problems in Children?
Noticing a memory problem in your child or teen can be incredibly unnerving. You may wonder if their memory lapses are normal for...
Read more >Caution! These 10 Drugs Can Cause Memory Loss - AARP
Drugs That May Cause Memory Loss · 1. Antianxiety drugs · 2. Cholesterol drugs · 3. Antiseizure drugs · 4. Antidepressant drugs ·...
Read more >Scikit-Learn Logistic Regression Memory Error - Stack Overflow
LogisticRegression ) will host its own copy of the data because it is a C++ library whose internal memory layout cannot be directly...
Read more >926497 - General BGPT regression bug for *memory - Monorail
Issue 926497: General BGPT regression bug for *memory* ... Understanding performance regressions: ... on Thu, Feb 7, 2019, 10:20 AM PST Project Member....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In today’s round of optimizations, I was able to drop a test suite task from 315MB (8.6M objects) down to 22MB (0.5M objects). The noticeable pauses from a full GC also disappeared.
There are roughly 30 test suites of equal size (140k tests per suite) in order to reduce the report size, as a single test task failed due to the memory overhead. Previously I had already optimized by aggressively removing test parameters and expected exceptions if successful and shortening + dedup’ing test names in the report. The GC is also tuned.
4.2M tests executing in parallel on TravisCI with 512mb heap now takes ~1 hour.
@krmahadevan It did seem a little better by performing more tests in the stresser. Since there are still places that retain all of them, e.g. ResultMap, unfortunately you have to fix all before we feel the impact.
If you feel that you have to wait on me and get blocked, you can perform my steps:
testng-stresser
and run the project.maxHeapSize = '256m'
locally to fail faster.gradlew cleanTest test
until it slows downjmap -dump:live,format=b,file=/Users/ben/Downloads/1.hprof "$(pgrep -f GradleWorkerMain | head -n 1)"