Поведение updatedb, iowait, процессы и тормоза
| grunewald |
|
|
Темы:
4
Сообщения:
665
Участник с: 24 октября 2008
|
Данная проблема широко распространена на всех дистрибутивах Linux. Заключается она в том, что при запуске updatedb он поглощает все системные ресурсы и начинает свопить винт. IOWait достигает 90 - 100%. В теории, отработав несколько минут процесс должен завершить работу и освободить ресурсы. Но из-за большого IOWait'а процесс пытается выполнять задачу в течение более длительного времени (у меня прошло 2 часа :) ). В итоге, я сохранил все данные и вышел из гнома, винт потрещал ещё минут 10 и перестал. Но процесс остался висеть в памяти и IOWait снизился лишь до 70 - 80%. Вопрос: нужно ли прибить этот процесс и почему такой высокий IOWait, если обращения к диску нет? Тормозов тоже нет. Хочется заметить, что когда я был на Убунте, это означало, что нужно перезагружаться (обычно, не получалось даже просто из X-ов выйти). Но после запуска, к примеру, firefox всё повторялось. Арч - единственный дистрибутив, на котором я могу работать без нажимания Reset. В той же самой Убунте, с некоторых пор, эта проблема решается настройкой её собственного планировщика. А что можно подкрутить в Арче, чтобы работа updatedb была незаметна? Проконсультируйте, кто-нибудь по значкам тем. Или это просто в epiphany alt к рисункам не работает? |
| vitok |
|
|
Темы:
13
Сообщения:
389
Участник с: 01 сентября 2008
|
Жесть! у меня таких проблем с гномом никогда небыло не в убунте не в арче. комп бывало что 2-3 недели без ребута держал, даже без ребута иксов. правда в убунте удалял кучу лишних пакетов, тот-же тракер, с его индексированием безполезным. кстати как гнома ставил? pacman -S gnome затем pacman -S gnome-extra ? последняя команда не для тру арчеров. я просто до установил руками что нужно мне было из гном-екстра, к примеру гном-питон, евинсе пдф ридер, гном-повер-менеджер. мне кстати очень понравилось как в арче зависимости отработаны, ничего лишнего ставить не нужно. попробуй снести гном-екстра pacman -Rsn gnome-extra и ручками поставить что нужно, может поможет. вожнможно еще нужно будет по удалять папки с конифигами те которые скрытые. П.С. если несу бред не по теме извиняй, просто реально обидно за гнома, что он у кого-то так жутко тормозит! и рассказал как сам ставил, т.к. у меня все без проблем работает. |
| rubicon |
|
|
Темы:
2
Сообщения:
208
Участник с: 17 октября 2008
|
Ппц парни… Тредстартер, ты как додумался тему поместить в Gnome && XFCE, а? Я ещё понимаю, можно проблему увидеть в updatedb, в модулях для контроллера или в планировщике i/o… Да хоть в ядре! Но в гноме… лицоладонь, блин. |
| grunewald |
|
|
Темы:
4
Сообщения:
665
Участник с: 24 октября 2008
|
А у меня в других DE/WM updatedb нет, вот в Гноме ему и место. :) Или updatedb к мультимедиа относится. Две минуты тормозов на индексацию я могу и потерпеть, просто было интересно - может чего узнаю. Удалял tracker? А updatedb с ним никак не связан? ;) Как я обычно ставлю Гном: # pacman -Sy gnome-session metacity gnome-panel gnome-applets gnome-terminal Но вот пришли ко мне гости полазить в интернете. Все они Linux в глаза не видели, а у меня TWM на экране. ;D Как-то неловко стало… А в кэше был только gnome, gnome-extra. Поставил, именно так, как ты и предположил. Чтобы всё блестело, сверкало, играло красками, а то при моём аскетичном подходе даже иконки не ставятся. Гости, конечно были шокированы тем, сколько всего нового они увидели. Они ушли, а я продолжил работу. А ещё через несколько часов заработал updatedb. Компы у всех разные, поэтому то, что происходит у меня, у тебя может никогда не произойти и наоборот. Может прояснится:
|
| rubicon |
|
|
Темы:
2
Сообщения:
208
Участник с: 17 октября 2008
|
grunewaldInfinite_facepalm.gif, ей богу. pacman -Qi $(pacman -Qo $(which updatedb) | cut -d' ' -f3) $ iso-info -f ~/Образы/archlinux-2008.06-core-i686.iso | grep mlocate
52551 /addons/core-pkgs/mlocate-0.20-2-i686.pkg.tar.gz |
| alexdsp |
|
|
Темы:
22
Сообщения:
307
Участник с: 07 февраля 2008
|
Мне кажется, если такой IOwait, то может, дело в том, каким образом включен HDD (к тому же он у Вас сам по себе такой медленный). Включен ли режим UDMA? Насколько я понял, у Вас чипсет SIS, может для него что-то надо включать в ядре и т.д? Такая тема обсуждалась часто, касательно тормозов планировщика IO, вроде как было похоже, что часто страдают этой проблемой в основном “не интел” чипсеты. У меня nvidia mcp51 и такая проблема тоже есть, но в меньшей степени, т.к. HDD быстрые, но тоже немного раздражает, что когда, скажем, DC++ хэширует шару, на компьютере становится работать некомфортно… |
| grunewald |
|
|
Темы:
4
Сообщения:
665
Участник с: 24 октября 2008
|
rubicon, слишком эмоционально - недостойное поведение настоящего аскета. :) Цитировать сам себя не хочу, но под отсутствием updatedb имелось в виду именно его поведение. В других DE/WM кроме Гнома, updatedb отсутствует как причина. :) Хотя, я понимаю, что ты не телепат. Мне не важно где он: в core или в extra, незачем смотреть зависимости пакетов. Тормозит работу он только в Гноме. И именно поэтому я открыл тему в этой ветке. Просто у тебя такой проблемы нет, вот ты и не разобрался. Для тебя вопрос сформулирую так: “При выполнении updatedb в Gnome комп тормозит, в других DE/WM тормозов нет.” alexdsp, как выяснилось, высокий IOWait не обязательно означает тормоза системы. Насчёт HDD ты 100%-но прав, но интересно, что так нагружает винт именно в Гноме. Только что в KDE4 всё отработалось без тормозов и нареканий. |
| amigo |
|
Темы:
35
Сообщения:
2126
Участник с: 05 февраля 2007
|
Интересно. Какая зависимость между updatedb и gnome? Какие демоны запущены? Вывод команды ps aux –sort=-%cpu когда начались тормоза?
Разберемся, голубчик!
|
| rubicon |
|
|
Темы:
2
Сообщения:
208
Участник с: 17 октября 2008
|
grunewaldВообще-то это не вопрос, да и формулировать нужно для всех. Как видишь, не я один не понимаю, причём здесь гном. Наверное объяснить это стоило в первом посте, как считаешь? Вообще, какого плана тормоза появляются? Недостаток процессорного времени, когда в ФФ страница прокручивается прерывисто и медленно или просто когда программы запускаются очень медленно? Стандартные лекарства: nice, ionice для /etc/cron.daily/updatedb и hdparm -Tt, fsck для винта. Стоит понизить приоритет updatedb, когда оно запускается по крону, есть вероятность, что это хотя бы не так сильно будет тормозить работу. hdparm покажет скорость винта для сравнения, а fsck определит наличие нечитаемых секторов. grunewaldВсё зависит от того, как прочитать мой пост. Телепат, просто мана нонче знаешь какая дорогая? Ого-го! |
| grunewald |
|
|
Темы:
4
Сообщения:
665
Участник с: 24 октября 2008
|
В общем, разобрался я с этой проблемой. :) Мда… не знаю теперь куда надо было пихать этот тред, но Гном оказался почти не причём. Проблема оказалась железно-ядерная на которую наложился глюк, опять-таки железа в Гноме. :) А вам слабо?! Дальше - фантастический триллер: Получилось следующее: отказала флэшка, в это время rhythmbox играл с неё музыку, я переключился на наутилус, чтобы её грамотно отмаунтить. В это время запустился updatedb. Наутилус подвис. Я решил дать ему время, пока работает индексирование, а сам решил в это время почитать вики через epiphany. Но чего-то увлёкся и пролетел час с лишним. :) На время я обратил внимание только тогда, когда мышь стала тормозить и в браузере задёргались страницы. Тогда я успел в консоли запустить top и увидел знакомую с Ubuntu картину: IOWait=95% (у меня был шок сначала: ведь жили-жили-не тужили. Даже подумалось о никчёмности прошлого перебора дистрибутивов). Я ждал, когда iowait опустится меньше 90% и закрывал одну из программ. После этого IOWait опять подскакивал до 95% и я повторял эти действия, пока всё не закрыл. Потом я вышел из Гнома в консоль (gdm не пользуюсь), запустил там top и стал ждать. Через 10 минут винт перестал шуршать, updatedb оставился в памяти с флагом D, но и IOWait остался высоким. Но я решил, что раз винт не трещит, то высокий IOWait систему тормозить не будет. Так оно и оказалось - когда я запустил Гном уже ничего не тормозило. Я открыл форум и написал этот тред. Но вот, Amigo задал вопрос по теме и нужно было восстановить ту обстановку, в которой были тормоза. Я решил начать подготовку к эксперименту с полной перезагрузки. В консоли я остановил top и выполнил reboot. Динамик пропищал и я ждал перезагрузки, но её не последовало. Я ребут в трёх вкладках прописал - бесполезно. Тогда написал shutdown -r now. После писка - ничего. shutdown -h now - то же самое. Вывалился из иксов в консоль и писал уже там те же команды. CTRL-ALT-DEL - пофигу! Полез читать /var/log/errors.log - и нашёл там целый вагон повторяющихся строк (как видно, время совпало с индексированием): Nov 4 00:02:22 arch FAT: Filesystem panic (dev sdb1) Nov 4 00:02:22 arch invalid access to FAT (entry 0xd65ae818) Nov 4 00:02:22 arch FAT: Filesystem panic (dev sdb1) Nov 4 00:02:22 arch invalid access to FAT (entry 0xf9ddf3c6) Nov 4 00:02:22 arch FAT: Filesystem panic (dev sdb1) Nov 4 00:02:22 arch invalid access to FAT (entry 0x285484ee) Всем большое спасибо за участие! Amigo - ты настоящий Amigo, без твоей помощи я бы не скоро вспомнил про флэшку. Спасибо, что вынудил перезагрузиться. rubicon, мы просто мало общались, поэтому до телепатического уровня ещё далеко. Извини, если что не так ляпнул! Есть у меня такое свойство - говорить между строк, никак избавиться не могу. Вы с Amigo про связи и зависимости пакетные, а я - про логические. Кстати, когда были тормоза, процессор был загружен максимум на 17 - 20%. alexdsp, ты меня подтолкнул к поиску инфы про HDD на SiS. Спасибо! Железо проблемное оказалось. All, я не против Гнома, если у вас сложилось такое впечатление. Я не против вообще чего-либо, кроме проприетарщины (opera не считается). Arch forever! USB-Flash отформатирована в reiserfs. Тему, в принципе, можно закрыть. |