求助：FASTt900 的带宽问题。

brian821003

to：Basten
       采集时写盘阵和文件拷贝时写盘阵是不同的。前者要求有很好的缓存性能，一旦发生缓存被写满导致无法写入盘阵的情况，采集会立刻断掉，导致采集失败。而拷贝文件写入在缓存写满的时候可以稍做等待，等清空缓存后继续写入。现在在4台上载机器中用SANergy测试，写速度在80MB/s以上。按道理说，带宽足够了。。表面上看来不是盘阵的问题，但是可能会是盘阵在缓存管理上的问题。

Basten

是不是控制器写缓存根本没有启用！？进SM看看啊。

brian821003

谢谢大家。。。前天我看了看手册，上面说segment的值小一些的话有助于提升媒体流的写入性能，所以我就把卷的segment值由原来的256调整到了128，昨天下午进行了2台同时采集50Mbps的码流，共进行了100分钟，没有出现报错情况，今天上午进行了4台50Mbps的采集，第13分钟的时候只有一台报错，后来重启。四台采集在下午1点的时候再次报错。。采集一共采了将近4个小时。。   

   控制器的电池是好的。。我昨天看了。。缓存也已经启用。现在苦于我的笔记本没有双网卡。。不能监控磁盘的使用状态。。明天去买一块网卡加上。。在SM里面我记得是可以监控缓存的使用情况的。。

    很不明白。为什么会突然卡死呢？如果说是采集卡的问题，那么单机采集并没有问题。那么采集卡的抱错说是缓冲区不足，一定是卡上的缓存不足，那么卡上的缓存不足是什么导致的呢？光纤通路？盘阵缓存？但是如果说不是盘阵的问题，那么四台采集怎么会同时报错呢？监控盘阵缓存的使用情况看来是最根本的解决方法了。。

wnzl

解决问题了，一定把方法贴出来哦

brian821003

呵呵。。现在情况有所改善。看来和segment的大小有关，原来在256K的时候最多能采集90分钟，现在改成了128K，最长采集了4个多小时。但是还有报错的情况发生，下一步打算进一步调整为64k，看是不是能彻底避免这种情况的发生。但是原因还是不很清楚，查了手册中关于segment size 的解释，原文如下：

    The choice of a segment size can have a major influence on performance in both IOPS and throughput. Large segment sizes increase the request rate (IOPS) by allowing multiple disk drives to respond to multiple requests. A small segment size increases the data transfer rate (MB/s) by allowing multiple disk drives to participate in one I/O request. Use a small segment size relative to the I/O size to increase sequential performance.
   
      You can use the performance monitor (see “Performance monitor data” on page 85) to evaluate how a given segment size affects the workload. Use the following guidelines:

1、If the typical I/O size is larger than the segment size, increase the segment size in order to minimize the number of drives needed to satisfy an I/O request. This is especially true in a multi-user, database, or file system storage environment. Using a single drive for a single request leaves other drives available to simultaneously service other requests.

2、 If we are using the logical drive in a single-user, large I/O environment (such as for multimedia application storage), performance is optimized when a single I/O request can be serviced with a single data stripe (the segment size multiplied by the number of drives in the array that are used for I/O). In this case, multiple disks are used for the same request, but each disk is only accessed once.

3、 Normally, a small segment size is used for databases, normal sizes for a file server, and large segment sizes for multimedia applications.

4、 If we increase the segment size we gain more throughput

       同样大致翻译一下：

    段大小的选择可以对 IOPS 和吞吐量产生重大的影响。段大小值大可以增加多磁盘请求响应的速率，小的段大小值则能够增加多磁盘参与的输入输出请求中数据的传输速率（以MB/s为单位）。使用相对于输入输出值较小的段大小值能够增加时序性能。

您可以使用性能监控来估计对于当前的工作量需要多少段大小。有以下指导方针：

1、如果通常的输入输出大小要比当前的段大小大，为了平衡对于驱动器的输入输出请求可以增加段大小值。这适用于多用户，数据库或者文件服务器的存储环境。

2、如果我们只有单独的用户使用逻辑驱动器，较大量的输入输出环境，当单独的I/O请求能够被单独的数据通路所接受那么性能将是最好的。既然这样，多个磁盘用来做同样的请求，但是所有的磁盘之能够访问一次。

3、正常的，较小的段大小值适用于数据库。中等的段大小值适用于文件服务器，较大的段大小值针对多媒体应用。

4、如果我们增加段大小，我们将获得更多的吞吐量。


总结一下，较小的 segment size 能够增加时序性能，也就是说能够承受更大的连续数据量。但是对于多媒体应用，又推荐较大的 segment size 。较大的 segment size 可以增加盘阵读取和写入的速度。看来为了能够正常写入，只好牺牲一些速度了。。但是从我测试的情况看来，当 segment size 由256K改为128K之后，盘阵的速度并没有太大的降低，也就有10MB/s的降低，这个程度还是可以忍受的。所以决定继续降低到64k待测。。。

wnzl

继续测试

brian821003

现在有个疑问，如果继续减小 segment 的值，会不会对磁盘的读写有很大的影响。

brian821003

继续测试中。。现在已经连续采集300分钟没有问题了。。由于磁带长度不够，后面的150分钟一直都是在采集黑场。但是仍然是50Mbps的码流文件。。。期待。。。看看是不是还会有问题。。

brian821003

经过这近一周的测试。问题并没有太大的改善。但是我发现了一个细节，就是使用SANergy测试的时候，一是速度波动很大，最高的时候能到120左右，而最低的时候能到90多。二是在用SANergy测试的时候发现进度条有时会出现“卡”的情况。每次一“卡”，测出的速度就必然会低。我想是因为在清空缓存的时候造成的。不知道对不对。还有就是速度又20M左右的波动，是属于正常范围么？再有这么“卡”，也是正常的么？