记一次数据库服务器优化过程

---

有项任务需要把大量的数据从一台服务器重新导入到另外一台服务器，于是开始这次折腾的过程。

---

首先是数据备份，因为服务器不在同一个地方，使用的数据库也不一样，那只有自己写个脚本，先在源服务器上把数据形成sql文件。最终形成1400多个文件，打包压缩成60多个文件。顺便说下，开12个进程干这个打包压缩，还跑了5个多小时才跑完，这个时候还不知道为啥这么慢。还好压缩率还算可以，300多G的sql文件用tar.gz格式压缩之后，只有30多G左右。

拷到新服务器上时没注意，挂着拷贝就干其他事情去了。然后解压缩时就发现有点不对劲了。因为有60多个压缩文件，想快点解压完，就开多个终端解压，每个终端解压其中的几个文件。开第一个终端的时候还能看到解压完成一个文件的时间算是可以接受，越开到后面发现每个终端的解压速度都慢下来了。网上找了会资料，不得要领。不过当时都快下班了，第二天又是周末，就没管它，让它跑着在。想着反正两天时间总能解压完成吧。

周一上班发现果然解压完成，就开始捣鼓入库。也是老方法，开多个进程入库，每个进程入库不同的sql文件。这下好慢啊，2G文件开9个进程都要15分钟左右才入库完成，算了下入库完成需要2天时间，这有点太长啊，又开始折腾，看看到底为啥这么慢。

首先连到数据库看看入库进程，show processlist肉眼观察，每个sql语句执行都需要7 、8秒左右，而sql语句是自己组帧的，一个sql语句只有入库1440条数据，按说不应该这么慢的。这个时候怀疑是sql语句组帧有问题，如果是的话那就没办法优化了，只能等它慢慢入库完成了。

再在自己的电脑上开虚拟机，建好和服务器一样的数据库和表，用同样的脚本测试入库时间，在虚拟机里入库很快就完成了，2G文件入库大概用时3分钟左右。这应该可以排除是sql语句的问题，入库慢应该是由其他原因导致的。

又在网上找来找去，找到个命令iotop，可以看到硬盘的读写速度。那就试下吧。果然，iotop看到在服务器上硬盘写速度只有10M左右，而且mysql入库进程是占用排行最高的，每个进程也只有1000K左右，怪不得那么慢啊。而在自己的电脑上虚拟机里面iotop看硬盘写入速度可以达到100M左右，性能差了10倍。

又有个命令是iostat -x 1,每秒一次查看io状态，看的也比较清楚了，服务器上的%util基本都在99以上，网上说这是瓶颈在硬盘啊。

这个时候开始怀疑是服务器上安装操作系统步骤出问题了，一度想再找个一样的服务器重装下系统试试。又在网上漫无目的的找，硬盘写入慢的原因。后来突然想到，这台服务器上安装了raid卡，是不是因为raid卡配置的问题导致啊，不知道是用的什么raid卡。又乱找一通，

cat /proc/scsi/scsi 
cat /proc/mdstat
/usr/dpt/raidutil -L all  
dmesg |grep -i raid

没有接触过嘛，出来的信息大部分看不懂。最后有位大佬在文章中武断的指出，99%服务器，基本都会是LSI的raid卡，都可以通过megaraid的工具进行管理，并给出了配置软件下载地址。那我就试试看吧。

下好了MegaCli-8.07.14-1.noarch.rpm，安装上，执行

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL

果然出来一串信息，raid卡确实是LSI的。接下来又用MegaCli64关键词找使用方法啊等等，最后找到个和我遇到的情况差不多的，说是raid卡配置不使用raid上的缓存时，对硬盘的写入速度影响巨大的，还给出了具体的解决办法。

那就再试试，照抄命令把raid配置成使用写缓存，回头看mysql入库速度，果然快多了，和在测试电脑上的虚拟机速度差不多。虽然说raid卡使用缓存，在掉电时会有丢失已写入缓存但未写入硬盘的数据的可能，但是性能上可能差了10倍左右。可能还有进一步优化的空间，不过这个速度现在看来应该已经够了。

以下几篇文章比较有帮助：
http://wap.sciencenet.cn/blog-3334560-1149201.html
https://blog.csdn.net/smileteo/article/details/40152271
https://blog.csdn.net/shengyyyyyy/article/details/78951747
https://blog.csdn.net/weixin_48356255/article/details/108581870