-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MemGator crashes after an hour with moderate usage #137
Comments
Could the duplicate flags |
@ibnesayeed I had not noticed the duplicate flag. I will change it and get back to you. Here is a more complete dump after a subsequent crash last night that indicates that the application ran out of memory.
|
I am wondering if the requests are simply accumulating faster than the archives can respond, causing the connections to build up in the MemGator binary for a variety of requesters based on where the error is responds (main.go lines 435-436). I may try to recompile MemGator with a newer version of Golang and report back. In the meantime, I have re-invoked the instance. |
It is possible that the TimeMap being processed is too large to fit in the memory of the machine. |
I suppose that is possible. I have performed the above and recompiled MemGator for go 1.16.5 and re-launched the binary. If it crashes again, I will receive a report and see if the trace remains similar to the above. |
I drastically reduced the parameters to have a Header timeout and Response timeout of 30s each and the instance seems more stable. This likely has the effect of excluding slow web archives but some results returned are better than the service being down. |
I am encountering an issue with my MemGator instance at https://aggregator.matkelly.com that has recently had an uptick in traffic with its deferral in Mink since the ODUCS MemGator instance has been down. I have not been able to isolate the problem but thought I might report it here.
I am running MemGator 1.0-rc8 on Debian 10 in a screen session with
memgator -l /logs/memgator.log -b /logs/memgator.bm [email protected] --spoof -t 10s -T 2m30s -r 3m0s -c "@machawk1" --proxy=https://aggregator.matkelly.com server
There does not appear to be any indication of a failure in the .log or .bm file but I can provide those if they would be helpful. Otherwise, the partial trace is below.
Caddy is being used as a reverse proxy.
The text was updated successfully, but these errors were encountered: