postgres数据库大批量单表导入数据引发性能故障

因公司经营管理策略原因，我们地区部门还是以开发外包和产品服务为主，对测试外包服务销售工作要求占比不高，而测试部门本来有四五个性能测试人员，加上老员工都比较积极做事在测试团队建设管理上不用花费太多精力。估计因为我对数据库、tomcat、linux性能这块了解比较深以前相关的测试环境都是我搭建部署，一直都很稳定，所以公司让我帮忙兼职做公司产品技术运维支持工作，因此我大部分时间都是在做软件产品基础设施搭建研究MYSQL\\PG\\TOMCAT\\Centos等优化配置和数据安全备份方法，作为初学者很多未知领域需要探索学习研究。

这段时间的运维感触是，做为一名技术运维人员需要一个拥有“耐心、静心、探索心、敬业心”，不然心情一爽rm -rf ，后果不敢设想，或者部署配置时日志格式、清理机制、数据存放路径、备份方式没弄好也会导致系统不稳定等问题。

当然有时客户自己也有专职运维人员，但是往往有些技术运维人员，对数据安全等敏感性没那么高，会误操作导致双方一下子手忙脚乱，例如系统缓慢就restart tomcat 或者kill pid 来应急，但是最终的效果是数据不一致或者丢失等现象。例如下面这个问题就是因为客户一下子插入700W笔数据，但是事先没跟我方项目人员沟通导致系统无法正常运行问题。

下午临近下班时，客户突然打电话给我方项目经理说，系统运行很慢，PG数据库服务器卡死，输入top 都要等五六分钟才能响应，但是CPU使用率不高，如下图：

这是看到的数据库服务器CPU使用率确实不高，通过free命令

看到内存将耗尽

通过top看到系统调用KSWAPd0，并运行占用时间比较长，于是我让项目经理打电话问客户说在操作什么，是不是在倒数据？

一开始客户说没做任何操作，但是持续监控一段时间查看了内存使用free一直很低，而且kswapd0进程一直被调度使用，

kswapd0进程的作用：它是虚拟内存管理中，负责换页的，操作系统每过一定时间就会唤醒kswapd ，看看内存是否紧张，如果不紧张，则睡眠，在 kswapd 中，有2 个阀值，pages_hige 和 pages_low，当空闲内存页的数量低于 pages_low 的时候，kswapd进程就会扫描内存并且每次释放出32 个free pages，直到 free page 的数量到达pages_high，由于内存实在不够用了, 于是就死掉了.

这说明一点客户在做大量数据插入操作，导致内存不足，引发系统卡顿，但是客户那边说没做任何操作，我们也怀疑是不是被安全攻击等，作为初级运维人员思维确实比较混乱，没有那么多经验，当时应急方式先重启数据库后，内存立马释放正常，但是没过几分钟又重现问题，这时我们双方打电话沟通了下，原来客户是有在对一张已有百万级数据量的表做迁移插入操作，插入数据也是百万级，知道原因后，也知道对应的表后，查看了该表发现客户在做操作时没有对该表的索引等先删除在插入操作导致系统就慢慢的死掉了。----这也是项目运维管理规范问题导致的。

PG数据库快速INSERT大量数据

临时删除index

有时候我们在备份和导入大量数据时，这个时候可以先把index删除掉。导入在建index。