Я перезагрузил наш сервер сегодня утром, но есть бесчисленное количество процессов, которые, кажется, работали более 600 дней?
Может кто-нибудь пролить свет?
Дата и время машины правильные:
[root@abc youdev]# hwclock
Wed 23 Jul 2014 15:50:35 BST -0.828434 seconds
[root@abc youdev]# date
Wed Jul 23 15:50:35 BST 2014
[root@abc youdev]#
Вот результат "верха" и "времени безотказной работы"
[youdev@abc ~]$ top
top - 15:13:40 up 6:52, 4 users, load average: 22.18, 21.86, 21.23
Tasks: 452 total, 11 running, 441 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32829408k total, 4504280k used, 28325128k free, 317572k buffers
Swap: 16482296k total, 0k used, 16482296k free, 574688k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
113 root 20 0 0 0 0 S 0.3 0.0 300194:22 events/14
1 root 20 0 19356 1540 1224 S 0.0 0.0 9712065h init
2 root 20 0 0 0 0 S 0.0 0.0 4788099h kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 10237405h ksoftirqd/0
... snip ...
55 root RT 0 0 0 0 R 0.0 0.0 300194:20 migration/13
56 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/13
[youdev@abc ~]$ uptime
15:13:47 up 6:52, 4 users, load average: 22.16, 21.86, 21.24
[youdev@abc ~]$
Запуск CentOS версии 6.4 (финал)
По предположению @jski, сработала полная холодная перезагрузка машины.
Значения Time + вершины вернулись к (практически) нулю.
Время + представляет время ЦП, или, более конкретно, «совокупное время ЦП, которое использовали процесс и дочерние элементы процесса».
Общее время процессора, которое задача использовала с момента ее запуска. Когда «Накопительный режим» включен, каждый процесс отображается с указанием времени ЦП, которое он и его мертвые дочерние элементы использовали. Вы переключаете «Накопительный режим» с помощью «S», которое является параметром командной строки и интерактивной командой. См. Интерактивную команду «S» для получения дополнительной информации об этом режиме.
Вот ссылка, объясняющая процессорное время, если вам интересно.
Мы столкнулись с аналогичной проблемой: * SLES 11sp2 * uname -a Linux admin 3.0.26-0.7-default # 1 SMP Tue Apr 17 10:27:57 UTC 2012 (3829766) x86_64 x86_64 x86_64 GNU / Linux * Dual Socket Xeon E52670
Выключение и включение питания решили проблему.