Step-by-Step Guide: 

What to Look For: Common Symptoms

If Sisense is running below the required specifications, you may observe:

• Persistent slowness or delays  – queries and dashboards take longer than expected.
• Unstable internal communication between services
• Frequent pod restarts or unexpected crashes – pods restarting frequently or stuck in Pending / CrashLoopBackOff.
• Repeated out-of-memory (OOM) errors – services shut down unexpectedly due to insufficient memory.
• General Instability – Intermittent outages, unreliable service communication, or repeated system crashes.

Running these checks before contacting Support will help confirm if the system meets the required specifications. This information is also valuable to share with Support agents, as it provides a clearer context about the environment’s health and helps accelerate troubleshooting.

Environmental Health Checklist

1. Environment Type & Kubernetes Version

Confirm if running on on-premises or managed Kubernetes (EKS/AKS/GKE).

• kubectl version
• kubectl cluster-info

2. Operating System

Ensure you are on a supported Linux distribution and version.
Reference: Sisense Linux Minimum Requirements

• cat /etc/os-release
• uname -a

3. Deployment Method

Check how Sisense was installed: RKE, Provisioner, or Helm.
Review your configuration files: single_config.yaml, cloud_config.yaml, or values.yaml.

4. Cluster Architecture

Verify the number of nodes and resources:

• One node for a single-node instance and a minimum of 3 nodes (2 app/query + 1 build)  for a multinode instance:

• • kubectl get nodes
  • kubectl get nodes --show-labels
  • Node label information could be filtered and highlighted with kubectl get nodes --show-labels | grep -i "application=\|query=\|build="

5. Storage

Check persistent volumes and storage classes:

• kubectl get pvc -n sisense
• kubectl get sc
• kubectl describe pvc <pvc-name> -n sisense

Identify the persistent volume type used by Sisense (e.g., fsx, gp2, gp3).  Check for provisioner type, like:

efs.csi.aws.com
fsx.csi.aws.com
kubernetes.io/aws-ebs

 On VMs/servers, confirm SSD (not HDD):

• lsblk -o NAME,HCTL,SIZE,MOUNTPOINT,ROTA,TYPE,MODEL

(ROTA=0 → SSD, ROTA=1 → HDD)

Note that hypervisors can emulate hardware. Even if a VM shows ROTA=0 → SSD, it does not mean that it is actually an SSD. It is important to clarify this question with the customer directly

6. Networking

 Identify which CNI plugin is used:

• kubectl get pods -n kube-system

Check for CNI pods like:

aws-node (EKS), calico-node, azure-cni-networkmonitor, etc.

 Test DNS & connectivity inside the cluster:

Create a temporary pod for network testing: kubectl run debug-pod --image=busybox --rm -it --restart=Never -- sh

Then, inside the pod, run:

• nslookup fs-xxxx.fsx.us-east-2.amazonaws.com
• ping fs-xxxx.fsx.us-east-2.amazonaws.com
• curl http://<internal-service>:<port>

7. Ingress & SSL

Check ingress configuration and SSL termination:

• kubectl get ingress -A
• kubectl describe ingress <ingress-name> -n <namespace>
• kubectl get pods -n ingress-nginx

8. Autoscaling Considerations

If you are running Kubernetes on EKS, AKS, or GKE, your cluster may have a Cluster Autoscaler enabled. This component automatically adds or removes nodes depending on workload demand.

On EKS, if you see labels such as karpenter.sh/provisioner-name (when using Karpenter) or eks.amazonaws.com/nodegroup, autoscaling is likely enabled. You can confirm by running:  kubectl describe node <node-name>

In addition to node autoscaling, Sisense services can take advantage of Pod Autoscaling using the Horizontal Pod Autoscaler (HPA). This allows services to scale in or out based on CPU and memory usage. To verify:

1. Check if HPA is installed and which workloads it applies to:
   kubectl get hpa -A
2. Inspect scaling targets and thresholds:
   kubectl describe hpa <hpa-name> -n <namespace>

Conclusion 

If your environment does not meet the Sisense minimum requirements, you may experience instability that cannot be resolved through troubleshooting alone. It is very important to ensure your system remains within these requirements, including the allocated CPU, RAM, and disk size. Running below the minimum specifications can lead to recurring issues such as slowness, pod failures, or general system instability.

Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.