Set PHP memory limit, upload size, and execution time

If a PHP application requires more memory, large files cannot be uploaded, or a long-running process times out, PHP limits can play a role.

The most important settings include:

memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_time

In CURIAWEB-cPanel you can configure many of these values via the MultiPHP INI Editor check and adjust – within the limits provided for your hosting.

In this guide, we will show you which PHP limits are responsible for which task, how to change them, and how to identify whether a PHP limit is actually the cause of your problem.

Important: PHP limits should not be preemptively set to the highest possible values. Only adjust the values that are actually required for your application. A higher limit does not fix faulty or inefficient program code.

What are PHP limits? #

PHP limits restrict certain resources or processing operations of a PHP script.

For example, you can determine:

• how much memory PHP is allowed to use
• how large a single uploaded file can be
• what size a complete POST request can be
• how long a PHP script is allowed to run
• how long PHP is allowed to process input data

These limits protect the hosting environment and prevent, among other things, individual processes from consuming unlimited resources.

An overview of the most important PHP limits #

PHP directive	Task
memory_limit	Limits the memory that a PHP script may use.
upload_max_filesize	Limits the size of a single file uploaded via PHP.
post_max_size	Limits the total size of data transmitted via a POST request.
max_execution_time	Limits the execution time of a PHP script.
max_input_time	Limits the time for processing input data.

The values do not appear to be completely independent of each other. Especially with file uploads, several limits have to match up.

Where do you change PHP limits at CURIAWEB? #

Log in to your CURIAWEB cPanel and open:

Software → MultiPHP INI Editor

For typical changes, we recommend the Basic mode, provided that the desired setting is offered there.

We explain the basic operation of the MultiPHP INI editor under Change PHP settings in cPanel.

CURIAWEB recommendation: Use the MultiPHP INI Editor for supported PHP settings. Do not distribute the same values across different php.ini-, .user.ini- or .htaccess-Configurations.

1. Select the correct domain or area #

Open the MultiPHP INI Editor and select the domain whose PHP configuration you want to edit.

Depending on the configuration, domains or the home directory may be offered for selection.

If there are multiple websites in your hosting account, carefully check which website is affected by the change.

2. Check current values #

Before you change anything, note down the current values.

For example:

memory_limit = previous value
upload_max_filesize = previous value
post_max_size = previous value
max_execution_time = previous value
max_input_time = previous value

This allows you to restore the original configuration if needed.

Practical Tip: If you need to change several related values, take a screenshot beforehand. This way you have documented the initial state.

3. Set memory_limit #

The Directive:

memory_limit

limits the memory that a PHP script may consume.

A value is typically specified, for example, like this:

256M

In doing so M for megabytes.

When is memory_limit relevant? #

If a PHP process reaches the allowed memory limit, an error message may include a hint such as:

Allowed memory size exhausted

contain.

Such a message often additionally contains information about how much memory should be used and in which PHP file the error occurred.

specifically increase memory_limit #

If your application demonstrably requires more PHP memory and your hosting allows it, you can memory_limit set it to a suitably higher value in the MultiPHP INI Editor.

Save the change and then repeat exactly the process where the memory error occurred.

Very high memory consumption should be investigated #

If an ordinary website requires an unusually large amount of PHP memory, the limit should not be increased exclusively.

Possible causes can include, for example:

• faulty plugin
• problematic theme
• inefficient individual PHP code
• very large amounts of data
• unusually complex import or export
• Programming error or loop

Important: If memory_limit must be continuously increased without knowing the cause of the high memory consumption, the application should be investigated.

PHP memory_limit and hosting RAM are not the same thing #

The PHPmemory_limit must not be confused with the total RAM resources of your hosting account.

CloudLinux also manages resources at the hosting account level.

A very high PHP settingmemory_limit therefore does not automatically increase the resources available to your hosting account as a whole.

We explain how to control these resources at Understanding CloudLinux Resource Usage in cPanel.

WordPress Memory Limit and PHP memory_limit #

In WordPress, you will also encounter terms such as:

WP_MEMORY_LIMIT

and if applicable:

WP_MAX_MEMORY_LIMIT

These values belong to the WordPress configuration and are not related to the server-side PHPmemory_limit identical.

WordPress cannot simply force more PHP memory than the PHP or hosting configuration actually allows.

Briefly explained: A high value in wp-config.php do not arbitrarily lift a lower server-side PHP limit.

4. Set upload_max_filesize #

The Directive:

upload_max_filesize

determines the maximum size of a single file that can be uploaded via PHP.

An example would be:

64M

This limit can be relevant, for example, in:

• WordPress media uploads
• Theme Uploads
• Plugin uploads
• Import files
• other upload forms of a PHP application

Upload limit in WordPress #

WordPress usually displays a maximum file size in the upload area.

If a file is larger than the permitted size displayed there, upload_max_filesize be one of the relevant settings.

However, this value is not the only limit.

5. also check post_max_size #

For PHP file uploads, additionally:

post_max_size

Important.

This directive limits the total size of a POST request.

A file upload is typically transmitted within such a request.

Therefore, must:

upload_max_filesize
post_max_size

be meaningfully coordinated with one another.

Why post_max_size should be larger than the desired file #

A POST request can contain additional form data alongside the actual file.

If, for example, you want to upload a file up to a certain size, you should post_max_size therefore providing sufficient space for the entire request.

A sensibly coordinated scheme could look like this, for example:

upload_max_filesize = 64M
post_max_size = 72M

These values are merely an example of the relationship between the two limits and are not a general CURIAWEB recommendation for every website.

Important: Set post_max_size not smaller than the file size that you via upload_max_filesize would like to allow.

Why a higher upload_max_filesize alone is not enough #

Assuming you configure:

upload_max_filesize = 128M
post_max_size = 32M

Then the smaller POST limit can still prevent a correspondingly large file from being successfully transferred.

Therefore, in case of upload problems, you should always check both values.

6. Set max_execution_time #

The Directive:

max_execution_time

limits the maximum execution time of a PHP script.

A value like:

60

typically stands for 60 seconds.

A longer execution time can become relevant, for example, in the case of complex PHP processes.

Typical situations for max_execution_time #

This may include, for example:

• larger imports
• larger exports
• Image processing
• certain backup processes
• extensive data processing
• certain update processes

Whether actually max_execution_time you should check the cause based on the error message or the behavior.

Maximum execution time exceeded #

When a PHP script reaches its time limit, an error message may contain, for example:

Maximum execution time exceeded

In this case max_execution_time directly relevant.

However, also check why the process takes so long.

Attention: An execution time of several minutes is not automatically the right solution. A hanging external service, an infinite loop, or inefficient code will not be fixed by a higher time limit.

Do not confuse max_execution_time with browser timeout #

If your browser reports a timeout, it does not automatically mean that PHP has max_execution_time has reached.

There are further technical components between the browser and PHP.

Simplified:

Browser
   ↓
Network
   ↓
Web server
   ↓
PHP
   ↓
Application
   ↓
Database / external services

An abortion can occur at different levels.

A 504 Gateway Timeout is not automatically a PHP limit #

If a website has a:

504 Gateway Timeout

report, should you not automatically max_execution_time increase.

A 504 error means that an involved server component did not receive an expected response in time. The exact cause must therefore be investigated.

7. Check max_input_time #

The Directive:

max_input_time

limits the time PHP is allowed to use for processing input data.

She is not the same as:

max_execution_time

and should only be adjusted if it is actually relevant to the specific process.

max_input_time and large forms #

With very large inputs or certain import processes, the processing of input data can play a role.

However, if an application explicitly points to another PHP directive, you should not preemptively max_input_time increase.

Save changes #

After you have adjusted the required values, save or apply the PHP configuration in the MultiPHP INI Editor.

Waiting for cPanel confirmation.

9. Check values after saving #

Then check whether the intended values are displayed in the MultiPHP INI Editor.

For example, if you have changed upload limits, check both:

upload_max_filesize

as well as:

post_max_size

10. Retest the exact affected process #

Repeat the operation that previously failed after making the change.

For example:

Memory error
→ run the same operation again

Upload too large
→ upload the same file again

Execution time exceeded
→ start the same process again

This is how you can determine if the change was actually relevant.

PHP limit changed, problem persists #

If the error remains unchanged despite the adjusted limit, you should not simply increase the value again.

Check instead whether:

• the correct limit has been changed
• the correct domain or area was selected
• the change is actually effective
• another technical limit applies
• the application itself is causing a problem
• a hosting resource limit is reached

Observe server-side limits #

A shared hosting account cannot modify PHP and server parameters indefinitely.

Certain settings can be predetermined on the server side or subject to an upper limit.

Just because you can enter a value in the MultiPHP INI Editor does not necessarily mean that any arbitrarily high setting will actually take technical effect.

Important: PHP configuration values operate within the limits of the entire hosting environment. A registered numerical value does not generate additional server resources.

PHP memory_limit and CloudLinux Memory Limit #

These two terms can easily be confused.

Simplified:

PHP memory_limit
→ PHP configuration of a script

CloudLinux resources
→ Resource limits of the hosting account

When the hosting account reaches a resource limit, an increase of memory_limit even miss the point.

We cover CloudLinux limits and their evaluation under Resource Limit Is Reached: Identify and Fix CloudLinux Limits.

Upload limit increased, WordPress still shows old value #

If WordPress still shows a lower maximum upload size after a change, first check:

• correct section in the MultiPHP INI Editor
• upload_max_filesize
• post_max_size
• whether the change was saved
• whether further local PHP configurations exist
• whether a server-side limit applies

Do not enter the same values redundantly into multiple configuration files on a hunch.

Uploading large files: PHP is not always the best way #

If you only want to transfer a very large file to your web space, the upload does not necessarily have to be done via a PHP application.

For normal files, you can use the cPanel file manager or FTP, for example.

We explain how to transfer files directly via cPanel at Upload, download, and edit files in cPanel.

For larger or recurring file transfers, FTP may be more suitable. We explain the setup at Create an FTP account in cPanel.

Practical Tip: If you only want to transfer a large ZIP file to the server, it is often more sensible to transfer the file directly via the hosting instead of significantly increasing the PHP upload limits of a web application for this purpose.

Large WordPress plugins or themes #

If a plugin or theme exceeds the allowed PHP upload size, adjusting the upload limits can be useful.

Alternatively, with the appropriate knowledge, a direct file transfer can also be used.

Make sure to transfer files to the correct directory and not to overwrite existing installations uncontrollably.

Large media files #

Just because PHP could technically allow a very large upload doesn't automatically mean that a very large file makes sense for a website.

In particular, images should be appropriately sized and optimized for web use.

Extremely large media files can strain storage space, loading time, and processing.

phpMyAdmin and large SQL files #

When importing an SQL file via phpMyAdmin, PHP limits can play a role, for example, if the file already exceeds the allowed upload size.

However, a failed database import can have numerous other causes.

This includes, for example:

• SQL syntax error
• already existing tables
• duplicate records
• Character set or collation issues
• Permission issues
• Server or database limits
• partially executed import

You can find the systematic diagnosis under phpMyAdmin import not working: Errors and large SQL files.

Do not blindly import large SQL file multiple times #

If a database import fails after running for a long time, you should not immediately import the same file again.

The import may have already created some of the tables or data.

First check the state of the target database and the specific error message.

max_execution_time for cron jobs #

For time-based tasks, you should not automatically assume that a problem is exclusively caused by max_execution_time is caused.

Cron jobs can have different execution paths and frameworks than a normal PHP request via the browser.

How to set up cron jobs is covered at Create a cron job in cPanel and set the schedule correctly.

PHP Limits and Website Performance #

Very high PHP limits do not automatically make a website faster.

For example:

memory_limit = very high
≠
website automatically faster

A limit defines a boundary. It is not a performance setting in the sense of an accelerator.

More memory can mask inefficient code #

If an application works again initially due to a significant increase in the memory limit, it should still be checked whether the actual memory requirement is plausible.

For example, a faulty plugin can consume more and more memory until an even higher limit is reached again.

More execution time can mask a slow process #

The same applies to max_execution_time.

If an operation suddenly takes 300 seconds instead of 30, a higher limit may prevent a timeout, but it still does not explain why the process is taking so long.

Therefore, in the case of recurring problems, the root cause should be investigated.

Check PHP version before debugging #

If PHP problems occurred immediately after a change in the PHP version, application compatibility should also be checked first.

Increasing PHP limits does not fix an incompatibility with a PHP version.

You manage the PHP version in CURIAWEB via the MultiPHP Manager.

Use error log #

If it is not clear which limit is being reached, the error log can provide important clues.

A message like:

Allowed memory size exhausted

points much more specifically to the cause than a general statement like „the website is not working.“.

We explain how to find and classify such clues under Read cPanel Error Log and find website errors.

Correctly assign typical error messages #

Some reports already provide a strong indication of the relevant level:

Observation	Check first
Allowed memory size exhausted	memory_limit and cause of memory consumption
File exceeds maximum upload size	upload_max_filesize and post_max_size
Maximum execution time exceeded	max_execution_time and cause of the long runtime
Resource Limit Is Reached	CloudLinux resources instead of just PHP limits
504 Gateway Timeout	investigate the entire processing chain

Do not increase all limits at the same time #

When an application reports a memory error, there is usually no reason to massively increase the upload size, POST size, and execution time all at once.

A targeted change facilitates the diagnosis.

Basic rule: Read error message → identify relevant limit → document initial value → adjust specifically → test the same process again.

Do not copy PHP limits from external guides via .htaccess #

Older tutorials sometimes recommend PHP configuration lines within the:

.htaccess

Such instructions can depend on the PHP operating mode used and, in an unsuitable environment, can even cause a server error.

Therefore, use the PHP management provided in the CURIAWEB cPanel for the settings described here.

If you an existing .htaccess you must investigate, you can find the procedure under .htaccess explained and safely edited.

Check PHP limits after website migration #

When a website has been migrated from another hosting provider, PHP configurations can differ.

For example, the previous website may have been operated with different values.

Additionally, files such as:

php.ini

or:

.user.ini

have been transferred from the old hosting.

Therefore, if unexpected PHP limits or errors occur after a move, you should also check existing local PHP configurations.

Do not delete local PHP configuration on a hunch #

If you a php.ini or .user.ini find, document their content or back up the file before you make any changes.

It may have been used intentionally by an application or a previous configuration.

Undo change #

If a changed PHP value does not help or has unexpected effects, you can restore the previously documented initial value.

Open:

Software → MultiPHP INI Editor

Select the correct range and enter the original value again.

Save afterwards and test the website again.

Example: File upload is too large #

Assuming an application cannot upload a required file due to its size.

Then you proceed systematically:

1. Check the size of the file.
2. Open the MultiPHP INI Editor.
3. Check upload_max_filesize.
4. Check post_max_size.
5. Document the previous values.
6. Adjust the values only as far as necessary.
7. Save the configuration.
8. Repeat the same upload.

If the upload still doesn't work, check for other possible limits instead of continually increasing the values.

Example: PHP memory limit exceeded #

For a message like:

Allowed memory size exhausted

do you proceed as follows:

1. Note the complete error message.
2. Check which file or component is named.
3. Check the current value of memory_limit.
4. Check whether the memory requirement of the application is plausible.
5. Adjust the limit in case of justified need within the available limits.
6. Test the same process again.
7. Investigate the application if memory consumption remains unusually high.

Example: Operation aborts after a long time #

If a PHP process terminates after a certain execution time:

1. Note the exact error message.
2. Check whether actually Maximum execution time exceeded is reported.
3. Check max_execution_time.
4. Check if the long execution time for the process is plausible.
5. Increase the value only when there is a concrete need.
6. Test the same process again.
7. In case of persistently long execution times, investigate the application or the process.

When should you contact support? #

If a required PHP limit cannot be changed, a set value does not take effect, or an operation continues to fail despite plausible settings, you should document the current state as precisely as possible.

Particularly helpful for an analysis are:

• affected domain
• PHP version used
• affected PHP directive
• original value
• newly set value
• exact error message
• which process fails
• Size of an affected file, if relevant
• used CMS or application
• whether the problem only occurred after a specific change

Do not transmit any passwords or other confidential access credentials.

Summary #

You can find the most important PHP limits in the CURIAWEB cPanel via Software → MultiPHP INI Editor check and adjust within available limits.

memory_limit limits the PHP memory, upload_max_filesize the size of a single uploaded file and post_max_size the total size of a POST request. max_execution_time concerns the execution time of a PHP script, while max_input_time relates to the processing of input data.

In the case of file uploads, it is particularly necessary to upload_max_filesize and post_max_size be meaningfully coordinated with each other. In the event of memory or runtime issues, however, you should not only increase the limit, but also check why the application requires an unusual amount of resources or time.

PHP limits are also not equivalent to the total CloudLinux resources of your hosting account. A very high PHP value does not generate additional server resources.

The most important procedure is therefore: Identify errors, determine the relevant limit, document the initial value, make targeted adjustments, and test the same process again.