[INSTRM-537] fitsview process does not keep up with exposure loop. Created: 21/Oct/18 Updated: 23/Oct/18 Resolved: 23/Oct/18 |
|
| Status: | Done |
| Project: | Instrument control development |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | cloomis | Assignee: | eric |
| Resolution: | Done | Votes: | 0 |
| Labels: | MCS | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The fitsview process which displays MCS images as they finish seems to grow without bound and causes observing (and the machine) to fall behind and eventually fail. A Gen2-driven exposure loop with the fitsview process off reads at the expected 5.5s per frame, and exposures can be streamed continuously. With fitsview turned on the RAM usage on the machine rises until the machine basically tips over. After a fitsview restart, taking 20 frames yields a fits view process which consumes ~50% of the system RAM. Taking a second such sequence (or starting with a longer one) causes all 24 cores to rail, for all windows to become unresponsive, and for the PFS processes to no longer be able to requests visits, etc. Looks like it tops out at about ~80% RAM usage, per the widget on the screen. Quitting fitsview clears RAM and makes the machine useable again. We tried setting the General/Num Images preference to 2 (from 10), but that did not affect growth. You could still see one step per image in the RAM usage plot. FWIW, we expect to read sequences of ~50 frames per telescope position this week. |
| Comments |
| Comment by eric [ 23/Oct/18 ] |
|
Fixed on the Gen2 simulator on 2018-10-21. Not sure, but I think this may be a Python 3 issue because we don't see this behavior with Python 2 on the summit Gen2 system (which is still Python 2). But I will roll the change over there anyway. |
| Comment by cloomis [ 23/Oct/18 ] |
|
Looks good. |