uscr 04.02.2011 23:50
Есть проблема! — Ubuntu и странные зависания.
Здравствуйте.В консоли пишу:
1 |
|
Сначала iftop рапортует о сумашедших скоростях и всё рады, а потом консоль виснет. Зависнуть может как приложение "Терминал" из стандартной поставки gnome, так и "настоящая" консоль (ctrl+alt+F1).
В dmesg сыпятся сообщения "NFS not available. < servername > not responding." Или типа того. Точный текст ошибки не важен, потому как NFS очень даже available, а сервер вполне responding - рядом стоит компьютер и пишет на NFS в это же время (если прекратить использовать NFS c этого компьютера - ничего не изменится).
Пробую:
1 |
|
Как, а главное что диагностировать\лечить?
Ubuntu 10.04 netbook remix
Acer aspire d250
При обычной работе проблем не замечаю. В том числе с чтением\записью.
UPD
Хм. ВСё таки проблема с сетью или с NFS.
cp -R ~/.mozilla ~/.mozilla.bckp отработала без сбоев, а cp -R ~/.mozilla /exports/progress/document зависла почти сразу (/exports/progress/document это и есть NFS шара). При чём после убийства консоли с зависшей командой cp -R ~/.mozilla /exports/progress/document вновь открытая консоль зависает при попытке воспользоваться автодополнением для пути /exports/progress/document. dmesg на этот раз чистый.
cppmm 05.02.2011 00:24 #
+ 2 -
Я бы проверил винт. cp работает несколько не так, как dd. Что будет, если натравить cat /dev/sda > /dev/null ? Ну и плюс прогнать тесты smartctl и badblocks.
у меня на ноуте было что-то похожее при копировании по ethernet.
Помогло уменьшение MTU до 750
Помогло уменьшение MTU до 750
Здесь много интересных моментов, но до конца я так и не разобрал проблему.
То что nfs может подвесить процессы в TASK_UNINTERRUPTABLE это нормально, но почему оно вешает всю систему, а не один процесс я долго немогу понять.
Для начала включи slabtop, там будет запись вроде nfs-cache (или nfs-buffer) типа того.
Вот когда ты большое файло скидываешь на nfs оно реально в сеть не пролазит и складывается в опреативке в этот самый буфер, а буфер то в slab - а slab это ядро и соответственно low-mem, который нельзя сваппить и который ограничен 1 Гигабайтом.
Соответственно место под структуры ядра нет и операции на память становятся очень дорогими ... в этот момент все висит, но slabtop будет иногда обновлятся, и ты будешь видеть как очищается буфер скидывая на nfs закэшированные данные, так вот как только буфер освободиться - система оживет.
А вот как это лечить и как именно kernel-nfs приводит к такой ситуации я пока непридумал - 100% ситуацию спасает переход на x86_64 но в случае атома это неработает.
То что nfs может подвесить процессы в TASK_UNINTERRUPTABLE это нормально, но почему оно вешает всю систему, а не один процесс я долго немогу понять.
Для начала включи slabtop, там будет запись вроде nfs-cache (или nfs-buffer) типа того.
Вот когда ты большое файло скидываешь на nfs оно реально в сеть не пролазит и складывается в опреативке в этот самый буфер, а буфер то в slab - а slab это ядро и соответственно low-mem, который нельзя сваппить и который ограничен 1 Гигабайтом.
Соответственно место под структуры ядра нет и операции на память становятся очень дорогими ... в этот момент все висит, но slabtop будет иногда обновлятся, и ты будешь видеть как очищается буфер скидывая на nfs закэшированные данные, так вот как только буфер освободиться - система оживет.
А вот как это лечить и как именно kernel-nfs приводит к такой ситуации я пока непридумал - 100% ситуацию спасает переход на x86_64 но в случае атома это неработает.
простите, может я не в теме, но разве у атома архитектура не х86?
Да.
Обычный интеловский x86-совместимый проц с пониженным энергопотреблением и тепловыделением.
Обычный интеловский x86-совместимый проц с пониженным энергопотреблением и тепловыделением.
Да атом это х86 (32 бита). А х86_64 это очевидно 64 бита.
В данном случае играет роль отсутствие разделения на LOW|HIGHMEM в x84_64
В данном случае играет роль отсутствие разделения на LOW|HIGHMEM в x84_64
Я предлагаю собрать perf из tools/perf ядра и запустить системный профайлер perf top чтобы посмотреть где система встаёт.
Была такая же проблема.. при копировании по NFS кау будто все замирало, я искал решение, но так и не нашел его. Если не ошибаюсь, то компьютер, с которого производится доступ к другому компьютеру словно ожидает выполнения операций ввода-вывода на другом компе. Особо сильно проявляется при копировании больших файлов более 1,3 Гб.. Что-то там жестко привязано на другой стороне. Попробуйте погуглить на тему опций монтированя удаленной шары..
У монтирования NFS шары есть опции hard и soft. Стоит поиграться с ними, если действительно проблема в nfs.
Может быть вам поможет, буквально вчера снова настроил на своем компе доступ к компу жены по NFS, нужно было скинуть ей файл, и не какой-то мелкий, а в 38 с лишним гигов.. Где-то что-то погуглил на тему "NFS large file freeze system" и в общем вот, мой /etc/exports на компе жены, то есть на компе с шарой:
А вот как я монтирую это в своем /etc/fstab:
У меня никаких опций специфических нет.. И файл скопировался за полчаса или чуть больше.. Забыл сказать, NFSv4.
# cat /etc/exports
# /etc/exports
192.168.2.2(rw,fsid=0,insecure,nohide,no_subtree_check,async)
А вот как я монтирую это в своем /etc/fstab:
#NFS4
kate:/home/kate/Torrents/ /home/gard/kateTorrents nf
У меня никаких опций специфических нет.. И файл скопировался за полчаса или чуть больше.. Забыл сказать, NFSv4.