Shortest query runs out memory


(Chenyuzhi) #1

Hi, I can use shortest query normally without specify depth param. For example:

{
      path as shortest(from: 0x24a, to: 0x4,numpaths: 2) {
        ~purchase
        purchase
      }
      path(func: uid(path)) {
        uid
      }
}

The result is:

{
  "data": {
    "path": [
      {
        "uid": "0x24a"
      },
      {
        "uid": "0x41"
      },
      {
        "uid": "0x5a12"
      },
      {
        "uid": "0x4"
      }
    ],
    "_path_": [
      {
        "purchase": [
          {
            "~purchase": [
              {
                "purchase": [
                  {
                    "uid": "0x4"
                  }
                ],
                "uid": "0x5a12"
              }
            ],
            "uid": "0x41"
          }
        ],
        "uid": "0x24a"
      },
      {
        "purchase": [
          {
            "~purchase": [
              {
                "purchase": [
                  {
                    "uid": "0x4"
                  }
                ],
                "uid": "0xbc2"
              }
            ],
            "uid": "0x4e"
          }
        ],
        "uid": "0x24a"
      }
    ]
  }
}

The depth of the shortest path is 2. But when I add the param depth: 1 in query, the alpha server doesn’t return result , and the server consumes memory until it runs out in the background. Here is the query block:

{
      path as shortest(from: 0x24a, to: 0x4, numpaths: 2, detph:1) {
        ~purchase
        purchase
      }
      path(func: uid(path)) {
        uid
      }
}

memory usage(total memory: 64g ):

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                 
 9357 root      20   0    57.990g 0.045t 355068 S  87.6 73.8   5:48.28 dgraph  

I don’t know if this is because the depth parameter I specified is less than the true depth of the shortest path. The former is 1, and the latter is 2?


(Guido Stepken) #2

Why i am not.surprised? go suffers same memory leaks, like C, C++. It you forget to release a reference, you automatically have a memory leak.


(Chenyuzhi) #3

Thank you for your reply. Maybe I didn’t express my meaning clearly.

What I want to express is that if we don’t know the depth of the shortest path of two nodes beforehand, and we specify the maximum depth parameter in the query, then this parameter is smaller than the former one (users may not know the parm depth too small when they first query), the program will be killed by the system because of excessive memory consumption.

But the user doesn’t know what’s wrong at this point, so I wonder if there’s any improvement or make it just returns an empty result.


(Michel Conrado (Support Engineer)) #4

Hi Chenyuzhi,

Thank you for being interested in the Dgraph and participating in the community positively.

I can see that what you presents can be something to be analyzed in detail. Please, if you can open an Issue in Dgraph’s Github in more detail and maybe reproduceble. It would be very good as we could investigate and do some fix.

If we can not reproduce quickly and practically, there is not much to do in the short term.

64GB of memory usage for a Query? this is in fact something that needs to be investigated. Are you sure that only the Dgraph was running? that there were no other processes and etc? 64GB is a lot!

Cheers.


(Chenyuzhi) #5

Hi, Michel,

Thanks for your reply, I had open an issue realted this problem in Dgraph’s Github.