Right now, the Tanka configs do not configure any Kubernetes resources for core-service and cockroachdb. This allows Kubernetes to kill them whenever the memory usage goes above some implementation-specific-limit (in GKE, this seems to be 2GB). Wing in particular has been subjected to frequent OOMKiller due to this.
As the industry scales, we also have the need to experiment with Go memory behavior as it directly impacts the Memory allocation in CRDB. We also may need to tune the cache and max-sql-memory parameter during CRDB start time.
It would be of great benefit to the whole industry if we can customize these parameters in Tanka through metadata - like we do for other customizations. Right now, this is what it looks like for Wing and doing it repeatedly for all clusters get very ugly.
local allManifests = dss.all(metadata);
local crdbContainers = allManifests.base.crdb_sset.spec.template.spec.containers;
allManifests {
base+: {
crdb_sset+: {
spec+: {
template+: {
spec+: {
containers: [
crdbContainers[0] {
resources: {
requests: {
cpu: '2',
memory: '10Gi',
},
limits: {
cpu: '2',
memory: '10Gi',
},
},
env+: [
{
name: 'GOGC',
value: '80',
},
{
name: 'GOMAXPROCS',
value: '2',
},
],
Right now, the Tanka configs do not configure any Kubernetes resources for core-service and cockroachdb. This allows Kubernetes to kill them whenever the memory usage goes above some implementation-specific-limit (in GKE, this seems to be 2GB). Wing in particular has been subjected to frequent OOMKiller due to this.
As the industry scales, we also have the need to experiment with Go memory behavior as it directly impacts the Memory allocation in CRDB. We also may need to tune the cache and max-sql-memory parameter during CRDB start time.
It would be of great benefit to the whole industry if we can customize these parameters in Tanka through metadata - like we do for other customizations. Right now, this is what it looks like for Wing and doing it repeatedly for all clusters get very ugly.