This commit is contained in:
2021-12-25 00:55:04 +00:00
parent 90f65e5319
commit 625ad16875

View File

@@ -250,24 +250,27 @@ TODO: 1 BETA DOCS:
---
- 1 issue: New reporting process is causing linux server to reboot with large reports and not much info as to why
theory: I'm running out of memory, however the do log doesn't show that so maybe need to do free mem check while running
potential fix:
need to limit chromium ram usage somehow or check the size of the data and if it's anywhere near the server ram then bump it up or...?
If it has to use disk memory, even if it could, that would be painfully slow so...hmmm.
really low timeout on low ram server to avoid this whole thing??
ram check constantly throughout render process and bail if gets within 80% of max maybe??
- 1 issue: New reporting process is causing linux server to reboot with large reports
AyaNova is really fast at compiling the data and can produce more data than a 1gb droplet can render in well under 1 minute
This causes chromium to eat up all teh ram quickly adn triggers somehow not known how, ayanova to reboot without any log or issue
might be some kind of linux protection thing, not sure
I played with some settings and now it appears it doesn't just crash the linux server (at least I *think* so, getting bleary eyed with this) but does go to swap and then drag on forever and ever
the moment it has to swap it pretty much stands still
So now, with the current settings for chromium the timeout can once again take hold
on a 1gb droplet setting it to 1m max render time seems to catch all the out of memory swap conditions
todo: figure out the appropriate timeout and range that a 2gb droplet can handle (and maybe larger ones as well for completeness)
testing with service wo's dispatch report
See if there can be a "auto" setting for report rendering that will just limit the time based on ram
or maybe an override that will ramp down to 1m if it sees less than 2g free ram or some value (actually this makes the most sense right now, jsut limit if short of ram otherwise let them set it at will)
Find a sane default to go with, 5m is too low for my windows dev and 1800 records, it isn't swapping just time consuming so needs to be higher for that
OPEN QUESTIONS:
Can I get the size of the data being sent to the report somehow and at least log it?
Why is chromium process triggering all of AyaNova to restart hard??
some kind of linux thing??
TRY: try temporarily bumping the ram if can in d.o. and see if it goes through
- try old server code from prior release and see if it crashes when doing that many wo??
maybe try in vm first can play with all manner of shit there and starve or add ram to figure out
todo: is there memory able to be freed up in getreport data as it's caching a lot during generation that could be used by rendering engine?
todo: are the reports fully efficient in memory usage and allocation?
sorting into second collection doubles size?
am I sending the data twice into the page (thought I saw that somewhere)
examine the dispatch report and see if there are efficiencies in memory usage / performance
TESTING INFO:
@@ -275,11 +278,16 @@ TESTING INFO:
memory definitelhy hits 99% on this one but doesn't crash just times out
bumped linux server to 2gb ram and was easily able to run 500 pages but it took 78% of ram to do it (I think)
1000 recs timed out at 5 minutes but didn't crash the server!!
1gb devops can run 200 pages of service wo dispatch in about 30 seconds without hitting swap
anything higher triggers swap
other reports are fine and go fast
I'm thinking 1m render timeout setting is appropriate limit for 1gb server
windev release run did 1000 recs in under 4 minutes, I think 3:40 or something
'' 1800 recs 1:38 to query and XX total to final render (timed out after 5:43 still churning away)
if select 1000 wo it will crash
mayb
-----