Как предотвратить последовательный шаблон паузы Java в Linux Mint

У меня есть приложение Java, работающее на Linux Mint. КАЖДУЮ минуту программа показывает очень заметное замедление -- паузу. Пауза составляет 3-4 секунды. Когда мы запускаем другие экземпляры той же программы, они также приостанавливаются на 3–4 секунды каждую минуту. Каждая программа останавливается в разные секунды минуты.

последнее обновление:

После последнего обновления (ниже) увеличение количества потоков в пуле потоков привело к исчезновению проблемы с графическим интерфейсом. После примерно 40 часов работы мы обнаружили утечку потока в вызове Jetty HttpClient blocking-GET (Request.send()). Чтобы объяснить механику, используя класс Executor: основной поток запускается каждые несколько минут. Он использует Executor для запуска независимого потока для вызова хоста с помощью HTTP-команды GET, HttpClient.request.send() Jetty.

Примерно через 40 часов работы произошел всплеск количества потоков, запущенных в пуле HttpClient. Итак, в течение 40 часов одни и те же потоки работали нормально. Рабочая гипотеза состоит в том, что примерно в это же время один или несколько вызовов send() не завершились или истекло время ожидания и не вернулись в вызывающий поток. По сути, этот/эти потоки висят внутри клиента Jetty.

При просмотре каждого регулярного цикла в jVisualMV мы видим нормальное поведение каждого цикла; некоторые потоки HttpClient запускаются для хоста GET, выполняются и исчезают всего за несколько секунд. Также на мониторе около 10 потоков, принадлежащих пулу потоков Jetty HttpClient, которые «присутствуют» в течение (сейчас) 10 часов.

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

  1. Что может произойти внутри HttpClient, что может просто повесить Request.send()
  2. Каков тайм-аут при возврате вызова? Я думаю, что все еще будут абсолютные тайм-ауты или проверки на блокировку и т. Д. (Нет?)
  3. Can the I/O system hang and leave the caller-thread hanging -- While Java obediently ...
    • Fires the manager thread at the scheduled time, then
    • Происходит следующее Http.Request.send(),
    • Новые потоки из пула запускаются для следующей отправки (что, по-видимому, и произошло).
    • В то время как более ранний send() застрял в подвешенном состоянии
  4. Могу ли я ограничить или иным образом очистить эти застрявшие темы?

Это происходило до того, как мы увеличили размер пула потоков. Произошло то, что «вина» стала больше фокусироваться на проблемной области. также мы с подозрением относимся к базовой системе, потому что у нас снова были зависания с Apache HttpClient примерно в одно и то же (не конкретное) время суток.

(предыдущее обновление)...

Наблюдаемое поведение приостановки заключается в том, что графический интерфейс JavaFX не обновляется/не обновляется; часы дисплея (textView), вызов setText() был зарегистрирован во время замораживания с двумя обновлениями x в секунду (это новая информация). Часы не обновляются (в Mint Linux), они продолжают обновляться при работе в Windows. Чтобы не повторяться в вопросах о сборщике мусора, журналах, зондах и т. д., ответ будет таким же; мы провели обширную диагностику в течение нескольких недель. Проблема, безошибочно, представляет собой сочетание: Linux JVM / Linux Mint / Threads (для JavaFX). Другая часть новых данных заключается в том, что увеличение количества пулов потоков на +2, по-видимому, устраняет зависание — необходимы дальнейшие испытания, чтобы подтвердить это и настроить числа. Однако возникает вопрос: Каковы параметры, определяющие разницу между двумя платформами??

Мы запускали несколько экземпляров программы в Windows в течение нескольких дней без пауз. Когда мы запускаем платформу Mint Linux, мы видим зависание, оно очень последовательное.

Программа имеет несколько запущенных потоков, работающих по расписанию. Один поток открывает Интернет для http-сокета. Когда мы закомментируем эту область, пауза исчезнет. Однако мы не видим такого поведения в Windows. Эксперименты указывают на что-то специфическое для сетевой подсистемы ввода-вывода Mint, планирования Linux, JVM Linux Java 8 или некоторого взаимодействия между ними.

Как вы можете догадаться, мы рвем на себе волосы. Например, мы отключили логирование, а пауза осталась. Мы возобновили регистрацию и только что сделали один вызов http-серверу с паузой каждые 60 секунд с тем же отсчетом секунд. Это происходит даже тогда, когда мы не делаем никакой другой обработки. Мы пробовали разные http-библиотеки и т. д. Совершенно очевидно, что это JVM или Linux.

Кто-нибудь знает способ решить эту проблему?


person will    schedule 16.08.2014    source источник
comment
Вы следили за вывозом мусора? Это может быть виновником.   -  person assylias    schedule 16.08.2014
comment
Все, включая вывоз мусора, контролируется. Мы совершенно уверены, что проблема связана с JVM, вводом-выводом и/или Linux. Различие, по-видимому, заключается в том, как ThreadPool реализованы для Linux JVM. Как я уже сказал, в Windows работает нормально, в Linux пауза. Эксперименты с размером пула потоков демонстрируют некоторое улучшение. Мы не уверены, почему они разные; если это действительно проблема или размер пула скрывает основную причину.   -  person will    schedule 17.08.2014
comment
Что происходит во время паузы? Могут ли другие потоки прогрессировать? Или они заморожены (как вы говорите) или просто замедлены? Какое поведение системы, которое вы наблюдаете, говорит вам о том, что произошла пауза? Какова активность ЦП и ввода-вывода системы во время паузы?   -  person Stuart Marks    schedule 17.08.2014
comment
Вы запускали VisualVM для него и видели, что можно запустить, когда он приостанавливается?   -  person chrylis -cautiouslyoptimistic-    schedule 17.08.2014
comment
VisualVM только что показал потоки, работающие, как и ожидалось. ГК не проблема. Потоки продолжают работать, графический интерфейс JavaFX не обновляется до 3-5 секунд, как описано. Часы обновляются каждые 0,5 секунды. Мы сделали System.out.println() при обновлении часов setText(). SysOut показывает, что другие потоки работают как положено, экран заморожен (приостановлен).   -  person will    schedule 17.08.2014
comment
@will Основные отличия, которые я могу придумать по сравнению с JavaFX, следующие: (i) потоки обрабатываются по-разному в Windows и Linux, и у вас может быть проблема с безопасностью потоков, которая проявляется только в одном (может быть, вы делаете вещи FX вне потока FX? ) (ii) фактическое отображение выполняется собственной библиотекой, которая отличается для Windows и Linux.   -  person assylias    schedule 17.08.2014
comment
@assylias ... Во-первых, JavaFX выдает исключение, когда вы делаете что-то, связанное с JavaFX, в другом потоке. Таким образом, мы смогли устранить эти ошибки. Кроме того, во всех потоках есть блоки Try/Catch для обнаружения чего-либо подобного.   -  person will    schedule 23.08.2014
comment
Я видел аналогичную проблему, когда http-связь зависала. Оказалось, что ротация журнала (то есть архивирование и ротация файла журнала) приостановила весь процесс.   -  person Elad Tabak    schedule 25.10.2018