单个数据库读的IO size 300K左右，存储整体IO并不大，是否会对存储整体的性能产生较大影响？
如果单个数据库读的IO size 300K左右，存储整体IO并不大（iops在6000左右，全闪），是否会对存储整体的性能产生较大影响？各存储厂商对此有解决方案么？
收起返回匿名用户的回答
有一点有点疑问，你说的“存储整体IO并不大 （iops在6000左右，全闪） ”，仅仅是IOPS不大，还是IO 吞吐量也不大？
从理论参数来讲， 每秒IO吞吐量＝IOPS乘以平均IO SIZE，那么你的存储其实IO吞吐量是会比较大的。
而根据我日常的使用，数据库出现该情况最典型的案例是在OLAP数据库的跑批处理时候，IO特征完全符合：IO SIZE大，IOPS小，IO吞吐量大。这是正常的现象，操作系统为了IO提升性能，增大每个IO获取的SIZE，这是有利于操作系统健康的。
不知道你是否是在使用过程中因为这种情况造成了其他什么问题了吗？
- IO吞吐量也并不大，整个IO吞吐量在800MB/s，因为是全闪，其他时间段存储的吞吐量可以达到3GB/s，但并无性能问题，响应时延不超过10ms，目前厂商给的答复是因为IO size太大，影响性能，比较怀疑这种观点，但已升级到国外三线，所以想确认下，其他厂商存储是否也存在类似问题
- 我这边确实因为这种情况造成了存储响应较慢，响应到了100ms以上，有观察过吞吐量，对于全闪，问题时间段的吞吐量并不大。
- 如果是响应时间，那需要考虑的东西就更多了：1.存储的性能（机头CPU）如何将直接影响响应时间，中低端存储的机头哪怕是用全闪，性能也不会很好，曾经分析过一台EMC VMAX的存储性能发现，吞吐量其实没达到极限，但是机头CPU在90%+，响应时间一直在100ms，这才是混闪.... 2.你需要考虑，存储上是否有其他能严重影响存储计算性能的特性——快照、克隆、远端拷贝、复制、虚拟化等等技术，这些技术是很吃存储计算性能的
- 这些都考虑过，CPU的性能也未到瓶颈，远程拷贝也停了，厂商也检查了所有的后端，最后结论就是IOsize大导致存储变大
- 300K是随机读吗？闪存是开启了压缩和重删功能吗？