[gentoo-user-ru] тормоза

[gentoo-user-ru] тормоза

[Alex Efros]

Hi!

Никто не сталкивался с периодическими подвисаниями системы секунд на 5-10?
При этом интерфейс вообще не работает (мышка движется, но клики мышки и
нажатия кнопок игнорируются), а когда через несколько секунд он "отвисает"
все клики/нажатые кнопки срабатывают (т.е. они не потерялись, а ждали
где-то в очереди).

Что интересно, у меня используется conky (разные системные индикаторы),
так после отвисания я на нём наблюдаю за тот период, что система ни на что
не реагировала, 100% загрузку одного из ядер CPU. Поймать гада, жрущего
в это время CPU не удаётся - как только я запускаю top или просто
переключаюсь в консоль с уже запущенным top использование CPU моментально
прекращается.

По симптомам это более всего похоже на баг ядра (хотя бы просто потому,
что система так жёстко подвисать не имеет права в принципе). Кроме того,
раньше (несколько месяцев назад) такого не случалось, а сейчас где-то раз
в несколько дней происходит.


P.S.
В общем, железо становится всё мощнее, а система в общем работает всё хуже.
Раньше это только с виндой происходило, но сейчас, похоже, и линух этим
заражается. Чего стоит только баг с дикими тормозами при интенсивном
дисковом I/O (когда у меня rtorrent новый файл создаёт или хеш считает на
машине ничего больше делать нельзя, и это при почти 0% загрузке CPU) -
сразу вспоминаются древние анекдоты про винду 3.1: "Папа, а что такое
многозадачность - подожди, сынок, сейчас дискету доформатирую и покажу".
Если кому интересно, вот инфа по этому багу:
    http://linuxforum.ru/index.php?showtopic=67731&st=0
    http://www.opennet.ru/opennews/art.shtml?num=19790
    http://bugzilla.kernel.org/show_bug.cgi?id=12309

-- 
			WBR, Alex.

Re: [gentoo-user-ru] тормоза

[Anton Kvashin]

Alex Efros пишет:
> Никто не сталкивался с периодическими подвисаниями системы секунд на 5-10?
> При этом интерфейс вообще не работает (мышка движется, но клики мышки и
> нажатия кнопок игнорируются), а когда через несколько секунд он "отвисает"
> все клики/нажатые кнопки срабатывают (т.е. они не потерялись, а ждали

Обзорная статья, описывающая работу системы и оценку производительности:
http://www.ibm.com/developerworks/ru/edu/l-lpic3306/section2.html

Попробуйте sar

-- 
Anton Kvashin

Re: [gentoo-user-ru] тормоза

[Alex Efros]

Hi!

On Wed, Apr 08, 2009 at 10:10:16AM +0600, Anton Kvashin wrote:
> Обзорная статья, описывающая работу 
> системы и оценку производительности:
> http://www.ibm.com/developerworks/ru/edu/l-lpic3306/section2.html
>
> Попробуйте sar

Статья хорошая, но я не вижу, чем мне sar поможет. Я уже через ssh с
соседнего компа и просто через запущенные в фоне top/vmstat >file собрал
кучу инфы по происходящему - только вот не ясно, что с этой радостью
делать. Разве что предыдущее ядро попробовать...

-- 
			WBR, Alex.

[gentoo-user-ru] Re: [gentoo-user-ru] тормоза

[Edward Hades]

2009/4/8 Alex Efros <powerman@powerman.asdfgroup.com>:
>  Разве что предыдущее ядро попробовать...

Или следующее. В 2.6.29, говорят, производительность возросла,
возможно и с этим багом что-то сделали.


-- 
Edward "Hades" Toroshchin,
Aides on irc.freenode.org

[gentoo-user-ru] Перенаправление портов в телнете

[Ящик на гугле]

Добрый день Всем!
Никто не знает с чего начинать решение проблемы:
Есть некая программа на Perl.
Отвечает по телнету:

пример: telnet://62.109.9.76:7300

а надо чтобы отвечало на стандартном порту 23

telnet://62.109.9.76

В самой программе это сделать нельзя.
Надо как то перенаправить запрос с порта 7300 на 23
Куда лезть за решением этой проблемы не пойму...
Может кто подскажет?

[gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Илья Красильников]

см. man ssh, ключик −R


--
С уважением, ИК



2009/4/9 Ящик на гугле <ua6atg@gmail.com>:
> Добрый день Всем!
> Никто не знает с чего начинать решение проблемы:
> Есть некая программа на Perl.
> Отвечает по телнету:
>
> пример: telnet://62.109.9.76:7300
>
> а надо чтобы отвечало на стандартном порту 23
>
> telnet://62.109.9.76
>
> В самой программе это сделать нельзя.
> Надо как то перенаправить запрос с порта 7300 на 23
> Куда лезть за решением этой проблемы не пойму...
> Может кто подскажет?
>
>
>

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Игорь]

9 апреля 2009 г. 12:59 пользователь Илья Красильников
<krasilnikov.ilya@gmail.com> написал:
> см. man ssh, ключик −R
>
>
а бреетесь Вы вероятно газонокосилкой?

PS для этой цели лучший вариант это iptables

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Илья Красильников]

> а бреетесь Вы вероятно газонокосилкой?
Нет :-)

Это БЫСТРОЕ и самое доступное решение.
Если человек "не знает с чего начинать решение проблемы", то пусть сделает так.

Собственно, да, я согласен, что (по качеству) лучше iptables.



2009/4/9 Игорь <yanchenko.igor@gmail.com>:
> 9 апреля 2009 г. 12:59 пользователь Илья Красильников
> <krasilnikov.ilya@gmail.com> написал:
>> см. man ssh, ключик −R
>>
>>
> а бреетесь Вы вероятно газонокосилкой?
>
> PS для этой цели лучший вариант это iptables
>

[gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Edward Hades]

Навскидку два решение: быстрое и правильное.

Быстрое: засунуть в inetd на 23 порт что-то типа nc -q 0 localhost 7300.

Правильное: перенаправлять порт с помощью iptables как-то так:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport  80 --dst
62.109.9.76 -j REDIRECT --to-port 8080

(правильность команды не гарантирую)

-- 
Edward "Hades" Toroshchin,
Aides on irc.freenode.org

[gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Edward Hades]

Соответственно изменив 8080 и 80 на нужные порты =)

-- 
Edward "Hades" Toroshchin,
Aides on irc.freenode.org

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Sergej Beresteckij]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

А нельзя ли Все таки чуть поподробней о "быстром и неправильном" способе?
Это куда идти в inetd? Честно говоря у меня сейчас не gentoo а Debian....
2 вечера убил на tptables, как то пока туго с движением вперед.

2009/4/9 Edward Hades <edward.hades@gmail.com>

> Навскидку два решение: быстрое и правильное.
>
> Быстрое: засунуть в inetd на 23 порт что-то типа nc -q 0 localhost 7300.
>
> Правильное: перенаправлять порт с помощью iptables как-то так:
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport  80 --dst
> 62.109.9.76 -j REDIRECT --to-port 8080
>
> (правильность команды не гарантирую)
>
> --
> Edward "Hades" Toroshchin,
> Aides on irc.freenode.org
>

[-- Attachment #2: Type: text/html, Size: 1066 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Edward Hades]

2009/4/11 Sergej Beresteckij <ua6atg@gmail.com>:
> А нельзя ли Все таки чуть поподробней о "быстром и неправильном" способе?

Ставим inetd (я использовал xinetd, конфиги соответственно для него;
если у тебя классический inetd или какая-то другая реализация,
придётся их поправить).
Ставим netcat.

Пишем в /etc/xinetd.d/telnet:

service telnet
{
        socket_type             = stream
        wait                    = no
        user                    = nobody
        server                  = /usr/bin/nc
        server_args             = -q 0 localhost 7300
}

(я предполагаю, что действие происходит на той же машине, где слушает
сервер, в противном случае следует соответственно изменить localhost).
Для более новых версий netcat может потребоваться заменить "-q 0" на "-c".
Кроме того, в /etc/xinetd.conf должна быть строка includedir
/etc/xinetd.d (у меня есть, не знаю как там в ваших дебианах).

Запускаем xinetd или (если он уже запущен) посылаем ему SIGHUP: sudo
killall -HUP xinetd

Я проверял -- у меня работает.

-- 
Edward "Hades" Toroshchin,
Aides on irc.freenode.org

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Ящик на гугле]

Здравствуйте, Edward.

Вы писали 11 апреля 2009 г., 20:34:25:

За идею спасибо, у меня получилось, только вот реализация иная.
Также использован   xinetd
Но файл другой
service my
  {
       type                    = UNLISTED
       flags                   = REUSE
       socket_type             = stream
       wait                    = no
       server                  = /bin/false
       protocol                = tcp
       interface               = 192.168.0.1
       port                    = 80
       user                    = nobody
       disable                 = no
       redirect                = 192.168.0.10 80
       log_type                = FILE /var/log/redirect.log
       log_on_success          += HOST DURATION USERID TRAFFIC USERID
       log_on_failure          = HOST ATTEMPT USERID
       only_from               = 192.168.0.0/24
  }

  IP и порт не мои, но это не столь важно.
  Далее делаем:  sudo
                      killall -HUP xinetd

                      и все работает.

                      Возможно несколько тупо (Я понимаю, iptables
                      несколько эстетичней) НО РАБОТАЕТ.
  

> 2009/4/11 Sergej Beresteckij <ua6atg@gmail.com>:
>> А нельзя ли Все таки чуть поподробней о "быстром и неправильном" способе?

> Ставим inetd (я использовал , конфиги соответственно для него;
> если у тебя классический inetd или какая-то другая реализация,
> придётся их поправить).
> Ставим netcat.

> Пишем в /etc/xinetd.d/telnet:

> service telnet
> {
>         socket_type             = stream
>         wait                    = no
>         user                    = nobody
>         server                  = /usr/bin/nc
>         server_args             = -q 0 localhost 7300
> }

> (я предполагаю, что действие происходит на той же машине, где слушает
> сервер, в противном случае следует соответственно изменить localhost).
> Для более новых версий netcat может потребоваться заменить "-q 0" на "-c".
> Кроме того, в /etc/xinetd.conf должна быть строка includedir
> /etc/xinetd.d (у меня есть, не знаю как там в ваших дебианах).

> Запускаем xinetd или (если он уже запущен) посылаем ему SIGHUP: sudo
> killall -HUP xinetd

> Я проверял -- у меня работает.




-- 
С уважением,
 Ящик                          mailto:ua6atg@gmail.com

[gentoo-user-ru] Re: [gentoo-user-ru] Перенаправление портов в телнете

[Konstantin Astafjev]

Hello Ящик,

Thursday, April 9, 2009, 12:51:49, you wrote:
> Есть некая программа на Perl.
> Отвечает по телнету:
> пример: telnet://62.109.9.76:7300
> а надо чтобы отвечало на стандартном порту 23
> telnet://62.109.9.76
> В самой программе это сделать нельзя.

Если подходит на уровне firewall, то возможно поможет:

iptables -t nat -A PREROUTING -d 62.109.9.76 -p tcp --dport 7300 -j DNAT --to 62.109.9.76:23

-- 
Konstantin Astafjev

Re: [gentoo-user-ru] тормоза

[Alex Efros]

Hi!

On Wed, Apr 08, 2009 at 02:00:33AM +0300, Alex Efros wrote:
> Никто не сталкивался с периодическими подвисаниями системы секунд на 5-10?
> При этом интерфейс вообще не работает (мышка движется, но клики мышки и
> нажатия кнопок игнорируются), а когда через несколько секунд он "отвисает"
> все клики/нажатые кнопки срабатывают (т.е. они не потерялись, а ждали
> где-то в очереди).

Ещё симптомы:
- на клаве в это время не работает даже NumLock (когда система отвисает то
  всё снова работает)
- почему-то sensors показывает стабильно высокую температуру CPU: 60-70
  градусов на обоих ядрах при 0% загрузке CPU (под виндой температура даже
  под нагрузкой не выше 50 градусов)
- если на машину во время этих тормозов зайти по ssh - можно работать без
  проблем

> Что интересно, у меня используется conky (разные системные индикаторы),
> так после отвисания я на нём наблюдаю за тот период, что система ни на что
> не реагировала, 100% загрузку одного из ядер CPU. Поймать гада, жрущего
> в это время CPU не удаётся - как только я запускаю top или просто
> переключаюсь в консоль с уже запущенным top использование CPU моментально
> прекращается.

Поймать гада удалось, но, боюсь, гады всё-таки каждый раз разные, и
виноваты не они, а всё-таки ядро.

Конкретно, зайдя по ssh видно, что 100% CPU кушают X-ы:

top - 06:56:51 up  1:29, 22 users,  load average: 1.07, 0.69, 0.34
Tasks: 406 total,   3 running, 403 sleeping,   0 stopped,   0 zombie
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
Mem:   2073092k total,   768420k used,  1304672k free,    85864k buffers
Swap:        0k total,        0k used,        0k free,   240884k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND          
 1823 root      20   0 51308  34m 8952 R  100  1.7  25:21.32 1 X                
17278 root      20   0  2648 1256  796 R    2  0.1   0:00.01 0 top              
    1 root      20   0  1500  320  268 S    0  0.0   0:00.26 0 runit            

При этом, в отличие от предыдущих случаев, даже conky на экране не
обновляется. Что наводит на мысль, что в предыдущие разы 100% CPU кушали
не X-ы.

Я сделал в этот момент strace для X, он выглядел примерно так:

Process 1823 attached - interrupt to quit
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
...

Ещё интересный момент был: при компиляции ядра компиляция замерла надолго
на LD vmlinuz - при этом процесс ld точно так же жрал 100% CPU.
Продолжалось это пару минут, потом я его прибил по Ctrl-C, запустил снова
make bzImage и он за пару секунд завершил сборку ядра, включая запуск
LD vmlinuz. Как вы понимаете, когда 100% CPU кушал ld, клава/мышка и X-Ы в
целом работали без проблем.

-- 
			WBR, Alex.

Re: [gentoo-user-ru] тормоза

[Alex Efros]

Hi!

On Wed, Apr 08, 2009 at 07:16:02AM +0300, Alex Efros wrote:
> Конкретно, зайдя по ssh видно, что 100% CPU кушают X-ы:

Я ещё запустил в фоне vmstat 5, и собрал инфу во время очередного
подвисания X-ов. Из него видно, что подвисание длилось примерно 4 минуты,
в течение которых ядро (system) кушало 40% от двух ядерного CPU, т.е. 80%
одного ядра, а X (user), получается, кушал оставшиеся 20% этого ядра.

Ещё можно обратить внимание на раза в 2-3 упавшее кол-во переключений
контекста в этот период, и большое кол-во переключений сразу по окончании
этого периода.

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 1226996  91168 305844    0    0     0    29 2127  530  1  1 98  0
 0  0      0 1227208  91176 305848    0    0     0    12 2124  503  1  1 98  0
 0  0      0 1227380  91184 305860    0    0     0    14 2125  515  1  1 98  0
 0  0      0 1227456  91184 305880    0    0     0    35 2131  511  1  1 98  0
 3  0      0 1226868  91192 305884    0    0     0    11 2134  898  2  2 96  0
 1  0      0 1226592  91200 305900    0    0     0    17 2168  925  9 28 63  0
 1  0      0 1226568  91212 305908    0    0     0    16 2162  279 12 40 49  0
 1  0      0 1226572  91220 305924    0    0     0    12 2161  242 12 40 49  0
 1  0      0 1226424  91252 305968    0    0    10    14 2172  273 12 40 48  0
 1  0      0 1206052  91264 306060    0    0     0    20 2261  667 19 41 40  0
 1  0      0 1206212  91272 306004    0    0     0    68 2210  441 12 40 48  0
 1  0      0 1206108  91280 306016    0    0     0    16 2168  314 12 39 48  0
 1  0      0 1225940  91288 306024    0    0     0    24 2164  293 12 39 49  0
 1  0      0 1226060  91296 306028    0    0     0    13 2161  273 12 40 49  0
 1  0      0 1225972  91296 306048    0    0     0     1 2154  259 12 39 49  0
 1  0      0 1226212  91304 306060    0    0     0    12 2149  252 11 40 49  0
 1  0      0 1225936  91316 306076    0    0     0    14 2152  274 11 40 49  0
 1  0      0 1226028  91324 306092    0    0     0    40 2155  270 11 40 49  0
 1  0      0 1226004  91332 306104    0    0     0    18 2151  252 11 40 49  0
 1  0      0 1225920  91340 306120    0    0     0    12 2150  237 11 40 49  0
 1  0      0 1225936  91348 306132    0    0     0    14 2151  243 11 40 49  0
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 1205372  91380 306244    0    0     0    73 2259  695 18 41 41  0
 1  0      0 1205748  91388 306172    0    0     0    42 2191  403 11 40 49  0
 1  0      0 1205920  91396 306188    0    0     0    12 2159  294 11 40 49  0
 1  0      0 1225108  91404 306184    0    0     0    60 2154  247 12 40 49  0
 1  0      0 1225468  91408 306204    0    0     0     0 2148  231 11 40 49  0
 1  0      0 1225460  91416 306216    0    0     0    15 2152  240 11 40 49  0
 1  0      0 1225608  91424 306236    0    0     0    15 2161  287 11 40 49  0
 1  0      0 1225740  91432 306248    0    0     0    19 2150  235 11 40 49  0
 1  0      0 1225392  91440 306260    0    0     0    11 2153  265 11 40 49  0
 1  0      0 1225468  91448 306272    0    0     0    14 2163  307 11 40 49  0
 1  0      0 1224924  91460 306292    0    0     0    34 2162  294 11 40 49  0
 1  0      0 1225124  91468 306304    0    0     0    23 2157  255 12 40 49  0
 1  0      0 1205072  91480 306400    0    0     0    59 2234  580 18 41 41  0
 1  0      0 1205300  91488 306344    0    0     0    22 2195  401 11 40 49  0
 1  0      0 1205184  91496 306352    0    0     0    13 2162  318 11 40 49  0
 1  0      0 1225080  91504 306356    0    0     0    26 2149  289 11 40 49  0
 1  0      0 1224980  91504 306376    0    0     0     0 2149  279 11 40 49  0
 1  0      0 1225444  91512 306388    0    0     0    54 2151  231 11 40 49  0
 1  0      0 1225212  91520 306404    0    0     0    16 2152  246 11 40 49  0
 1  0      0 1225212  91528 306416    0    0     0    15 2150  245 12 40 49  0
 1  0      0 1224908  91540 306432    0    0     0    18 2152  239 12 39 49  0
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 1225080  91548 306448    0    0     0    14 2150  238 11 40 49  0
 1  0      0 1225040  91556 306460    0    0     0    14 2152  252 11 40 49  0
 1  0      0 1225080  91564 306464    0    0     0    14 2152  239 11 40 49  0
 1  0      0 1204540  91572 306560    0    0     0    11 2222  543 18 41 41  0
 2  0      0 1205100  91580 306508    0    0     0    52 2189  423 11 40 49  0
 1  0      0 1205088  91588 306520    0    0     0    19 2161  307 12 39 49  0
 1  0      0 1224620  91596 306524    0    0     0    12 2151  237 11 40 49  0
 1  0      0 1224612  91604 306540    0    0     0    24 2150  251 11 40 49  0
 1  0      0 1224908  91612 306552    0    0     0    13 2152  244 12 39 49  0
 1  0      0 1224856  91620 306564    0    0     0    14 2161  279 11 40 49  0
 1  0      0 1224892  91628 306568    0    0     0    40 2153  242 11 40 49  0
 2  0      0 1224800  91628 306592    0    0     0     0 2154  252 11 40 49  0
 1  0      0 1224636  91644 306596    0    0     0    60 2153  267 12 40 49  0
 1  0      0 1224508  91660 306600    0    0     0    21 2149  254 11 40 49  0
 1  0      0 1224668  91660 306632    0    0     0     0 2149  259 12 39 49  0
 0  0      0 1204776  91672 306728    0    0     0    18 2210 1316 16 26 58  0
 0  0      0 1205208  91680 306672    0    0     0    54 2161  666  1  1 98  0
 0  0      0 1205396  91688 306684    0    0     0    60 2135  567  1  1 98  0
 0  0      0 1225136  91696 306688    0    0     0    13 2124  494  1  1 98  0
 0  0      0 1226920  91704 306704    0    0     0    24 2124  494  1  1 98  0
 0  0      0 1220028  91712 306716    0    0     0    21 2198  810  6  2 92  0

-- 
			WBR, Alex.

Re: [gentoo-user-ru] тормоза

[Alex Efros]

Hi!

On Wed, Apr 08, 2009 at 07:40:05AM +0300, Alex Efros wrote:
> Я ещё запустил в фоне vmstat 5, и собрал инфу во время очередного
> подвисания X-ов. Из него видно, что подвисание длилось примерно 4 минуты,

Работать с системой сегодня было нереально - X-ы висли каждые несколько
минут. Перегрузился, и пока полёт нормальный - вероятно, этот баг теперь
будет, как и раньше, происходить с каким-то другим процессом, не X-ами, и,
соответственно, будет намного менее заметен.

-- 
			WBR, Alex.

[gentoo-user-ru] Re: [gentoo-user-ru] тормоза

[Михаил Молчанов]

у меня тоже такое бывало, но при удалении hal'а пропало.

Re: [gentoo-user-ru] тормоза

[spirit]

Alex Efros пишет:
> Hi!
>
> Никто не сталкивался с периодическими подвисаниями системы секунд на 5-10?
> При этом интерфейс вообще не работает (мышка движется, но клики мышки и
> нажатия кнопок игнорируются), а когда через несколько секунд он "отвисает"
> все клики/нажатые кнопки срабатывают (т.е. они не потерялись, а ждали
> где-то в очереди).
>
> Что интересно, у меня используется conky (разные системные индикаторы),
> так после отвисания я на нём наблюдаю за тот период, что система ни на что
> не реагировала, 100% загрузку одного из ядер CPU. Поймать гада, жрущего
> в это время CPU не удаётся - как только я запускаю top или просто
> переключаюсь в консоль с уже запущенным top использование CPU моментально
> прекращается.
>
> По симптомам это более всего похоже на баг ядра (хотя бы просто потому,
> что система так жёстко подвисать не имеет права в принципе). Кроме того,
> раньше (несколько месяцев назад) такого не случалось, а сейчас где-то раз
> в несколько дней происходит.
>
>
> P.S.
> В общем, железо становится всё мощнее, а система в общем работает всё хуже.
> Раньше это только с виндой происходило, но сейчас, похоже, и линух этим
> заражается. Чего стоит только баг с дикими тормозами при интенсивном
> дисковом I/O (когда у меня rtorrent новый файл создаёт или хеш считает на
> машине ничего больше делать нельзя, и это при почти 0% загрузке CPU) -
> сразу вспоминаются древние анекдоты про винду 3.1: "Папа, а что такое
> многозадачность - подожди, сынок, сейчас дискету доформатирую и покажу".
> Если кому интересно, вот инфа по этому багу:
>     http://linuxforum.ru/index.php?showtopic=67731&st=0
>     http://www.opennet.ru/opennews/art.shtml?num=19790
>     http://bugzilla.kernel.org/show_bug.cgi?id=12309
>
>   
урли довольно интересные... особенно
http://bugzilla.kernel.org/show_bug.cgi?id=12309 , на который ведет одна
из страниц форума.
у меня Core2Duo E8500 3Ghz .. винты сата, чипсет интел G35... в общем
одна из конфигураций, которая была описана на форуме.
однако у меня софтверный рейд на двух винтах. и на нем стоит /.
много дисковых операций я не совершал, однако когда у меня оперативы
было 1Г, то когда своп начинал юзаться, система "повисала" на минут 5 аж,
когда отвисала видел что в свопе 600М болтается :). в эти "повисы" даже
мышка не двигалась :) ядро было 2.6.26
Сейчас у меня 3Г ОЗУ и ядро 2.6.28.8 ... тормозов я не вижу видать
потому, что ничего не свопится.
однако когда начинают считаться хеши в linuxdcpp то становиться довольно
проблематично что то делать... мышка подтормаживает или где нить музыка
заикнеться. благо п2п пользуюсь редко, а скорость хеширования порядка
120Мб/с. хотя! иногда скорость достигает и 180Мб/с что правильно... но
почему то в половине случаев оно идет на низких скоростях.. хотя проц не
используется на полную.. так что при подчете хеша все упирается в винт таки.
кстати ФС - ext4.  не ext4dev. с 2.6.28 оно избавилось от суффикса dev.