| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0003313 | Spring engine | General | public | 2012-11-01 03:56 | 2012-11-04 00:55 | ||||
| Reporter | abma | ||||||||
| Assigned To | abma | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | resolved | Resolution | not fixable | ||||||
| Product Version | 91.0.1+git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0003313: QTPFS seems to use significant more memory | ||||||||
| Description | Some validation tests fail with: Error: Spring: Fatal Error (general) std::bad_alloc (thats because of ulimit) | ||||||||
| Steps To Reproduce | run spring with ulimit set to 1GB: ulimit -v 1000000 spring | ||||||||
| Additional Information | map is "Altair_Crossing-V1", this is a (small) 8x8 map http://buildbot.springrts.com/builders/validationtests/builds/1880/steps/validation%20test/logs/stdio http://buildbot.springrts.com/builders/validationtests/builds/1880/steps/validation%20test_1/logs/stdio http://buildbot.springrts.com/builders/validationtests/builds/1880/steps/validation%20test_2/logs/stdio http://buildbot.springrts.com/builders/validationtests/builds/1880/steps/validation%20test_5/logs/stdio | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
 Notes |
|
|
Kloot (developer) 2012-11-01 12:11 Last edited: 2012-11-01 12:24 |
I've always been aware of this, but it is almost impossible to fix due to the quadtree design used. However, maps like Altair require around 150MB for QTPFS and should not normally cause any bad_allocs. What is the ulimit for Spring processes on the validation host? |
|
abma (administrator) 2012-11-01 12:55 |
ulimit -v 1000000 (see above) |
|
abma (administrator) 2012-11-02 10:03 Last edited: 2012-11-02 10:04 |
how good does memory usage scale? on what does memory usage depend? i guess it depends on map size & count of units with different footprints? its no problem to change ulimit, but it should be some reasonable value so it kills spring when it really uses to much memory :) |
|
Kloot (developer) 2012-11-02 13:23 |
It scales linearly with some factors (number of movedefs), quadratically with others (map size), and anywhere between constant and exponential for one in particular (terrain topology, which determines the tesselation pattern), so usage is not easy to predict. Also, with a lower ulimit like 1GB Spring doesn't immediately run out of memory, but large contiguous allocations (as required by QTPFS) will fail. That makes it even harder to pick a reasonable fixed value for all maps. |
|
abma (administrator) 2012-11-03 18:17 |
is there a way to track how many memory is allocated in which part of the engine? mmgr seems to currently not work, see 0003316 |
|
abma (administrator) 2012-11-04 00:53 |
so... i would say this is no bug, just a known limitation or something like this |
|
abma (administrator) 2012-11-04 00:55 |
https://github.com/spring/spring/commit/d972e7a2bd41787b8c475f8f203a306458f020fb |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-11-01 03:56 | abma | New Issue | |
| 2012-11-01 04:00 | abma | Additional Information Updated | View Revisions |
| 2012-11-01 04:16 | abma | Additional Information Updated | View Revisions |
| 2012-11-01 12:11 | Kloot | Note Added: 0009292 | |
| 2012-11-01 12:22 | Kloot | Note Edited: 0009292 | View Revisions |
| 2012-11-01 12:24 | Kloot | Note Edited: 0009292 | View Revisions |
| 2012-11-01 12:55 | abma | Note Added: 0009293 | |
| 2012-11-02 10:03 | abma | Note Added: 0009297 | |
| 2012-11-02 10:04 | abma | Note Edited: 0009297 | View Revisions |
| 2012-11-02 13:23 | Kloot | Note Added: 0009298 | |
| 2012-11-03 18:17 | abma | Note Added: 0009299 | |
| 2012-11-03 18:17 | abma | Relationship added | related to 0003316 |
| 2012-11-04 00:53 | abma | Note Added: 0009300 | |
| 2012-11-04 00:53 | abma | Status | new => resolved |
| 2012-11-04 00:53 | abma | Resolution | open => not fixable |
| 2012-11-04 00:53 | abma | Assigned To | => abma |
| 2012-11-04 00:55 | abma | Note Added: 0009301 | |
| Issue History |