| 1 |
Hi! |
| 2 |
|
| 3 |
On Wed, Apr 08, 2009 at 02:00:33AM +0300, Alex Efros wrote: |
| 4 |
> Никто не сталкивался с периодическими подвисаниями системы секунд на 5-10? |
| 5 |
> При этом интерфейс вообще не работает (мышка движется, но клики мышки и |
| 6 |
> нажатия кнопок игнорируются), а когда через несколько секунд он "отвисает" |
| 7 |
> все клики/нажатые кнопки срабатывают (т.е. они не потерялись, а ждали |
| 8 |
> где-то в очереди). |
| 9 |
|
| 10 |
Ещё симптомы: |
| 11 |
- на клаве в это время не работает даже NumLock (когда система отвисает то |
| 12 |
всё снова работает) |
| 13 |
- почему-то sensors показывает стабильно высокую температуру CPU: 60-70 |
| 14 |
градусов на обоих ядрах при 0% загрузке CPU (под виндой температура даже |
| 15 |
под нагрузкой не выше 50 градусов) |
| 16 |
- если на машину во время этих тормозов зайти по ssh - можно работать без |
| 17 |
проблем |
| 18 |
|
| 19 |
> Что интересно, у меня используется conky (разные системные индикаторы), |
| 20 |
> так после отвисания я на нём наблюдаю за тот период, что система ни на что |
| 21 |
> не реагировала, 100% загрузку одного из ядер CPU. Поймать гада, жрущего |
| 22 |
> в это время CPU не удаётся - как только я запускаю top или просто |
| 23 |
> переключаюсь в консоль с уже запущенным top использование CPU моментально |
| 24 |
> прекращается. |
| 25 |
|
| 26 |
Поймать гада удалось, но, боюсь, гады всё-таки каждый раз разные, и |
| 27 |
виноваты не они, а всё-таки ядро. |
| 28 |
|
| 29 |
Конкретно, зайдя по ssh видно, что 100% CPU кушают X-ы: |
| 30 |
|
| 31 |
top - 06:56:51 up 1:29, 22 users, load average: 1.07, 0.69, 0.34 |
| 32 |
Tasks: 406 total, 3 running, 403 sleeping, 0 stopped, 0 zombie |
| 33 |
Cpu(s): 4.7%us, 11.6%sy, 0.0%ni, 82.5%id, 1.1%wa, 0.1%hi, 0.1%si, 0.0%st |
| 34 |
Mem: 2073092k total, 768420k used, 1304672k free, 85864k buffers |
| 35 |
Swap: 0k total, 0k used, 0k free, 240884k cached |
| 36 |
|
| 37 |
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND |
| 38 |
1823 root 20 0 51308 34m 8952 R 100 1.7 25:21.32 1 X |
| 39 |
17278 root 20 0 2648 1256 796 R 2 0.1 0:00.01 0 top |
| 40 |
1 root 20 0 1500 320 268 S 0 0.0 0:00.26 0 runit |
| 41 |
|
| 42 |
При этом, в отличие от предыдущих случаев, даже conky на экране не |
| 43 |
обновляется. Что наводит на мысль, что в предыдущие разы 100% CPU кушали |
| 44 |
не X-ы. |
| 45 |
|
| 46 |
Я сделал в этот момент strace для X, он выглядел примерно так: |
| 47 |
|
| 48 |
Process 1823 attached - interrupt to quit |
| 49 |
--- SIGALRM (Alarm clock) @ 0 (0) --- |
| 50 |
sigreturn() = ? (mask now []) |
| 51 |
--- SIGALRM (Alarm clock) @ 0 (0) --- |
| 52 |
sigreturn() = ? (mask now []) |
| 53 |
--- SIGALRM (Alarm clock) @ 0 (0) --- |
| 54 |
sigreturn() = ? (mask now []) |
| 55 |
--- SIGALRM (Alarm clock) @ 0 (0) --- |
| 56 |
sigreturn() = ? (mask now []) |
| 57 |
--- SIGALRM (Alarm clock) @ 0 (0) --- |
| 58 |
sigreturn() = ? (mask now []) |
| 59 |
... |
| 60 |
|
| 61 |
Ещё интересный момент был: при компиляции ядра компиляция замерла надолго |
| 62 |
на LD vmlinuz - при этом процесс ld точно так же жрал 100% CPU. |
| 63 |
Продолжалось это пару минут, потом я его прибил по Ctrl-C, запустил снова |
| 64 |
make bzImage и он за пару секунд завершил сборку ядра, включая запуск |
| 65 |
LD vmlinuz. Как вы понимаете, когда 100% CPU кушал ld, клава/мышка и X-Ы в |
| 66 |
целом работали без проблем. |
| 67 |
|
| 68 |
-- |
| 69 |
WBR, Alex. |
Archives