mysql如何排查虚拟内存swap使用过高问题_调整innodb_flush_method与swappiness
MySQL卡但CPU低时，大概率是SWAP导致：先用vmstat 1查si/so是否持续大于0，再结合free -h确认SwapUsed上涨；需设innodb_flush_method=O_DIRECT、swappiness=1、memlock无限并启用innodb_numa_interlea ve。
MySQL卡但CPU很低，先看 vmstat 1 里的 si 和 so
遇到MySQL响应慢如蜗牛，而mysqld进程的CPU使用率却只有个位数时，别急着去翻慢查询日志或者怀疑索引和锁。这时候，十有八九是SWAP（虚拟内存交换）在背后捣鬼。典型的症状是，连SELECT 1这样的简单查询都可能超时，连接数不断堆积，慢查询日志里塞满了“Waiting for table flush”的记录。
怎么快速确认？打开终端，运行vmstat 1。关键要看si（swap-in，每秒从磁盘交换到内存的千字节数）和so（swap-out，每秒从内存交换到磁盘的千字节数）这两列。如果它们持续大于0，而不是偶尔跳动，那就基本坐实了内存换入换出是性能毛刺的元凶。再配合free -h命令，观察SwapUsed是否在持续上涨，就能彻底锁定问题。
这里有个常见的误区：看到used内存很高就紧张。其实，内存被使用是正常的。真正的危险信号是a vailable（可用内存）持续低于1GB，同时swpd（已使用的交换区大小）还在不断增长。
innodb_flush_method=O_DIRECT 要配对生效，不能只改一半
很多DBA知道设置innodb_flush_method=O_DIRECT可以让InnoDB数据文件绕过操作系统的页缓存（page cache），从而减少内存竞争。但配置后效果不明显，甚至问题依旧？这很可能是因为只做了一半。
这个参数只作用于InnoDB的数据文件（.ibd文件），而重做日志（redo log）默认仍然会经过OS cache。这就导致InnoDB的缓冲池（buffer pool）和日志缓冲（log buffer）在内存层面形成了“内耗”，尤其是在写入密集的场景下，会加剧页回收（page reclaim）的压力，间接提高了系统触发SWAP的倾向。
要让它真正生效，得确保以下几点：
- 在
my.cnf配置文件的[mysqld]段中，明确写上innodb_flush_method=O_DIRECT。 - 注意不要和
O_DSYNC混用，后者并不绕过缓存，性能通常更差。 - 启用
O_DIRECT后，InnoDB缓冲池会直接占用物理内存，占用会更“实在”。如果之前把innodb_buffer_pool_size设到了物理内存的80%，现在可能需要下调到70%或更低，否则MySQL服务可能无法启动。 - 最后，别忘了验证：启动MySQL后，执行
SHOW VARIABLES LIKE 'innodb_flush_method';，确保输出是O_DIRECT，而不是空值或async_unbuffered。
swappiness=1 是减缓，memlock 才是根治
将/proc/sys/vm/swappiness设置为1（甚至0），是常见的优化建议，但这只是降低了内核主动进行内存交换的“倾向性”。它并不能给MySQL进程穿上“金钟罩”——一旦系统内存严重不足或OOM killer被触发，mysqld进程的页面依然可能被换出到SWAP。
真正能让MySQL进程免疫SWAP的，是内存锁（memlock）。这相当于告诉操作系统：“这部分内存必须常驻物理内存，不许动。”配置步骤如下：
- 编辑
/etc/security/limits.conf文件，为运行MySQL的用户（通常是mysql）添加两行配置：mysql soft memlock unlimited mysql hard memlock unlimited
- 在
my.cnf的[mysqld]段中，增加一行：innodb_use_sys_malloc=0（如果使用了jemalloc等替代的内存分配器，这一步至关重要）。 - 必须确保MySQL是以root用户启动，或者启动用户拥有相应的权限，否则
memlock配置不会生效。使用systemd管理服务时，需检查User=mysql是否与limits.conf中配置的用户一致。 - 配置后如果启动失败，并报错
Cannot allocate memory，首先检查innodb_buffer_pool_size是否设置得过大，超过了物理内存的70%。 - 如果一切配置妥当但问题仍在，可以立即检查进程的能力位：
cat /proc/`pidof mysqld`/status | grep -i "cap"，确认输出中包含cap_ipc_lock，这表示内存锁能力已生效。
NUMA 架构下不配 innodb_numa_interlea ve，memlock 可能白开
在多路CPU服务器（尤其是Intel Xeon平台搭配CentOS/RHEL系统）上，还有一个隐藏的“坑”：NUMA（非统一内存访问）架构。如果MySQL启动时没有指定正确的NUMA策略，即使配置了memlock，锁定的内存也可能全部集中在某一个NUMA节点（node）上。这会导致该节点内存迅速耗尽，而其他节点的内存却大量空闲。操作系统感知到“局部内存不足”，依然会将部分内存页换出到SWAP，之前的优化努力就白费了。
解决这个问题很简单：对于MySQL 5.6.27及以上版本，直接在my.cnf中设置innodb_numa_interlea ve=ON即可。对于更老的版本，则需要在启动脚本中，使用numactl --interlea ve=all命令来包裹mysqld_safe启动命令。
可以这样理解：memlock是给汽车装上了防爆胎，而innodb_numa_interlea ve则是确保四个轮胎气压均衡。缺了后者，车子看着配置齐全，一上高速（高负载）就可能出问题。
相关攻略
之前遇到一个典型的性能问题：一个订单查询接口，平均响应时间达到了3秒，P99响应时间甚至超过10秒。用户投诉不断，老板也天天催着解决。排查后发现，一张500万数据的订单表，查询条件是WHERE user_id = ? AND status = ? AND create_time > ?，但表上只有一
今天处理了一个典型的主从复制中断案例，SQL线程报错1032。遇到这种情况，先别急着跳过事务——这很可能是MySQL 8 0并行复制与无主键表共同埋下的一个“暗雷”。下面咱们就顺着这条线索，从Binlog机制到Hash冲突，把这个问题彻底讲清楚。 主从复制异常是运维和面试中的常客，而触发异常的场景五
在维护MySQL 8 0主从复制架构时，你是否也曾在从库的错误日志里，被两条反复横跳的警告信息刷屏？没错，就是那个“Invalid replication timestamps”和紧随其后的“returned to normal values”。这不仅仅是日志噪音，更是一个明确的信号：你的服务器时间
相信不少DBA同行都遇到过这种令人头疼的场景：一个预计耗时数小时的MySQL大表结构变更操作，你熟练地输入nohup mysql -e ALTER TABLE huge_table ENGINE=InnoDB; &，然后安心地关闭了终端窗口。然而几小时后回来检查，却发现任务早已无声无息地中止，日
今天，我们通过一个在线旅游平台酒店搜索的实战案例，深入解析MySQL数据同步到Elasticsearch的四种主流技术方案。透彻理解这些方案，无论是应对技术面试还是处理实际开发中的架构选型，都能让你游刃有余，有效规避常见的技术陷阱。 许多开发者都曾面临类似的困境：面试中被问到如何保障MySQL与ES
热门专题
热门推荐
制作PPT用什么软件好？2024年五大主流工具深度评测 无论是职场汇报、学术答辩还是项目路演，一份专业且吸引人的PPT演示文稿都至关重要。面对众多制作工具，如何选择最适合自己的那一款？本文将对五款主流的PPT软件进行全方位对比分析，从功能、协作、设计到易用性，助您根据核心需求做出最佳决策，高效打造令
今日A股市场整体走势偏弱，朗玛信息（股票代码300288）股价同步调整，截至收盘下跌3 16%，全天成交额4783 73万元，换手率为1 77%，公司总市值约为35 21亿元。股价的短期波动，引发了投资者对其核心投资逻辑与未来潜在机会的深入探讨。 异动深度解析：AI医疗战略的机遇与挑战 朗玛信息是市
《超级蠕虫大战圣诞老人2》是一款休闲益智游戏，攻略涵盖基本操作、关卡解锁与道具使用。玩家需掌握战斗策略与技能升级，熟悉敌人特性和环境机制。合理运用道具并完成隐藏任务可获取奖励，多人模式注重策略博弈。建议多练习并参与社区交流，同时注意游戏时长以保护视力。
在Kimi里搜索“2026年北京积分落户政策细则”，如果跳出来的总是房产中介的软文、培训机构的广告或者各种自媒体猜测，那说明默认的联网检索没有经过过滤。想要获得干净、权威的结果，必须主动使用结构化的提示词进行限定。 用结构化提示词锁定权威信源 这一步是关键，直接决定了你看到的信息是来自官方发布渠道，
为避免代码丢失，Qoder编辑器需手动开启自动保存功能。全局设置中可开启开关并选择触发条件，如按时间间隔或窗口失去焦点时保存。还可为特定项目单独配置，覆盖全局设置。若功能失效，需检查文件位置是否只读、用户权限是否足够，并避免直接编辑受保护的系统文件。