Skip to main content

BE Configuration

PhoenixAI Anywhere deploys shared-data clusters, so a cluster has no BE nodes — compute runs on CN nodes, and the parameters on this page that apply to a CN are read from cn.conf. The same split between dynamic and static parameters applies.

Some configuration items are dynamic parameters, which you can set on a running node with SQL. The rest are static parameters, read from cn.conf only at startup, so the CN must restart before a change takes effect.

On Kubernetes you do not edit cn.conf on a node: it is projected into the pod from a ConfigMap, and an edit made inside the pod is discarded the next time the pod restarts. A dynamic change made with SQL is lost on that restart too, and CN pods restart on their own — a rolling upgrade, a node drain, an autoscaler scaling a warehouse in and back out. So set anything that is meant to be permanent in the ConfigMap, whether the parameter is dynamic or static. See Configure BE static parameters below.

View BE configuration items​

You can view the BE configuration items using the following command:

SELECT * FROM information_schema.be_configs WHERE NAME LIKE "%<name_pattern>%"

Configure BE parameters​

Configure BE dynamic parameters​

You can configure a dynamic parameter of a BE node by updating the value in information_schema.be_configs.

warning

Setting an invalid value may cause unknown behaviors. Check twice before you run the command to update the configuration.

-- Replace <config_key> with the key of the configuration and <config_value> with the value.
UPDATE information_schema.be_configs SET VALUE = <config_value> WHERE name = "<config_key>";

Configure BE static parameters​

Change the ConfigMap that supplies cn.conf, then restart the CNs. There are two routes, depending on how the cluster was deployed.

With Helm, add the parameter to phoenixai.phoenixAICnSpec.config in your values file and run helm upgrade:

phoenixai:
  phoenixAICnSpec:
    config: |
      # ... the rest of cn.conf, unchanged ...
      mem_limit = 80%

The chart hashes the rendered configuration into a pod annotation, so helm upgrade rolls the CN StatefulSet on its own and the new value takes effect.

warning

config replaces cn.conf in full — it is not merged with the chart's default. Copy the whole block out of the chart's values.yaml and add your parameter to it, or the CNs start without thrift_port, webserver_port, heartbeat_service_port, brpc_port and everything else the default sets. configyaml, the map form of the same setting, behaves the same way and additionally discards config when it is set.

With the operator alone, edit the ConfigMap named by phoenixAICnSpec.configMapInfo on the PhoenixAICluster, then restart the CNs yourself. The operator does not watch that ConfigMap, and the configuration hash above is a chart feature rather than an operator one, so nothing rolls the pods for you:

kubectl -n <namespace> rollout restart statefulset <cluster-name>-cn
kubectl -n <namespace> rollout status  statefulset <cluster-name>-cn

A CN added by a PhoenixAIWarehouse has its own StatefulSet, named <warehouse-name>-warehouse-cn, and its own spec.template.configMapInfo to change.

See Deploy with Operator or Deploy with Helm for creating the ConfigMap in the first place.

Parameter groups​

The parameters are grouped in these categories: