The infer of --lru_mb flag giving wrong value and breaking the cluster (on helm)

@MichelDiz Actually this is a helm chart issue. I fixed it in version dgraph-0.0.9 of the helm chart. This is a duplicate?

That’s not a Helm issue cuz we have a feature that infers the amount of RAM in the machine and set it automatically - it works on Linux machines as it is, but not on macOS. Your solution solves Zhouqiang’s issue and that’s great. But the origin of the issue still there.

BTW, we should have a way to add or modify any flag on helm chart. e.g: if I wanna block mutations, I can’t. Cuz there’s no way to add the flag --mutations=disallow via value editing. Only manual editing.

@MichelDiz On Linux the default is -1.0 and this results in a Sentry error and subsequent crash. The helm chart even if launched from macOS is running the containers on Linux in a HyperKit VM.

Verify I understand the expected behavior: the expected results is that It should not sentry on Linux?

You can find the instructions for that in the helm charts readme with example files in hcl, toml, properties, yaml, and json.

Thus you can have a values file like this:

alpha:
  configFile:
    config.json: |
      {
        "lru_mb": 2048,
        "mutations": "disallow"
      }

Make sure to have lru_mb due to error with dgraph alpha

Yes, but I believe it uses the Unix shell as a context for Darwin. Then it will run on Darwin and not on the virtual machine. Unless it is over SSH.

However, this does not explain why it does not happen in the instance that I am running in GCP. I am using this same helm repository, I killed and recreated instances several times and I had no problems. And I’ve never seen anyone using Linux complain about the same problem. Just Darwin.

I also, use Darwin, but I don’t use any HyperKit VM. I use a K3s in an Alpine machine. Also have used the Helm repo there.

Nice, so your improvement works for other flags too. Thanks.

Do you see? the issue still there. Any mac user will in some moment step into that issue.

We had created this feature to infer the memory because Dgraph was buzzing for that flag (the flag was mandatory). Forcing the user to enter the amount of memory. After a while, this flag was useless, because we no longer had LRU. Then we put this feature, which apparently only works on Linux terminals and Windows (because I didn’t see anyone complain about it on the Windows platform).

Perhaps the line of code (or lib) that makes this inferring is not compatible with Darwin.

@joaquin let’s move the conversation to the other ticket.

I am on Ubuntu 19.10 host laptop deploying this on GKE (k8s 1.16) and I reproduce this easily. You can see it with:

helm repo update
helm install "tst-1" dgraph/dgraph --version 0.0.8

If LRU not specified, I get Sentry alerts and CrashBackOff.

The logs showed:

I0729 00:30:50.811909      15 sentry_integration.go:48] This instance of Dgraph will send anonymous reports of panics back to Dgraph Labs via Sentry. No confidential information is sent. These reports help improve Dgraph. To opt-out, restart your instance with the --enable_sentry=false flag. For more info, see https://dgraph.io/docs/howto/#data-handling.
2020/07/29 00:30:50 LRU memory (--lru_mb) must be at least 1024 MB. Currently set to: -1.000000
For more information on --lru_mb please read https://docs.dgraph.io/deploy/#config

What’s the other ticket?

So what was changed? I have used it a few weeks ago. What exactly changed to trigger this? makes no sense. I have used it in Rancher.

By checking the older versions I can see that --lru_mb {{ .Values.alpha.lru_mb }} still there. It wasn’t removed. Can you tell in which moment the Helm repo wasn’t with the LRU flag? And as it was with it, why it returns -1.000000?

Ahh I see it was this PR Dgraph configuration file support by darkn3rd · Pull Request #40 · dgraph-io/charts · GitHub
I see that you removed the lru_mb from the command line. But anyway there is still an issue. Even if you remove that flag Dgraph should automatically add the 25% of RAM in the machine.

BTW, There’s no issue with Sentry. The issue is about the -1.000000 only. See the my last comment at LRU memory in Alpha server by default set to a negative value in MacOS

This one LRU memory in Alpha server by default set to a negative value in MacOS

The helm chart version dgraph-0.0.8 changed, it was released July 23.

The default is -1 type Float from dgraph alpha --help.
It is not exhibiting the 25% behavior.

I am deny by discuss.dgraph.io yesterday because I am new here. Now it works, thank you very much