SELinux性能开销通常为1%–5%，取决于策略配置、工作负载与硬件；AVC检查、宽松策略及频繁日志记录是主因，文件服务器延迟升2%–3%，数据库TPS降1%–4%，容器启动增50–200ms。
SELinux 本身确实会带来一定性能开销，但实际影响程度远低于多数人预期，关键取决于策略配置、工作负载类型和硬件环境。在合理配置下，多数生产场景中 CPU 和 I/O 延迟增加通常在 1%–5% 范围内，而非数量级下降。
策略粒度与 AVC 日志频率是主要开销来源
SELinux 的访问控制决策（AVC）由内核安全模块实时执行，每次系统调用涉及资源访问（如 open()、connect()、mmap()）时都可能触发策略检查。真正影响性能的不是“开启 SELinux”，而是：
- 使用过于宽松或未优化的策略（如 targeted 策略中大量 use_boolean 规则动态计算）
- 频繁触发 AVC 拒绝并写入日志（auditd 记录 + 内核 AVC 缓存查找 + 用户态 audit 守护进程处理）
- 启用 permissive 模式但未关闭 audit 日志——此时仍做完整检查，仅不拒绝，日志量反而更大
典型场景下的实测差异参考
基于 Red Hat 和社区公开基准测试（如 dbench、fio、pgbench、HTTP 并发压测），常见结论如下：
- 文件服务器（NFS/Samba）：元数据操作（stat、ls）延迟上升约 2%–3%，大文件顺序读写基本无差异
- 数据库（PostgreSQL/MySQL）：TPS 下降约 1%–4%，高并发小事务场景中锁竞争与 AVC 检查叠加可能略放大延迟
- 容器运行时（podman/docker with SELinux enabled）：容器启动时间增加 50–200ms（主要来自标签设置与上下文验证），运行时请求处理影响可忽略
- Web 服务（nginx/Apache）：静态文件服务吞吐变化
降低开销的实用优化方式
无需关闭 SELinux，即可显著收窄性能差距：
- 禁用冗余审计日志：在 /etc/audit/rules.d/ 中移除或注释掉 -a always,exit -F arch=b64 -S open* 类规则；或设 audit=0 内核参数（仅调试用）
- 合并布尔值规则：用 semanage boolean -m --on/off 批量调整，避免运行时反复查询 /sys/fs/selinux/booleans/
- 使用自定义最小策略模块：用 sepolicy generate 或 audit2allow -M 构建仅覆盖必要域的策略，替代全量 targeted 策略
- 确保文件系统支持扩展属性（xattr）且已挂载 with xattr：避免每次访问都 fallback 到默认上下文查找
何时需要特别关注 SELinux 性能
以下情况建议专项评估：
- 高频小文件随机 I/O 场景（如编译构建、CI 临时目录操作）
- 低延迟要求服务（金融行情网关、实时音视频转发）中 SELinux 与 seccomp/bpf 同时启用
- 容器化环境中每个 Pod 都分配独立 MCS 标签（s0:c1,c2 形式），导致内核策略缓存命中率下降
- 使用非标准 LSM（如 SELinux + Yama + LoadPin 共存），策略交互复杂度上升
SELinux 的性能代价本质是安全抽象的必然成本，不是缺陷。它带来的隔离强度、细粒度权限控制和漏洞缓解能力，在多数关键业务中远超那几个百分点的开销。真正的问题往往出在策略滥用或日志过载，而不是机制本身。
