Утечка дескриптора файла Netty - PullRequest
Новая
       9

Утечка дескриптора файла Netty

0 голосов
/ 15 октября 2018

ОС: Ubuntu 14.04
JVM: 1.8.0_181
Netty: 4.1.8 (в настоящее время не используются встроенные реализации epoll .. надеемся перейти к этому)

Нам удалось толькочтобы найти несколько узлов, демонстрирующих поведение и впоследствии включивших мониторинг, чтобы помочь отследить его дальше, наблюдаемое поведение состоит в том, что экземпляры anon_inode & pipe резко возрастают с нормального уровня ~ 1,5k & ~ 3k до сотен тысяч плюс (один экземпляр был ~ 808k и ~ 1.6M) .. нам еще предстоит получить дамп кучи, мы должны быть в состоянии сделать это сейчас, когда мониторинг уже на месте.

Обнаружено в сервисах, которые используют только Netty какклиент (а также те, у кого есть сервер, но, возможно, тот факт, что это происходит на стороне клиента, помогает сузить его)

Не отображаются журналы, которые указывают на перестройки селектора.

Во всехвероятно, это наш код, но если вы можете указать нам на то, что мы могли бы сделать, чтобы произвести это (очень редко, мы ловили сервер в этом состоянии 4 или 5 раз и несколько разre отчеты), что было бы оценено.например, я не вижу, чтобы мы создавали много экземпляров клиентской начальной загрузки, конвейера канала и т. д. Мы выполняем миллиарды вызовов в день с этой настройкой на 1000 узлов, так что это некий крайний случай.

Как частьрасследование, которое мы проводили, (немного заставляет меня хотеть нативную реализацию epoll) и обнаружило эту «интересную» последовательность вызовов из реализации java

Это из базового клиента, который пишет одну строку,он использует UDP для записи строки метрической выборки, затем закрывает / закрывает 

sendto(22, "blah:-523410803|#blah:what,hey:ho\n", 34, 0, {sa_family=AF_INET6, sin6_port=htons(2003), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
    <... sendto resumed> )            = 34
    epoll_wait(21, [{EPOLLIN, {u32=19, u64=19}}], 8192, 0) = 1
    socketpair(AF_UNIX, SOCK_STREAM, 0, [23, 24]) = 0
    close(24)                         = 0 # close one end of the pair just 
    created
    dup2(23, 22)                      = 22 # WHY? .. currently 22 is being used to write output, this should result in 22 being closed and 22 then points to the same thing as 23
    epoll_ctl(21, EPOLL_CTL_DEL, 22, 0x7f346cf1208c) = -1 ENOENT (No such file or directory) # lose interest in 22
    close(22) # close 22 (which is actually 23)

Хотя кажется, что результатом является то, что все должно быть закрыто, бонусная пара сокетов / close / dup2 / close неожиданна, сделайтеВы видите здесь дыру, которая может привести к утечке?Я знаю, что вы открыли несколько ошибок JDK, так что надеемся, что это одна из них: -)

Мы также видим, что они не используют CLOEXEC в некоторых местах, но действительно ли это проблема?(JVM когда-либо форк / exec или, может быть, docker exec / attach?)

Заранее спасибо!

...