Ubuntu服务器的磁盘I/O性能瓶颈，往往直接表现为数据库写入慢、网站加载卡顿、甚至服务无响应。要解决这个问题，最直接有效的手段就是调整磁盘I/O调度器。现代Linux内核支持多种I/O调度算法，但在Ubuntu 20.04及之后的版本中，默认启用的通常是多队列（blk-mq）架构下的调度器。你可以通过以下命令查看当前磁盘使用的调度器：

cat /sys/block/sda/queue/scheduler

输出结果中括号括起来的就是当前生效的调度器。对于NVMe固态硬盘，通常显示为[none]，因为内核认为这类设备无需复杂的软件调度，直接将请求交给硬件处理效率最高。对于传统的SATA/SAS机械硬盘或低端固态硬盘，你可能会看到mq-deadline或bfq。如果你的服务器主要运行数据库或高并发Web应用，并且使用的是固态硬盘，保持none是最佳选择。如果使用的是机械硬盘，且需要兼顾系统响应速度和吞吐量，可以将调度器修改为mq-deadline。临时修改的命令如下：

echo mq-deadline > /sys/block/sda/queue/scheduler

要使配置永久生效，需要修改GRUB引导参数。编辑/etc/default/grub文件，在GRUB_CMDLINE_LINUX行添加elevator=mq-deadline，然后执行update-grub并重启系统。但仅仅切换调度器还不够，对于机械硬盘，调整队列深度和预读大小能带来显著的性能提升。nr_requests参数控制着I/O调度队列的最大请求数，适当降低这个值可以减少I/O延迟，提升交互式应用的响应速度。你可以通过以下命令将其设置为128或64：

echo 64 > /sys/block/sda/queue/nr_requests

read_ahead_kb参数定义了预读的数据量，对于顺序读取频繁的场景，比如日志分析或流媒体服务，增大这个值可以大幅提升吞吐量。通常建议设置为256或512，甚至1024，具体取决于你的工作负载。通过blockdev命令可以查看和设置：

blockdev --getra /dev/sda
blockdev --setra 512 /dev/sda

除了调度器和队列参数，文件系统的挂载选项同样深刻影响着磁盘性能。在/etc/fstab中，为存放数据库文件的ext4或xfs分区添加noatime和nodiratime挂载选项，可以禁止更新文件和目录的访问时间戳，从而减少不必要的写操作，这对固态硬盘的寿命和性能都有好处。一个典型的优化后的挂载条目如下：

UUID=xxx /data ext4 defaults,noatime,nodiratime 0 2

对于需要极高写入性能的场景，比如消息队列或高频交易日志，可以考虑将写屏障（barrier）禁用，但前提是服务器配备了可靠的UPS电源或备用电池，否则断电可能导致文件系统损坏。这需要在挂载选项中添加nobarrier，风险较高，务必谨慎评估。

日志轮转的安全保留策略

磁盘I/O优化解决了性能问题，但磁盘空间的管理同样致命。运维中最常见的磁盘爆满原因之一就是日志文件无限制增长。logrotate是Ubuntu下标准的日志轮转工具，但默认配置往往过于简单，无法满足安全审计和合规性要求。一个健壮的日志保留策略必须同时考虑轮转频率、保留份数、压缩存储和安全权限。我们来看一个针对关键服务（如Nginx访问日志）的生产级配置示例，通常放置在/etc/logrotate.d/目录下：

/var/log/nginx/*.log {
    daily
    missingok
    rotate 90
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

这个配置的含义非常明确：每天轮转一次，保留90天的历史日志，超过90天的旧日志会被彻底删除。compress指令会对轮转后的日志进行gzip压缩，节省大量磁盘空间。delaycompress配合compress使用，意味着最近一次轮转的日志不会被压缩，这方便了需要立即查看昨天日志的场景。create 640 root adm则强制新创建的日志文件权限为640，属主为root，属组为adm，这比默认的600或644更符合安全最佳实践，既允许日志分析工具通过adm组读取，又防止了普通用户的窥探。sharedscripts确保postrotate中的重载信号只执行一次，而不是每个匹配的日志文件都触发一次，这对于Nginx这类多日志文件的服务至关重要。

应对日志轮转失效与安全加固

很多运维人员遇到过logrotate配置正确但就是不生效的情况。排查这类问题的第一步是手动调试运行，使用-d参数进行预演，-f参数强制执行：

logrotate -d /etc/logrotate.d/nginx
logrotate -f /etc/logrotate.d/nginx

如果强制轮转成功，但定时任务没有自动执行，需要检查系统的cron或systemd timer配置。在较新的Ubuntu发行版中，logrotate由systemd timer触发，你可以通过systemctl status logrotate.timer查看定时器的状态和下次触发时间。另一个常见陷阱是日志文件的权限或父目录权限导致logrotate无法写入或重命名文件。确保运行logrotate的用户（通常是root）对日志目录有写权限，并且目录没有设置不可变属性。

从安全保留的角度看，仅仅轮转和压缩是不够的。对于需要满足等保或GDPR合规的场景，日志的防篡改和远程备份是必须的。一个轻量级的方案是利用rsync将压缩后的日志实时同步到专用的日志归档服务器，并在归档服务器上启用文件完整性监控工具如AIDE。同步命令可以写入postrotate脚本中，确保每次轮转完成后立即触发同步。更严格的策略是使用auditd审计框架记录所有对日志文件的访问和修改，并将审计日志本身也纳入轮转和远程备份的范围。你可以在/etc/audit/rules.d/目录下添加规则，监控关键日志目录：

-w /var/log/nginx/ -p wa -k nginx_logs

这条规则会记录所有对/var/log/nginx/目录下文件的写入和属性修改操作，标签为nginx_logs，方便后续通过ausearch命令检索。结合远程syslog或集中化日志平台，将审计事件实时外发，即使服务器被攻破，攻击者也无法抹除已经传输到外部的日志记录。

磁盘空间告警与自动化清理的深度结合

即使有了完善的轮转策略，突发的流量洪峰或应用错误仍可能在短时间内写满磁盘。因此，必须建立磁盘空间监控和自动化应急清理机制。在Ubuntu下，你可以编写一个简单的脚本，通过df命令检查磁盘使用率，当超过阈值（如90%）时，除了发送告警邮件外，还可以主动清理非关键的缓存文件或临时文件。但要注意，自动化清理必须严格限定范围，避免误删重要数据。一个更安全的做法是结合logrotate的maxsize参数，它允许你设置日志文件的最大体积，一旦超过这个大小，无论是否到达轮转周期，都会触发轮转。例如：

/var/log/app/*.log {
    maxsize 100M
    rotate 10
    compress
    missingok
    notifempty
}

这样配置后，即使日志增长速度异常，单个文件也不会超过100MB，有效防止了磁盘被单个巨型日志文件撑爆。对于数据库的慢查询日志或错误日志，这种基于大小的轮转策略比基于时间的轮转更加可靠。

最后，不要忽视内核日志和系统日志本身的安全保留。Ubuntu默认使用rsyslog或systemd-journald管理系统日志。对于rsyslog，你可以在/etc/rsyslog.d/50-default.conf中为不同facility的日志指定不同的保留策略，并配合logrotate进行轮转。而systemd-journald则通过/etc/systemd/journald.conf文件控制，关键参数包括SystemMaxUse和SystemMaxFileSize，它们直接限制了日志占用的磁盘空间上限和单个日志文件的大小。设置一个合理的上限，例如SystemMaxUse=2G，可以防止journal日志无限膨胀。

通过将磁盘I/O调度优化与严谨的日志轮转安全保留策略相结合，你不仅能让Ubuntu服务器跑得更快，还能确保它在长期运行中保持稳定、合规且易于审计。这种底层的基础设施调优，正是资深运维工程师的价值所在。