为什么异步版本的TCP回显服务器使用的内存比同步服务器多50倍？

Question

我有一个使用标准库的简单TCP回显服务器：

use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("localhost:4321").unwrap();
    loop {
        let (conn, _addr) = listener.accept().unwrap();
        std::io::copy(&mut &conn, &mut &conn).unwrap();
    }
}

它使用大约11 MB的内存：

​

​

托基奥

如果我将它转换为使用tokio：

tokio = { version = "0.2.22", features = ["full"] }

use tokio::net::TcpListener;

#[tokio::main]
async fn main() {
    let mut listener = TcpListener::bind("localhost:4321").await.unwrap();
    loop {
        let (mut conn, _addr) = listener.accept().await.unwrap();
        let (read, write) = &mut conn.split();
        tokio::io::copy(read, write).await.unwrap();
    }
}

它使用607 MB内存：

​

​

async_std

类似地，对于async_std：

async-std = "1.6.2"

use async_std::net::TcpListener;

fn main() {
    async_std::task::block_on(async {
        let listener = TcpListener::bind("localhost:4321").await.unwrap();
        loop {
            let (conn, _addr) = listener.accept().await.unwrap();
            async_std::io::copy(&mut &conn, &mut &conn).await.unwrap();
        }
    });
}

它还使用607 MB内存：

​

​

为什么异步版本的程序使用的内存比同步版本多55倍？

Answer 1

我在这里尝试过，就像您在评论中说的，有几个64 in的块：

==> pmap -d $(pidof tokio)
3605:   target/release/tokio
Address           Kbytes Mode  Offset           Device    Mapping
…
0000555b2a634000     132 rw--- 0000000000000000 000:00000   [ anon ]
00007f2fec000000     132 rw--- 0000000000000000 000:00000   [ anon ]
00007f2fec021000   65404 ----- 0000000000000000 000:00000   [ anon ]
00007f2ff0000000     132 rw--- 0000000000000000 000:00000   [ anon ]
00007f2ff0021000   65404 ----- 0000000000000000 000:00000   [ anon ]
00007f2ff4000000     132 rw--- 0000000000000000 000:00000   [ anon ]
00007f2ff4021000   65404 ----- 0000000000000000 000:00000   [ anon ]
…

这些块既不是可读的，也不是可写的，因此它们没有映射，也不使用任何内存。它们只是表示保留的地址空间。

此外，正如您所看到的，每个65404 K块都是在132 K块之后出现的。因为65404+132正好是65536，所以我怀疑这些块代表了预留的地址空间，以防运行时以后需要增长132K块中的一个。看看事情如何处理几个小时和几千个连接可能是有趣的。

Answer 2

您应该查看RES列。一个使用1.0MB，另一个使用1.6MB。

其中大部分可能是启动tokio运行时所需的固定开销，以及它的线程池。

Answer 3

glibc的malloc实现为每个线程分配一个新块。块的大小由编译时常数HEAP_MAX_SIZE(来源)指定.因为tokio运行时会产生多个线程，所以会导致这种高的虚拟内存使用量。

为了避免这种情况，您可以使用cargo build --target=x86_64-unknown-linux-musl为musl目标编译锈蚀程序。

毕竟，这是glibc的优化，而不是铁锈或tokio运行时的影响。