Как устранить утечку памяти при множественных соединениях в net/http Golang?

Question

[videxerion]

У меня есть следующая функция:

var client = &http.Client{
    Timeout: time.Millisecond * 100,
}

func scan(ip string) (error, string, string, string) {
    resp, err := client.Get("http://" + ip)

    // Закрытие неиспользуемых соединений
    client.CloseIdleConnections()

    if err != nil {
        return err, "", "", ""
    }

    headers := buildHeaders(resp.Header)
    body, _ := io.ReadAll(resp.Body)

    // закрытие тела ответа
    resp.Body.Close()

    return err, headers, string(body), resp.Status
}

Данный код приводит к огромной утечке памяти. В процессе дебага выяснилось что в net/http в функции queueForIdleConn() в файле transport.go происходит следующее:

if t.idleConnWait == nil {
    t.idleConnWait = make(map[connectMethodKey]wantConnQueue)
}
q := t.idleConnWait[w.key]
q.cleanFront()
q.pushBack(w)
t.idleConnWait[w.key] = q
return false

Получается так что в idleConnWait = {map[http.connectMethodKey]http.wantConnQueue} постоянно записываются новые элементы, но судя по размеру никогда не освобождается. Как правильно сделать так что бы этот массив очищался?

Примечания:

1. Программа кидает соединения множеству адресов 95% которых недействительны (не отвечают).
   
2. Эта функция запускается сразу в большом кол-ве горутин (go scan())
   

Comments

[Евгений Мамонов]

> Данный код приводит к огромной утечке памяти

Хорошо бы, для начала понять, сколько памяти реально течёт, есть сомнения, что эта map'а, занимает много памяти.

> Эта функция запускается сразу в большом кол-ве горутин (go scan())

Также нужно понять сколько горутин запускается?
Почему? Потому, что каждая из них, в зависимости от размера стэка, потребляет память.
Если их запускается очень много и/или, например, они не завершаются, вот тут уже более реальна "огромная" утечка памяти.

[videxerion]

Евгений Мамонов,
> есть сомнения, что эта map'а, занимает много памяти.
Собственно, именно на это я и жалуюсь.
> Также нужно понять сколько горутин запускается?
Одновременно работает не более 200 горутин которые точно завершаются. Проблема не в количестве горутин, а то что эта мапа которая представляет собой очередь, раздувается (вполне себе может и 100 тыс. элементов содержать и 300 тыс).

[darst]

videxerion, вообще-то всё логично в одномоментном потребление памяти. Я так понимаю, что сразу создаётся много соединений, и клиент просто не успевает освободить ресурсы, чтобы переиспользовать подключения. Попробуй запусти в одном потоке или сделай семафор на 10 горутин.

Answer 1

[Виктор Кожухарь]

Скорей всего, проблема в том, что вы возвращаете ошибку, не закрывая http соединение.
Для этого была специально введена одна из самых привлекательных конструкций языка - defer.

var client = &http.Client{
    Timeout: time.Millisecond * 100,
}

func scan(ip string) (error, string, string, string) {
    resp, err := client.Get("http://" + ip)
    // Здесь сразу желательно обработать ошибку ...
    
    // Закрываем соединение в конце выполнения
    // функции в любом случае,
    // даже если где-то возникнет ошибка
    defer resp.Body.Close()

    // Закрытие неиспользуемых соединений
    // Нужно ли это теперь?
    // client.CloseIdleConnections()

    // Проблема могла быть тут
    // if err != nil {
    //     return err, "", "", ""
    // }

    headers := buildHeaders(resp.Header)
    body, _ := io.ReadAll(resp.Body)

    // и это нам уже особо не нужно
    // resp.Body.Close()

    return err, headers, string(body), resp.Status
}

Comments

[videxerion]

Это решение не сработает сразу по нескольким причинам:
1. Когда вы убрали проверку на то появилась ли ошибка или нет, вы будете пытаться закрыть nil (чему будет равен resp при неудачной попытки соединения) что будет приводить к ошибкам.
2. Из выше сказанного выходит что это помогает от засилья удавшихся, но простаивающих соединений. У меня же все наоборот, куча неудавшихся соединений которые библиотека net/http зачем то ждёт и хранит в памяти

[Виктор Кожухарь]

videxerion, Может быть, мне ещё и проект за вас дописать? ))
Понятно, что ошибки надо обрабатывать, и хорошая IDE вам непрозрачно на это намекнет. Тем более, что и я вам намекнул на это комментарием сразу после cient.Get. Что именно делать с ошибкой - это уже только вы знаете. Логгировать, падать, возвращать? Я-то откуда знаю?

Главное - это defer, который отрабатывает в любом случае, что бы у нас там ни случилось уже после соединения при чтении данных и т.д. Эта конструкция языка Go (и некоторых других языков) - одно из гениальнейших решений в программировании, когда исключается целый класс багов, возникающих из-за невнимательности программистов.

[videxerion]

Виктор Кожухарь,
> Может быть, мне ещё и проект за вас дописать? ))
Было бы неплохо, но пока вы не справляетесь даже с собственными мыслями в голове потому не могу его вам доверить.
> Понятно, что ошибки надо обрабатывать
Ну тогда прежде чем закомментировать мой if который как раз обрабатывает ошибку(её возвращает в другую часть кода) вам стоило лучше подумать.
Да и в конечном итоге есть главный вопрос. Как все это должно помочь? Потому что resp.Body.close() работает только на удавшиеся подключения (коих 5% от общей массы соединений). А у меня проблема в том что куча неудавшихся соединений копится в очереди и потому занимает память.

Answer 2

[calculator212]

Вообще есть сомнения что дело в этой мапе, первое что в глаза бросается, это то что вы неправильно обрабатываете ошибки пример из оф доки

resp, err := http.Get("http://example.com/")
if err != nil {
	// handle error
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)

Вы сначала проверяете на ошибку и если ошибки нет, через defer закрываете соединение.
Второе - вам стоит почитать про http.Transport и некоторые особенности клиентов, т.к. даже соединения которые должны были закрыться могут висеть очень долго

tr := &http.Transport{
	MaxIdleConns:       10,
	IdleConnTimeout:    30 * time.Second,
	DisableCompression: true,
}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://example.com")

Также желательно в самой системе посмотреть таймауты и настройки для tcp соединений (это не так часто нужно но если у вас много запросов клиентских, то может помочь).
Также можете поискать альтернативные клиенты и пулы клиентов, а также как правильно реюзать соединения

Получается так что в idleConnWait = {map[http.connectMethodKey]http.wantConnQueue} постоянно записываются новые элементы,

В целом есть вероятность, что "утечка" тут, но это очень легко проверить даже без профилировщика, т.к. эта мапа уникальна для каждого клиента, то можно напрямую проверять сколько клиент занимает памяти, но на самом деле есть большая вероятность, что проблема в том, что вы неправильно используете client, т.к. эта мапа периодически очищается и расти она должна только до определенного значения

Comments

[videxerion]

tr := &http.Transport{
	MaxIdleConns:       10,
	IdleConnTimeout:    30 * time.Second,
	DisableCompression: true,
}

Уже пытался, не сработало и в этот раз.

> В целом есть вероятность, что "утечка" тут
Вероятность этого 100% т.к я специально лазил проверять где забивается. Вопрос мой в том как очищать этот массив или ещё лучше как сделать так что бы библиотека net/http сама за собой правильно подчищала.

[calculator212]

videxerion, я написал в чем могут быть прблемы и как их исправить, пример который я привел это просто пример а не то как надо делать, там параметров намного больше которые нужно учитывать, перечитайте еще раз комментарий и по порядку попробуйте выполнить рекомендации. Также советую переписать код, в функции scan явно не стоит использовать CloseIdleConnections это нужно в отдельное место выложить.

Вероятность этого 100% т.к я специально лазил проверять где забивается.

Сколько занимает эта мапа памяти и как проводилась проверка? И опять же проблема вероятно не с ней а с тем что вы неправильно выполняете запросы, из-за чего она может забиваться.

[calculator212]

videxerion, в целом может быть проблема, если используется одна из старых версий го, но баг с этой штукой пофиксили давно https://github.com/golang/go/issues/33849

[videxerion]

calculator212,
> первое что в глаза бросается, это то что вы неправильно обрабатываете ошибки
Не думаю, Body.Close() понадобится только в том случае если соединение было успешным. Как и сказано таких соединений дай бог будет 5% от общей массы. Потому поначалу когда их вообще нет (первые пол часа перебора наверное) то и забивать такие соединения память не могут. И Body.Close() в таком случае вообще не отрабатывает ни разу.

> вам стоит почитать про http.Transport и некоторые особенности клиентов
Собственно я читал и изучал код библиотеки, но пока не понял как правильно совершать запрос, что бы запросы в никуда очищались. Потому я и здесь, хочу узнать как. Знай я как это сделать не задавал бы вопрос.

> Сколько занимает эта мапа памяти и как проводилась проверка?
Память занимает в зависимости от времени работы программы (это же утечка). Расход замерялся профайлером.

1. Потребление в диспетчере задач - 386 МиБ


2. Вывод top из pprof

Showing top 10 nodes out of 33
      flat  flat%   sum%        cum   cum%
   69.51MB 43.29% 43.29%   131.07MB 81.63%  net/http.(*Transport).getConn
   60.56MB 37.72% 81.00%    61.06MB 38.03%  net/http.(*Transport).queueForIdleConn
    7.50MB  4.67% 85.68%     7.50MB  4.67%  net.(*Resolver).internetAddrList.func1
    7.50MB  4.67% 90.35%   143.07MB 89.10%  main.scan
       6MB  3.74% 94.08%        7MB  4.36%  net.(*sysDialer).dialSingle
       4MB  2.49% 96.57%        4MB  2.49%  net.JoinHostPort
       2MB  1.25% 97.82%        2MB  1.25%  net.IPv4
    0.50MB  0.31% 98.13%       17MB 10.59%  net/http.(*Transport).dialConn
         0     0% 98.13%   143.07MB 89.10%  main.scanChunk
         0     0% 98.13%    16.50MB 10.28%  net.(*Dialer).DialContext

3. Вот что профайлер думает про функцию queueForIdleConn

.          .   1100:	// Register to receive next connection that becomes idle.
         .          .   1101:	if t.idleConnWait == nil {
         .          .   1102:		t.idleConnWait = make(map[connectMethodKey]wantConnQueue)
         .          .   1103:	}
         .          .   1104:	q := t.idleConnWait[w.key]
         .          .   1105:	q.cleanFront()
         .        6MB   1106:	q.pushBack(w)
  380.89MB   380.89MB   1107:	t.idleConnWait[w.key] = q
         .          .   1108:	return false
         .          .   1109:}
         .          .   1110:
         .          .   1111:// removeIdleConn marks pconn as dead.
         .          .   1112:func (t *Transport) removeIdleConn(pconn *persistConn) bool {

4. Деббагер GoLand показывает что эта map`а имеет в себе аж 347 956 элементов.

[videxerion]

calculator212,
> в целом может быть проблема, если используется одна из старых версий го, но баг с этой штукой пофиксили давно

В целом действительно похоже на мой случай, но у меня практически актуальная версия Golang.

└[~/Develop/GO/Gnet-Scanner]> go version               
go version go1.22.2 linux/amd64

[calculator212]

videxerion, а с какой скорость идёт сканирование?
Можно попробовать установить эти параметры

&http.Transport{
		MaxIdleConns:        10, // global number of idle conns
		MaxIdleConnsPerHost: 5,  // subset of MaxIdleConns, per-host
		// declare a conn idle after 10 seconds. too low and conns are recycled too much, too high and conns aren't recycled enough
		IdleConnTimeout: 10 * time.Second,
		// DisableKeepAlives: true, // this means create a new connection per request. not recommended
	}

[videxerion]

calculator212, программа использует одновременно не более 200 потоков. Тайм-аут у меня 200 миллисекунд. Итого скорость которую я замерял где-то 2 тысячи адресов в секунду(у меня есть функция которая измеряет скорость).
Касаемо новых параметров, опробую сразу как буду у машины

[videxerion]

calculator212, попробовал, ничего не изменилось. Размер map`ы все ширится.

[calculator212]

videxerion, а количество соединений в системе остается таким же или увеличивается? (через netstat можно проверить например)