在Linux下给Kingbase8做性能调优，“用力过猛”比“不作为”更危险。结合你之前的优化实践，以下是几个极易踩坑的“伪优化”：
1. 内存分配：把系统“饿死”
误区：把
"shared_buffers" 设得无限大（如物理内存的80%），认为缓存越大越好。
真相：Linux内核需要Page Cache来缓存文件系统元数据。如果数据库吃光了内存，内核被迫频繁回收Page Cache，会导致I/O抖动（明明有SSD，查询却变慢）。
正解：
"shared_buffers" 通常不超过物理内存的 25%-40%，必须给操作系统留足“呼吸空间”。
2. 调度算法：SSD强行用CFQ
误区：沿用机械硬盘时代的
"CFQ"（完全公平队列）调度器。
真相：CFQ是为机械盘寻道优化的，SSD没有磁头，用CFQ会引入不必要的排队延迟。
正解：SSD必须用
"noop"（无操作）或
"deadline"。检查命令：
"cat /sys/block/sdX/queue/scheduler"。
3. 大页内存（HugePages）：盲目开启
误区：看到内存大就无脑开HugePages，认为能减少TLB Miss。
真相：HugePages是不可交换的。如果配置过多，会导致系统物理内存被“锁死”，其他进程（如备份工具、应用中间件）因申请不到内存而OOM被杀。
正解：仅在
"shared_buffers" > 8GB 且物理内存极度充裕时开启，并精确计算页数（
"(shared_buffers + 2GB) / 2MB"）。
4. 文件系统：滥用
"noatime" 和
"nobarrier"
误区：为了省I/O，在所有磁盘上都加
"nobarrier"。
真相：
"nobarrier" 会禁用写入屏障。如果机器断电或崩溃，WAL日志可能损坏，导致数据库无法启动（数据丢失风险）。
正解：
-
"noatime"：可以加，确实能提升SELECT性能。
-
"nobarrier"：严禁在普通服务器（无UPS/电池缓存）上使用。仅在有电池保护的RAID卡或企业级全闪存阵列上才考虑。
5. 网络参数：无脑放大缓冲区
误区：把
"net.core.rmem_max" 等参数设成几个GB，以为能加速网络传输。
真相：Kingbase是短连接或长连接池，单次传输数据量不大。过大的缓冲区会浪费内存，并增加TCP重传的RTO（超时）时间，反而降低故障恢复速度。
正解：保持默认或微调（如16MB-64MB），无需追求极致。
6. 最致命的“静默杀手”：透明大页（THP）
误区：不关心
"/sys/kernel/mm/transparent_hugepage/enabled" 的状态。
真相：Linux默认开启的透明大页（THP） 会与Kingbase的内存分配器（特别是高版本）冲突，导致内存膨胀和CPU使用率飙升（
"kswapd"进程疯狂工作）。
正解：必须关闭。在
"/etc/rc.local" 中加入：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
7. 连接数：把
"max_connections" 当饭吃
误区：看到“连接池满”报错，就直接把数据库的
"max_connections" 从1000改到5000。
真相：每个连接都是一个进程（PostgreSQL架构）。连接数每增加1000，内存开销（work_mem * 连接数）和锁竞争呈指数级增长。系统会因上下文切换过多而卡死。
正解：严禁调高。必须使用连接池（如PgBouncer、应用层连接池）来复用连接，数据库端保持低值（如300-800）。
8. 检查点（Checkpoint）过于激进
误区：把
"checkpoint_completion_target" 设成 0.1，以为能快速刷脏。
真相：这会导致检查点期间I/O爆发，正常业务查询被“卡住”，产生RT（响应时间）毛刺。
正解：设高（0.7-0.9），让脏页在后台平滑写入，避免业务高峰期的写入堵塞。
