pi Slows down and web server not responding
Hi,
Just had this issue, maybe more than once now. Just got up after printing overnight and the repetier server web interface was not responding and the print was not finished. I thought it had locked up completely (I have had this before) but the printer is still printing but it looks like it gets a command every 10 seconds or more. Any ideas?
About to restart
Thanks
Just had this issue, maybe more than once now. Just got up after printing overnight and the repetier server web interface was not responding and the print was not finished. I thought it had locked up completely (I have had this before) but the printer is still printing but it looks like it gets a command every 10 seconds or more. Any ideas?
About to restart
Thanks
Comments
The fact that it is still working and ssh will time out shows that except the slow down everything seems to be ok. Typical reason is said high memory usage which normally does not happen. Is the network normally rock solid? Many or frequent connections might increase memory usage. Or also seen in past chromium starts getting bigger.
Thanks again
top
in that to see memory and cpu usage. That should give you early a warning when one of the components starts using more memory and even if you miss it you still have the last update on screen to see what used memory/cpu. That allows it narrow down the problem.
So the main question would be what are you doing that others not having the problem don't do.
If no one is connected watching (lets except touchscreen here) I'm quite sure it would not happen. As soon as you have an open connection the server buffers unread messages etc. Normally no issue since connected devices read the data so we can delete it freeing memory.
First question is are you using 0.91.2? For older versions I know ways to get that error but all known ways are closed at the moment.
If you are on latest version I#d like to ask you to do little debug session. Add a virtual printer for printing (assuming it will happen there as well) or just select virtual port for your printer. That way you do not need to waste filament as the test will ruin the print.
Follow these instructions, install gdb first.
https://www.repetier-server.com/knowledgebase/debugging-crashes-hangs-on-linux/
Once you see memory rises lets say over 5% start gdb, attach process a create a full backtrace and send it to me. Then I see where all threads are doing what. Hopefully that will give the final hint to where it hangs or where we accumulate memory.
That is exactly what I do if I manage to get a similar error and most of the times it is possible to see what is going wrong.
CPU usage sound good. If you have more users connected it increases a bit, also uploading g-codes makes server parse them and render them so cpu will be 100%.
Free memory is not what you see in free memory. That is misleading. You need to add buffer/cache to it. Linux will use all unused memory to cache read files for better speed. But if memory is needed it will also return that directly so it counts to free memory.
The problem with this to debug is that you need to start gdb when memory starts increasing but before you start to swap. Once it swaps you can not open debugger and analyse. I think it is a problem where memory slowly increases over time so if you look from time to time that would suffice. As soon as top shows > 8% for server I think you can start debugger.
You need do exactly as the doc says. Run normally the print and once you see memory is increasing start debugger and attach. Do not start server. All I need is output of
at that point to see which threads are running and might not free memory any more. Since this will take time the print is now not good any more, which is why I suggested the virtual printer. In case of a real print you might pause in server so it moves away, then do the debugger stuff and continue for the rest of the print with "c" in debugger. But stopping again with Ctrl+C does not work - it will crash the server which listens for the signal.