numa节点_从一个案例看关闭NUMA的必要性

上星期，一个制造业的网友让我帮助分析一下一个系统性能问题。这个系统总是在某些时候突然出现卡顿，时间持续1-2分钟。可能对于大多数OLTP系统来说，一两分钟的卡顿或者略慢一点都是没有太大风险的。对于银行来说，可能也就是ATM机上取款的时候稍微慢了1-2秒钟；对于运营商来说可能充值的时候慢了一分钟才到账。虽然这些都会让客户不爽，但是也耽误不了太大的事情。不过这件事放到制造业的智能工厂就不一样了。老白2018年曾经参观过一个广东的智能车间。大量的工业机器人替代了传统的工人，原本3000工人的车间现在只需要13个管理人员就能玩得转了，管理这个智能车间的核心数据库运行在一台Oracle exadata一体机上。当时我就问客户，为啥要下血本买这么好的数据库一体机。客户说，如果一条指令无法在10秒钟内下发到这3000个机械臂上，良品率就会下降，所以必须确保整个管理系统的性能。

回到这个案例，这个客户近期遇到了多次系统卡顿的情况，经过分析发现卡顿的时候的主要等待事件是Log file sync，于是设置了_use_adaptive_log_file_sync=false。不过关闭了自适应日志同步功能后，问题并未好转，还是经常会出现卡顿。老白首先看了卡顿期间的ASH报告

前台进程中出现了log file sync等待， 这五分钟里的平均等待Log file sync的会话有9.55个，确实比出