Пользовательские процессы в D-состоянии приводят к сбросу сторожевого таймера с использованием Linux 2.6.24 и процессора arm
Большинство процессов пользовательского пространства заканчиваются в D-состоянии после того, как устройство работает в течение 3-4 дней, когда оно работает на процессоре ARM. Сверху o/p видно, что процессы, находящиеся в D-состоянии, ожидают системных вызовов "page_fault" и "squashfs_readpage". В конечном итоге это приводит к сбросу сторожевого таймера. Процессы, которые переходят в D-состояние, могут занять необычно много времени для восстановления.
Ниже приводится вершина о / п, когда система попадает в беду:
top - 12:00:11 up 3 days, 2:40, 3 users, load average: 2.77, 1.90, 1.72
Tasks: 250 total, 3 running, 238 sleeping, 0 stopped, 9 zombie
Cpu(s): 10.0% us, 75.5% sy, 0.0% ni, 0.0% id, 10.3% wa, 0.0% hi, 4.2% si
Mem: 191324k total, 188896k used, 2428k free, 2548k buffers
Swap: 0k total, 0k used, 0k free, 87920k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1003 root 20 0 225m 31m 4044 S 15.2 16.7 0:21.91 user_process_1
3745 root 20 0 80776 9476 3196 **D** 9.0 5.0 1:31.79 user_process_2
129 root 15 -5 0 0 0 S 7.4 0.0 0:27.65 **mtdblockd**
4624 root 20 0 3640 256 160 **D** 6.5 0.1 0:00.20 GetCounters_cus
3 root 15 -5 0 0 0 S 3.2 0.0 43:38.73 ksoftirqd/0
31363 root 20 0 2356 1176 792 R 2.6 0.6 40:09.58 top
347 root 30 10 0 0 0 S 1.9 0.0 28:56.04 **jffs2_gcd_mtd3**
1169 root 20 0 225m 31m 4044 S 1.9 16.7 39:31.36 user_process_1
604 root 20 0 0 0 0 S 1.6 0.0 27:22.76 user_process_3
1069 root -23 0 225m 31m 4044 S 1.3 16.7 20:45.39 user_process_1
4545 root 20 0 3640 564 468 S 1.0 0.3 0:00.08 GetCounters_cus
64 root 15 -5 0 0 0 **D** 0.3 0.0 0:00.83 **kswapd0**
969 root 20 0 20780 1856 1376 S 0.3 1.0 14:18.89 user_process_4
973 root 20 0 225m 31m 4044 S 0.3 16.7 3:35.74 user_process_1
1070 root -23 0 225m 31m 4044 S 0.3 16.7 16:41.04 user_process_1
1151 root -81 0 225m 31m 4044 S 0.3 16.7 23:13.05 user_process_1
1152 root -99 0 225m 31m 4044 S 0.3 16.7 8:48.47 user_process_1
Еще одно интересное наблюдение состоит в том, что когда система попадает в эту проблему, мы можем постоянно видеть процесс "mtdblockd", работающий в верхней части окна. Мы отключили своп на этом устройстве. в устройстве нет явной утечки памяти.
Есть идеи, какие могут быть возможные причины, процессы застряли в D-состояниях?
1 ответ
D-состояние означает, что процессы застряли в ядре в состоянии сна TASK_UNINTERRUPTIBLE, вряд ли это будут ошибки в коде обработки ошибок Squashfs, потому что если процесс выйдет из Squashfs с мьютексом, система быстро остановится, как и другие запущенные процессы Сквош и спал вечно в ожидании мьютекса. Вы также увидите низкую среднюю загрузку / системное время, так как большинство процессов будут находиться в спящем режиме. Кроме того, нет никаких доказательств того, что Squashfs совершил какие-либо ошибки ввода-вывода.
Средняя нагрузка (2,77) и системное время (75,5%) чрезвычайно высоки, в сочетании с тем, что в Squashfs_readpage (который завершается, но медленно) указывается множество процессов, что указывает на перебои в работе системы. Недостаточно памяти, и система тратит все свое время на постоянное (повторное) требование страниц подкачки с диска. Это будет учитывать тот факт, что многие процессы находятся на Squashfs_readpage, системное время чрезвычайно велико, потому что система тратит большую часть своего времени на Squashfs в задачах декомпрессии, интенсивно использующих процессор. Другие процессы застряли в Squashfs, ожидающих мьютекс декомпрессора (только один процесс может быть декомпрессирован за один раз, потому что состояние декомпрессора является общим).