Configure PHP Settings in rConfig V8 Core

After reading this page, you can locate the active php.ini file on your rConfig V8 Core server, raise the memory_limit and max_execution_time values to suit your device count, and confirm the new values took effect. This prevents the timeout and out-of-memory failures that hit large configuration downloads, reports, and bulk operations.

When to use this

PHP ships with conservative defaults (often 128M memory and a 30 second execution limit) that suit small web apps but not a network configuration manager processing large config files across many devices. Tune these settings when you see “Allowed memory size exhausted” errors, tasks that fail part way through, or sluggish reports as your inventory grows.

Prerequisites

• Shell access to the rConfig server with sudo privileges
• The PHP version your install uses (run php -v to confirm, usually 8.3)
• A maintenance window, since editing php.ini requires a PHP and web server restart
• Familiarity with the V8 Core installation guide layout

Which PHP settings matter most?

memory_limit

memory_limit is the maximum memory a single PHP process can use before PHP terminates it. rConfig needs headroom here when processing large config files, generating reports with extensive history, or running bulk operations across many devices. Too little shows up as “Allowed memory size exhausted” errors during downloads, report generation, or bulk actions.

max_execution_time

max_execution_time is how long a PHP script may run before PHP kills it. The default protects the server from runaway processes but can cut off legitimate long operations such as downloading configs from hundreds of devices or generating large audit reports. The queue system handles most long-running work in the background, so prefer it over ever-larger execution times for very large jobs.

Note

For deployments with thousands of devices, lean on the queue system rather than continually raising max_execution_time. Queue workers process jobs in the background with their own timeout handling, separate from PHP execution limits. See the Horizon Queue Manager guide.

Recommended values

These values assume a server dedicated to rConfig, where PHP is the primary memory consumer. They allocate roughly 75-85% of RAM to PHP, leaving the rest for the OS, database, and web server. Reduce them if other memory-intensive applications share the host.

Server RAM	Recommended memory_limit	Deployment size
4GB	3072M (3GB)	Small: under 500 devices
8GB	6144M (6GB)	Medium: 500-1,000 devices
16GB	12288M (12GB)	Large: 1,000-5,000 devices
32GB+	28672M (28GB)	Enterprise: 10,000+ devices

Environment size	Recommended max_execution_time	Rationale
Small (under 100 devices)	300 seconds (5 minutes)	Most operations finish within this window
Medium (100-500 devices)	600 seconds (10 minutes)	Bulk operations need extended processing
Large (500-1,500 devices)	900 seconds (15 minutes)	Tasks span many devices
Enterprise (1,500+ devices)	1200 seconds (20 minutes)	Large-scale operations need the most time

Tip

Set these values in consultation with your system administrator (and rConfig support for large deployments) so the overall host stays stable. Use top or htop to observe actual PHP memory use during peak operations, then adjust from real data rather than estimates.

Find the active php.ini file

PHP can use different php.ini files for the web server (PHP-FPM or Apache) and for command-line and queue operations. Settings must match across both for rConfig to behave consistently. Print the active file with:

php -i | grep "Loaded Configuration File"

Common locations:

• Ubuntu/Debian: /etc/php/8.3/fpm/php.ini, /etc/php/8.3/apache2/php.ini, /etc/php/8.3/cli/php.ini
• CentOS/RHEL/Rocky/AlmaLinux: /etc/php.ini for FPM, Apache, and CLI

Edit and apply the settings

Back up php.ini before editing

A syntax error in php.ini can stop PHP loading entirely and take rConfig offline until fixed. Always create the dated backup shown below, and test changes in a non-production environment first where possible.

Ubuntu / Debian

1. Confirm your PHP version and the active config file path.

   php -v
   php -i | grep "Loaded Configuration File"

2. Back up the configuration file. If you run Apache rather than PHP-FPM, back up its php.ini too.

   sudo cp /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.backup.$(date +%Y%m%d)
   sudo cp /etc/php/8.3/apache2/php.ini /etc/php/8.3/apache2/php.ini.backup.$(date +%Y%m%d)

3. Open the configuration file in an editor.

   sudo nano /etc/php/8.3/fpm/php.ini

4. Locate memory_limit. Press Ctrl+W, type memory_limit, press Enter. Change the value to suit your server RAM, for example:

   memory_limit = 6144M

5. Locate max_execution_time. Press Ctrl+W, type max_execution_time, press Enter. Change the value to suit your deployment size, for example:

   max_execution_time = 600

6. Save and exit. Press Ctrl+O, then Enter to confirm, then Ctrl+X.

7. Restart PHP and your web server.

   # PHP-FPM with Nginx
   sudo systemctl restart php8.3-fpm
   sudo systemctl restart nginx
   
   # Apache
   sudo systemctl restart apache2

8. Verify the new values.

   php -i | grep memory_limit
   php -i | grep max_execution_time

CentOS / RHEL / Rocky / AlmaLinux

1. Confirm your PHP version and the active config file path.

   php -v
   php -i | grep "Loaded Configuration File"

2. Back up the configuration file.

   sudo cp /etc/php.ini /etc/php.ini.backup.$(date +%Y%m%d)

3. Open the configuration file in an editor.

   sudo vi /etc/php.ini

4. Locate memory_limit. Press /, type memory_limit, press Enter, then press i to edit. Change the value to suit your server RAM, for example:

   memory_limit = 6144M

5. Locate max_execution_time. Press Esc, then /, type max_execution_time, press Enter, then press i to edit. Change the value to suit your deployment size, for example:

   max_execution_time = 600

6. Save and exit. Press Esc, type :wq, press Enter.

7. Restart PHP and your web server.

   # PHP-FPM with Nginx
   sudo systemctl restart php-fpm
   sudo systemctl restart nginx
   
   # Apache
   sudo systemctl restart httpd
   sudo systemctl restart php-fpm

8. Verify the new values.

   php -i | grep memory_limit
   php -i | grep max_execution_time

Confirm the change took effect

The command-line check above verifies the values used by CLI scripts and queue workers. To confirm the web interface also picked up the change, run a resource-intensive task such as generating a large report, then check the Application Log for any memory or timeout errors. If the operation completes cleanly, the configuration is adequate.

If you also cleared application caches as part of an update, refresh the rConfig cache so it does not serve stale config:

php /var/www/html/rconfig/artisan rconfig:clear-all

This command clears the Laravel cache and config. See the CLI commands reference for full details. It is not required just for a php.ini change, but it is useful after broader configuration work.

Common gotchas

Caution

• Editing the wrong php.ini. PHP-FPM, Apache, and CLI can each load a separate file. Run php -i | grep "Loaded Configuration File" for the context you are changing, and update both web and CLI files identically so queue workers match the web interface.
• Forgetting the restart. New values do not apply until PHP-FPM or the web server restarts. Run the restart commands for your stack after saving.
• Setting memory too high. Allocating nearly all RAM to PHP lets a runaway process exhaust the host and crash it. Keep memory_limit at roughly 75-85% of RAM on a dedicated server.
• Leaving phpinfo files behind. A phpinfo.php file exposes server configuration and credentials. Delete it immediately after any verification, never leave it on a production server.

What’s next

• Horizon Queue Manager to offload large operations to background workers instead of raising execution limits.
• System Logs to view PHP errors and exceptions when troubleshooting.
• Update PHP on your rConfig server when moving to a newer PHP version.