• [6.7x +]Dashboard memory leak


    -Daedalus
    • Minor

    This one has been around for a while (possibly longer than 6.7, I just think that was when I first noticed it) so it may have been reported already.

     

    I leave the dashboard open a lot of the time just for general monitoring.

    When navigating to another page after it's been left idle for some time, there will be a large spike in CPU usage (on the client machine), and a big drop in memory usage.

     

    I haven't charted this, but the affect is noticeable after about a an hour; on moving to any other page, there will be a delay of maybe a second or so. After a couple of hours, it's several seconds, and several hundred megs of RAM reclaimed.

    I'm not sure exactly when it happens - maybe over night - but Chrome will eventually "Aw, Snap!" and crash.

     

    Certainly not the highest of priorities I know, but I figured I'd mention this as given one of the things we'll be getting in 6.10. I wouldn't want this to detract from an otherwise sanky new look. 😎

     



    User Feedback

    Recommended Comments

    Until now every Unraid 6.x version relied on traditional polling of the server to update the GUI in real-time.

     

    On the Dashboard there are multiple fields which are getting updated regularly. It is the task of the browser to initiate each time a poll request to obtain the new information and update the GUI accordingly.

    Polling puts load on both the browser and server, and may consume more memory over time (depending on the browser).

     

    Starting with Unraid version 6.10 the traditional polling mechanism is replaced by a websocket event driven model using Nchan.

     

    An event driven model has a number of key advantages.

    - It allows the server to send information when changes take place (better efficiency)

    - Multiple clients can be served at the same time without huge impact on the server load (better scalability)

    - A client only needs to act when new information is received (better responsiveness)

     

    The event driven model also solves the issue of stale sessions when people open multiple browsers (on different computers) and forget to close them after usage. This resulted in csrf token mismatches when the server was restarted.

     

    So far all testing with the event driven model looks very promising and a solid improvement!

     

    • Like 3
    • Haha 1
    Link to comment
    Share on other sites

    Figures. I get off my ass after years of not reporting it... and it's fixed already. :D

     

    New model sounds great! And from what little I saw on Twitter looks pretty spiffy as well.

    Edited by -Daedalus
    Link to comment
    Share on other sites


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.