Java периодически зависает на фьютексе и очень низком выходе ввода-вывода

В настоящее время мое приложение периодически блокируется в IO, и вывод очень низкий. Я использую некоторую команду для отслеживания процесса.

Используя jstack, я обнаружил, что приложение зависает в FileOutputStream.writeBytes.

Я обнаружил это, используя strace -f -c -p pid для сбора информации о системных вызовах. В обычной ситуации он имеет как фьютекс, так и системные вызовы записи. Но когда все пошло не так, остались только системные вызовы фьютексов. Приложение продолжает вызывать фьютекс, но все терпит неудачу и выдает ETIMEDOUT, вот так:

<futex resumed>  =-1 ETIMEDOUT (Connecton timed out)
futex(Ox7f823, FUTEX_WAKE_PRIVATE,1)=0
futex(Ox7f824, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME) =-1<unfinished>
<futex resumed>  =-1 ETIMEDOUT (Connecton timed out)
futex(Ox7f823, FUTEX_WAKE_PRIVATE,1)=0
futex(Ox7f824, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME) =-1<unfinished>

Эта проблема возникает периодически, продолжается в течение нескольких минут или часов и снова становится нормальной.

В частности, при блокировке в IO echo 3 > /proc/sys/vm/drop_caches всегда временно переводит его в нормальное состояние. Я погуглил и нашел похожий пример, список ниже.

  1. високосная секунда. Не работает, ntpd нашей системы остановлен.
  2. прозрачная ошибка огромных страниц. https://bugzilla.redhat.com/show_bug.cgi?id=879801 Это очень похоже на мою проблему, но мой процесс khugepaged работает нормально, и нагрузка всегда почти нулевая. Обычно drop_caches работает и для моего приложения. И моя система тоже многоядерная и с большим объемом памяти. Это не работает для меня. Так кто-нибудь встречал ту же проблему или знаком с этой проблемой?

Немного информации о моей системе. ОС: Redhat 6.1, ядро ​​версии 2.6.31

JDK:1.7.0_05

Процессор: X5650, 24 ядра

Память: 24 ГБ и 48 ГБ


java io huge-pages futex
person bforevdr    schedule 28.08.2015    source источник
comment
Я боюсь, что JDK:1.7.0_05 слишком стар. Вы должны попробовать последнюю версию Java7. Это самый простой первый шаг.   -  person sibnick    schedule 01.09.2015
comment
@bforevdr Похоже на проблему с ядром, вы пробовали переустановить дату своей системы и попробовать еще раз? используя что-то вроде этого date -s "`date`" ?   -  person kucing_terbang    schedule 01.09.2015
comment
Раньше пробовал jdk 1.8, вроде не работает, буду подробный тест. Также я обнаружил, что при блокировке потоки gc продолжали вызывать futex(), но терпели неудачу. Но из jstat -gcutil YGCT и FGCT были нормальными, заняли всего несколько секунд.   -  person bforevdr    schedule 01.09.2015
comment
Можете ли вы проверить трафик пейджингового ввода-вывода (подкачка) и использование блочного устройства? Используйте iostat -x -m -d 1 и, возможно, также vmstat и top. Возможно, ОС просто использует оперативную память и начинает переключаться на тот же физический диск.   -  person Radu    schedule 16.10.2015
comment
Вероятно, связано с ошибкой futex_wait() в Linux... из-за чтобы зафиксировать b0c29f79ecea. Платформа Red Hat и версия ядра выглядят примерно так.   -  person jww    schedule 24.03.2018

Ответы (2)


arrow_upward
3
arrow_downward

Может быть, ошибка ядра в futex_wait()?

Вы можете прочитать об этом здесь: https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64

person Guy Sela    schedule 12.08.2016

arrow_upward
0
arrow_downward

В дополнение к скачкам часов и вышеупомянутой (довольно старой) ошибке ядра THP, еще одной распространенной причиной неожиданной блокировки java при вводе-выводе является чтение very< /em> медленный и блокирующий /dev/random, который некоторые библиотеки предпочитают более часто используемому и гораздо более эффективному /dev/urandom.

Простой способ узнать, был ли это виновник:

sudo mv /dev/random /dev/random.real
sudo ln -s /dev/urandom /dev/random

... затем перезапустите приложение и посмотрите, остановит ли оно блокировку ввода-вывода. После завершения теста вы, вероятно, захотите восстановить /dev/random:

sudo mv /dev/random.real /dev/random

... и открыть ошибку, когда поставщик приложения просит использовать /dev/urandom, где это уместно.

person Aex Aey    schedule 07.05.2019