16 寸 M1 Max 在拷贝文件的时候只有两个能效核心 100%运行,导致拷贝的比较慢?

2022-03-11 23:18:31 +08:00
 yoyoyoyolol
拷贝 300 多 GB 的文件(都是代码等小文件),只有两个能效核心跑满 100%,其他核心都没运行导致拷贝要几个小时,有没有办法让所有核心都进行拷贝呢
2610 次点击
所在节点    Apple
21 条回复
dingwen07
2022-03-12 00:42:13 +08:00
M1Pro/Max 系统的很多操作都这样
比如安装 Xcode ,要一个小时。。。
BrettD
2022-03-12 00:45:41 +08:00
瓶颈是文件系统和 IO 而不是 CPU 吧
GQ1996
2022-03-12 00:55:44 +08:00
瓶颈不是 cpu ,一口气 300G 的话如果是 512G 的版本,SLC 缓存原因,会在 100 多 G 的时候拷贝速度降非常多。1T 的话 300 多 G 没什么问题。
minsheng
2022-03-12 01:31:25 +08:00
@dingwen07 App Store 安装很迷但是直接下载还是挺快的,这里还有一个高速解压 xip 的项目: https://github.com/saagarjha/unxip
minsheng
2022-03-12 01:31:59 +08:00
@GQ1996 这个可能要让楼主先看一下活动监视器里的磁盘 IO 来确定
minsheng
2022-03-12 01:32:48 +08:00
楼主试一下 Terminal 的 cp/mv ? Finder 干啥都挺慢的,删个 Xcode 能删死机……
minsheng
2022-03-12 01:33:39 +08:00
Spotlight 和 Time Machine 也要适当注意,macOS 小文件多起来各种 hook ,虽然可能比 Windows 杀毒软件好点但真没好到哪里去
felixcode
2022-03-12 01:37:09 +08:00
大概率 IO 问题,数据量大到一定程度必须写入磁盘时,磁盘的 IOPS 非常低。
https://v2ex.com/t/834674
GQ1996
2022-03-12 02:21:37 +08:00
@minsheng 对的,还有一个 bug 要注意,如果是用快捷键 command+c 复制的,要小心复制后不要用 iphone 上会读取剪切板的 app 。不然有一个进程会把 command C 的所有文件读取一遍,导致把要复制的那部分 io 都抢完了。随便找段文字复制一下再用手机,这个 universal clipboard 的 bug 已经我一直能复现。
yoyoyoyolol
2022-03-12 03:39:35 +08:00
@BrettD @GQ1996 @minsheng @felixcode @GQ1996 感谢回复 根据 @minsheng 回复使用 cp 命令复制果然快了很多,什么原理呢,测试结果已补充
yoyoyoyolol
2022-03-12 03:53:22 +08:00
@minsheng 虽然使用 cp 命令复制块很多,但是复制出来的文件大小和源文件大小不一致,测试文件夹 172GB ,使用 cp 复制后的文件夹 358GB ,使用 finder 右键复制出来的大小是一致的 172GB ,移动硬盘格式和 macbook 硬盘格式一致为 APFS 格式
yoyoyoyolol
2022-03-12 04:06:07 +08:00
@minsheng 请忽略那个文件大小不一致的问题,那个是因为右键显示简介里面文件大小刷新的太慢了😅
Pierson
2022-03-12 08:35:07 +08:00
macOS QOS 的问题,记得以前在哪里看到一篇博文提到,macOS 会根据任务的优先级而不是实际性能需要进行调控。
jdjingdian
2022-03-12 10:09:08 +08:00
m1 系列外接 usb 硬盘,是没法使用 uasp 加速的( Intel 的有),所以我的移动硬盘在 Intel Mac 上能跑 500MB/s ,在 m1 上只能跑到 300MB/s
minsheng
2022-03-12 11:08:55 +08:00
@GQ1996 那要是 Command C 了一个 Xcode ,iPhone 不就直接卡死了吗😂我记得 Universal Clipboard ,应该说 UIKit 的 Clipboard API 整体都是同步的🤦‍♂️
minsheng
2022-03-12 11:16:24 +08:00
@yoyoyoyolol Apple 在 Snow Leopard 的时候引入了一个系统级别的任务队列管理系统,Grand Central Dispatch ,现在想来这东西怕不是也是为了 iPhone 设计的。它的一个功能就是可以创建有优先级的任务队列。你可以选择如 background (清理垃圾?)、userInitiated (导出?)、userInteractive ( UI 任务)这样的优先级。

这个优先级在 macOS 上之前的作用主要是在多个线程同时执行的情况下,低优先级的线程会抢不到计算资源。这还导致了 macOS 用了几十年的 spin lock 被弃用了,因为 spin lock+有优先级的调度会导致死锁😂。

到 Apple Silicon 出来,大家发现,如果你选 background 优先级,那么不只是抢计算资源,低优先级的线程会直接跑在小核上,任何其它系统设置都改不了。其实这个挺好的,因为 MacBook 之前的一大问题就是很多这种后台任务可以触发 Intel 的睿频,导致风扇狂转续航爆炸。但是具体到这里就会导致 Finder 变慢了。

对于你说的 cp 文件大小不一致,其实我觉得可能是会存在的。APFS 是支持文件 COW 的,如果你原地复制一个大文件,APFS 不会真的拷贝任何数据,而是链接回原文件。如果你对两者之一做了修改,才会真正进行文件复制。那如果你原文件 A 、B 其实是一个文件,然后按顺序复制到别的宗卷,就会出现这个情况:复制 A 的时候,发现在第二个宗卷,没法 COW 优化,复制一份;复制 B 的时候,已经忘了自己复制过 A 了,那再复制一份吧。最后导致总文件增大。

注意,如果是同宗卷复制,那不会出现这个情况,因为复制出来的 C 、D 和原来的 A 、B 指向同一个物理意义上的文件。
yoyoyoyolol
2022-03-12 12:34:40 +08:00
@minsheng 感谢大佬分享
yoyoyoyolol
2022-03-12 12:43:57 +08:00
@GQ1996 @minsheng 刚才说的这个问题,我这几天使用的过程中也确实发现了,有一次我拷贝 200GB 文件后,文件拷贝完成后的很长一段时间内,流量监控软件都显示我的上传带宽被占满,一直已 15MB/s 的速度在上传,后来我查了这个上传进程是 icloud ,网上查了相关资料,把系统偏好设置->通用->允许在这台 Mac 和 iCloud 设备之间使用“接力”选项关闭后,再复制文件就没有出现过这种情况。“接力”功能会把文件先上传 icloud 服务器,但这样拷贝大文件的时候就会有问题😅
neiltroyer849
2022-03-12 16:15:51 +08:00
想要插画问一句 po 主的 cpu 历史记录看不同内核运作情况的那个 app 是啥来着
yoyoyoyolol
2022-03-12 18:49:53 +08:00
mac 系统的活动监视器选到 cpu ,双击底部下面的 CPU 折线图就弹出来了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/839776

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX