# Automation customization {% hint style="info" %} All restrictions are compared to the original spec values of the workload {% endhint %} Customize your automation with the following settings: ```yaml timeConstraints: wasteMaxAutomationFrequency: "30m" # Applies recommendations to decrease resources every 30 minutes fixResiliencyMaxAutomationFrequency: "30m" # Applies recommendations to increase resources every 30 minutes maintenanceWindow: monday: - "00:00-23:59" tuesday: - "00:00-23:59" wednesday: - "00:00-23:59" thursday: - "00:00-23:59" friday: - "00:00-23:59" saturday: - "00:00-23:59" sunday: - "00:00-23:59" maintenanceWindowIgnoredForResiliency: false # deprecated, use "maintenanceWindowIgnoredMinResiliencyLevel" instead maintenanceWindowIgnoredMinResiliencyLevel: None # Indicates the minimum resiliency risk level required to bypass maintenance window constraints and resolve the issue restrictions: workloadMinWasteUSDPerMonth: 5 # Activates automation only if monthly waste exceeds a set threshold (for example, $5) cpuManagement: request: increaseEnabled: true/false # default false decreaseEnabled: true/false # default true minimumCores: 0.5 # default unset, to override to unset, use -1 maximumCores: 8 # default unset, to override to unset, use -1 limit: keepLimit: true/false # default true memoryManagement: request: increaseEnabled: true/false # default false decreaseEnabled: true/false # default true minimumGib: 1 # default unset, to override to unset, use -1 maximumGib: 16 # default unset, to override to unset, use -1 limit: increaseEnabled: true/false # default false decreaseEnabled: true/false # default false minimumGib: 2 # default unset, to override to unset, use -1 maximumGib: 31 # default unset, to override to unset, use -1 memoryLeakDetection: maxMemoryIncreaseIterations: daily: 4 # default 3 weekly: 7 # default 7 ``` ## Time constraints ```yaml spec: automation: operational: timeConstraints: wasteMaxAutomationFrequency: "30m" # Applies recommendations to decrease resources every 30 minutes fixResiliencyMaxAutomationFrequency: "30m" # Applies recommendations to increase resources every 30 minutes maintenanceWindow: sunday: [00:00-23:59] maintenanceWindowIgnoredForResiliency: false # deprecated, use "maintenanceWindowIgnoredMinResiliencyLevel" instead maintenanceWindowIgnoredMinResiliencyLevel: None # Indicates the minimum resiliency risk level required to bypass maintenance window constraints and resolve the issue ``` ### :wastebasket: wasteMaxAutomationFrequency {% hint style="danger" %} `maxAutomationFrequency` field is deprecated as of autoscaler version **v1.0.16**. If `maxAutomationFrequency` is present and `wasteMaxAutomationFrequency` is not specified, `maxAutomationFrequency` will override `wasteMaxAutomationFrequency`. {% endhint %} This optional field defines the maximum frequency at which automated actions can be executed to apply recommendations when waste is detected, and resource reduction is needed. {% hint style="info" %} If no `wasteMaxAutomationFrequency` is specified, PerfectScale defaults to values based on the type of workload: Deployment: "30m" \ Rollout: "30m"\ DaemonSet: "4h"\ StatefulSet: "24h"\ CronJob: "30m"\ Job: "30m" {% endhint %} ### 🚨 fixResiliencyMaxAutomationFrequency {% hint style="danger" %} `maxAutomationFrequency` field is deprecated as of autoscaler version **v1.0.16**. {% endhint %} This optional field defines the maximum frequency at which automated actions can be executed to apply recommendations when resiliency risks are detected, and resource increase is needed. {% hint style="info" %} If no `fixResiliencyMaxAutomationFrequency` is specified, PerfectScale defaults to values based on the type of workload: Deployment: "30m" \ Rollout: "30m"\ DaemonSet: "4h"\ StatefulSet: "24h"\ CronJob: "30m"\ Job: "30m" {% endhint %} ### :clock10: **Maintenance window** The maintenance window defines the timeframe for PerfectScale to implement the recommendations. The maintenance window is particularly helpful in minimizing the impact of changes on business operations and provides a structured approach to system updates and changes. {% hint style="info" %} Time is indicated in UTC. {% endhint %} **Example 1**\ The automation actions are scheduled daily between 00:00 and 23:59 UTC: ```yaml timeConstraints: maintenanceWindow: monday: - "00:00-23:59" tuesday: - "00:00-23:59" wednesday: - "00:00-23:59" thursday: - "00:00-23:59" friday: - "00:00-23:59" saturday: - "00:00-23:59" sunday: - "00:00-23:59" ``` **Example 2**\ Excluding a specific day from automation maintenanceWindow. ```yaml timeConstraints: maintenanceWindow: monday: - "00:00-00:00" tuesday: - "00:00-00:00" wednesday: - "00:00-00:00" thursday: - "00:00-00:00" friday: - "00:00-00:00" ``` To exclude a specific day(s) from an automation maintenanceWindow, set the timeframe to `00:00-00:00` (e.g., Monday-Friday in the example above). {% hint style="info" %} In the example above, the maintenanceWindow does not specify a timeframe for Saturday and Sunday. As a result, these days default to a `00:00-23:59` window. {% endhint %} **Example 3** The automation actions are scheduled for the end of one day and the beginning of the next. ```yaml timeConstraints: maintenanceWindow: monday: - "00:00-02:30" - "23:30-23:59" tuesday: - "00:00-02:30" - "23:30-23:59" wednesday: - "00:00-02:30" - "23:30-23:59" thursday: - "00:00-02:30" - "23:30-23:59" friday: - "00:00-02:30" - "23:30-23:59" saturday: - "00:00-02:30" - "23:30-23:59" sunday: - "00:00-02:30" - "23:30-23:59" ``` {% hint style="danger" %} The following configuration is invalid because time intervals must be contained within a single day. The example below ranges from late Monday into early Tuesday: ```yaml timeConstraints: maintenanceWindow: monday: - "23:30-02:30" ``` {% endhint %} ### :person\_gesturing\_no: maintenanceWindowIgnoredMinResiliencyLevel {% hint style="danger" %} `maintenanceWindowIgnoredForResiliency` is deprecated. {% endhint %} In some cases, you may want Automation to override the maintenance window to ensure that critical resiliency issues, such as CPU throttling or OOM occurring outside the maintenance window, are properly addressed by an immediate resource increase. ```yaml spec: automation: operational: timeConstraints: maintenanceWindowIgnoredMinResiliencyLevel: None ``` This field indicates the minimum resiliency risk level required to bypass maintenance window constraints and resolve the issue. When set to `None` (default), the maintenance window constraints are enforced. However, when one of the resiliency levels is selected (`Low`, `Medium`, `High`), PerfectScale Automation will ignore maintenance window constraints for risks with the indicated resiliency level and above, applying changes to resolve the issue. **Example 1** The maintenance window will be ignored for risks at any level. ```yaml maintenanceWindowIgnoredMinResiliencyLevel: Low ``` **Example 2** The maintenance window will be ignored for risks with `Medium` and `High` risk levels ```yaml maintenanceWindowIgnoredMinResiliencyLevel: Medium ``` **Example 3** The maintenance window will be ignored for `High` risks only. ```yaml maintenanceWindowIgnoredMinResiliencyLevel: High ``` ## 💡cpuManagement: keepLimit In general, we recommend removing CPU limits when possible. Doing so can improve the performance and efficiency of your workloads by allowing them to use available CPU resources more freely. However, be aware that removing misconfigured CPU limits can increase memory consumption in many cases. This requires **adjusting** both **memory requests and limits** to ensure **optimal performance** and **efficient use** of resources. {% hint style="success" %} We **highly recommend** that removing CPU limits always be combined with **enabling `increase allowed` memory settings**. This allows the system to automatically adjust memory resources to meet the increased demands, maintaining the stability and performance of your workloads. {% endhint %} ## :arrows\_counterclockwise: maxMemoryIncreaseIterations `maxMemoryIncreaseIterations` sets the maximum allowed number of daily and weekly memory limit increase iterations. {% hint style="info" %} `max_memory_increase_iterations` is a mandatory field. Make sure it exists and doesn't equal to 0. {% endhint %} Once the number of daily or weekly memory increase iterations reaches the maximum value, to prevent potential memory leaks, PerfectScale Automation will stop recursive memory increase. In order to notify the customer, PerfectScale will raise a relevant indicator and create an [Alert](https://docs.perfectscale.io/2.0-self-hosted-or-perfectscale-documentation/configure-alerts/alerts-overview).