What version of Dgraph are you using?
Have you tried reproducing the issue with the latest release?
Yes, the above.
What is the hardware spec (RAM, OS)?
Fedora 30 / Docker
2 alphas limited to 8gb each (30gb total available)
Steps to reproduce the issue (command/config used to run Dgraph).
# 1 zero, 2 alphas (--lru_mb 2048), 1 ratel $ docker stack deploy ...
Expected behaviour and actual result.
On a completely fresh execution of dgraph (zero+alphas), the alter schema command to load my schema sometimes takes much, much longer to complete than normal. While the command is running, one of the alphas will max out the CPU to the point where my machine will sometimes freeze for several minutes.
This issue has been reported before with no resolution: Very slow schema mutation on empty database
I have come across what I believe to be the same issue many times on several versions of Dgraph (IIRC as early as v1.1.0). I also have a fairly large schema: 29 types and 171 predicates. As in the original report, if I restart my machine the problem goes away, but only for a while. At first, an alter schema will complete in seconds, but the problem eventually returns.
However, I would prefer not to have to restart my machine, and I think it is worthwhile to determine the actual cause of the problem.
My schema shows up in Ratel within seconds. The problem appears to be related to indexing. I have 50 predicates indexed. If I remove the indexes before the alter schema command, it will complete within seconds.
run_in_background does not seem to make any difference.
I have also tried:
- Pruning all containers and removing the volumes.
- Restarting the docker daemon
Neither one of these seems to make any difference.