Всем привет
Есть кусок кода- который выполняется в многопоточном режиме- в чем суть
Код не менялся,ничего не менялось- лишь нарастал объем данных ,которые этот код обрабатывал и вот в какой то момент я обнаруживаю что результат работы кода - условно посчиаем его в записях в бд стал 900 к ,вместо положенных 1.7 млн
иду на сервер - смотрю что там - там на 100% загружены 10 ядер
при этом прилоежние работу не продолжает но и не стопается ( добавил специально логи )
очень похоже на дед лок.
прогнал все это дело 4 раза - всегда блочится похоже в одном и том же месте тоесть грубо говоря на 900 к записи все дедлочится и привет.Но разве такое возможно чтобы дедлок был всегда идентичен- тоесть работает приложение все норм и бац на 91231212 записи все блочится и на следующий прогон именно на том же порядковом номере .
Есть еще предположение что приложение упирается в лимиты по памяти и какие то потоки не могут получить свои данные изза этого и все так же виснет хз

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

это рандом номер- вычислить на какой именно записи происходит не представляется возможным.
вообщем при старте процесса задйствованы 10 ядер- и когда происходит нечтно похожее на дедлок - то все 10 ядер так и остаются загружены на 100% при этом дальше процесс уже не идет

бд не умирает ,она,по крайне мере в логах все норм
ну и до обновления данных - все было норм- спокойно держала нагрузку такую и принимала от 1,5 и выше записей

я с тобой согласен что если бы 1.7 просто превратились в 900 к то вопросов бы я не задавал тут- проблема в том,что приложение не завершает свою работу ,при этом ядра ,нагружены на 100ку
очень похоже на какую то блокировку потоков ,но как тут выше отписались при дедлоке ядра не грузятся на 100%
а тут картина такая что именно на 100ку все загружено .-Отпускает только тогда когда ты стопаешь приложение.

дело в том,что код то не менялся - он работал и работал себе и тут новая дата подъехала и привет

суть вообще этого приложения
перегон данных из монго в постргрес

Я склонялся к дед локу ,но раз при дедлоке не может быть 100% загрузки ядер ,буду сейчас вычленять опытным путем ,какой именно элемент данных вызывает это состояние приложения.

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

петро какой метод занимает 100 я тебе и без профилирофчика скажу - тот который и есть многопоточный)
я туда накинул маркеров - так вот все идет хорошо ,где то 900к элементов обрабатываются и далее происходит что то ,что не дает никаких ошибок ни в бд,ни в приложении,ни на серваке,при этом по маркерам я вижу что метод не закончил свою работу


вот тут я не дожидаюсь сообщения "ждем потоки" ,что говорит,что потоки чем то заняты

мб это livelock

Значит он всегда работал неверно, и проблема проявляется только при определенных условиях/объемах данных.
так объем не изменился по сути 17 гиг против 17.5,а вот что то в данных не то - видимо это и есть причина сейчас буду вычленять проблему
пс.сейчас я прогоню заново и пойму хотя бы на каком элменте происходит эта проблема
ибо всегда оно в одном и том же месте- далее я сделаю прогон тех элементов которые попадают в этот пул( там 8 потоков - каждый берет в процес по элементу)
прогоню отдельно каждый из них и найду хотя бы тот элемент ,который вызывает эту проблему

все там есть,петро не мешай плиз в этой теме - дай люди со знаниями накинут варинты проблемы.

Стоит уменьшить кол-во выделяемой памяти JVM, тогда проблема скорей всего воспроизведется раньше. Еще как вариант - увеличить кол-во потоков, но это усложнить последующий анализ.

PS: Хм.. Я не всегда могу редактировать свои сообщения?
память тут к сожалению не причем-я тоже думал что мы упираемся в лимиты - накинул памяти и все равно состояние это возникает в одном и том же месте- я думаю это какие то проблемы с данными ,так как раньше все работало с такими же объемами и не было никаких проблем.
Тоесть если бы теория памяти была верна - мы бы при увеличении или уменьшении получали это состояние в разный момент времени- но оно всегда одно и тоже- точней не время а именно последние логи - обработка такого то элемента и привет подвисание

спасибо за развернутый овет- сейчас получу это состоние блокировки и сделаю все что вы выше описали

объекты все одинаковые - тоесть если бы было не так оно бы не работало и раньше
но кому то плохееет явно - что метод не завершается ,а вот кому надо понять -так как в логах везде тишь да гладь да божья благодать

человек,а не ты- ты то сиди ровно и не мешай людям общаться
пс.давно пора администрации форума сделать функцию Unwanted чтобы петро забыл сюда дорогу)

набрал топ - получил процесс который 900% занимает ЦПУ
команда выше не работает -


ни одна из этих команд не приводит к успеху
какой то конфликт с монго сервером судя по всему

я запускаю ctl сервис ,хз где там джава спряталась) но она точно есть ибо приложение работает

бд тут не причем
900% цпу висит на процессех прилоежния
где то рядом пострегрес с 1.3 %
так что иди спать конь педальная)

да это именно оно - приложение запускается sudo systemctl start app.service

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

сейчас временно убрал многопоточку - посмотрим что будет в обычном режиме - упрется в тоже место или нет
сейчас я уже думаю что бд - вероятно не может такое количество засейвить- и где то что то превращается в вечно ждущеее состояние

если в обычном режиме все пройдет гладко- значит буду уменьшать количество потокв.

пс.как снять тред дамп с ctl службы я завтра спрошу у админов- может есть какой то иной способ

Ок, ну эт хорошо, значит локализовали что это хотя бы наше приложение. А дальше нужно искать уже точно строку кода, вполне возможно что там какой-то баг который в вечный цикл вводит приложение. Это очень быстро отыскивается с помощью thread dump'a. И этому нужно обязательно обучиться - снимать дампы это одно из первых и лучших средств траблшутинга. Поэтому лучше сразу потратить время и разобраться.
авторCommand 'jcmd' not found, but can be installed with:jcmd устанавливается вместе с JDK. Т.е. находится в JAVA_HOME/bin, ищи там. Однако в комплект JRE эта утилита не входит, поэтому если у тебя именно JRE - се ля ви. Нужно будет поставить JDK.
pavel_nvне знаю как насчет jcmd
но на моем опыте обычно используется
jstack <PID> - снять тред-дамп
jmap <PID> - снять хип-дампЭти тоже входят только в JDK, но на сегодняшний день jcmd их вытесняет. Она в себя включает эти две возможности, а также многие другие:
jcmd helpThe following commands are available:
Compiler.CodeHeap_Analytics
Compiler.codecache
Compiler.codelist
Compiler.directives_add
Compiler.directives_clear
Compiler.directives_print
Compiler.directives_remove
Compiler.perfmap
Compiler.queue
GC.class_histogram
GC.finalizer_info
GC.heap_dump
GC.heap_info
GC.run
GC.run_finalization
JFR.check
JFR.configure
JFR.dump
JFR.start
JFR.stop
JVMTI.agent_load
JVMTI.data_dump
ManagementAgent.start
ManagementAgent.start_local
ManagementAgent.status
ManagementAgent.stop
Thread.print
VM.class_hierarchy
VM.classloader_stats
VM.classloaders
VM.command_line
VM.dynlibs
VM.events
VM.flags
VM.info
VM.log
VM.metaspace
VM.native_memory
VM.print_touched_methods
VM.set_flag
VM.stringtable
VM.symboltable
VM.system_properties
VM.systemdictionary
VM.uptime
VM.version
help

я могу локально прогнать впринципе эти данные,локально у меня установлен jdk ,правда не линукс ,а винда.

нет прав у меня на установку

я сейчас локально запустил - у меня тут есть jdk ,id процесса,который грузит ядра я увижу в виндовском диспетчере задач - не уверен что это именно тот id,который можно будет посдавить в jcmd ,но попробуем

где то через два часа система стопорнется и попробуем

пс.если кто то знает как на винде найти процессы и сколько они откушали ресурсов - подскажите пож

посмотрел этот скрипт - про джаву там ничего нет - только настройки с которыми запускается приложуха

набрал java --version