Hello Percona Team,
I am working on an OpenShift Cluster with this configuration: 3 worker nodes and 4 cores CPU and 32 Gib RAM for each node.
Today, I tried to install and setup Percona Operator to manage our projects’ database. I installed Percona Operator for PostgreSQL from OperatorHub of OpenShift web console.
After installing successfully, I added a new PerconaPGCluster from Percona Distribution for PostgresSQL Cluster via the form view. Then, the pods of percona postgres database were be generated and run as expected.
But, when I checked CPU and RAM usage after above installation, I found that Percona database cluster took too much of these resources.
After some more analyzes,
I had to remove the Percona Operator from my OpenShift cluster to ensure our existing projects to work fine.
So, please check this case and let me know whether I did some wrong setup or configuration.
I am looking forward to hearing your response.
Hi Kieu,
Given that this is an operator issue would it be possible to re-allocate to the Percona Operator for PostgreSQL category, available here?
Also would you like sharing the cr.yaml files that you are using?
Hi Takis,
Thank you for your response.
Here is my cr.yaml. It’s the default cr.yaml from Percona guideline..
apiVersion: pg.percona.com/v1
kind: PerconaPGCluster
metadata:
labels:
pgo-version: 1.3.0
name: cluster1
spec:
# secretsName: cluster1-users
# sslCA: cluster1-ssl-ca
# sslSecretName: cluster1-ssl-keypair
# sslReplicationSecretName: cluster1-ssl-keypair
upgradeOptions:
versionServiceEndpoint: https://check.percona.com
apply: disabled
schedule: "0 4 * * *"
database: pgdb
port: "5432"
user: pguser
disableAutofail: false
tlsOnly: false
standby: false
pause: false
keepData: true
keepBackups: true
# pgDataSource:
# restoreFrom: ""
# restoreOpts: ""
# tablespaceStorages:
# lake:
# volumeSpec:
# size: 1G
# accessmode: ReadWriteOnce
# storagetype: dynamic
# storageclass: ""
# matchLabels: ""
# walStorage:
# volumeSpec:
# size: 1G
# accessmode: ReadWriteOnce
# storagetype: dynamic
# storageclass: ""
# matchLabels: ""
# userLabels:
# pgo-version: "1.3.0"
pgPrimary:
image: percona/percona-postgresql-operator:1.3.0-ppg14-postgres-ha
# imagePullPolicy: Always
resources:
requests:
cpu: 500m
memory: "256Mi"
# limits:
# cpu: 500m
# memory: "256Mi"
# affinity:
# antiAffinityType: preferred
# nodeAffinityType: required
# nodeLabel:
# kubernetes.io/region: us-central1
# advanced:
# nodeAffinity:
# requiredDuringSchedulingIgnoredDuringExecution:
# nodeSelectorTerms:
# - matchExpressions:
# - key: kubernetes.io/e2e-az-name
# operator: In
# values:
# - e2e-az1
# - e2e-az2
tolerations: []
volumeSpec:
size: 1G
accessmode: ReadWriteOnce
storagetype: dynamic
storageclass: ""
# matchLabels: ""
expose:
serviceType: ClusterIP
# loadBalancerSourceRanges:
# annotations:
# pg-cluster-annot: cluster1
# labels:
# pg-cluster-label: cluster1
# customconfig: ""
pmm:
enabled: false
image: percona/pmm-client:2.29.0
# imagePullPolicy: Always
serverHost: monitoring-service
serverUser: admin
pmmSecret: cluster1-pmm-secret
resources:
requests:
memory: 200M
cpu: 500m
# limits:
# cpu: "1"
# memory: "400M"
backup:
image: percona/percona-postgresql-operator:1.3.0-ppg14-pgbackrest
# imagePullPolicy: Always
backrestRepoImage: percona/percona-postgresql-operator:1.3.0-ppg14-pgbackrest-repo
resources:
requests:
cpu: "200m"
memory: "48Mi"
# limits:
# cpu: "1"
# memory: "64Mi"
# affinity:
# antiAffinityType: preferred
volumeSpec:
size: 1G
accessmode: ReadWriteOnce
storagetype: dynamic
storageclass: ""
# matchLabels: ""
# storages:
# my-gcs:
# type: gcs
# bucket: some-gcs-bucket
# repoPath: ""
schedule:
- name: "sat-night-backup"
schedule: "0 0 * * 6"
keep: 3
type: full
storage: local
pgBouncer:
image: percona/percona-postgresql-operator:1.3.0-ppg14-pgbouncer
# imagePullPolicy: Always
# exposePostgresUser: false
size: 3
resources:
requests:
cpu: "1"
memory: "128Mi"
# limits:
# cpu: "2"
# memory: "512Mi"
# affinity:
# antiAffinityType: preferred
expose:
serviceType: ClusterIP
# loadBalancerSourceRanges:
# annotations:
# pg-cluster-annot: cluster1
# labels:
# pg-cluster-label: cluster1
pgReplicas:
hotStandby:
size: 2
resources:
requests:
cpu: "500m"
memory: "256Mi"
# limits:
# cpu: "500m"
# memory: "256Mi"
volumeSpec:
accessmode: ReadWriteOnce
size: 1G
storagetype: dynamic
storageclass: ""
# matchLabels: ""
# labels:
# pg-cluster-label: cluster1
# annotations:
# pg-cluster-annot: cluster1-1
enableSyncStandby: false
expose:
serviceType: ClusterIP
# loadBalancerSourceRanges:
# annotations:
# pg-cluster-annot: cluster1
# labels:
# pg-cluster-label: cluster1
pgBadger:
enabled: false
image: percona/percona-postgresql-operator:1.3.0-ppg14-pgbadger
# imagePullPolicy: Always
port: 10000
# securityContext:
# fsGroup: 1001
# supplementalGroups: [1001, 1002, 1003]
By using this default cr.yaml to run the Percona distribution for PostgresSQL on our cluster, the CPU and RAM increased a lot (about more than 20%).
Please let me know if there is any configuration in operator or cr.yaml to optimize the CPU and RAM usage, but still keep the normal effort.
