Automated, safe, and flexible script to optimize disk, memory, and network parameters on Linux servers. Features backup/restore, logging, performance testing, and multiple optimization levels.
⚠️ WARNING: THIS SCRIPT CHANGES CRITICAL SYSTEM FILES AND PARAMETERS!
- Always make a backup before use.
- The script overwrites
/etc/sysctl.conf(backup is created automatically).- Must be run as root and will modify disk, kernel, and network settings.
- Not intended for desktop use or non-expert users.
- Misuse may result in unstable or unbootable systems!
Short answer:
On most modern Linux systems, default parameters prioritize stability and compatibility—not peak performance for demanding workloads.
You may see real improvements if:
- You run database, storage, file or streaming servers with many users or high I/O.
- You operate servers with a lot of RAM and modern SSD or NVMe disks.
- You want to maximize throughput or connection handling for specific applications.
What can change?
- Up to 20–50% higher disk throughput on some workloads (e.g. large file transfers, parallel IO).
- Drastic improvement in handling thousands of simultaneous network connections.
- More efficient use of available RAM for shared memory and disk caching.
When is this not needed?
- For laptops, desktops or small VMs running standard office/web apps, the benefit is usually minor.
- On many cloud/VPS platforms, kernel or disk settings may be locked or have minimal effect.
Summary:
These optimizations are mainly for system administrators and power users running high-demand Linux servers.
- Conservatism: Linux distributions set kernel, VM, and disk parameters to values that avoid edge-case crashes and work on almost all hardware—from old spinning disks to the latest NVMe.
- Safety for all: Default sysctl.conf, disk scheduler, and network buffer settings prevent issues on minimal RAM, virtualized, or embedded systems.
- Diversity: Not all workloads are equal—a database server and a desktop need radically different settings.
- Disk scheduler (e.g.,
noop,deadline,cfq): Determines how Linux orders and prioritizes read/write requests to disks. For SSD/NVMe, simpler schedulers (likenoop) are often much faster than legacy (rotating-disk-friendly) algorithms. - Read-ahead (
read_ahead_kb): Sets how much data Linux reads in advance per I/O request, which can boost performance for large sequential reads. - Queue depth (
nr_requests): Allows more outstanding IO operations in parallel; useful for high-throughput disks. - Memory management (
vm.dirty_ratio,vm.swappiness, etc): Dictates when and how data is written from RAM to disk, and how much RAM is used for caching. - Shared memory/semaphores: Critical for database performance; default values are often too low for modern hardware.
- Network stack tuning: Adjusts TCP buffer sizes and queue lengths for servers handling thousands of simultaneous connections.
- Databases (PostgreSQL, MySQL, Oracle):
Properly tuned shared memory, disk scheduler, and dirty page settings can increase transaction throughput, reduce latency, and prevent bottlenecks under heavy load. - File and storage servers:
Higher queue depths and more aggressive read-ahead allow higher sustained transfer rates, especially over fast networks and storage backends. - Web servers / Proxies:
Tuning TCP stacks and connection queues improves resilience against connection floods and high concurrent loads.
Yes!
- Linux continues to use safe defaults to avoid support headaches across millions of device types.
- Data centers, performance-focused SaaS, cloud workloads, and high-end VMs benefit from manual fine-tuning, especially as hardware (NVMe, huge RAM) outpaces default kernel values.
- Automation matters: This script combines best-practice parameters and automatic hardware detection, making it easy to apply (and revert) advanced tuning safely.
Bottom line:
If your Linux server is doing "serious" work (data, network, high concurrency), manual optimization is often still necessary—and this script makes it safe, repeatable, and reversible.
- Purpose
- What the script does
- Features
- Requirements & Supported Systems
- Installation & Usage
- Flags & Levels
- Examples
- Restore & Backup
- Output & Logging
- Edge Cases & Tips
- Results & Performance
- License
This script aims to maximize I/O performance and optimize kernel, disk, and network parameters for Linux servers with large amounts of RAM and fast disks (e.g., for databases or storage-intensive workloads).
- Backs up system files before any changes
- Dynamically optimizes kernel parameters based on system RAM
- Tunes disk scheduler and read-ahead on all
/dev/sd*disks (skips risky tweaks on VMs) - Tunes network and file system parameters for high concurrency
- Supports multiple optimization levels (safe, aggressive, custom)
- Restore: easy rollback to the last backup
- Logs all actions to
/var/log/linux-disk-optimization.log - Runs performance tests before/after (with
iozoneif installed) - Dry-run mode: see what would be done, without changing anything
- Automatic backup & restore of
/etc/sysctl.conf - Optimization levels: safe, aggressive, custom
- Full change logging
- Performance tests (with
iozoneif available) - Detects virtual machines and skips risky optimizations
- Dry-run mode for safe simulation
- Safety checks (root, dependencies, etc)
- Debian/Ubuntu (tested on kernel 4.x/5.x)
- Physical Linux servers or powerful VMs where disk parameters can be changed
- Must be run as root
- RedHat/CentOS/Fedora (may require manual tweaks)
- macOS, BSD, WSL
- Virtual/cloud servers where blockdev/IO parameters are locked (some cloud providers)
- Desktop systems (may affect usability and stability!)
-
Clone the repo:
git clone https://github.com/Caripson/Linux-disk-optimization.git cd Linux-disk-optimization -
Make the script executable:
chmod +x runme.sh
-
Run the script (as root):
sudo ./runme.sh --level=aggressive
Or do a dry run:
sudo ./runme.sh --dry-run
| Flag | Function |
|---|---|
--level=safe |
Conservative, safe optimization (default) |
--level=aggressive |
Maximal performance (use at your own risk) |
--level=custom |
Manual tuning (requires editing values in the script directly) |
--dry-run |
Only shows what would be changed, makes no changes |
--restore |
Restores the latest backup of /etc/sysctl.conf |
--help |
Show help and usage examples |
Safe optimization:
sudo ./runme.sh --level=safeAggressive optimization (max performance):
sudo ./runme.sh --level=aggressiveShow all planned changes without writing anything:
sudo ./runme.sh --dry-runRestore to the latest backup:
sudo ./runme.sh --restore- Backups of
/etc/sysctl.confare saved with a timestamp in the same directory. - When using
--restore, the script replaces your current sysctl.conf with the latest backup. - Manual restore:
sudo cp /etc/sysctl.conf.bak.YYYY-MM-DD-HHMMSS /etc/sysctl.conf sudo sysctl -p
- All actions are logged to
/var/log/linux-disk-optimization.log. - Log includes errors and warnings.
- Performance test results (
iozone) are saved to/tmp/iozone_test_*.log.
- Virtual machine: The script detects VMs and skips disk parameter tuning (can be forced manually).
- Cloud platforms: Ensure you have permission to change blockdev/sysctl parameters.
- IOzone must be installed manually for benchmarking (
sudo apt-get install iozone3). - Custom sysctl: In "custom" mode, edit parameter values in the script before running.
- Multiple runs: Always make a backup if you are making repeated changes.
- Performance tests (
iozone) run before and after optimization and are saved in/tmp. - Typical improvements may include:
- Higher I/O throughput on large file transfers
- More concurrent connections, improved socket/network performance
MIT License. See LICENSE for details.
Open a GitHub issue for problems, bugs, or suggestions!