确实，每个系统都挺复杂的，还是得实测

--
👇
fakeshadow: 单个sleep只要几百字节。 量化我觉得要结合实际应用，高并发内存占用计算很困难。像是tcp连接除了系统内存还有用户内存。常见的io都套buffer，甚至多层套buffer，这个占用就只能自己实测了。异步休眠也经常有嵌套的情况。

--
👇
lithbitren: 有没有更量化点的指标，比如一个tcp链接，有人说是8-10k，主要是缓冲区开辟的，结果有人测出平均才3-4k，百万并发仅用3g+内存。 https://zhuanlan.zhihu.com/p/25241630?utm_id=0

不知道这种不涉及网络io的纯休眠tokio协程会是怎样占用内存的，也是想试试实现类似于redis那样的定时任务，是不是在handle里直接休眠就好了，还是专门搞一个时间轮把任务注册进去。 现在想想，handle作为协程挂起来的内存可能也得考虑进去，感觉开销一下子又大了不少。

--
👇
fakeshadow: tokio使用层级时间轮来储存休眠任务，在windows平台上使用iocp来超时阻塞线程的开销也很小，大量并发也能保证性能。简要介绍可以参考https://tokio.rs/blog/2018-03-timers

单个sleep只要几百字节。 量化我觉得要结合实际应用，高并发内存占用计算很困难。像是tcp连接除了系统内存还有用户内存。常见的io都套buffer，甚至多层套buffer，这个占用就只能自己实测了。异步休眠也经常有嵌套的情况。

--
👇
lithbitren: 有没有更量化点的指标，比如一个tcp链接，有人说是8-10k，主要是缓冲区开辟的，结果有人测出平均才3-4k，百万并发仅用3g+内存。 https://zhuanlan.zhihu.com/p/25241630?utm_id=0

不知道这种不涉及网络io的纯休眠tokio协程会是怎样占用内存的，也是想试试实现类似于redis那样的定时任务，是不是在handle里直接休眠就好了，还是专门搞一个时间轮把任务注册进去。 现在想想，handle作为协程挂起来的内存可能也得考虑进去，感觉开销一下子又大了不少。

--
👇
fakeshadow: tokio使用层级时间轮来储存休眠任务，在windows平台上使用iocp来超时阻塞线程的开销也很小，大量并发也能保证性能。简要介绍可以参考https://tokio.rs/blog/2018-03-timers

有没有更量化点的指标，比如一个tcp链接，有人说是8-10k，主要是缓冲区开辟的，结果有人测出平均才3-4k，百万并发仅用3g+内存。 https://zhuanlan.zhihu.com/p/25241630?utm_id=0

不知道这种不涉及网络io的纯休眠tokio协程会是怎样占用内存的，也是想试试实现类似于redis那样的定时任务，是不是在handle里直接休眠就好了，还是专门搞一个时间轮把任务注册进去。 现在想想，handle作为协程挂起来的内存可能也得考虑进去，感觉开销一下子又大了不少。

--
👇
fakeshadow: tokio使用层级时间轮来储存休眠任务，在windows平台上使用iocp来超时阻塞线程的开销也很小，大量并发也能保证性能。简要介绍可以参考https://tokio.rs/blog/2018-03-timers

tokio使用层级时间轮来储存休眠任务，在windows平台上使用iocp来超时阻塞线程的开销也很小，大量并发也能保证性能。简要介绍可以参考https://tokio.rs/blog/2018-03-timers