Closed 0xzxdx closed 3 years ago
根据你们自己封装p1p2的并行数进行规划就是最好的。
我尝试每隔15分钟运行一个任务,结果都卡死了
2021-09-30T18:09:14.738Z INFO lotus-bench lotus-bench/main.go:119 Starting lotus-bench
2021-09-30T18:09:14.738Z INFO lotus-bench lotus-bench/main.go:933 [1] Writing piece into sector...
2021-09-30T18:09:14.738Z INFO lotus-bench lotus-bench/main.go:934 recovery addPieceCmd sid={{x 144} 8}
2021-09-30T18:12:15.298Z INFO lotus-bench lotus-bench/main.go:946 [1] Running replication(1)...
2021-09-30T18:12:15.299Z INFO lotus-bench lotus-bench/main.go:948 recovery preCommit1Cmd sid={{x 144} 8}
2021-09-30T18:12:15.299Z INFO lotus-bench lotus-bench/main.go:949 recovery preCommit1Cmd ticket=x
2021-09-30T18:12:15.299Z INFO lotus-bench lotus-bench/main.go:950 recovery preCommit1Cmd pieces=[{34359738368 x}]
并行属于待开发内容,目前的代码,更适合使用taskset给每个进程分配cpu。 或者您使用golang协程,就能使到到官方的核心分配方案。
话说如果用Docker跑,会不会比taskset更方便
我用taskset限制了使用那几个CPU
$ taskset -cp 0,1,48,49 42575
pid 42575's current affinity list: 0,1,48,49
pid 42575's new affinity list: 0,1,48,49
$ taskset -cp 2,3,50,51 42576
pid 42576's current affinity list: 2,3,50,51
pid 42576's new affinity list: 2,3,50,51
从htop上面看,似乎还是只用了一个CPU
针对红框中的每个PID,进行taskset -cp
分配,现在似乎看起来是正常的
lotus 本身对硬件协调性要求高,不是高调度性的程序。我认为容器化不会给他带来多大优点,反倒会削减性能,增加解决问题的难度。 嗯嗯,taskset 是权宜之计,国庆节后,我们应该会花一点时间优化扇区修复,针对大家给的意见,进行改进,做的更易用。
如果你在这方面有什么更好的想法,可以分享给我们做个改进的参考。
配置如下:
尝试单个任务大概4小时左右就可以恢复完了,但是多任务应该怎么分配比较合理呢?