High server load on a DirectAdmin server is one of the most disruptive problems a web hosting company faces — it slows every site on the server simultaneously, triggers alerts from monitoring tools, and leads to client escalations within minutes. Unlike a single-site issue, high load affects everyone on the box. This guide covers the 7 most effective ways to diagnose and fix DirectAdmin server high load, from MySQL query bottlenecks to Apache worker exhaustion and malware-driven resource consumption.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 1: Diagnose the High Load Before Changing Anything
Changing settings without knowing the cause of high load can make things worse. Spend 5 minutes diagnosing first — it will save hours.
uptime
# or
cat /proc/loadavg
A load average above the number of CPU cores is considered high. On a 4-core server, load above 4.0 for more than a few minutes indicates a problem.
top -b -n1 | head -30
# Press 'M' in interactive top to sort by memory, 'P' for CPU
Note the top 5 processes by CPU. If mysqld is at the top, the problem is database-related. If httpd or apache2 is dominant, the problem is web traffic or PHP. If php-fpm, it is application-level.
iostat -x 1 5
If %iowait is consistently above 30%, your bottleneck is disk — not CPU or RAM.
mysql -e "SHOW PROCESSLIST;" | head -30
mysql -e "SHOW STATUS LIKE 'Slow_queries';"
# Add to /etc/my.cnf under [mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
systemctl restart mysqld
# After a few minutes, check the slow log:
mysqldumpslow -t 10 /var/log/mysql/slow.log
# Show queries running over 60 seconds
mysql -e "SELECT ID, USER, HOST, DB, TIME, INFO FROM information_schema.processlist WHERE time > 60 ORDER BY time DESC;"
# Kill a specific query
mysql -e "KILL QUERY 1234;"
# In /etc/my.cnf under [mysqld]
max_connections = 150 # Lower if server has 4GB RAM
query_cache_type = 1
query_cache_size = 64M
innodb_buffer_pool_size = 1G # Set to 50-70% of total RAM
table_open_cache = 400
Restart MySQL after changes: systemctl restart mysqld
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
perl mysqltuner.pl --user root --pass YOUR_ROOT_PASS
Follow the recommendations in the output for your specific workload.
ps aux | grep httpd | wc -l
# Check memory per process
ps aux | grep httpd | awk '{sum += $6} END {print sum/1024 " MB total"}'
# Edit /etc/httpd/conf/httpd.conf or /etc/apache2/apache2.conf
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 75 # Set to: total RAM (MB) / RAM per Apache process (MB)
MaxConnectionsPerChild 1000
</IfModule>
Reload Apache: systemctl reload httpd
mod_php runs inside every Apache process, meaning even static file requests load PHP into memory. PHP-FPM uses a separate process pool and is far more memory-efficient. In DirectAdmin → Admin Panel → CustomBuild, switch to PHP-FPM and rebuild PHP.
ps aux --sort=-%mem | grep php | head -10
# In /usr/local/lib/php.ini or the domain-specific php.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
OPcache caches compiled PHP bytecode, eliminating repeated parsing overhead on every request.
In DirectAdmin → User Panel → PHP Configuration, lower memory_limit to 128M for standard shared hosting accounts. Accounts legitimately needing more memory can be moved to their own PHP-FPM pool with a higher limit.
# Most-requested URLs in the last 5 minutes
tail -1000 /var/log/httpd/access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
# IPs making the most requests
tail -1000 /var/log/httpd/access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
csf -d ATTACKER_IP "Brute force block"
csf -r # Reload firewall rules
Add to /etc/httpd/conf.d/block-brute.conf:
<LocationMatch "/(wp-login\.php|xmlrpc\.php)">
Order Deny,Allow
Deny from all
Allow from YOUR_OFFICE_IP
</LocationMatch>
# In /etc/csf/csf.conf
CT_LIMIT = 150 # Max connections per IP before block
CT_INTERVAL = 30 # Check interval in seconds
iotop -o -b -n 5 # Install with: yum install iotop
# Check largest log files
find /var/log -name "*.log" -size +100M | xargs ls -lh
# Force logrotate to run immediately
logrotate -f /etc/logrotate.conf
If your data partition is on a slow HDD, move /var/lib/mysql to an SSD or NVMe volume. This single change can reduce MySQL I/O wait by 80% on read-heavy databases.
echo deadline > /sys/block/sda/queue/scheduler # Or 'noop' for NVMe
# Make persistent in /etc/rc.local
ps aux | grep -E "(apache|nobody|www-data)" | grep -v httpd | grep -v php
Any process running as the web server user that is not httpd or php is suspicious.
clamscan -r /home/ --exclude-dir="^/proc" --log=/tmp/clamscan.log
# Or use Maldet (Linux Malware Detect)
maldet -a /home/
for user in $(cut -d: -f1 /etc/passwd); do
crontab -l -u "$user" 2>/dev/null | grep -v "^#" | grep -q "." && echo "=== $user ===" && crontab -l -u "$user" 2>/dev/null
done
Cryptomining cron jobs typically run commands like wget -q http://... | bash or execute hidden binaries from /tmp.
DirectAdmin supports OpenLiteSpeed via CustomBuild. In DirectAdmin → Admin Panel → CustomBuild Options, switch the web server to LiteSpeed and rebuild. LiteSpeed is event-driven (like Nginx) and consumes a fraction of Apache's memory under the same load.
Nginx handles static files and connection queuing far more efficiently than Apache. Keep Apache running on port 8080 and put Nginx on port 80 to pass dynamic requests to Apache while serving static content directly. DirectAdmin supports this configuration via CustomBuild's Nginx + Apache option.
Monitoring DirectAdmin Server Load Proactively
Reactive high-load fixes are costly. Set up these monitoring tools to catch problems before they become client-impacting:
- Munin — lightweight server monitoring with graphs for CPU, MySQL connections, Apache processes, and disk I/O over time
- Netdata — real-time, per-second server metrics with zero configuration:
bash <(curl -Ss https://my-netdata.io/kickstart.sh) - CSF login failure alerts — in CSF settings, enable email alerts for login failure spikes so you know about brute force attacks the moment they start
- MySQL slow query log — keep it always enabled with
long_query_time=2and review weekly
When to Call a Managed Server Support Expert
Some load issues require infrastructure-level changes that go beyond configuration tuning:
- Load spikes persist after all tuning — may indicate hardware failure (failing drive causing I/O wait)
- MySQL InnoDB corruption causing repeated crashes under load
- Needing to migrate accounts off an overloaded server to a new box without downtime
- Implementing a multi-server load balancing architecture for a growing hosting business
Our managed DirectAdmin support team at CloudHouse Technologies specialises in server performance emergencies for web hosting companies. We diagnose the root cause, apply the fix, and set up monitoring to prevent recurrence — typically within hours of your first contact.
High server load on DirectAdmin is always caused by one of a small number of identifiable root causes — MySQL query overload, Apache worker exhaustion, brute force attacks, disk I/O, or compromised accounts. The key is diagnosing in the right order: check load average, identify the top process, then apply the targeted fix. If load keeps returning after your fixes, the underlying issue is likely infrastructure capacity or an undetected malware infection — both of which CloudHouse's 24/7 server support team handles for hosting companies worldwide.
