5

I have a simple TCP echo server using standard library:

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();
    }
}

It uses about 11 MB of memory:

standard library

Tokio

If I convert it to use 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();
    }
}

It uses 607 MB of memory:

tokio

async_std

Similarly, with 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();
        }
    });
}

It also uses 607 MB of memory:

async_std

Why do the asynchronous versions of the program use 55x more memory than the synchronous one?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Gurwinder Singh
  • 38,557
  • 6
  • 51
  • 76
  • 1
    Since it appears that you are using a Unix system, have you tried valgrind? Specifically, `valgrind --tool=massif` is able to give you heap snapshots with the total allocated per allocation site. – Matthieu M. Aug 04 '20 at 09:16
  • 6
    The `VIRT` column shows the amount of address space assigned to the process. The `RES` column shows the amount of address space mapped to physical memory. Saying the process "uses" 607 MB of memory just because it gets that much address space seems a bit off. – Sven Marnach Aug 04 '20 at 09:25
  • 1
    @SvenMarnach Why is it getting that much address space? I am not sure if it is relevant but `pmap` shows several ~64 MB blocks `00007f617c021000 65404K ----- [ anon ]`. – Gurwinder Singh Aug 04 '20 at 10:11
  • 1
    The reason for getting that much address space probably depends on internals of your operating system, and I don't even know what your OS is. In any case, I wouldn't worry about it. On a modern 64-bit system, address space never is a limiting factor, so the OS can hand it out to processes liberally. – Sven Marnach Aug 04 '20 at 11:11
  • How big is your executable file in each instance? – Jmb Aug 04 '20 at 14:57
  • @jmb About 3.5 MB ... – Gurwinder Singh Aug 04 '20 at 16:39

3 Answers3

5

You should look at the RES column. One uses 1.0MB, the other uses 1.6MB.

Most of it is likely to be a constant overhead needed to start tokio runtime and a threadpool for it.

Kornel
  • 97,764
  • 37
  • 219
  • 309
3

I tried it here, and like you said in the comments, there are several 64MB blocks:

==> 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 ]
…

Those blocks are neither readable nor writable, so they aren't mapped and don't use any memory. They simply represent reserved address space.

Moreover as you can see, each of those 65404K block comes immediately after a 132K block. Since 65404+132 is exactly 65536, I suspect that these blocks represent address space that is reserved in case the runtime needs to grow one of those 132K-blocks later on. Might be interesting to see how things look after a couple of hours and a few thousand connections.

Jmb
  • 18,893
  • 2
  • 28
  • 55
1

The malloc implementation of glibc allocates a new block for each thread. The size of the block is specified by the compile-time constant HEAP_MAX_SIZE(Source). Because the tokio runtime spawns multiple threads it results in this high virtual memory usage.

To avoid this you can compile your rust program for the musl target with cargo build --target=x86_64-unknown-linux-musl.

After all, this is a optimization by glibc and not an effect by rust or the tokio runtime.

koplas
  • 11
  • 1