Preloader
Panel Stability

Tutorial: How to Fix Memory Leak in XUI.ONE

Diagnose and resolve high RAM usage caused by PHP workers, FFmpeg, and Database caching.

Is XUI.ONE Leaking?

Usually, what looks like a memory leak is actually a misconfiguration in the underlying software stack. PHP-FPM workers may not be recycling, FFmpeg jobs might be getting stuck, or MariaDB might be caching too aggressively. This guide walks you through fixing these specific issues.

1Step 1: Identify the Culprit

Don't guess! Use system tools to see exactly what is consuming your memory. Run this command to see the top memory-using processes:

ps -eo pid,cmd,%mem,rss --sort=-rss | head -n 20

What to look for:

  • php-fpm: If these are at the top and growing, your workers aren't recycling.
  • ffmpeg: If you see hundreds of these, you might have stuck transcoding jobs.
  • mariadbd/mysqld: If this is huge, your buffer pool is likely too large for a shared server.

2Step 2: Service Controls

Before applying fixes, know how to restart XUI correctly to clear immediate issues. Depending on your installation, use one of these commands:

service xuione restart # OR systemctl restart xuione

3Step 3: Optimizing PHP-FPM (The Main Fix)

PHP workers often retain memory after processing requests. To prevent this "leak," we force them to recycle.

Edit your PHP pool config (commonly in /etc/php/7.x/fpm/pool.d/www.conf or similar):

nano /etc/php/7.4/fpm/pool.d/www.conf

Critical Settings to Change:

# Recycle worker after 200 requests to free memory pm.max_requests = 200 # Use ondemand to save RAM when idle pm = ondemand pm.process_idle_timeout = 10s # Restart master process if too many children fail emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 10s

Restart PHP-FPM: sudo systemctl restart php7.4-fpm (adjust version number as needed).

4Step 4: Managing FFmpeg & Transcoding

Stuck transcoding jobs are a major cause of memory exhaustion.

Check running jobs:

pgrep -a ffmpeg | wc -l

If the number is much higher than your active streams, you have zombies. If a single PID keeps growing in memory usage over hours, investigate the stream source. Ensure you are using the FFmpeg build provided or supported by XUI.ONE to avoid compatibility leaks.

5Step 5: Database Tuning

MariaDB/MySQL loves to eat RAM for caching. On a dedicated database server, this is good. On an "all-in-one" streaming server, it starves FFmpeg.

Check your current buffer pool size in MySQL console:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

If it is set to 80% of your RAM, reduce it in your my.cnf config. Leave enough headroom for PHP and FFmpeg spikes.

6Step 6: Verification

After applying these fixes, monitor your server for 24 hours. Use the watch command to see if memory stabilizes:

watch -n 60 "free -h; echo; ps -eo cmd,rss --sort=-rss | head -n 15"

Success means PHP workers appear and disappear (ondemand) or reset their memory usage (max_requests), and Swap usage remains at zero.

Important Legal Notice
Xtream-Masters is a software development company. We build and license professional software tools — we do not host, store, stream, index, or distribute any audio, video, playlist, channel, or DRM-protected content of any kind. Every product we sell is an empty technical platform; all content processed through our software is supplied, configured, and controlled solely by the end user, who must hold the necessary rights and comply with applicable law. Copyright or DMCA notices must be directed to the operator or stream origin of the URL concerned — not to Xtream-Masters. See our Terms, Privacy Policy, and Refund Policy for full details.