Open SUSE 10.3 проблемы с быстродействием (замедление работы системы в операциях с диском...)

[AlexNT]

Добавил вторую картинку Промазал сначала.

То есть, у Вас суперовский IDE диск. Я хочу такой-же. Преславутая Windows Vista копирует файл объемом 6 гигов на том же харде (не с харда на хард, а на том-же) 29-30 мб/с. Хард - Вестерн 320 гигов, 16 Мб - кеш, интерфейс - SATA2. Буду завтра на работе, могу картиночку приложить. Да, c XP - при работе с IDE то же могу прислонить. А кто-то может добавить еще как выполняется копирование в БСД. А потом Вы решите это копирование или фигурное катание.

Уважаемый Юрий, вы внимательно прочитайте о чем тут идет речь. Тут речь идет не о скорости копирования в 2.4 vs 2.6. Почему в к замерам то к этим приходите в этой теме? Проблема то в том что когда ИДЕТ ПРОЦЕСС КОПИРОВАНИЯ ПРОЦЕССОР ЗАГРУЖЕН НА 100 процентов И КОМП ТОРМОЗИТ в ядре 2.6, а когда идет копирование на ядре 2.4 процессор ВАПЩЕ НЕ ЗАГРУЖЕН и КОМП НЕ ТОРМОЗИТ. И судя по всему эта проблема не специфичная конкретно для какого то оборудования. У кого то все в норме у кого то нет.

В FreeBSD КОПИРОВАНИЕ ИДЕТ НОРМАЛЬНО, так же как и в 2.4 ядре, когда файл копируется процессор не загружен фактически.
А в 2.6 просто непонятно чем простейшая операция копирования так занимает процессор.

Оборудование: ASUS P4S800-MX целер 2.6, операционка Open SuSe 10.3 такой же глюк наблюдается на ASUS M2NPV-VM. Система только что установленая ядро не пересобрано. Начинаю копировать файл с места на места в системе ext3 наблюдаю что CPU IDLE = НУЛЮ. IOWAIT = 99.
Как это понимать или объяснить? Говорят что UDMA не работает, но оно работает, т.к. если его реально выключить то тогда система минут по 10 грузится.

Ну как еще то объяснить проблему?

Так же пробовал все ставить на рейзер, СИТУАЦИЯ АНАЛОГИЧНАЯ. Переключал планировщик - меняется тока характер тормозов, но как тормозило так и тормозит. На целере я даже в опере не могу вкладку переключить когда на 2.6 что то в фоне копируется. Это как попробовать в 95 винде на 486том форматировать дискету и в процессе что то пытаться сделать, как ни странно эффект прям один в один.

[A_1]

КОМП ТОРМОЗИТ в ядре 2.6,

Если я правильно понимаю, проблема именно в этом.

То, что процессор загружен на 100% не страшно, если он своевременно освобождается для более приоритетных задач.
И чем он занят, интуитивно понятно - кэширует чтение/запись.
Непонятно, что делать. Отключить кэширование?

Обо всём поговорили, кроме объёма оперативной памяти. Или я пропустил?
Что, если размер кэша такой, что всё остальное при этом просто в своп уходит?
Как бы это обнаружить?

imho прежде чем решать, проблему надо бы её локализовать.

[HighwayStar]

Предлагаю. для объективного тестирования производительности дисков а не абстрактных кде окошек с серединой процесса копирования.

1. Создаем файл размером 1Gb

Код: Выделить всё

dd if=/dev/zero of=testfile.1gb bs=1M count=1000

при этом можно уже оценить скорость записи на диск. У меня на данном этапе получилось

Код: Выделить всё

1000+0 записей считано
1000+0 записей написано
 скопировано 1048576000 байт (1,0 GB), 33,4718 c, 31,3 MB/c

2. Копируем данный файл на другой раздел этого же жесткого диска, засекая время.

Код: Выделить всё

time cp testfile.1gb /mnt/target/temp

Я получил

Код: Выделить всё

real    0m46.747s
user    0m0.052s
sys     0m4.844s

далее берем real время и делим объем нашего файла на него.
1000M/46.747s = 21.39Mb/s

3. точно так же можно вычислить скорость считывания с HDD

Код: Выделить всё

time cp testfile.1gb /dev/null

я получил

Код: Выделить всё

real    0m22.573s
user    0m0.032s
sys     0m1.168s

В дело вступает калькулятор:
1000M/22.573s = 44.30Mb/s

Исходный раздел ext3 целевой - reiserfs. Винт SATA работающий в режиме SATA1

[AlexNT]

...

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

Вот вам скриншоты с TOP в первом случае и во втором с ядром 2.4 и 2.6. При любых операциях с винчестером в 2.6 система занимает процессор и все встает колом, я даже скриншот делаю с трудом. В 2.4 все нормально, процесс идет я могу делать что то еще.

Мне когда то приходилось на ассемблере писать программы для процессоров типа Z80, там была команда halt, она один такт пропускала просто. Так вот такое ощущение что в ядре 2.6 в цикле копирования выполняется тысячи таких хальтов. Что делать и кто виноват никто сказать не может.

КОМП ТОРМОЗИТ в ядре 2.6,

Если я правильно понимаю, проблема именно в этом.

То, что процессор загружен на 100% не страшно, если он своевременно освобождается для более приоритетных задач.
И чем он занят, интуитивно понятно - кэширует чтение/запись.
Непонятно, что делать. Отключить кэширование?

Обо всём поговорили, кроме объёма оперативной памяти. Или я пропустил?
Что, если размер кэша такой, что всё остальное при этом просто в своп уходит?
Как бы это обнаружить?

imho прежде чем решать, проблему надо бы её локализовать.

1. Дело именно в том, что процессор занят и занят себе, пока не закончится процесс копирования.
- В случае с кешированием, скорость возрастает всего на 6-8мб в секунду, а производительность страдает немотивировано.
2. Работать когда идет копирование невозможно, ибо пока не кончится процесс копирования все дико тормозит.
3. В случае с моей ситуацией СВОП ПУСТ. Что видно на скриншотах.

Тогда вопрос тогда где задаются параметры кеширования чтения записи?

[HighwayStar]

Какие еще объективные расчеты вы хотите замерить?

Когда я в фоне копирую образ 4 гигабайта я не могу работать пока не дождусь окончания копирования.

Только что попробовал. Смотрю кино в Kaffeine и внезапно начинаю копировать тестовый файл из своего поста выше. Как это ни странно видео тормозить не начинает. Звук не прерывается. ЧЯДНТ?

Естественно копирование при этом происходит несколько медленнее. У меня оно заняло 1m21.789s.
Как получить такие тормоза что станет невозможно работать? о какого рода работе идет речь? Если нужно работать с приложением которое само активно использует HDD то возможно описаная вами ситуация.

[AlexNT]

Какие еще объективные расчеты вы хотите замерить?

Когда я в фоне копирую образ 4 гигабайта я не могу работать пока не дождусь окончания копирования.

Только что попробовал. Смотрю кино в Kaffeine и внезапно начинаю копировать тестовый файл из своего поста выше. Как это ни странно видео тормозить не начинает. Звук не прерывается. ЧЯДНТ?

Естественно копирование при этом происходит несколько медленнее. У меня оно заняло 1m21.789s.
Как получить такие тормоза что станет невозможно работать? о какого рода работе идет речь? Если нужно работать с приложением которое само активно использует HDD то возможно описаная вами ситуация.

не затруднит ли вас, сделать аналогичный скриншот с топом в процессе копирования файла примерно в середине копирования? хотелось бы увидеть насколько занят процессор...

1. Начал смотреть фильм, включил копирование и получил рывки и заикания при воспроизведении...
2. В процессе копирования тыкнул в меню (подождал слегка) запустил браузер и наблюдал за прыгающим курсором пока копирование не завершилось браузер не запустился.

[HighwayStar]

ответом на скриншоты приведенные выше с ядром 2.4 является man vmstat
читаем

These are percentages of total CPU time.

us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

В 2.4 время ожидания завершения операций ввода-вывода просто не учитывалось и включалось в показатель Idle
Поэтому для объективности тестов прибавь wa к id в top полученом на ядре 2.6

[AlexNT]

ответом на скриншоты приведенные выше с ядром 2.4 является man vmstat
читаем

These are percentages of total CPU time.

us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

В 2.4 время ожидания завершения операций ввода-вывода просто не учитывалось и включалось в показатель Idle
Поэтому для объективности тестов прибавь wa к id в top полученом на ядре 2.6

Я это прекрасно понимаю, но машина то ТОРМОЗИТ. Я прекасно понимаю что датчик в 2.4 не учитывался и был в идле. НО КОМП ТО ТОРМОЗИТ.
в 2.4 НЕ ТОРМОЗИТ, в 2.6 ТОРМОЗИТ. Я и пытаюсь это объяснить и помощи прошу.

У вас то он в каком состоянии при копировании находится? Скока он сжирает ресурсов?

Что мне толку прибавлять иостат к идле от этого что я должен решить что комп не тормозит и сидеть ждать запуска браузера чтоли? Или смотреть дергающийся фильм и внушать себе "ничего ничего это все отлично чтоли?"

Потом запускаю FreeBSD 6.3 начинаю делать тоже самое в кде, запускаю копирование с винта на винт, тяну по фтп, запускаю всякие чаты, браузеры, смотрю кино! И у меня ничего не тормозит.

[HighwayStar]

У вас то он в каком состоянии при копировании находится? Скока он сжирает ресурсов?

Что мне толку прибавлять иостат к идле от этого что я должен решить что комп не тормозит и сидеть ждать запуска браузера чтоли? Или смотреть дергающийся фильм и внушать себе "ничего ничего это все отлично чтоли?"

У меня ничего не дергается при копировании.
Пожалуйста, картинки:

[AlexNT]

У вас то он в каком состоянии при копировании находится? Скока он сжирает ресурсов?

Что мне толку прибавлять иостат к идле от этого что я должен решить что комп не тормозит и сидеть ждать запуска браузера чтоли? Или смотреть дергающийся фильм и внушать себе "ничего ничего это все отлично чтоли?"

У меня ничего не дергается при копировании.
Пожалуйста, картинки:

У вас просто более быстрый процессор, скорее всего пентиум или атлон. А время вашего процессора так же сожрано как и у меня, тока он как раз вытягивает видео. У вас тоже самое.

[A_1]

У вас просто более быстрый процессор,

А может просто целерон 2.6 виноват?
У него кэш всего лишь 128 Кб.
Ему просто тяжело между задачами переключаться.

У меня частота 1.7 против 2.6, но кэш 2 Мб.
И работает безо всяких тормозов...

[HighwayStar]

У вас просто более быстрый процессор, скорее всего пентиум или атлон. А время вашего процессора так же сожрано как и у меня, тока он как раз вытягивает видео. У вас тоже самое.

У меня Sempron 2500+ на Socket 754. Чему тут вытягивать видео?

И в чем может быть проблема если он нагружен при копировании всего на 4% пользователем и 12% системой? Остается еще 80% на другие задачи.

Опять же если вы утверждаете что во freebsd ничего не тормозит, точто там делает процессор в ожидании окончания операции ввода-вывода? Там внезапно повышается производительность жесткого диска до производительности процессора?

[AlexNT]

У вас просто более быстрый процессор,

А может просто целерон 2.6 виноват?
У него кэш всего лишь 128 Кб.
Ему просто тяжело между задачами переключаться.

У меня частота 1.7 против 2.6, но кэш 2 Мб.
И работает безо всяких тормозов...

Блин... Я же русским языком пишу. В FreeBSD все нормально... На ядре 2.4 все нормально. На ядре 2.6 операции ввода вывода занимают процессорное время НЕМОТИВИРОВАНО. Параметр iowait что означает? Он означает что ПРОЦЕССОР ЗАНЯТ ВВОДОМ ВЫВОДОМ НА КАКОЙ ТО ПРОЦЕНТ. Дак на скриншотх с ядра 2.6 ВИДНО ЧТО ПРОЦЕССОР ЗАНЯТ ВВОДОМ ВЫВОДОМ НА 80-90 ПРОЦЕНТОВ.

ДАК КАК МОЖНО МИКРОПОРЦЕССОР ЗАГРУЗИТЬ ТО КОПИРОВАНИЕМ ФИЛЬМА НА 90 ПРОЦЕНТОВ?

На Атлоне 2ухядерном я копирую и смотрю кино. ОДНО ЯДРО ПРИ КОПИРОВАНИИ СОЖРАНО НА 100 процентов. Там да не тормозит.
Я сервер если поставлю на линуксе файловый он мне любой камень будет прогревать постоянным 100 процентов. Неужели кроме меня это никто не замечает?

У вас просто более быстрый процессор, скорее всего пентиум или атлон. А время вашего процессора так же сожрано как и у меня, тока он как раз вытягивает видео. У вас тоже самое.

У меня Sempron 2500+ на Socket 754. Чему тут вытягивать видео?

И в чем может быть проблема если он нагружен при копировании всего на 4% пользователем и 12% системой? Остается еще 80% на другие задачи.

Опять же если вы утверждаете что во freebsd ничего не тормозит, точто там делает процессор в ожидании окончания операции ввода-вывода? Там внезапно повышается производительность жесткого диска до производительности процессора?

По вашему что означает параметр iowait? ЧТО ПРОЦЕССОР ЗАНЯТ "ЧЕМ ТО" А ЧЕМ ОН ЗАНЯТ ТО? Где вы увидели 80 процентов свободных ресурсов? Черным по белому написано что ВАШИ СВОБОДНЫЕ РЕСУРСЫ УШЛИ В IOWAIT.
По поводу "производительность жесткого диска до производительности процессора" я вапще не понял масло маслянное какое то...
Вам что объяснить как микропроцессор работает а как контроллер жесткого диска? Что такое "шина данных", "шина адреса", "такт" и прочее?

По поводу "Опять же если вы утверждаете что во freebsd ничего не тормозит, точто там делает процессор в ожидании окончания операции ввода-вывода?" Дак в ожидании ввода-вывода ОН ПРОСТАИВАЕТ В FreeBSD! А В ЯДРЕ 2.6 НА ЛИНУКСЕ ЗАНЯТ! Ваш же top это показывает елки моталки. Свободен это IDLE, все остальное НА СКОЛЬКО ЧЕМ ЗАНЯТ ПРОЦЕССОР.

[AlexNT]

Вот вам мессага с опеннета:

цитата:
--------------------------------------------------------------------------------------------------------------------------------------
"Ubuntu периодически тормозит, 'входит в ступор'"
Сообщение от Jet (??) on 20-Дек-07, 16:12
>Не сталкивался, так что могу дать лишь несколько общих советов. Топ, кроме
>загрузки общей, показывает ее и по процессами, посмотрите, кто там самый
>прожорливый. Загруженность процессора это не единственная причина тормозов, есть еще система
>ввода вывода, посмотрите что в таких ситуациях показывает iostat/vmstat. Также проверьте
>не связаны ли тормоза с запуском чего-либо по крону.

Посмотрел. iowait достигает 90-99%, считывание-запись на жесткий диск в этот момент по нулям...
vmstat показывает cpu wait 95

Очевидно что ядро что-то ждет... Но чего оно ждет и как это исправить?

----------------------------------------------------------------------------------------------------------------------------------------
3. "Ubuntu периодически тормозит, 'входит в ступор'"
Сообщение от Jet (??) on 20-Дек-07, 20:14
>[оверквотинг удален]
>проц - интел КореДуо Озу 1Гб
>
>Установлено все по умолчанию.
>
>Система периодически "входит в ступор","залипает" то есть не просто тормозит, а тормозит
>таким образом: перестает воспроизводить звук (xmms, mplayer), не реагирует на запуск
>прог, окошки при этом могут переключатся, в mc возможно переходить между
>каталогами но невозможно просмотреть файл, топ показывает примерно 30-40% загрузку...
>Это "залипание" длится до 30 секунд, потом все продолжается как обычно.
>У кого нибудь такое было? Что вгоняет систему в ступор?
----------------------------------------------------------------------------------------------------------------------------------------
решение было такое:
в файле /var/log/kern.log были найдены строки:
Dec 20 18:20:18 x-laptop kernel: [16119.308000] ata1: port is slow to respond, please be patient (Status 0xd0)
Dec 20 18:20:23 x-laptop kernel: [16124.292000] ata1: device not ready (errno=-16), forcing hardreset
Dec 20 18:20:23 x-laptop kernel: [16124.292000] ata1: soft resetting port
Dec 20 18:20:24 x-laptop kernel: [16124.708000] ata1.00: configured for UDMA/100
Dec 20 18:20:24 x-laptop kernel: [16124.900000] ata1.01: configured for UDMA/25

поиск по гуглу привел к страничке с утилитой для перепрошивки сидирома.
http://forum.rpc1.org/viewtopic.php?p=206622

файл: TS-L632D_AS99_ASUS_OEM.zip

firmware сидюка было перепрошито. проблема исчезла.

Подвисания возникали из-за того, что каждые несколько минут происходил резет сидюка, что приводило к iowait 90% и соответственно система замирала.

Ноутбук asus a6jc сидиром TS-L632D

Ключевой момент выделен жирным.

[HighwayStar]

Ну вот, это то о чем я говорил ранее - проблемы с железом. Только в этом случае могут быть такие зависания, иначе бы большинство сообщений данного форума были с жалобами на подобные зависания.
Во время IOwait процессор ни чем не занят.Не случайно же раньше это время входило в Idle.
В любой ОС, с любым ядром процессор будет ждать пока выполнятся операции ввода-вывода, за исключением наверное риалтаймовых ОС.

[AlexNT]

Ну вот, это то о чем я говорил ранее - проблемы с железом. Только в этом случае могут быть такие зависания, иначе бы большинство сообщений данного форума были с жалобами на подобные зависания.
Во время IOwait процессор ни чем не занят.Не случайно же раньше это время входило в Idle.
В любой ОС, с любым ядром процессор будет ждать пока выполнятся операции ввода-вывода, за исключением наверное риалтаймовых ОС.

Вы вапще сейчас какую то ерунду пишете. IOWAIT - это ожидание ввода вывода. Раньше куда это уходило, пешком так и уходило? Раньше этот датчик НЕ УЧИТЫВАЛСЯ ВСЕГО НАВСЕГО. От того что он раньше не учитывался проблема остается. Idle - это свободен, Iowait - ЭТО ЗАНЯТ ОПЕРАЦИЕЙ ВВОДА ВЫВОДА, и в нормальном виде НА НЕЗАГРУЖЕНОЙ ДИСКОВЫМИ ОПЕРАЦИЯМИ МАШИНЕ этот параметр должен быть 3-2 процента. Копирование фильма это что ПОЛНАЯ ЗАГРУЗКА ПРОЦЕССОРА МАШИНЫ ДИСКОВОЙ ОПЕРАЦИЕЙ ВВОДА ВЫВОДА?

Если вы не понимаете что такое загрузка процессора зачем вы спорите то?

Вы же мне свой топ показали с таким же iowaitом, у вас тоже проблема железа? И у меня и у всех тут? А как 2.4 ядро ставишь проблема исчезает?

Или вы считаете что должно быть - идет копирование процессор занят на 100 процентов кончилось - свободен на 100 процентов? Ну тогда я не вижу смысла разговор продолжать.

[A_1]

AlexNT, успокойтесь уже, пожалуйста.
Во время Iowait процессор совершенно свободен и мог бы заняться чем-нибудь другим.
НО, система занята и не даёт процессору достойных задач.
Дело всё-таки не в железе, а в системе.
А раз система занята, то и видны тормоза.
Так, мо моему.

[AlexNT]

AlexNT, успокойтесь уже, пожалуйста.
Во время Iowait процессор совершенно свободен и мог бы заняться чем-нибудь другим.
НО, система занята и не даёт процессору достойных задач.
Дело всё-таки не в железе, а в системе.
А раз система занята, то и видны тормоза.
Так, мо моему.

Поддерживаю на 100 процентов.

Система свободна когда (либо в том числе) iowait стремится к нулю, и занята когда iowait стремится к 100 процентам. Разве это не так?

Вопрос чем занята система при копировании большого файла?
Вот при архивировании понятно, а вот при тупом копировании нет.
Такой iowait может быть на загруженом серваке к которому цепанулось человек 40 и все что то качают, но никак не при копировании одного единственного файла.
Куда копать? Какие параметры менять?
Как ограничить использование CPU при работе с диском?

Я с процессорами знаком вполне явно, архивирование это процесс математических вычислений он стремится занять весь процессор. Копирование же это работа контроллера жестких дисков. Проблема явно в драйверах для работы с HDD если работу контроллера выполняет процессор.

[-sanches-]

Пошаманил тут на Debian с ядром 2.6.24-1-686.
Копировал 4 гига 1 файлом с одного раздела на другой.
Железо
-Processor-
Name : Intel® Celeron® D CPU 3.20GHz
Family, model, stepping : 15, 6, 4 (Pentium 4)

-PCI Devices-
IDE interface : Intel Corporation 82801EB/ER
IDE interface : Intel Corporation 82801EB

-IDE Disks-
Seagate ATA ST380811AS.

При копировании реакция системы на действия юзера уменьшается заметно но сосем не критично. Скорость копирования от 10 до 15 Мб/сек.
Видео показывает нормально (естественно не hdtv и dvd)
Показания top очень странные. (Вообще говоря, в одной книге по оптимизации Unix систем, это утилиту вовсе не жаловали).
Запускаю при процессе копирования top с парраметрами по умолчанию. Самый первый показатель:

Код: Выделить всё

Cpu(s):  6.9%us,  3.9%sy,  0.1%ni, 87.4%id,  1.5%wa,  0.1%hi,  0.1%si,  0.0%st

Второй

Код: Выделить всё

Cpu(s):  9.7%us, 27.1%sy,  0.0%ni,  0.0%id, 63.2%wa,  0.0%hi,  0.0%si,  0.0%st

Третий

Код: Выделить всё

Cpu(s):  5.3%us, 11.3%sy,  0.0%ni,  0.0%id, 82.7%wa,  0.0%hi,  0.7%si,  0.0%st

И далее значение wa колеблется от 80 до 95 %.
А теперь если запустить top -d 0.1 то можно заметить, что значение wa меняется от 20 до 100 % весьма хаотично (даже значение 0 замечал). Так что думаю, полагаться только на показания top не совсем правильно.

[A_1]

Система свободна когда (либо в том числе) iowait стремится к нулю, и занята когда iowait стремится к 100 процентам. Разве это не так?

Думаю, что не совсем так. Или совсем не так.
iowait - характеристика дисковой системы, а не операционной.

Вопрос чем занята система при копировании большого файла?

Есть гипотеза.
У меня система находится пусть не на отдельном диске, но на совсем отдельном разделе.
А для системы это наверное отдельное дисковое устройство.
Со своим кэшем и т.п.
При своей работе система часто пишет на диск своё состояние, логи, да мало ли зачем ей диск нужен.
И если загрузить системный диск копированием, то система может ждать в общей очереди.
Отсюда и тормоза.
Как проверить?

[-sanches-]

При своей работе система часто пишет на диск своё состояние, логи, да мало ли зачем ей диск нужен.
И если загрузить системный диск копированием, то система может ждать в общей очереди.
Отсюда и тормоза.
Как проверить?

Ну это все поверхностная теория и проверять ее не имеет смысла. Поищите в нэте книгу "Настройка производительности Unix-систем : Мусумеси Д.-П". Хоть она и старая, но тем не менее очень интересная. Я ее так и не дочитал, ибо сложно быстро осмыслить такой поток информации.

[AlexNT]

В общем уважаемые господа товарищи, я за возможно слишком резкий тон выше прошу прощения HighwayStar, Yuriy.
Видимо я слегка переработал просто, нервы шалят.

Я вооружился системами FreeBSD 6.3, Slackware 12, Windows XP.
Забыл про iowait и просто копировал с места на место 4 гигабайтый файл.
Смотрел на показания KDEшного монитора. В процессе копирования пытался что то делать.

В общем то спецэффекты наблюдались на всех системах. Но характер спецэффектов разный.
Если не доверять датчикам (в XP и FreeBSD 6.3) процессор свободен, в Slackware 12 как бы занят, то гм...
определенные торможения заметны во всех системах. В Slackware 12 более выражены чем у остальных.
Однако, в целом (если ничего не копируется) быстрее всех шевелится графический интерфейс у
Slackware (хотя бы та же opera).

В общем то я затрудняюсь что либо утверждать далее...
Скорее всего мое мнение не объективно. Как то разобраться в этом спорном вопросе наверное сможет только разработчик ядра.

10 лет назад мне приходилось работать с контроллером гибких магнитных дисков ВГ93 на аппаратном уровне, там это работало так:
Программа подавала команду контроллеру он ее выполнял, процессор ожидал выполнения и в момент ожидания простаивал. Но так как
у процессора тех времен была всего одна программа обработки прерывания (собственно и прерывание было тоже одно). Можно было сделать
"одновременную" загрузку и выполнение программы. Т.е. работа с контроллером осущетвлялась на уровне программы обработки прерывания,
а работа с основной программой на стандартном уровне.

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

Это все мое лично ИМХО конечно же.

[A_1]

10 лет назад мне приходилось работать с контроллером гибких магнитных дисков ВГ93 на аппаратном уровне, там это работало так:
Программа подавала команду контроллеру он ее выполнял, процессор ожидал выполнения и в момент ожидания простаивал.

Даже такой допотопный контроллер, как КР1818ВГ93 уже мог работать в режиме dma.
И операционные системы того времени этим пользовались. Когда программа давала задание на чтение/запись, система просто передавала контроллеру адрес для данных и прочие параметры, после чего возвращала управление программе.
И окончания чтения/записи ждала уже программа, а не система. Хотя вполне себе были программы, которые в это время занимались полезными вещами.
Аппаратных прерываний у системы было достаточно, а кроме того были и программные. Ну в точности как сейчас.

Многозадачная система от однозадачной отличается лишь тем, что есть у неё диспетчер процессов, который переключает процессор между разными процессами.
Есть пенальти за такое переключение, причём тем больше, чем меньше у процессора кэш.
Всё же склоняюсь я к такому объяснению.

Если есть такая возможность, замените селерон на что-нибудь более пристойное.
Если я прав, должно помочь.

[artb1sh]

Даже такой допотопный контроллер, как КР1818ВГ93 уже мог работать в режиме dma.

в то время как в ядрах начиная с 2.6.24 половину опций с дма убрали..

правда не знаю как и лечить медленную работу с дисками(((

[Reg]

Предлагаю. для объективного тестирования производительности дисков а не абстрактных кде окошек с серединой процесса копирования.

ок.
Система:
Ноут, материнка EliteGroup, чипсет SiS какой-то. Проц S478 Intel Pentium4 3.0Ghz Prescott, 2x256 DDR400, Hard IDE Seagate 100Gb.
OpenSuSe 10.3 со всеми обновлениями. Жестский разбит, оба раздела reiserFS.

Код: Выделить всё

reg@reg-note:~> dd if=/dev/zero of=testfile.lgb bs=1M count=1000
1000+0 записей считано
1000+0 записей написано
 скопировано 1048576000 байт (1,0 GB), 71,4512 c, 14,7 MB/c
reg@reg-note:~>

Во время выполнения операции проц занят на 100%, Переключения меж окнами быстрое, а вот запуск новых приложений приостанавливается - конк например запустился ТОЛЬКО после прекращения операции. Скрин - desctop7

Далее:

Код: Выделить всё

reg-note:/home/reg # time cp testfile.lgb /tmp

real    2m15.997s
user    0m0.048s
sys     0m3.868s

Ваще жесть. 1000М/135.997=7,35 Mb/s
На SLED10 такого вроде не было... Дома на 845чипе и IP4 2.8 Prescott копирование работает гораздо быстрее, по загрузке просто непомню...

Напрашивается вывод - нестандартные чипсеты с ядром 2.6 не дружат - скорее всего по-умолчанию что-то отключено для увеличения стабильности...

Да, кстати! совсем забыл добавить. Система работоспособна ТОЛЬКО с параметром при загрузке acpi=off. Иначе - отваливается мышка с клавиатурой через 20-30 после загрузки. SLED10 работала с пол-года на этой же системе абсолютно нормально...

[AlexNT]

10 лет назад мне приходилось работать с контроллером гибких магнитных дисков ВГ93 на аппаратном уровне, там это работало так:
Программа подавала команду контроллеру он ее выполнял, процессор ожидал выполнения и в момент ожидания простаивал.

Даже такой допотопный контроллер, как КР1818ВГ93 уже мог работать в режиме dma.
И операционные системы того времени этим пользовались. Когда программа давала задание на чтение/запись, система просто передавала контроллеру адрес для данных и прочие параметры, после чего возвращала управление программе.
И окончания чтения/записи ждала уже программа, а не система. Хотя вполне себе были программы, которые в это время занимались полезными вещами.
Аппаратных прерываний у системы было достаточно, а кроме того были и программные. Ну в точности как сейчас.

Многозадачная система от однозадачной отличается лишь тем, что есть у неё диспетчер процессов, который переключает процессор между разными процессами.
Есть пенальти за такое переключение, причём тем больше, чем меньше у процессора кэш.
Всё же склоняюсь я к такому объяснению.

Если есть такая возможность, замените селерон на что-нибудь более пристойное.
Если я прав, должно помочь.

Думаю что вы правы. Купил 80тку саташную домой, а дома атлон двухядерный, погоняю SuSe там хорошенько, посмотрю что и как будет. Скорее всего будет все нормально. Наверное я слишком много хочу от несчастного целерона.

Даже такой допотопный контроллер, как КР1818ВГ93 уже мог работать в режиме dma.

в то время как в ядрах начиная с 2.6.24 половину опций с дма убрали..

правда не знаю как и лечить медленную работу с дисками(((

Но всеже что то не то в работе дисковой подсистемы есть...

[AlexNT]

Ваще жесть. 1000М/135.997=7,35 Mb/s
На SLED10 такого вроде не было... Дома на 845чипе и IP4 2.8 Prescott копирование работает гораздо быстрее, по загрузке просто непомню...

Напрашивается вывод - нестандартные чипсеты с ядром 2.6 не дружат - скорее всего по-умолчанию что-то отключено для увеличения стабильности...

Да, кстати! совсем забыл добавить. Система работоспособна ТОЛЬКО с параметром при загрузке acpi=off. Иначе - отваливается мышка с клавиатурой через 20-30 после загрузки. SLED10 работала с пол-года на этой же системе абсолютно нормально...

Что то подобное я наблюдаю на своем хламе, кстати тоже на SIS чипсете. Не считая того что acpi у меня не выключено. Насколько быстрее копирование будет работать на nForce дома посмотрю в выходные. И замеры выложу.

[V_e_n_o_m]

Ваще жесть. 1000М/135.997=7,35 Mb/s
На SLED10 такого вроде не было... Дома на 845чипе и IP4 2.8 Prescott копирование работает гораздо быстрее, по загрузке просто непомню...

Напрашивается вывод - нестандартные чипсеты с ядром 2.6 не дружат - скорее всего по-умолчанию что-то отключено для увеличения стабильности...

Да, кстати! совсем забыл добавить. Система работоспособна ТОЛЬКО с параметром при загрузке acpi=off. Иначе - отваливается мышка с клавиатурой через 20-30 после загрузки. SLED10 работала с пол-года на этой же системе абсолютно нормально...

Что то подобное я наблюдаю на своем хламе, кстати тоже на SIS чипсете. Не считая того что acpi у меня не выключено. Насколько быстрее копирование будет работать на nForce дома посмотрю в выходные. И замеры выложу.

Доброго времени....
Проходил мимо... почитал... любопытно и даже несколько забавно. Позволю себе добавить свои пару копеек в общую копилку. Из всего вышеописаного сделал вывод. вышеперечисленые странности имеют место быть на матерях с чипсетом SIS независимо от мощности процессора и если не ошибаюсь относительно новом чипе nFORCE. Так может проблема всётаки не в железе. а в реализации драйвера для железа под ядро 2.6. Потому-что это явление наблюдается только на определённых чипсетах. У себя гоняю 10.3 на nFORCE 2 проц 1800Мгц - ничего подобного наблюдать недоводилось. Есть ещё Duron900 на чипсете VIA. гонял на нём 10.2 10.3 и SLES10SP1 никаких проблем с падением быстродействия незамечал. безусловно при копировании наблюдается некоторое замедление по времени запуска программ. но их быстродействие остаётся без изменений. Можно конечно провести некую аналогию с виндой. Только ненужно ругаться! Там доводилось наблюдать нечто подобное и просто кликаньем мышью это не лечилось. Возможно не к месту. но железо для обоих осей одинаковое. В общем, система самостоятельно вырубала режим дма винта и просто включение его в настройках ничего недавало. Причина довольно интерестна, драйвер оси отслеживал ошибки ввода-вывода и при превышении некоторого порога принудительно вырубал режим дма. Причём причиной ошибок могли быть и завышенный режим дма и некачественный шлейф или длинный шлейф и возможно, некоторый перегрев южного моста( может ещё чегото). К чему это я? Наверное к тому, что разработчики линукса не глупее виндовозных и возможно предусмотрели подобную защиту в своих драйверах( надеюсь что так). И если такое присходит, то наверное, нужно внимательно изучить системные логи, возможно система подскажет в чем дело.
В предыдущих постах упоминалась утилита hdparm, штука весьма мощная и универсальная, но по порядку. В центре управления 10.2 присутствовал аплет позволяющий управлять режимами дма дисков( в ручную) и переключать драйвер( у меня на выбор было три варианта драйвера), в 10.3 такого аплета почемуто нет или он не устанавливается по дефолту. В общем аплет значительно упрощал жизнь обычному юзеру. Но вернёмся к hdparm. В редыдущих постах утилита использовалась как средство вывода информации о режимах работы винта, а также тестирования его быстродействия. Но ведь она может задавать режим работы винчестера по желанию пользователя. Почемуто никто не воспользовался этой возможностью. В своё время мне доводилось "играться" возможностями утилитки по оптимизации работы винчестера ещё под Мандривой 10 и судя по тестам тойже hdparm выиграть в скорости работы винта, хотя и незначительно. На глаз конечно этот прирост заметен практически небыл( в работе системы и программ), но всёже.
Возможно стоит попробовать подобрать подходящие для винта параметры работы, например режим udma, возможно даже слегка понизив его. Не 5, а 4 или 3, т.к. даже для современного винта udma5 ИМХО никчему. Винт полюбому не сможет "перекинуть" 133Мб/сек. Также есть и другие параметры оказывающие влияние на скорость работы, а большая загрузка проца неудивительна при работе винта в 16-битном режиме( смотри вывод hdparm). Нужно также понимать, что утилита весьма серьёзная и задание неправильных параметров может привести к плачевным последствиям!
В общем, дочитавших мой бред до конца, пршу не ругаться сильно, помоч хотел. Удачи.

[Deo]

Спужавшись замерил и я... Suse 10.3 32 - kernel 2.6.22.5
MSI k9n Ultra rev 2.1 (NForce 500 какой-то) и Атлон 3800х2

Код: Выделить всё

Jah:/home # dd if=/dev/zero of=testfile.lgb bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 13.6177 s, 77.0 MB/s
Jah:/home # time cp testfile.lgb /home/deo
real    0m24.143s
user    0m0.088s
sys     0m4.484s
Jah:/home # hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  190 MB in  3.01 seconds =  63.17 MB/sec

Однако. Прикопировании с НТФС партиции на райсер больших объемов данных скорость пляшетв широком диапазоне (такое чуйство, чтопериодически "захлебывается") и система действительно призадумывается... может перегревается что-то...

[artb1sh]

Доброго времени....
У себя гоняю 10.3 на nFORCE 2 проц 1800Мгц - ничего подобного наблюдать недоводилось.

правда не знаю, но в новых ядрах драйвер nForce2 включить врятли удастся

хотя я не об этом, видно что проблема есть и как видно у многих но решение искать очень затруднительно(((((

Код: Выделить всё

dd if=/dev/zero of=testfile2.lgb bs=1M count=1000
1000+0 записей считано
1000+0 записей написано
 скопировано 1048576000 байт (1,0 GB), 44,2155 c, 23,7 MB/c