- 主题:帮我算个数学题
你看我发的帖子还有上来就问候我是不是有病,要不要看看病的"我要LIKE!",我觉得我可能和他有杀fu之仇,所以他完全不能正常的回复我,没办法,什么人都有
【 在 siegfried415 的大作中提到: 】
: 随便你，不会再回你了。。。
:
--
FROM 114.241.136.*
我早都不生气了，水木上什么样的人都有，没逻辑的，杠精的，装叉的，也许从这些人的眼里看，我们也是没逻辑的，杠精的，装叉的，怎么办呢？只能接受吧，这个世界就是这么设计的，哈哈。
【 在 myspam 的大作中提到: 】
: 你看我发的帖子还有上来就问候我是不是有病,要不要看看病的"我要LIKE!",我觉得我可能和他有杀fu之仇,所以他完全不能正常的回复我,没办法,什么人都有
: 【 在 siegfried415 的大作中提到: 】
: : 随便你，不会再回你了。。。
: ...................
--来自微水木3.5.1
--
FROM 113.232.128.*
和这个话题无关，你确实很杠精
【 在 siegfried415 (更号2) 的大作中提到: 】
: 我早都不生气了，水木上什么样的人都有，没逻辑的，杠精的，装叉的，也许从这些人的眼里看，我们也是没逻辑的，杠精的，装叉的，怎么办呢？只能接受吧，这个世界就是这么设计的，哈哈。
: --来自微水木3.5.1
--
FROM 115.171.203.*
大家彼此彼此了。。。
【 在 cppbuilder 的大作中提到: 】
: 和这个话题无关，你确实很杠精
:
: 【 在 siegfried415 (更号2) 的大作中提到: 】
: ...................
--来自微水木3.5.1
--
修改:siegfried415 FROM 113.232.128.*
FROM 113.232.128.*
据说个人办公娱乐游戏等操作，队列深度一般是1-4。包括了你提到的磁盘操作解压打包等。
我找不到测试软件及原始出处，所以也不全信。
但是你说同时处理几万个小文件就产生几十上百的队列我也觉得不可信。
所以现在还是需要有个能监控磁盘队列的软件来让事实说话。
【 在 siegfried415 的大作中提到: 】
: 我经常用beyond compare对比两个目录，这两个目录中可能有几万个甚至几十万个文件，bc能做到在几十秒之内完成几十万个文件的比较，你觉得在这种情况下，操作系统会会不会每秒钟发出成千上万的读写指令？然后这些指令为什么就不能在ssd中被分配到不同的队列中来并行的去执行呢？
: 类似的操作，还有打包，压缩和解压缩，备份与同步，编译内核，git操作等等，都涉及到大量的小文件的读写，你怎么知道这些操作无法利用ssd的并行读写能力呢？
: --来自微水木3.5.1
--
FROM 125.120.112.*
他的留言说的是“几十秒内对比完上万个文件的瓶颈都不在iops上，如果文件小的话，比如每个文件4KB，上万个文件才4MB，即使单线程也能搞定”
他表达的意思正是你所说的小文件性能损耗在非磁盘环节更多，磁盘本身不是瓶颈。
我们已经知道磁盘4k单线程能达到4MB/s（1000iops）甚至40MB/s（10kiops），这些文件对cpu等系统的压力更大。
他并没有用文件总大小来说总开销，而是磁盘能承受这么多的文件，你的系统其它跟的上吗？
【 在 siegfried415 的大作中提到: 】
: 我发现你真是一个外行：
: 编过系统程序的都知道，小文件的读写是非常慢的，因为小文件读写的主要开销是花在系统调用的上下文切换环节上。说句题外话，被面试人如果用小文件的总长度来估计大量小文件操作的总开销，说明你对OS一知半解，肯定通不过我的面试的。。。
:
--
FROM 125.120.112.*
我认为一般的应用程序的确没必要直接操控硬件。直接操控硬件有可能获得性能提升，但编程难度大，而且来兼容性降低，需要针对不同的硬件有不同的设计（比如针对ssd和hdd就不一样了）。
系统提供了各种通用接口和平台，就是让开发者无视硬件是什么，不需要处理底层。这种逻辑分级是有它的意义的。
不这么做的是一些非主流的程序，测试软件不必说，服务器的特定应用也有直接操控硬件的意义，负载重，硬件、软件环境可控并有专人维护，所以这个可以单独拿出来作为例外。
【 在 siegfried415 的大作中提到: 】
: 那你的意思是，应用程序无法通过OS直接利用ssd的并行读写能力了，是吗？那为什么服务器上的应用就可以通过OS来对ssd进行并行读写？
:
--
FROM 125.120.112.*
他表达的不是这个意思，如果我没记错的话，他表达的意思是，把小文件的系统调用浪费的时间刨除掉，然后用同等数据量的大文件的IO来估算拷贝时间，然后得出并不需要多线程来进行处理的结论。--这显然是错误的，为了让小文件能做和大文件同样的拷贝速度，就必须让一些文件的系统调用和另外一些文件的IO访问同时进行，这一定需要某种程度的并行/并发操作才能做到。
【 在 beijiaoff 的大作中提到: 】
: 他的留言说的是“几十秒内对比完上万个文件的瓶颈都不在iops上，如果文件小的话，比如每个文件4KB，上万个文件才4MB，即使单线程也能搞定”
: 他表达的意思正是你所说的小文件性能损耗在非磁盘环节更多，磁盘本身不是瓶颈。
: 我们已经知道磁盘4k单线程能达到4MB/s（1000iops）甚至40MB/s（10kiops），这些文件对cpu等系统的压力更大。
: ...................
--
FROM 113.233.223.*
ssd经常提的队列深度1时的4k速度，比如40MB/s，这个就是考虑了小文件操作会慢的前提，测得的一个数字。用这种方法表达磁盘性能是合理，也是行业通用方法（参考各产品铭牌）。
40MB/s就意味着4kB的小文件，完成了10k次io每秒。并且在队列为1的条件下测的。
磁盘是能达到这个性能的，既然能实测到，说明做简单读写的时候系统加上其他开销也是能支撑这个性能的。当然如果有其他计算需求，比如文件预览、比较、hash，那电脑很可能就跟不上了。
我相信他表达的意思就是对于磁盘来说，这点速度单线程就很简单，所以不需要多线程。如果达不到，大概率瓶颈是系统其它组件。
另外小文件就算多线程，也远赶不上大文件处理速度。磁盘内部类似上下文开销要耗掉性能和时间。
【 在 siegfried415 的大作中提到: 】
: 他表达的不是这个意思，如果我没记错的话，他表达的意思是，把小文件的系统调用浪费的时间刨除掉，然后用同等数据量的大文件的IO来估算拷贝时间，然后得出并不需要多线程来进行处理的结论。--这显然是错误的，为了让小文件能做和大文件同样的拷贝速度，就必须让一些文件的系统调用和另外一些文件的IO访问同时进行，这一定需要某种程度的并行/并发操作才能做到。
:
--
FROM 125.120.112.*
我找到在win下如何查看队列深度了。
资源监视器-磁盘-存储-选择列：磁盘队列长度。
我相信一般磁盘操作在主流ssd上，队列长度不超过2，极端点3吧。
我回复到这的时候突然发现你说的是线程数呀。。
线程数这个怎么看……
【 在 zli07 的大作中提到: 】
: 但是即使再烂的ssd，4K读写也能达到每秒好几兆的速度，换算成4K的话就是好几千个文件。
: 我的观点从来没有变过，那就是日常生活中的操作根本用不到4k 64thd，而你用的例子根本不能反对我的观点
: :
--
FROM 125.120.112.*