pulseui icon indicating copy to clipboard operation
pulseui copied to clipboard

Large query causes client memory problems

Open ryanhamilton opened this issue 2 years ago • 4 comments

user-rh reported "A typical chart query will be approximately 600k rows with 3 columns (time, price1, price2) and I poll every 10 seconds. This has cause the front end to crash a couple of times due to running out of memory."

It's been a while since we looked at reducing memory usage and increasing performance. It's easy for added features to degrade performance. Let's investigate.

ryanhamilton avatar Nov 20 '23 09:11 ryanhamilton

Options we have discussed before:

  • Increasing speed and reduce memory usage of rendering pipeline (nice part is that increases here benefit everything)
  • Object pooling of expensive objects.
  • Smart Table Delta
  • InfiniteZoom support

ryanhamilton avatar Nov 20 '23 10:11 ryanhamilton

Checking for memory leaks, relpayed multiple days data in 20 minute window chunks: Client memory went up and down as expected. Tracking objects, shows no long lived objects. Overall memory of Chrome process went up and down as expected. THis does still leave the possibility of an issue over time, e.g. maybe a timer? As I was playing back at speed. image

ryanhamilton avatar Nov 20 '23 11:11 ryanhamilton

On kdb subscription I could cause th eserver memory to spike due to previously found issue: https://github.com/micronaut-projects/micronaut-core/issues/8984 Once the backlog cleared it was fine: image

However the client side memory still returned to normal. I then tried polling in case it was polling specific, and again it returned to normal. Tried JS heap snapshots and tracing. Can't find anything long lived.

ryanhamilton avatar Nov 20 '23 11:11 ryanhamilton

user-rh reported "crash" then stack trace with:

    com.sqldashboards.webby.WebSocketServer$DashboardEngine lambda$new$0
WARNING: Subscriber for admin seems to be a slow subscriber.
    com.sqldashboards.dashy.QueryEngine2$1 run
SEVERE: big loopy scheduled problems
io.micronaut.websocket.exceptions.WebSocketSessionException: Session closed
        at io.micronaut.http.netty.websocket.NettyWebSocketSession.sendAsync(NettyWebSocketSession.java:166)
        at io.micronaut.websocket.WebSocketSession.sendAsync(WebSocketSession.java:154)

I have not been able to recreate this scenario. When a subscriber falls behind they should be slowed (this was), then stopped. This wasn't. I tried force closing the browser and that still didn't give the error in the logs.

ryanhamilton avatar Nov 20 '23 12:11 ryanhamilton