总体影响与量级
在 CentOS 上，SELinux 会引入一定的访问控制开销，但在多数通用工作负载下通常不明显。早期 Phoronix 在 Fedora 11 的横向测试显示，开启 SELinux 仅导致少数场景约 5% 的性能下降；实际经验也表明，开销更多体现在 磁盘 I/O 与 数据库 等频繁访问资源的场景，常见范围为 5%–10%。对一般桌面与常规开发环境，默认策略通常已足够顺手，不会对体验造成显著影响。
影响来源
- 额外的 CPU 开销：每次访问文件、进程间通信、网络端口等，内核需进行 MAC 检查（如 avc_check_permission），在高并发与频繁系统调用路径上更明显。
- 磁盘 I/O 延迟：涉及大量文件创建/访问/重命名时，标签检查与策略匹配会增加少量延迟。
- 内存占用：用于存储 安全上下文 与 策略规则 的元数据，通常增量较小且可接受。
- 策略与日志因素：策略过“宽”或应用频繁触发 AVC 拒绝，会导致更多检查与日志写入，放大开销。
以上开销与是否命中策略、策略粒度、应用访问模式密切相关。
降低开销的实用做法
- 优先使用 targeted 策略：保持 SELINUXTYPE=targeted，仅保护关键服务，避免 strict 的全系统强制检查带来的额外成本。
- 用 Permissive 做 A/B 验证：执行 setenforce 0 切换到宽容模式（仅记录不拦截），对比性能差异；若性能明显回升，再精调策略而非直接禁用。
- 精简与定制策略：
- 用 semanage/ausearch/audit2allow 分析并生成最小必要策略，减少不必要的拒绝与检查。
- 关闭不使用的 SELinux Booleans（如 setsebool -P httpd_can_network_connect_db off），降低策略检查面。
- 只在必要时才禁用：将 SELINUX=disabled 视为最后手段，会带来显著安全降级；确需禁用时，记得修改 /etc/selinux/config 并重启。
- 定位热点：用 perf/flamegraph 观察是否 avc_check_permission 等路径占比过高，针对性优化策略或访问路径。
上述方法能在不明显牺牲安全性的前提下，尽量压低 SELinux 带来的开销。
何时考虑关闭或放宽
- 极端低延迟/高并发场景：如超低延迟交易、部分高性能计算/存储路径，确有需要时可在评估风险后临时放宽或关闭。
- 兼容性紧急排障：应用与现有策略冲突且短期难以收敛时，可先切 Permissive 恢复业务，再并行完善策略。
- 安全边界已由其他机制覆盖：例如容器/K8s 以命名空间与容器运行时为主、网络侧有严格微分段与防火墙策略时，可在充分评估后决定是否放宽主机层 SELinux。
无论选择哪种方式，都应先建立基线、控制变更窗口、并保留回滚路径。