Память не освобождается обратно в ОС
Если вы знакомы с использованием Java Selector, вы можете эмулировать тайм-аут сокета самостоятельно с помощью селектора. Полезно видеть sun.nio.ch.SocketAdaptor.
Следует соблюдать осторожность при использовании Thread.interrupt (). SocketChannel - прерыватель канала. Когда вы читаете описание InterruptibleChannel, Thread.interrupt () вызывает закрытие SocketChannel. Если вы хотите использовать SocketChannel после таймаута, вы не можете использовать функцию InterruptibleChannel.
1 ответ
Существует библиотека libvips для отслеживания и отладки количества ссылок - вы можете попробовать включить это и посмотреть, есть ли у вас утечки.
https://libvips.github.io/libvips/API/current/libvips-vips.html#vips-leak-set
Хотя из вашего комментария выше о bimg memory Похоже, что все в порядке.
Легко протестировать память libvips из Python. Я сделал эту небольшую программу:
#!/usr/bin/python3
import pyvips
import sys
# disable libvips operation caching ... without this, it'll cache all the
# thumbnail operations and we'll just be testing the jpg write
pyvips.cache_set_max(0)
for i in range(0, 10000):
print("loop {} ...".format(i))
for filename in sys.argv[1:]:
# thumbnail to fit 128x128 box
image = pyvips.Image.thumbnail(filename, 128)
thumb = image.write_to_buffer(".jpg")
т.е. несколько раз миниатюрный набор исходных изображений. Я запустил это так:
$ for i in {1..100}; do cp ~/pics/k2.jpg $i.jpg; done
$ ../fing.py *
И смотрел RES наверху. Я видел:
loop | RES (kb)
-- | --
100 | 39220
250 | 39324
300 | 39276
400 | 39316
500 | 39396
600 | 39464
700 | 39404
1000 | 39420
Пока у вас нет утечек на счетах, я думаю, что вы видите ожидаемое поведение. Процессы Linux могут выпускать страницы только в конце кучи обратно в ОС (посмотрите вызовы srs brk и sbrk):
https://en.wikipedia.org/wiki/ Sbrk
Теперь представьте, если 1) libvips выделяет 6 ГБ, 2) среда выполнения Go выделяет 100 КБ, 3) libvips выпускает 6 ГБ. Ваша libc (вещь в вашем процессе, которая будет вызывать sbrk и brk от вашего имени) не может вернуть 6 ГБ обратно в ОС из-за выделения 100 КБ в конце кучи. Некоторые реализации malloc демонстрируют лучшее поведение при фрагментации памяти, чем другие, но стандартная версия linux довольно хороша.
1114 На практике это не имеет значения. malloc будет повторно использовать дыры в вашем пространстве памяти, и даже если этого не произойдет, они все равно будут выгружены под давлением памяти и не будут в конечном итоге съедать оперативную память. Попробуйте запустить ваш процесс в течение нескольких часов, и посмотрите RES. Вы должны увидеть, как оно подкрадывается, но затем стабилизируется.
(Я совсем не специалист по ядру, вышеизложенное - только мое понимание, исправления очень приветствуются, конечно)