Why is my Go server memory leaking?

Question

I've written a simple TCP server.
The problem is that when stress-testing it, it seems that the memory usage is increasing dramatically, and not decreasing when he test is done. When the server is started, it takes ~700KB.
During and after the stress-test, the memory usage jumps to ~7MB.
Here's my code:

package main

import (
    "net"
    "log"
    "fmt"
    "bufio"
)

func main() {
    ln, err := net.Listen("tcp", ":8888")
    if err != nil {
        log.Fatal(err)
    }
    defer ln.Close()
    for {
        conn, err := ln.Accept()
        if err != nil {
            fmt.Println(err)
            continue
        }
        go handle(conn)
    }
}

func handle(conn net.Conn) {
    defer conn.Close()
    fmt.Println("Accepted", conn.LocalAddr())
    for {
        buf, err := bufio.NewReader(conn).ReadString('\n')
        if err != nil {
            break
        }
        msg := string(buf[:len(buf)-2])
        fmt.Println("Received", msg)
        conn.Write([]byte("OK\n"))
    }
}

Any help is much appreciated.

Note: I'm using tcpkali for loading it. This is the command line:

tcpkali -em "testing\r\n" -c 100 -r 1000 -T 60  127.0.0.1:8888

EDIT: Following some comments below, I ran some tests and here are the results:

1. Started the server and ran tcpkali.
2. After the first run, RSS was at 8516.
3. After a second run, RSS climbed to 8572.
4. Server is now idle. 5 minutes later, RSS climbed to 8588.
5. 5 more minutes later, RSS climbed to 8608, and seems stable.
6. After 15 minutes of break, I ran tcpkali again, and RSS climbed to 8684.
7. A few minutes break, another tcpkali run, RSS climbs to 8696.
8. A few minutes break, another tcpkali run, RSS climbs to 8704.
9. A few minutes break, another tcpkali run, RSS climbs to 8712.

Now, I don't know what you call this, but I call this a memory leak. Something is wrong here. No memory is freed, and RSS is keep climbing every time I run a test. Obviously, this thing cannot be deployed to production as it will eventually consume all available memory.
I also tried calling os.FreeOSMemory() but nothing happens.

My system is Go 1.9.4 on macOS 10.13.1. Is this environment related or am I missing something?

LAST UPDATE:
Following @Steffen Ullrich answer and the tests that failed on my environment, I gave it a try on Ubuntu server, and the memory is freed after a few minutes of idle time.
Seems like there's an issue with macOS.

Answer 1

Go does not release memory it allocated from the OS immediately. The reason is probably that allocating memory is costly (needs system calls) and the chance is high that it will be needed in the near future anyway again. But, if memory gets long enough unused it will be released eventually so that the RSS of the process decreases again.

Doing your test again with slight modifications will show this (it did at least for me):

1. Start you program and look at the RSS.
2. Run tcpkali, wait for tcpkali to end and look at the RSS again. It is much higher now since lots of memory was needed for the program to do the intended task.
3. Don't stop the program but run tcpkali again and wait again for it to end. When looking at the RSS you should see that it did not grow (much) further. This means that the program used the already allocated memory again and did not need to allocate new memory from the system.
4. Now monitor the RSS and wait. After a while (about 10 minutes on my system) you should see the RSS go down again. This is because the program has determined now that the allocated but unused memory will probably not be used any longer and returned the memory back to the OS.

Note that not all memory might be given back. According to Understanding Go Lang Memory Usage it will not return (in go 1.3) the memory used for the stacks of the go routines since it is more likely that this will be needed in the future.

For testing you might also add some debug.FreeOSMemory() (from runtime/debug) at strategic places (like when you break out of the loop in the goroutine) so that the memory gets returned earlier to the OS. But given that the lazy return of memory is for performance such explicit freeing might impact the performance.