Как избавиться от плодящихся threads (java потомки) в Linux при использовании бекенда на Kotlin (Ktor + Coroutines)?

Question

[Антон]

Есть бекенд, (парсер) написанный на Kotlin (фреймворк Ktor + Coroutines + PostgreSQL + Redis) и скомпилированный в jar.
Проблема заключается в том, что постепенно нарастают threads ( если смотреть в htop , то это thr).
Запускаю в терминале парсер командой

sudo java -Xmx256m -Xms256m -jar zeon-backend-0.0.1-all.jar -Xopt-in=kotlin.RequiresOptIn. parser >build/zeon-parser.log 2>&1 &

Захожу спустя день в утилиту htop, а там отображает порой до 3000 thr

При этом память (озу) не утекает практически, все возможные открытые транзакции с postgres закрываются и не накапливаются, с редисом тоже всё хорошо.

Если кратко, то "парсер" ходит по аудио потокам (интернет радио станции), посредством http запросов (okhttp3) и потом все соединения и чтение потока закрывается.
Запускаю парсер в корутинах, в скоупе на Dispatcher.IO потоке. Да собственно как только я уже его не запускал, одна и та же ситуация. Спустя день если зайти - пара тысяч thr накапливается.

Также мониторил через VisualVM. Ничего сверхъестественного там не увидел. В какую сторону копать, понятия не имею. Не особо хочется делать костыль, аля крашить парсер в коде спустя n кол-во времени и перезапускать автоматом с помощью юнита systemd..

Comments

[pfg21]

почитать код, текут "треды" :)

[Антон]

pfg21, Да собственно если даже парсить ничего не буду, а просто в цикле корутины запускать начну, даже не создавая новых экземпляров coroutine scope , всё равно треды набегут. Я хз как посмотреть, что именно там так "раздраконивается".. ((

[pfg21]

Антон, самое тупое - посмотреть условия, при которых создаются и уничтожаются треды.
явно есть косяки с уничтожением отработанных тредов.
память освобождается (коль она не течет), а тред не уничтожается.

[Антон]

pfg21, просто я сам в коде нигде треды не создаю, кроме корутины, которая на IO диспатчере крутится, и ведь она имеет фиксированный размер в 64 потока. PS: а памяти парсер потребляет спустя сутки больше, чем допустим спустя 10 минут. Но немного увеличенное потребление памяти связанно ведь с тем, что у меня как раз 3 тысячи тредов накопилось.. Просто иногда думаю, может ли это CoroutineScope порождать треды под себя, если ему 64 потока в какой то момент становится мало.. И убийство скоупа, с последующим его новым созданием, врятли что то освободит.. (

Answer 1

[mayton2019]

Несколько мыслей. Не претендует на правильность. Особенностей Котлин не знаю но подозреваю что он под капотом просто использует Java Threads.

1) Java используют модель потоков при коророй 1 поток ОС не равен потоку JVM. Обычно 1 поток ОС может обслуживать много Java threads. В состоянии покоя threads мало потребляют ресурсов.

2) Я пока не вижу проблем до тех пор пока у вас нет нехватки Heap. 1 Thread по умолчанию аллоцирует 1Мб поэтому 1000 тредов могут у вас скушать гигабайт. Есть опция командной строки которая это регулирует. Ее надо трогать аккуратно чтоб не получить другую ошибку типа Stackoverflow.

3) По поводу того чем заняты threads. Сделайте дамп стека потоков как один чел тут пишет https://www.baeldung.com/java-thread-dump

И посмотрите на вершине стека какую функцию каждый поток выполняет. Если например они друг друга блокируют или ждут I/O - это будет повод поговорить с программистом. Может код написан неоптимально.

4) Кроме того программист должен был заложить в конфиги регулятор числа рабочик потоков в пуле. Это может быть нечто вроде

Executors.newFixedThreadPool(....);

короче поищите в сорцах. Если не заложил - попросите пускай сделает это property.

Comments

[Антон]

Сделал дамп в течении 2 дней работы парсера. Есть .jfr файл, есть программа JDK Mission Control. Только вот не совсем понял, куда там смотреть, и на что обращать внимание.
Дамп весит 5 гбайт, брал небольшой кусок для анализа.
Единственное что вроде как понял, что вкладка Thread Dumps нужна.
Там пишет

spoiler

2022-07-26 04:00:45
Full thread dump OpenJDK 64-Bit Server VM (11.0.15+10-Ubuntu-0ubuntu0.20.04.1 mixed mode):

Threads class SMR info:
_java_thread_list=0x0000ffff2c153e30, length=1014, elements={
0x0000ffff8c015800, 0x0000ffff8c1e0800, 0x0000ffff8c1e5000, 0x0000ffff8c1fc800
................
и куча вот такого текста:
................
"OkHttp listen2.myradio24.com" #3448 daemon prio=5 os_prio=0 cpu=1489.07ms elapsed=20062.16s tid=0x0000ffff601dc800 nid=0x329b82 waiting on condition [0x0000fffea8bfd000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
- parking to wait for <0x00000000f150a240> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
at java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11.0.15/SSLSocketImpl.java:1038)
at okio.InputStreamSource.read(JvmOkio.kt:90)
at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:129)
at okio.RealBufferedSource.skip(RealBufferedSource.kt:405)
at okhttp3.internal.http2.Http2Connection$ReaderRunnable.data(Http2Connection.kt:647)
at okhttp3.internal.http2.Http2Reader.readData(Http2Reader.kt:180)
at okhttp3.internal.http2.Http2Reader.nextFrame(Http2Reader.kt:119)
at okhttp3.internal.http2.Http2Connection$ReaderRunnable.invoke(Http2Connection.kt:618)
at okhttp3.internal.http2.Http2Connection$ReaderRunnable.invoke(Http2Connection.kt:609)
at okhttp3.internal.concurrent.TaskQueue$execute$1.runOnce(TaskQueue.kt:98)
at okhttp3.internal.concurrent.TaskRunner.runTask(TaskRunner.kt:116)
at okhttp3.internal.concurrent.TaskRunner.access$runTask(TaskRunner.kt:42)
at okhttp3.internal.concurrent.TaskRunner$runnable$1.run(TaskRunner.kt:65)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.15/ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.15/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.15/Thread.java:829)

имеет ли это какое то значение, - не пойму. Стоит ли обратить внимание на okhttp3 и делать его подозреваемым - не знаю ))

[mayton2019]

Я думаю что все у вас в порядке. Просто интернет радио медленно отдает трафик.

По поводу плодящихся Java-threads. 215 штук на процесс. Я не готов сказать много это или мало
для Kotlin-приложения. Если это число стационарно и не растет - то причин для беспокойства нет. Вы просто достигли макс-величины пула.

Я не специалист по Kotlin. И я не знаю какие крутить гайки чтобы корутины быстрее отпускали потоки.
В любом случае поговорите со разработчиком zeon-backend.

[Антон]

По поводу плодящихся Java-threads. 215 штук на процесс.

У меня плодится до 3000 threads. В итоге парсер перестает нормально работать/висит. zeon-backend я и делал, по этому говорить не с кем ((

[mayton2019]

Антон, странно все это. Можно предложить заняться реверс инжинирингом, но это авантюра. Я бы себе такого не посоветовал.

[Антон]

mayton2019, каким еще к чёрту реверс-инжинирингом?)) У меня есть весь исходный код. Я из него скомпилировал JAR. Исходя из снятого 5-ти гигового дампа, видно, что java thread'ы содержат внутри okhttp инстансы или коннекшены..
Вот один из них:

"OkHttp listen2.myradio24.com" #3448 daemon prio=5 os_prio=0 cpu=1489.07ms elapsed=20062.16s tid=0x0000ffff601dc800 nid=0x329b82 waiting on condition [0x0000fffea8bfd000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
- parking to wait for <0x00000000f150a240> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)

Что это может означать, почему они накапливаются и точно ли они являются источником порождения threads - никак не могу разобраться. Такое чувство, что connection даже по таймауту не отваливается и остается висеть почему то..

[Антон]

Вот кстати скрин из htop на данный момент. Threads стало уже больше 2к.

[mayton2019]

Ты разработчик? Это твой код? Или ты просто его унаследовал от кого-то и пытаешся разобраться? Я почему спрашиваю. Можно сильно ускорить решение проблемы если знать условия. Просто с 1 поста я посчитал тебя админом или девопсом и дальше мои советы строились из этого.

Уж извини если обидел :)

[Антон]

mayton2019, да нет, не обидел. Нет, сам написал на Kotlin. Я думаю нужно просто создать фиксированный пул java потоков, и посадить на них корутины.. Потому что скоуп корутин, как мне кажется, порождает слишком много всего, вместо того чтобы переиспользовать в некоторых моментах. Либо я упустил что то очень важное и по этому такая ситуация происходит.

[mayton2019]

Антон, скорее всего ты где-то не закрываешь какие-то ресурсы. Коннекшены. Сетевые сокеты. Дальше я просто не могу говорить у меня фантазия закончилась. Нужны сорцы.

Выложи в гитхаб ну хотя-бы ту ключевую часть которая в стектрейсе.

[Evgeny Novoselov]

Антон, интересно, а 3к тредов в каком статусе? В VisualVM есть плагин или вкладка Threads https://docs.oracle.com/javase/8/docs/technotes/gu... . Пальцем в небо, может быть они в статусе ожидания на чтение из ресурса информации? Кажется все таки неверно спроектировано приложение

[Антон]

Evgeny Novoselov, Вот вкладка threads в VisiualVM из дампа на 5 гб. (отсортировал список по статусу Running) .
98% названий , это OkHttp и 5-7 одних и тех же интернет адресов (listen7.myradio24.com, italo.italo.nu, radio.adds.su, air.dnbfm.ru...)

Парсер пробегает примерно 800 радиостанций. Других ~790 адресов в этом списке тредов (в состоянии Running) - нет.
Ширина канала, скорость, при этом на VPSке нормальная

Hosted by htp GmbH (Hannover) [263.92 km]: 8.166 ms
Testing download speed................................................................................
Download: 2041.41 Mbit/s
Testing upload speed......................................................................................................
Upload: 1165.67 Mbit/s

[Антон]

Evgeny Novoselov, а вот Thread Dump

"OkHttp listen6.myradio24.com" #1373 daemon prio=5 os_prio=0 cpu=1875.19ms elapsed=84516.82s tid=0x0000ffff44149800 nid=0x3280ad waiting on condition  [0x0000fffed55fd000]
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
        - parking to wait for  <0x00000000f746ed30> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
        at java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
        at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11.0.15/SSLSocketImpl.java:1038)
        at okio.InputStreamSource.read(JvmOkio.kt:90)
        at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:129)
        at okio.RealBufferedSource.skip(RealBufferedSource.kt:405)
        at okhttp3.internal.http2.Http2Connection$ReaderRunnable.data(Http2Connection.kt:647)
        at okhttp3.internal.http2.Http2Reader.readData(Http2Reader.kt:180)
        at okhttp3.internal.http2.Http2Reader.nextFrame(Http2Reader.kt:119)
        at okhttp3.internal.http2.Http2Connection$ReaderRunnable.invoke(Http2Connection.kt:618)
        at okhttp3.internal.http2.Http2Connection$ReaderRunnable.invoke(Http2Connection.kt:609)
        at okhttp3.internal.concurrent.TaskQueue$execute$1.runOnce(TaskQueue.kt:98)
        at okhttp3.internal.concurrent.TaskRunner.runTask(TaskRunner.kt:116)
        at okhttp3.internal.concurrent.TaskRunner.access$runTask(TaskRunner.kt:42)
        at okhttp3.internal.concurrent.TaskRunner$runnable$1.run(TaskRunner.kt:65)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.15/ThreadPoolExecutor.java:1128)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.15/ThreadPoolExecutor.java:628)
        at java.lang.Thread.run(java.base@11.0.15/Thread.java:829)