copyright | lastupdated | keywords | subcollection | ||
---|---|---|---|---|---|
|
2024-10-17 |
limits for code engine, limitations for code engine, quotas for code engine, project quotas in code engine, app limits in code engine, job limits in code engine, limits, limitations, quotas |
codeengine |
{{site.data.keyword.attribute-definition-list}}
{: #limits}
The following sections provide technical details about the {{site.data.keyword.codeenginefull}} limitation and quota settings. {: shortdesc}
How does my resource allocation effect my project quotas and billing?
From the console, you can view information about your current {{site.data.keyword.codeengineshort}} resource allocation from your project overview page. If you want to display information about the allocated memory and vCPU values based on what you configured for each specific application or job, then view the listing of your applications or jobs in your project. With the CLI, you can also get information about your current resource allocation usage for the project with the project get
command.
With {{site.data.keyword.codeengineshort}}, you pay for only the resources that you use based on the configured memory and vCPU that your workloads consume, and any incoming HTTP calls. If your app scales to zero or your job or build isn't running, you are not consuming resources, and so you are not charged. To host all your applications and jobs, {{site.data.keyword.codeengineshort}} deploys and manages the necessary infrastructure for you. However, while you are not billed for this infrastructure, it does count toward the project quotas. For more information about quotas, see the following tables.
The use of ephemeral storage is now bounded by memory. The ephemeral storage in {{site.data.keyword.codeengineshort}} cannot exceed the default value of 0.4 GB (400 MB) or the configured value for memory. If you need more than the default for ephemeral storage, you must increase your memory according to the valid combinations of vCPU and memory. {: important}
See Supported memory and CPU combinations for more information about the relationship between ephemeral storage and memory.
{: #limits_application}
The following table lists the limits for applications.
Category | Default | Maximum value | Need to extend the maximum? |
---|---|---|---|
CPU | 1.0 | 12.0 | Contact IBM support |
Ephemeral storage | 400 M | 48 G \n (limited by memory) | Contact IBM support |
Max scale | 10 | 250 | Contact IBM support |
Memory | 4 G | 48 G | Contact IBM support |
Min scale | 0 | 250 | Contact IBM support |
Concurrency | 100 | 1000 | Contact IBM support |
Timeout | 300 seconds | 600 seconds | Contact IBM support |
{: caption="Application limits"} |
For more information about supported CPU and memory combinations, see Supported memory and CPU combinations.
{{site.data.keyword.codeengineshort}} has limits for apps within a project.
- You are limited to 40 apps per project.
- You are limited to a total of 120 revisions for all apps per project.
{{site.data.keyword.codeengineshort}} does not support overcommitment for application resources. Therefore, if you create an application by using the API or with kubectl apply -f <yaml>
, the values for Resource.Requests
and Resource.Limits
for CPU
, Memory
, and Ephemeral Storage
must be specified and must be the same.
{: #limits_job}
The following table lists the limits for jobs.
Category | Default | Maximum value | Need to extend the maximum? |
---|---|---|---|
Array indices | 0 | 9999999 | Contact IBM support |
Array size | 1 | 1000 | N/A |
CPU | 1.0 | 12.0 | Contact IBM support |
Ephemeral storage | 400 M | 48 G \n (limited by memory) | Contact IBM support |
Memory | 4 G | 48 G | Contact IBM support |
Retries | 3 | 5 | Contact IBM support |
Timeout | 7200 seconds (2 hours) | 86400 seconds (24 hours) | Contact IBM support |
{: caption="Job limits"} |
Array indices are comma-separated lists or a hyphen-separated range of indices, which specifies the job instances to run; for example, 1,3,6,9
or 1-5,7-8,10
.
Array size is the number of job instances to run in parallel.
For more information about supported CPU and memory combinations, see Supported memory and CPU combinations.
{{site.data.keyword.codeengineshort}} is limited to 100 jobs per project. After 100 job runs are started, be sure to clean up older job runs before you start new job runs.
{: #job_size_limit}
{{site.data.keyword.codeengineshort}} limits the size of jobs and job runs with a maximum of 10 KiB. When you create or update jobs and job runs with the console, CLI, or API, {{site.data.keyword.codeengineshort}} checks the size of the job or job run. If the operation exceeds the limit, a size limit exceeded error is given. If you receive this error, try reducing the size of your job or job run in one of the following ways.
-
If you use commands and arguments, try reducing the use of these options, make them shorter, or move them into the container image that is used by your job or job run.
-
If you use environment variables, try to use fewer environment variables or make them shorter. You can use secrets or configmaps to define environment variables and import them into the job by using the
--env-from-secret
or--env-from-configmap
options with thejob create
,job update
,jobrun submit
, andjobrun resubmit
commands.
For more information about troubleshooting jobs, see Troubleshooting - Why can't I submit a job run?.
{: #limits_functions}
The following table lists the limits for functions.
Category | Maximum |
---|---|
Length of runtime | 120 seconds |
Memory | 48000 MB |
Code size (inline) | 100 KB, including base64 overhead |
Code size (local source) | 200 MB compressed |
Code size (API) | 100 KB, including base64 overhead |
{: caption="Function limits"} |
{: #subscription-cron-limit}
The following table lists the limits for the periodic timer subscription.
Category | Maximum | Need to extend the maximum? |
---|---|---|
Size of data | 4096 bytes | Contact IBM support |
{: caption="Periodic timer limits"} |
{{site.data.keyword.codeengineshort}} limits the size of data for Periodic timer (cron) events with a maximum of 4096 bytes. When you create or update periodic timer (cron) events, {{site.data.keyword.codeengineshort}} checks the size of the cron event data. If the Periodic timer (cron) event data exceeds the limit, a size limit exceeded error is given. If you receive this error, try reducing the cron event data size to less than 4096 bytes.
For more information about troubleshooting subscriptions, see Debugging subscriptions.
{: #limits_projects}
The following table lists the limits for projects.
Category | Maximum | Need to extend the maximum? |
---|---|---|
Project per region | 20 | Contact IBM support |
{: caption="Project limits"} |
The maximum number of projects includes projects that are active and any projects that are not permanently deleted. When you delete a project, the project is soft deleted, and can be restored within 7 days before it is permanently deleted. Use the console or the CLI to display soft-deleted projects. For more information, see deleting a project. {: important}
{: #project_quotas}
The following table lists the quotas for projects.
Be aware that the limits apply independently from each other within a project. If a limit is reached, such as the limit of 512 GB of memory, this quota limit might impact the ability to run a workload, even if another limit is not yet reached, such as 250 instances of apps or jobs.
Category | Description |
---|---|
Apps | You are limited to 40 apps per project. |
App revisions | You are limited to a total of 120 revisions for all apps per project. |
Builds | You are limited to 100 build configurations per project. |
Build runs | You are limited to 100 build runs per project before you need to remove or clean up old ones. |
Configmaps | You are limited to 100 configmaps per project. |
CPU | The total combination for all the app instances, running job instances, and running build instances cannot exceed 128 vCPU. |
Domain mappings (custom) | You are limited to 80 custom domain mappings per project. |
Ephemeral storage | The total combination for all the app instances, running job instances, and running build instances cannot exceed 512 G of ephemeral storage. |
Functions | You are limited to 20 Functions per project. |
Instances (active) | The number of app instances, function instances, running job instances, and running build instances cannot exceed 250. |
Instances (total) | The number of active instances and the number of completed job and build instances cannot exceed 2500. |
Jobs | You are limited to 100 jobs per project. |
Job runs | You are limited to 100 job runs per project before you need to remove or clean up old ones. |
Memory | The total combination for all the app instances, running job instances, and running build instances cannot exceed 512 G of memory. |
Secrets | You are limited to 100 secrets per project. |
Subscriptions ({{site.data.keyword.cos_full_notm}}) | You are limited to 100 ({{site.data.keyword.cos_short}}) subscriptions per project. |
Subscriptions (Kafka / {{site.data.keyword.messagehub_full}}) | You are limited to 100 Kafka subscriptions per project. |
Subscriptions (Periodic timer (cron)) | You are limited to 100 periodic timer (cron) subscriptions per project. |
{: caption="Project quotas"} |
For example, you are limited to 128 vCPU or 250 active instances of an app or job. Since each limit applies independent of other limits, suppose you want to scale an app to 250 instances with 0.125 VCPU. These values result in about 32 vCPU, which works as this result is less than the maximum of 128 vCPU. However, you cannot use 512 instances with 0.125 vCPU, which would still meet the maximum of 128 vCPU, but would violate the limit for a maximum of 250 instances.
{: #increase-limits}
Limit values are fixed, but can be increased by contacting IBM support and creating a support case.