不懂硬件,今天经历了raid卡对性能的影响,特记录如下。

一台需要做journal的中控服务器,在压力相当的情况下,比其他服务器的写延迟大很多。

top查看每个cpu的数据,发现部分cpu的wa时间非常大(90%)。iostat -dx 3,发现write rqm虽然也持续较大(经常5、6k,甚至上万),写入流量几十MB/s,但对比相似机型,iowait也不会达到如此高。虽然我们的场景是每条journal(KB-百KB)都需要fsync到磁盘,但也不应该性能这么差。

继续安装iotop命令(需翻墙),sudo执行,发现写入操作都集中在journal threads上(TID是thread id,可以gstack 查看具体是什么线程)。B519E22D-58CD-4E92-8227-89C0BD429C44

 Bash |  copy code |? 
1
Thread 5 (Thread 140711690905952 (LWP 15782)):
2
#0  0x0000003f0b90b8fb in __fsync_nocancel () from /lib64/tls/libpthread.so.0
3
#1  0x0000000000573d5f in sp::tm::FileJournalWriter::write ()
4
……
5
#8  0x0000000000789bd8 in thread_proxy ()
6
#9  0x0000003f0b90610a in start_thread () from /lib64/tls/libpthread.so.0
7
#10 0x0000003f0b0c5ee3 in clone () from /lib64/tls/libc.so.6
8
#11 0x0000000000000000 in ?? ()

至此怀疑并不是软件问题。

联系op同学检查硬件,最终发现raid卡的write cache出现问题:

31a628a85965f2359a37ca8cc

作为缓存,raid cache的作用具体体现在读与写两个不同的方面:

  • 作为写,一般存储阵列只要求数据写到cache就算完成了写操作,当写cache的数据积累到一定程度,阵列才把数据刷到磁盘,可以实现批量的写入。所以,阵列的写是非常快速的。至于cache数据的保护,一般都依赖于镜相与电池(或者是UPS)。
  • cache在读数据方面的作用一样不可忽视,因为如果所需要读取的数据能在cache中命中的话,将大大减少磁盘寻道所需要的时间

而我们的服务器在raid故障时,还需要穿透raid做大量write和fsync,将压力真正压到磁盘上,就必然导致io性能的急剧下降了。这种情况只有更换raid卡。

我们靠谱op的解释:

RAID卡里本身有一个cache 数据写到RAID卡的cache里,就返回了,表现出来的性能要比数据直接落盘好。但是为了保证数据掉电不丢失,RAID卡需要有个电池,在掉电后通过电池把数据刷到磁盘里,保证数据可靠性。由于故障机器的RAID卡电池坏了,掉电后无法回刷数据,为了保证数据可靠性,不能通过cache缓存数据,所有的写操作必须直接落到磁盘上,写性能就会变差。

参考资料:
http://xxrenzhe.blog.51cto.com/4036116/1312510

Leave a Reply