V2EX › firejoke 的所有回复 › 第 2 页 / 共 16 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯

2022 年 1 月 20 日

回复了 firejoke 创建的主题 › Python › 控制子进程的 cpu 使用率

@wevsty #6
在系统成面设置进程优先级来控制资源调度确实要方便很多，但就像 @ClericPy #7 描述的，操作系统内的资源调度对我们来说约等于是黑盒，不能达到想要的效果，所以如果能在程序成面做到控制的话，可控度就高多了，希望能找到更合适的方案。

2022 年 1 月 20 日

回复了 firejoke 创建的主题 › Python › 控制子进程的 cpu 使用率

@wevsty #1
@junnplus #2
@Buges #3
@ClericPy #4
我需要应用的场景，是在资源空闲的时候，用尽预期的所有资源，而在有其他进程也需要占用资源时，能动态的让出资源。
也可以用 cgroups 设定进程组占用 cpu 时间比其他进程组要少，但这样我就得为每一个可能启用的其他任务规划资源占比，并且每次都要手动修改已有的 cgroup 参数。
所以就想着，如果能自动动态的在程序成面规划资源占用的话，就能少动手了😋

2022 年 1 月 7 日

回复了 firejoke 创建的主题 › 武汉 › 寻武汉滑板爱好者

@gitgabige #1 感谢~

2021 年 11 月 23 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@ohayoo #34 还在调试多进程和协程的组合，后面会贴一下的。

2021 年 11 月 22 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@yufpga #29 我看日志里，我同时开了好多个 task ，这个 task 的循环里 await query 或 add 或 commit ，就会跳到另一个 task 的循环里的 query 或 add 或 commit 。

2021 年 11 月 22 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@hustlibraco #30 换成异步文件读，就可以换成 async for 了。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@O5oz6z3 #26 不是，当不存在较长的 io 等待的时候，协程和单线程没差。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Contextualist #25 对欸！资源是消耗在每一条查询和写入的操作上，如果批量写，就可以降低写入频率，至于查询，我已经在查询字段上加了索引，我改一下试试。感谢~
然后我看到你之前提到的 trio ，看他的文档像是涉及到异步操作的都有涉及，感觉非常不错啊。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Contextualist #23 是的，就是两个大文件，所以我也觉得文件 IO 不是我这里的瓶颈，协程在这个场景中没体现出他的优势，我已经改成了多进程了。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@locoz #20 我昨天最后也是改成用多进程了，一个进程专门读文件，然后放进队列，其他子进程从队列读，然后操作数据库，那看来我思路没跑偏。还有其他的解法吗？多进程和协程的结合，一般都是以多进程为主吗？

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Contextualist #14 看文档的意思，是说用异步文件 IO ，在从内存读取时反倒会变慢，在从磁盘读取的时候会加快，在不同环境下其结果是不可预测的。那我如果单独用一个进程读取文件到内存，然后另一个进程从内存读取然后再操作，应该可以绕开这个问题。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@LeeReamond #13 嗯，我昨天也想了一下，如果每一步阻塞住的操作实际上都很快，那 asyncio 其实发挥不出切换等待的优势。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@documentzhangx66 #12 设备性能应该没问题，12 核 24 线程，64G 内存，磁盘读取速度也没有跑满，IO 读写也不是特别高。

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@locoz #11 我也感觉似乎没发挥出 asyncio 的优势，每一条数据都不超过 1kb ，所以可能除了数据库操作稍微耗时长一点，其他地方等待的很少，所以和单线程的性能差不多？另外请教一下，“没有包上隐式多进程” 具体是指什么呢？

2021 年 11 月 21 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Trim21 #8 我改成了 asyncfiles ，然后把队列的 join 去掉了，这次成功跳到了其他 await 的位置，确实如你所说，感谢！
但测试发现，虽然没了 io 的阻塞，但写入速度还是没太大变化，他每读一行，切到其他 task ，和我之前没读一行，join 住，就执行流程来说，是不是没差？

2021 年 11 月 20 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Nitroethane #6 每行数据小于 1kb ，而且是用的 for ，这里相当于一个生成器

2021 年 11 月 20 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@Trim21 #4 所以，也会导致如果不主动用队列的 join 阻塞住，就不会跳到其他 await 的地方？

2021 年 11 月 20 日

回复了 firejoke 创建的主题 › Python › 关于 asyncio 执行 IO 密集型操作的不解

@long2ice #1
@Trim21 #2
文件这里只是读取，然后放进队列里，这也会导致阻塞吗？

2021 年 11 月 5 日

回复了 firejoke 创建的主题 › Ansible › 关于 AWX 执行 ansible 的原理不解的地方

@julyclyde #3 嗯，按这里 ansible-runner 调用方法来看，是根据指定根目录的目录结构来执行一个任务，可以认为是为单一指定的 project 保存一个 inventory 存档，这样就能理解。
但为了这个目的的话，专门为这个 project 建一个 inventory group 不就行了，不管整个 inventory 怎么更新，只要这个 inventory group 不变就行了，每次执行这个 project 都使用这个 group 。

2021 年 11 月 5 日

回复了 firejoke 创建的主题 › Ansible › 关于 AWX 执行 ansible 的原理不解的地方

@julyclyde #1 在 inventory 插件里，也是只从 api 里获取一次，中途不会在执行这个动作，所以不存在这个情况。

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯