net/http: too many open files

[ecavalcanti]

What version of Go are you using (go version)?

go1.11.1

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

• amd64
• darwin
• MacOS High Sierra (10.3.6)

What did you do?

The error too many open files is being thrown by submitting 20 requests per second in the code below.
The limit of open files on my system is 256 ( ulimit -n ).
Using lsof -p the FD is growing and not released.
If the OS open files limit is incremented the problem just is postponed. And I think that increment is not the solution.

package main

import (
	"log"
	"net/http"

	"golang.org/x/crypto/bcrypt"
)

func main() {

	srv := &http.Server{
		Addr: ":9000",
	}

	http.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
		log.Printf("/auth")
		if err := bcrypt.CompareHashAndPassword([]byte("$2y$10$MWTmFsLIM3jHVNiDDZH/U.qkpebJ/z02phdclx9rEcz5B7/cbujcy"), []byte("test")); err != nil {
			log.Printf("Error on check key and secret. (%v)", err.Error())
			w.WriteHeader(http.StatusUnauthorized)
			return
		}

		w.WriteHeader(http.StatusOK)
	})
	log.Printf("Listening on port 9000")
	log.Fatal(srv.ListenAndServe())

}

What did you expect to see?

The FD be released and not throw too many open files error.

What did you see instead?

http: Accept error: accept tcp [::]:9000: accept: too many open files.

[bradfitz]

If your server can't do 20 qps because its CPU is busy with, say, bcrypt but your load testing tool (which? you don't say.) keeps generating new connections, I would expect it to fail like this.

I'm not sure there's anything to do here.

[ecavalcanti]

I am using the artillery to run the tests:

artillery quick -d 60 -r 20 http://localhost:9000/auth

[bradfitz]

Well, the load testing tool has taught you something: you now know what your server can't do. Binary search on the -r value a bit and find the server's limit.

What do you want me to do with this bug?

[wsc1]

caddy suggests to up the ulimit on fd's for production use. It seems to me like an OS config issue and not a bug in Go or it's std lib