ssd上不能用deadline调度器，因其无机械寻道，使用deadline会引入多余排序开销，导致i/o吞吐下降15–30%；linux内核5.0起默认禁用nvme的deadline，但sata ssd仍可能被误配。
SSD上为什么不能用deadline调度器
SSD没有机械寻道，用deadline反而引入多余排序开销，实际I/O吞吐下降15–30%。Linux内核从5.0起默认对NVMe设备禁用deadline，但SATA SSD仍可能被误配。
查当前调度器：cat /sys/block/sdX/queue/scheduler（把sdX换成你的缓存盘，如sdb）
临时切到kyber（推荐）或none（旧内核用noop）：echo kyber > /sys/block/sdX/queue/scheduler
永久生效需写入/etc/default/grub的GRUB_CMDLINE_LINUX里加elevator=kyber，再update-grub && reboot
HDD上设deadline却还是卡，问题可能不在调度器
deadline只优化请求顺序，不减少小文件数量。Composer的cache/vcs/目录里一个Git裸仓库就含数万小文件，stat()和open()调用本身就会压垮HDD IOPS。
- 先禁用vcs缓存：
composer config -g cache-vcs false - 验证是否生效：
ls ~/.composer/cache/vcs/应为空 - 若仍卡，检查
df -i——inode耗尽比I/O慢更致命
挂载方式比调度器影响大十倍
Docker里-v $(pwd)/vendor:/app/vendor这种宿主机挂载，会让每次file_put_contents()都穿过FUSE或VirtioFS桥接层，延迟从0.1ms涨到10ms+。调度器再优也救不回来。
正确做法：
- 开发时用命名卷：
docker run -v composer-vendor:/app/vendor php:8.3 - CI中确保
composer install在容器内执行，而非宿主机生成后拷贝 - 缓存路径必须落在本地SSD或
/dev/shm，别设成/tmp——某些systemd发行版会定时清空
WSL2用户特别注意/mnt/c路径
WSL2挂载Windows分区走的是9P协议，/mnt/c/Users/xxx/project下跑composer install，实测比/home/xxx/project慢4倍以上，且Extracting archive阶段频繁卡住。
必须做两件事：
-
composer config -g cache-dir "/home/$USER/.composer-cache"（确保路径在Linux原生文件系统） - 项目根目录移到
~/projects/，绝不要放在/mnt/c/下 - 如果要用Windows PHP，确认
vendor/不在OneDrive、BitLocker加密卷或NTFS压缩属性开启的目录里
