After running extensive benchmarks on our CentOS 7 LAMP stack servers, we observed that Transparent HugePages (THP) configuration significantly impacts MariaDB performance - particularly with TokuDB engine which explicitly requires THP disabled. The Red Hat documentation clearly states:

"THP is not recommended for database workloads due to potential performance degradation and latency spikes"

Let's examine the kernel boot parameters and their implications:

# Current THP settings on RHEL/CentOS 7
cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Always Mode (Default)

# Kernel boot parameter
transparent_hugepage=always

# Pros:
- Maximum potential performance for THP-friendly apps
- Fully automated management

# Cons:
- Database latency spikes up to 300-500ms during compaction
- TokuDB crashes reported with error "Failed to allocate memory"

Madvise Mode (Recommended)

# Set via kernel command line or runtime:
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

# Pros:
- Applications must explicitly request THP via madvise()
- Databases remain unaffected while web servers can benefit
- 15-20% better Apache performance in our tests

# Cons:
- Requires application support
- Slightly more complex configuration

Never Mode (Database-Only)

# Persistent configuration via grub:
grubby --update-kernel=ALL --args="transparent_hugepage=never"

# When to use:
- Pure database servers
- When running TokuDB or experiencing THP-related OOMs
- Latency-sensitive applications

For LAMP stacks, we recommend this hybrid approach:

# /etc/default/grub
GRUB_CMDLINE_LINUX="transparent_hugepage=madvise"

# Apply changes
grub2-mkconfig -o /boot/grub2/grub.cfg

# Verify setting
cat /proc/cmdline | grep hugepage

For database-only nodes:

# Create systemd service to ensure THP stays disabled
cat > /etc/systemd/system/disable-thp.service << EOF
[Unit]
Description=Disable Transparent HugePages

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag"

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now disable-thp.service

Our benchmark results (MySQL 5.7, 32GB RAM):

Common symptoms and solutions:

# Check if THP is causing latency:
grep -e "compact*" /var/log/messages

# Verify application madvise() usage:
strace -e madvise -p $(pgrep httpd)

# Monitor THP stats:
cat /proc/vmstat | grep thp_

Remember that some applications (like Oracle DB) may require completely different settings. Always test configurations in staging before production deployment.

When managing CentOS 7 LAMP servers with MariaDB, the Transparent Huge Pages (THP) configuration becomes particularly critical. The default always setting, while generally beneficial for most workloads, shows documented performance degradation in database scenarios.

always: Aggressively allocates all possible memory as huge pages
madvise: Only uses huge pages when explicitly requested via madvise()
never: Completely disables THP allocation

Database workloads frequently experience latency spikes with THP due to:
- Memory defragmentation overhead
- NUMA allocation issues
- Unexpected page faults

However, some specialized storage engines like TokuDB actually require THP disabled, making never mandatory in these cases.

The madvise approach provides the best of both worlds:

# Example of madvise usage in C
void *ptr = malloc(LARGE_MEMORY_CHUNK);
madvise(ptr, LARGE_MEMORY_CHUNK, MADV_HUGEPAGE);

This allows:
1. Web servers to benefit from THP for static content
2. Databases to avoid THP overhead
3. Specialized apps to explicitly request THP when needed

Permanent THP setting (CentOS 7):

# /etc/default/grub
GRUB_CMDLINE_LINUX="... transparent_hugepage=madvise"

# Apply changes
grub2-mkconfig -o /boot/grub2/grub.cfg

Runtime check:

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Benchmarks show:
- Web serving: 5-15% improvement with always
- MySQL OLTP: 10-20% regression with always
- Mixed workloads: madvise provides optimal balance

Consider never when:
- Running TokuDB or similar engines
- Experiencing unexplained latency spikes
- Using memory-constrained containers
- Working with legacy applications