Интересно, разработчики слышали про многозадачность?

http://i.imgur.com/R1riD74.png - Службы все виндовые. И тут не показано, какая сколько процессора ест.

Вот так должно быть: http://i.imgur.com/59YnxK9.png
Может ты не с правами администратора запустил?
Или может антивирус как-то блочит, попробуй остановить его на пару минут.
Чем помочь более не знаю :) Возможно это реально svchost без процессов внутри - они из него отвалились, а память свою, буферы всякие - не почистили. И тут уже ничего не сделаешь кроме перезапуска svchost'а. Но это просто предположение, правильного ответа я не знаю

Нет. <svcname>.exe работают сами по себе безо всяких svchost'ов. Засовывать сервисы в библиотеки, и загружать их специальной пускалкой придумали, так как вместо множества отдельных процессов-сервисов — один, это позволяет экономить память (библиотека требует меньше памяти), а в те времена ОЗУ экономили как могли. Минус в том, что сбой в любом таком сервисе может уронить весь хост-процесс со всеми сервисами, которые висят на нем. А в винде это критично.

Ну вот, теперь ты можешь скриншотить использование ресурсов в системном мониторе, убивать их по одной и смотреть какой импакт дал каждый следующий убитый процесс xD

Не замечал такого. Тут или кеш маленький у тотема и IO забит. Или забит проц и процессы апта идут с более высоким приоритетом (а должно быть наоборот).

Хочешь сказать, что в один процесс допихивается несколько dll-ок? Во-первых, как это выглядит технически, а во-вторых, почему это до сих пор не выпилят?

привел же методику тестирования - код на C#, копипаста на гитхабе. На 32-битном шиндовсе нельзя запустить более ~1400 тредов. Суммарно процессов верхнего уровня можно запустить сильно меньше, чем тредов в одном процессе. Учитывая какое это убогое количество, эти процессы нужно экономить. Если ты будешь запускать svcname.exe на каждый чих, у тебя максимум процессов быстро израсходуется. А если ты все эти процессы оформишь как dll'ки и впихнешь в один процесс в виде раздельных тредов, то это поможет немного сэкономить ресурсы. Тем более, что память у них будет общая, и вместо прокидывания данных по пайпам или еще как-то (что приводит к неизбежному копированию), ты сможешь просто передавать сосденим процессам указатели на куски собственной памяти. Профит, не?

Там есть вкладка Threads. Там можно глянуть.

Да, спасибо, прочитал, оказывается на википедии есть.

Да, точно! Спасибо! Правда жрать пока перестало. Ждем-с...

что в один процесс допихивается несколько dll-ок?

Да, и они выполняются в отдельных потоках. А потоки в win не являются процессами, в отличии от unix-систем.

почему это до сих пор не выпилят?

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

так винапи ж завернули в .net'овые обёртки, пиши на обёртках? или есть проблемы?

Там 100% код заполнен исключительно синхронным I/O который говно. Надо на уровне ОС любой синхронный I/O запретить. Чтобы читать из UI-потока было нельзя вообще, а мерзостные fread/fwrite во всех вариациях просто удалить.

кстати, для нативного кода (для C/C++) есть какие-нибудь green threads, которые реально применяются? Особенно кроссплатформенные

Я уже давно убедился, что на винде есть нормальная многозадачность,

Да, а где такую винду можно найти? IO ставит любую виденную мною винду на колени также, как и линукс.

пересборка мира по большей части нагружает процессор, а не IO

Только IO и нагружает по большей части.

Нет.

как минимум, это копирование будет прерываться рандомными эпизодическими чтениями-записями в других местах, например, обновить метаданные ФС, в своп залезть, да и эти самые большие файлы не факт что непрерывно располагаются в ФС

Это всё мелочи на уровне 1-5%.

Если у тебя не 32 мегабайта оперативы, то пересборка ядра нагружает IO только в самом её начале, далее вся нагрузка только на проц. Если у тебя не так - ищи проблему в железе.

На 32-битном шиндовсе нельзя запустить более ~1400 тредов.

Можно. Минимум, на порядок больше можно. Ограничения тут фундаментальные, в Линуксе будет всё тоже самое.

Там идёт чтение/запись нередко в десяток-два потоков

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

Если у тебя не 32 мегабайта оперативы,

Вообще ничего не значащая величина. Раньше и 1Мб было много.

то пересборка ядра нагружает IO только в самом её начале, далее вся нагрузка только на проц.

В каком начале? При чем тут пересборка ядра, если речь о пересборке мира?

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

Ох уж эти диванные теоретики, балаболят о том, чего совершенно не знают и не понимают.

на винде когда включается индексация системного жесткого диска - а она включается часто и жрёт не менее 20Мб/с, т.е. ровно макс скорость моего HDD, все программы на винде виснут намертво

вот оно бл*ть что... не мог понять почему иногда это происходит. не говоря уже о том, почему вообще происходит мое и винды взаимодействие.

Это всё мелочи на уровне 1-5%.

скорее 10-50%

более того, даже при строго линейном копировании скорость сильно зависит от размера блока

я вот экспериментировал с dd if=/dev/sda of=/dev/sdb и копировал терабайтные харды с одного на другой

постоянная скорость выше 100м держится только при определённом размере блока, не помню точно, 1 мегабайт или 8, во всех остальных случаях оно резво копирует первые несколько десятков гигабайт, а дальше скорость начинает падать, и к концу dd показывает среднюю скорость около 50 мегабайт/c

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

Моя копипаста (см ссылку выше) может делать только 1400. Чяднт?

даже при строго линейном копировании скорость сильно зависит от размера блока

наверно кривости реализации firmware устройст

скорее ограничения движущегося механизма

arturpub> Август 2015 года, а линукс не может в приоритеты ui-critical.

Может. Просто планировщик надо подходящий использовать.

Надо на уровне ОС любой синхронный I/O запретить
а мерзостные fread/fwrite во всех вариациях просто удалить.

и у каждого будет свой тормозный костыль, эмулирующий синхронный IO. дай бог, чтоб без polling'а. короче фантазия из серии «не дай бог сбудется».

неособо проблема, да линуксом нереально пользоваться на hdd, но это очень просто решается покупкой ssd

не факт, на венде бывают драйвера nvidia чудачат. Поищи 'nvidia huge disk usage'

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

Ну так и ответь тогда, почему перевод /var/tmp на tmpfs ускоряет процесс сборки многократно :D

У меня такие проблемы и с ssd были и есть.

Ну так и ответь тогда, почему перевод /var/tmp на tmpfs ускоряет процесс сборки многократно

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

Чяднт?

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

скорее 10-50%

50% - это бред.

можешь сам измерить

Раньше и 1Мб было много

В те времена, когда 1Мб было много, никакого Линукса не было в помине.

При чем тут пересборка ядра, если речь о пересборке мира?

Разница не большая на самом деле. Сначала закачиваются в память наиболее используемые файлы, потом трафик уже становится незначительным.

Измерял много раз. Если у меня копирование по сетке происходит со скоростью менее 100 мегабайт в секунду, это повод беспокоиться и разбираться.

так то с жёсткого в сеть или наоборот, а мы копирование с диска на диск обсуждаем

100 мегабайт в секунду

точно мегабайт, не мегабит? По гигабитной сетке?

Какая разница ? В случае с сетью, наоборот, медленнее должно быть. C обеих сторон два диска, каждый с FS и метаданными, но доп. тормоза вносит сеть.

Да, 100 мегабайт/c, 1000mbit. Прикинь. Техника на гране фантастики, будущее уже здесь. Оно лет 7 назад уже так работало, сейчас это уже маловато.

Какая разница ? В случае с сетью, наоборот, медленнее должно быть. C обеих сторон два диска, каждый с FS и метаданными, но доп. тормоза вносит сеть.

нее, как раз задержка помогает по идее

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

С I/O в linux беда, и я об этом всем говорю. Но разрабы упорно отрицают сей факт, ага.

Поставил на копирование с удаленной шары 90гб данных, открыл терминал. Bash (именно bash! окно появилось нормально) загружается 30 секунд. Окей, ЯСНОПОНЯТНО.

вот когда задержа между чтением с одного и записью на другой минимальна, могут и простои на ожидание возникать

Кеширование должно работать.

кэш не бесконечный, 32Мб или сколько там сейчас ставят, он сразу заполнится

Да я про кеш ОС, вообще-то.

Потому что ты куришь что-то не то. Ядро в распакованном виде - гигабайт, оно засосётся в оперативу

Это ты чего-то не то куришь. Прежде чем сорцы засосать в кеш их надо всё равно прочитать с диска, после чего... они будут уже не нужны в кеше. Т.к. при компиляции нужно только одно чтение. Таким образом, на чтение с диска кеш вообще почти влияния не окажет.

С записью — эффект от кеша будет приличный. Вот только временные файлы из кеша будут синкаться на диск, чтобы... потом оттуда удалиться. Опять оверхед.

...

И снова ты теоретизируешь там, где у меня была многолетняя практика. Я с Gentoo провёл десятка два-три машинолет в разных конфигурациях. tmpfs скорость компиляции реально ускоряет офигенно. Но не на каждой машине есть возможность выделить 4-6 Гб оперативки под tmpfs для /var/tmp/portage.

И в процессе сборки нагрузка на IO часто лимитирует куда больше нагрузки на CPU.