Тормоза из ниоткуда

vasek	# 9 лет, 3 месяца назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Имеется одна неплохая утилита atop (точнее сказать три утилиты в одной). Можешь помониторить ей. У нее имеется один хороший плюс - она создает лог, что исключает необходимость пялиться в монитор и дает возможность посмотреть прошлую историю. Ошибки не исчезают с опытом - они просто умнеют

# 9 лет, 3 месяца назад

Сообщения: 11340

Участник с: 17 февраля 2013

Имеется одна неплохая утилита atop (точнее сказать три утилиты в одной).
Можешь помониторить ей. У нее имеется один хороший плюс - она создает лог, что исключает необходимость пялиться в монитор и дает возможность посмотреть прошлую историю.

Ошибки не исчезают с опытом - они просто умнеют

sergo13p	# 9 лет, 3 месяца назад
Темы: 1 Сообщения: 11 Участник с: 31 декабря 2012	У меня тоже люто тормозит система. Вроде нашёл свою причину: chromium за несколько секунд выжирал 4Г памяти. Установил Хром - пока htop показывает что использовано памяти 1,8Г. С Firefox используется 1,4Г. Буду наблюдать дальше

vasek	# 9 лет, 3 месяца назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Небольшое отступление насчет памяти, потребляемой запущенными процессами (пришлось достать свои старые записи) Чтобы точно определить сколькой и какой памяти отжирает процесс необходимо использовать адресную карту памяти. А утилиты типа ps, top, htop и другие им подобные + к этому всевозможные скрипты для определения памяти дают очень приближенную картину и не отображают реально занимаемую процессом память. Основной их плюс — выдача информации в режиме реального иремени. Реально занимаемая процессом память это память, которую занимает процесс без учета памяти, занимаемой разделяемыми библиотеками. PS......не совсем точно - нужно смотреть загружены или не загружены разделяемые библиотеки (см. ниже) Реально занимаемую память лучше смотреть по карте памяти — это так называемый объем памяти приватного адресного пространства. Ниже приведен выхлоп разных утилит для firefox (открыто 7 влладок) 1) ps aux ..... 1152 4.1 4.9 788548..... 151472 …...... /usr/lib/firefox/firefox 2) top ….......…. 1152 2.3 5.2 781008....158468 …....../usr/lib/firefox/firefox 3) htop ….......... 1152 …......... 762M ...154M …......./usr/lib/firefox/firefox 4) pmap (запуск pmap -d 1152) — информацию берет из карты памяти (лишнее убрал) 1152: /usr/lib/firefox/firefox 08048000 108 r-x-- 0000000000000000 008:00003 firefox ….............................................................................................. 9f13d000 316 r-x-- 0000000000000000 008:00003 libFLAC.so.8.2.0 9f18c000 4 rw--- 000000000004e000 008:00003 libFLAC.so.8.2.0 …............................................................................................ mapped: 781004K writeable/private: 391088K shared: 140916K Примечание — большинство библиотек упоминается дважды (иногда может и больше) - значение памяти, реально занимаемое процессом без учета памяти, занимаемой разделяемыми библиотеками, имеет режим доступа "rw---" В последней строке самая нужная и важная информация - mapped: 781004K - общее количество памяти, отведенной под файлы (то есть память которую отвела процессу система, как будто бы он работает один) - writeable/private: 391088K - общее количество приватного адресного пространства (реально занятая процессом память) - shared: 140916K - общее количество адресного пространства, которое firefox использует совместно с другими процессами. Реально занимаемая firefox память составляет 391088K (эту цифру ни одна из утилит не показывает). PS......это если разделяемые библиотеки загружены, а если не загружены, то +140916K - итого 532004К И как вывод, чтобы сократить отжирание памяти, нужно сокращать одновременный запуск разнотипных процессов, использующих разнотипные библиотеки (почуствовал на себе, когда используя Gnome 2 запускал для учета трафика и т.п. KDE- ый NEMO). Проверил pmap и пришлось отказаться от части чужеродных программ. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 лет, 3 месяца назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Небольшое отступление насчет памяти, потребляемой запущенными процессами (пришлось достать свои старые записи)
Чтобы точно определить сколькой и какой памяти отжирает процесс необходимо использовать адресную карту памяти. А утилиты типа ps, top, htop и другие им подобные + к этому всевозможные скрипты для определения памяти дают очень приближенную картину и не отображают реально занимаемую процессом память. Основной их плюс — выдача информации в режиме реального иремени.
Реально занимаемая процессом память это память, которую занимает процесс без учета памяти, занимаемой разделяемыми библиотеками.
PS......не совсем точно - нужно смотреть загружены или не загружены разделяемые библиотеки (см. ниже)

Реально занимаемую память лучше смотреть по карте памяти — это так называемый объем памяти приватного адресного пространства.
Ниже приведен выхлоп разных утилит для firefox (открыто 7 влладок)
1) ps aux ..... 1152 4.1 4.9 788548..... 151472 …...... /usr/lib/firefox/firefox

2) top ….......…. 1152 2.3 5.2 781008....158468 …....../usr/lib/firefox/firefox
3) htop ….......... 1152 …......... 762M ...154M …......./usr/lib/firefox/firefox
4) pmap (запуск pmap -d 1152) — информацию берет из карты памяти (лишнее убрал)
1152: /usr/lib/firefox/firefox
08048000 108 r-x-- 0000000000000000 008:00003 firefox
…..............................................................................................
9f13d000 316 r-x-- 0000000000000000 008:00003 libFLAC.so.8.2.0
9f18c000 4 rw--- 000000000004e000 008:00003 libFLAC.so.8.2.0
…............................................................................................
mapped: 781004K writeable/private: 391088K shared: 140916K
Примечание — большинство библиотек упоминается дважды (иногда может и больше) - значение памяти, реально занимаемое процессом без учета памяти, занимаемой разделяемыми библиотеками, имеет режим доступа "rw---"
В последней строке самая нужная и важная информация
- mapped: 781004K - общее количество памяти, отведенной под файлы (то есть память которую отвела процессу система, как будто бы он работает один)
- writeable/private: 391088K - общее количество приватного адресного пространства (реально занятая процессом память)
- shared: 140916K - общее количество адресного пространства, которое firefox использует совместно с другими процессами.
Реально занимаемая firefox память составляет 391088K (эту цифру ни одна из утилит не показывает).
PS......это если разделяемые библиотеки загружены, а если не загружены, то +140916K - итого 532004К

И как вывод, чтобы сократить отжирание памяти, нужно сокращать одновременный запуск разнотипных процессов, использующих разнотипные библиотеки (почуствовал на себе, когда используя Gnome 2 запускал для учета трафика и т.п. KDE- ый NEMO). Проверил pmap и пришлось отказаться от части чужеродных программ.

Ошибки не исчезают с опытом - они просто умнеют

Natrio	# 9 лет, 3 месяца назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	vasek, как насчёт этого: $ pmap -d `pidof firefox`\|tail -n1 mapped: 815020K writeable/private: 551720K shared: 1244K $ free total used free shared buffers cached Mem: 1029260 836140 193120 0 60708 307172 -/+ buffers/cache: 468260 561000 Swap: 1060252 0 1060252 После выгрузки firefox: $ free total used free shared buffers cached Mem: 1029260 586940 442320 0 60984 312116 -/+ buffers/cache: 213840 815420 Swap: 1060252 0 1060252 Смотрим, насколько уменьшилась после выгрузки firefox занятая память без учёта буферов и кэша. 815420 - 561000 = 254420 , что примерно в два раза меньше той цифры, что показывает pmap. Мало того, эта цифра вообще больше общего количества занятой памяти в тот момент :) P.S. Что касается knemo, то вся память, занимаемая им, вместе с kde-шными библиотеками и демонами теряется на фоне объёмов, отжираемых огнелисом, так что экономия на отказе от "разнородных программ" выходит весьма сомнительная.

Natrio

# 9 лет, 3 месяца назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

vasek, как насчёт этого:

$ pmap -d `pidof firefox`|tail -n1
mapped: 815020K    writeable/private: 551720K    shared: 1244K
$ free
             total       used       free     shared    buffers     cached
Mem:       1029260     836140     193120          0      60708     307172
-/+ buffers/cache:     468260     561000
Swap:      1060252          0    1060252

После выгрузки firefox:

$ free
             total       used       free     shared    buffers     cached
Mem:       1029260     586940     442320          0      60984     312116
-/+ buffers/cache:     213840     815420
Swap:      1060252          0    1060252

Смотрим, насколько уменьшилась после выгрузки firefox занятая память без учёта буферов и кэша.
815420 - 561000 = 254420 , что примерно в два раза меньше той цифры, что показывает pmap. Мало того, эта цифра вообще больше общего количества занятой памяти в тот момент :)

P.S.
Что касается knemo, то вся память, занимаемая им, вместе с kde-шными библиотеками и демонами теряется на фоне объёмов, отжираемых огнелисом, так что экономия на отказе от "разнородных программ" выходит весьма сомнительная.

vasek	# 9 лет, 3 месяца назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Заранее извиняюсь за длинный ответ. Natrio, читая в свое время о вопросах памяти, я понял одно, что это темная дыра — чем больше читаешь и чем больше узнаешь, тем все больше не понимаешь. Натыкаешься на совершенно новые вещи о которых никогда и неслышал, а, главное, находятся спецы, которые объсняют все возникающие противоречия. Так что дискутировать здесь можно до бесконечности — я буду приводить свои мнения, ты свои и это никогда не кончится. Так что спорить я не буду. Приведу для примера несколько моментов, которые для меня были неожиданностью. 1. Кэш. Всем на компьютере управляет операционная система, которая по своему усмотрению влазит в дела по распределению оперативной памяти. И как только часть памяти освобождается, она постепенно заполняется кешем. Но как только запущенным программам понадобится оперативная память, то кеш сразу ее освобождает. И не стоит определять сколько памяти занято и сколько свободно (это ничего не дает) - оперативная память будет освобождена по первому требованию. Именно по этому многие спецы считают, что оперативной памяти нужно ставить как можно больше (то есть ее никогда мало не бывает). И они утверждают, что быстродействие компьютера, во многом, зависит именно от этого. Ну а когда ее не слишком много, тут и начинаешь выскребать, как говорится, по сусекам. 2. Это вообще для меня нонсенс. Если посмотреть внимательно карту памяти некоторых процессов, например, тех же браузеров, то можно увидеть вот такую штуку (это вывод pmap для firefox) acce3000 8192 rw--- 0000000000000000 000:00000 [ anon ] ad4e3000 4 ----- 0000000000000000 000:00000 [ anon ] ad4e4000 12288 rw--- 0000000000000000 000:00000 [ anon ] ae0e4000 4 ----- 0000000000000000 000:00000 [ anon ] ae0e5000 8192 rw--- 0000000000000000 000:00000 [ anon ] ae8e5000 4 ----- 0000000000000000 000:00000 [ anon ] ae8e6000 8192 rw--- 0000000000000000 000:00000 [ anon ] И таких строк бывает иногда много (объем памяти, занимаемой ими, то же большой). Простым языком — это виртуальная память, запрошенная процессом у ОС. Процесс запросил память, ядро ему её выделило, если ресурсы позволяют. Но, как некоторые считают, это может использоваться и как видеопамять - X отображают её в своё адресное пространство (вот это я точно не понимаю) и хранят там всякую ерунду, например, взяли для фона какую то картинку, вот она и хранится в памяти Х, а главное, что эта память потом не возвращается или же возвращается не полностью. Картинка приведена только для примера, а основными причинами, как пишут, может быть: 1. Вообще-то время жизни графического контекста напрямую не связано со временем жизни процесса, который его создал (очевидный пример: отрисовка X клиента, выполняющегося на удалённой машине). Так что чего-то заведомо плохого в таком поведении нет. 2. Это может быть глюк в клиентской программе, например, она "забывает" освободить графический контекст. 3. Это может быть глюк в самом Xorg. 4. Это может быть глюк в драйвере видеокарты. Ну и таких нюансов очень много. Еще раз повторюсь, спорить я не буду — правы будут все, смотря с какой стороны к этому подходить. Ну и для желающих, поэкспериментировать и узнать куда утекает память — имеются некоторые нестандартные утилиты - например, valgrind и другие. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 лет, 3 месяца назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Заранее извиняюсь за длинный ответ.
Natrio, читая в свое время о вопросах памяти, я понял одно, что это темная дыра — чем больше читаешь и чем больше узнаешь, тем все больше не понимаешь. Натыкаешься на совершенно новые вещи о которых никогда и неслышал, а, главное, находятся спецы, которые объсняют все возникающие противоречия. Так что дискутировать здесь можно до бесконечности — я буду приводить свои мнения, ты свои и это никогда не кончится.
Так что спорить я не буду.
Приведу для примера несколько моментов, которые для меня были неожиданностью.
1. Кэш. Всем на компьютере управляет операционная система, которая по своему усмотрению влазит в дела по распределению оперативной памяти. И как только часть памяти освобождается, она постепенно заполняется кешем. Но как только запущенным программам понадобится оперативная память, то кеш сразу ее освобождает. И не стоит определять сколько памяти занято и сколько свободно (это ничего не дает) - оперативная память будет освобождена по первому требованию. Именно по этому многие спецы считают, что оперативной памяти нужно ставить как можно больше (то есть ее никогда мало не бывает). И они утверждают, что быстродействие компьютера, во многом, зависит именно от этого. Ну а когда ее не слишком много, тут и начинаешь выскребать, как говорится, по сусекам.
2. Это вообще для меня нонсенс. Если посмотреть внимательно карту памяти некоторых процессов, например, тех же браузеров, то можно увидеть вот такую штуку (это вывод pmap для firefox)
acce3000 8192 rw--- 0000000000000000 000:00000 [ anon ]
ad4e3000 4 ----- 0000000000000000 000:00000 [ anon ]
ad4e4000 12288 rw--- 0000000000000000 000:00000 [ anon ]
ae0e4000 4 ----- 0000000000000000 000:00000 [ anon ]
ae0e5000 8192 rw--- 0000000000000000 000:00000 [ anon ]
ae8e5000 4 ----- 0000000000000000 000:00000 [ anon ]
ae8e6000 8192 rw--- 0000000000000000 000:00000 [ anon ]
И таких строк бывает иногда много (объем памяти, занимаемой ими, то же большой).
Простым языком — это виртуальная память, запрошенная процессом у ОС. Процесс запросил память, ядро ему её выделило, если ресурсы позволяют.
Но, как некоторые считают, это может использоваться и как видеопамять - X отображают её в своё адресное пространство (вот это я точно не понимаю) и хранят там всякую ерунду, например, взяли для фона какую то картинку, вот она и хранится в памяти Х, а главное, что эта память потом не возвращается или же возвращается не полностью. Картинка приведена только для примера, а основными причинами, как пишут, может быть:
1. Вообще-то время жизни графического контекста напрямую не связано со временем жизни процесса, который его создал (очевидный пример: отрисовка X клиента, выполняющегося на удалённой машине). Так что чего-то заведомо плохого в таком поведении нет.
2. Это может быть глюк в клиентской программе, например, она "забывает" освободить графический контекст.
3. Это может быть глюк в самом Xorg.
4. Это может быть глюк в драйвере видеокарты.

Ну и таких нюансов очень много. Еще раз повторюсь, спорить я не буду — правы будут все, смотря с какой стороны к этому подходить.
Ну и для желающих, поэкспериментировать и узнать куда утекает память — имеются некоторые нестандартные утилиты - например, valgrind и другие.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 9 лет, 3 месяца назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Забыл написать вывод - почему я больше доверяю pmap - все таки это карта памяти, которая никого не обманывает и дает реальную картину размещения процесса в адрессном пространстве памяти (указаны конкретные адреса ячеек памяти). А уж как эту информацию интерпретировать - дело каждого. PS.....При этом я имею информацию о совместной (с другими процесами) памяти + информацию о наличии anon, и предупрежден чем мне это может грозить. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 лет, 3 месяца назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Забыл написать вывод - почему я больше доверяю pmap - все таки это карта памяти, которая никого не обманывает и дает реальную картину размещения процесса в адрессном пространстве памяти (указаны конкретные адреса ячеек памяти). А уж как эту информацию интерпретировать - дело каждого.

PS.....При этом я имею информацию о совместной (с другими процесами) памяти + информацию о наличии anon, и предупрежден чем мне это может грозить.

Ошибки не исчезают с опытом - они просто умнеют

Natrio	# 9 лет, 3 месяца назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Всё так, только не надо забывать, что адресное пространство само по себе виртуально, то есть оно не равно (а фактически обычно намного больше) физической памяти. И потом, я не спорю с выводом pmap – я просто пытаюсь его интерпретировать не исходя из комментариев, а сопоставляя с глобальными параметрами памяти, которые выдаёт free, и беру оттуда не "используемую" вообще память, а за вычетом того самого кэша, то есть памяти, которая УЖЕ НЕ принадлежит процессам. Так вот по-моему, writeable/private в выводе pmap это одна из статей именно ВЫДЕЛЕННОЙ процессу памяти, а разницу между выделенным адресным пространством и физически занятой памятью, думаю, объяснять не надо :) Соответственно, mapped это вся выделенная процессу память, а writeable/private – та часть выделенного адресного пространства, которая доступна этому и только этому процессу, в том числе на запись. А уж какая часть её есть физическая память, а какая нет – большой вопрос :) С тем, что памяти чем больше тем лучше я тоже не спорю, потому что больше памяти – больше кэша, меньше повторных загрузок с диска, даже если не используется свап. В частности, когда нынче модуль памяти меньше 4х гиг уже не сыщешь в магазинах, проблема "разнородных программ" становится всё менее и менее актуальной.

Natrio

# 9 лет, 3 месяца назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

Всё так, только не надо забывать, что адресное пространство само по себе виртуально, то есть оно не равно (а фактически обычно намного больше) физической памяти.
И потом, я не спорю с выводом pmap – я просто пытаюсь его интерпретировать не исходя из комментариев, а сопоставляя с глобальными параметрами памяти, которые выдаёт free, и беру оттуда не "используемую" вообще память, а за вычетом того самого кэша, то есть памяти, которая УЖЕ НЕ принадлежит процессам.

Так вот по-моему, writeable/private в выводе pmap это одна из статей именно ВЫДЕЛЕННОЙ процессу памяти, а разницу между выделенным адресным пространством и физически занятой памятью, думаю, объяснять не надо :)
Соответственно, mapped это вся выделенная процессу память, а writeable/private – та часть выделенного адресного пространства, которая доступна этому и только этому процессу, в том числе на запись. А уж какая часть её есть физическая память, а какая нет – большой вопрос :)

С тем, что памяти чем больше тем лучше я тоже не спорю, потому что больше памяти – больше кэша, меньше повторных загрузок с диска, даже если не используется свап. В частности, когда нынче модуль памяти меньше 4х гиг уже не сыщешь в магазинах, проблема "разнородных программ" становится всё менее и менее актуальной.

vasek	# 9 лет, 3 месяца назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Natrio со всем согласен. Спасибо за дискуссию, в ходе ее многое для себя вспомнил и прояснил. Ошибки не исчезают с опытом - они просто умнеют

mehanoid	# 9 лет, 3 месяца назад
Темы: 28 Сообщения: 382 Участник с: 27 апреля 2010	marlock Nepomuk отключен? Отключен, да marlock Ещё попробовал бы с помощью cpupower выставить performance пресет для процессора. Я пробовал вообще отключить изменение частоты. Позавчера всё равно тормоза словил, хотя тормозило немного поменьше. Ну при максимальной частоте это вполне ожидаемо. marlock И ещё - скинь сюда вывод smartctl -s on -a /dev/sda Может быть проблема в харде. Вроде говорит, что ошибок нет... ошибок нет vanoc Течет plasma-desktop, а именно число открытых декрипторов файлов. Наглядно это можно увидеть выполнив sysctl fs.file-nr. Сама по себе plasma-desktop течет довольно медленно, поэтому, как правило, утечка не видна, НО если начать копировать файлы на флешку или еще куда-нить, то можно заметить как число очень быстро побежит watch cat /proc/sys/fs/file-nr. Попробовал покопировать и последить, у себя такого не заметил. Во время тормозов пока не представилось возможности посмотреть. А так, поставил временно xfce, и за вчера и сегодня тормозов не было. Может быть, действительно в кедах дело. Хотя не стоит делать поспешных выводов. В общем, пока надо понаблюдать. Потом отпишусь о результатах. Спасибо большое всем за помощь!

mehanoid

# 9 лет, 3 месяца назад

Темы: 28

Сообщения: 382

Участник с: 27 апреля 2010

marlock
Nepomuk отключен?

Отключен, да

marlock
Ещё попробовал бы с помощью cpupower выставить performance пресет для процессора.

Я пробовал вообще отключить изменение частоты. Позавчера всё равно тормоза словил, хотя тормозило немного поменьше. Ну при максимальной частоте это вполне ожидаемо.

marlock
И ещё - скинь сюда вывод smartctl -s on -a /dev/sda
Может быть проблема в харде.

Вроде говорит, что ошибок нет...
ошибок нет

vanoc
Течет plasma-desktop, а именно число открытых декрипторов файлов. Наглядно это можно увидеть выполнив sysctl fs.file-nr. Сама по себе plasma-desktop течет довольно медленно, поэтому, как правило, утечка не видна, НО если начать копировать файлы на флешку или еще куда-нить, то можно заметить как число очень быстро побежит watch cat /proc/sys/fs/file-nr.

Попробовал покопировать и последить, у себя такого не заметил. Во время тормозов пока не представилось возможности посмотреть.

А так, поставил временно xfce, и за вчера и сегодня тормозов не было. Может быть, действительно в кедах дело. Хотя не стоит делать поспешных выводов.
В общем, пока надо понаблюдать. Потом отпишусь о результатах. Спасибо большое всем за помощь!

mehanoid	# 9 лет, 2 месяца назад
Темы: 28 Сообщения: 382 Участник с: 27 апреля 2010	Итак, продолжение истории. Под xfce тормоза тоже замечены были, так что дело не в кедах точно. Дошли у меня руки до того, чтобы поставить систему с нуля. Даже это не помогло =( В новую систему старые конфиги не копировал (разве что zsh). Особо сервисов в систему тоже не ставил никаких (разве что Network Manager и samba). А что ещё могло общего с предыдущей системой остаться? Ну видеодрайвер. Попробовал свободный поставить - то же самое. Зато я выяснил, при каких условиях эти тормоза возникают, как оказалось, не в случайное время. Последовательность действий такая: 1. Какое-то время ноут должен поработать от батареи 2. Подключаем ноут к сети 3. Немного ждём 4. Profit! Видимо я раньше не мог этого обнаружить из-за того, что тормоза не сразу после подключения к сети начинаются. Вначале еле заметные тормоза появляются, а потом уже резко начинает всё тормозить. Под убунтой такая же последовательность действий никаких тормозов не вызывает.

mehanoid

# 9 лет, 2 месяца назад

Темы: 28

Сообщения: 382

Участник с: 27 апреля 2010

Итак, продолжение истории.
Под xfce тормоза тоже замечены были, так что дело не в кедах точно.

Дошли у меня руки до того, чтобы поставить систему с нуля. Даже это не помогло =(
В новую систему старые конфиги не копировал (разве что zsh). Особо сервисов в систему тоже не ставил никаких (разве что Network Manager и samba). А что ещё могло общего с предыдущей системой остаться? Ну видеодрайвер. Попробовал свободный поставить - то же самое.

Зато я выяснил, при каких условиях эти тормоза возникают, как оказалось, не в случайное время. Последовательность действий такая:
1. Какое-то время ноут должен поработать от батареи
2. Подключаем ноут к сети
3. Немного ждём
4. Profit!
Видимо я раньше не мог этого обнаружить из-за того, что тормоза не сразу после подключения к сети начинаются. Вначале еле заметные тормоза появляются, а потом уже резко начинает всё тормозить.
Под убунтой такая же последовательность действий никаких тормозов не вызывает.