Pull to refresh

Comments 171

Вы круты! :) Таких доступных(и полезных) и толково написанных статей я давно не читал!
Спасибо, однако вынужден признать, что к третьей части я уже несколько утомился и хотел лишь побыстрее закончить. Поэтому все немного сумбурно и без особого углубления в детали.
Ничего, самая мудреная все равно получилась первая.
Вопрос «чайника», не лазившего столь далеко в дебри Windows. Насколько ваши рецепты помогают на XP?

С одной стороны, описание CreateFile говорит, что новых флагов со времён XP вроде и не появлялось, с другой — в документе, который вы подкинули, про XP ни слова.
Рецепты конкретно из этой статьи — никак.
А почему Вы используете XP?
У меня дома три ноута разного возраста, на одном предустановлена XP, на другом Vista, на третьем Win7. Думаю, что у многих так же. Не вижу смысла покупать новую версию ОС для старого железа, тем более, пока старая еще поддерживается — достаточно просто держать включенными все обновления.
Ну, вдруг он из тех психов, что покупают софт за деньги :)

На самом деле «используете XP» — это неправильная формулировка, звучит как будто для этого нужно прилагать усилия. Правильнее спросить «почему вы не переходите на новую версию», тогда понятно, что усилия нужны не использовать XP. А для любых усилий, как известно нужны веские основания (что-то не работает, что-то тормозит, там красивее или безопаснее). Пока достаточных оснований не накопится у конкретного человека, он не станет переходить.
Я вот пока не могу. Мне три дня надо убить на то, чтобы всё переставить и настроить. Работает, обновляется — что ещё надо?
Угу, именно из-за этих отговорок хожу на работу с двумя ноутами уже год.
Я тоже использую только лицензионный софт (в том числе Windows).

> Правильнее спросить «почему вы не переходите на новую версию»
В общем да, но такая формулировка имеет смысл только если за последние 10 лет не покупался новый компьютер. В противном случае (даже если речь идет о самосборе без предустановленной системы) стоит говорить о миграции с одной XP на другую или о миграции же с XP на что то более новое.

Люди продолжают мигрировать на XP на новых боксах потому, что считают, что ничего не изменилось.

Вот приоритеты памяти и суперфетч — пара примеров того, что видно пользователю. Еще композитинг, супербар, работающий поиск и пр…
При апгрейде железа не нужно никуда мигрировать. Если система при обновлении железа валится в BSOD в 99% случаев помогает накатывание поверх с сохранением всех установленных программ и настроек.
Не апгрейде железа, а покупке нового компьютера. 10 лет назад у меня был винт на 10 гиг, материнская плата, не поддерживающая ни современных процессоров, ни современной памяти, ни современных слотов расширения (в том числе для графической карты). Что там говорить — там не было даже USB. Речь идет о полной смене компьютера. Лично я уже и забыл сколько раз «переезжал» на совершенно новое железо за последние 10 лет, но менее привязанные к технике люди гарантированно «переезжали» как минимум пару раз.
Покупка нового компьютера это тоже апгрейд железа. Установленную систему на новый компьютер тоже можно перенести описанным выше способом.
Согласен, можно. В старых версиях были проблемы с ide контроллерами при замене материнки, но сомневаюсь, что все те ~60% сидящих на XP делают это потому что либо ни разу не обновляли компьютер либо потому, что при обновлении компьютера всегда мигрируют систему целиком
Я отчётливо вижу как работает Windows 2000/Windows XP/Windows 7 на моём железе. На данный момент это — c2q 3.2ghz + 8gb (сейчас xp), p4 3ghz + 2,5gb (сейчас w7) и нетбук на atom'e (xp). Поскольку жене только интерент нужен, у неё на p4 w7. Этой мой старый компьютер, там раньше работала w2k и wxp. Разница видна сразу, нет w7 не тормозит. Но в общем более медлительна и это сильно заметно. Причём я недавно поставил ей ssd (intel) и всё равно не сравнить c winxp и тем более w2k. И приоритеты памяти и суперфетч, всё это — не заметно! На w7 работать — неприятно из-за плохого отклика. У меня системы все куплены + подписка от microsoft'a. И все они присутствуют в виртуальных машинах уже на моём текущем железе (c2q) — и там разница ещё более очивидна. Я бы до сих пор работал под w2k, только новый софт от ms (принудительно) перестал устанавливаться, хотя после хаков инсталера прекрасно работал.
Вот как раз повышение responsiveness — это первое, что я заметил, когда перешел на висту. Из-за композитинга окно появляется сразу (я уже забыл что такое фликеринг) и только тогда, когда полностью готово. Кроме того, таки да, вместо CPU используется видеокарта, которая чаще всего простаивает когда пользователь работает с десктопом.
Из-за суперфетч я уже забыл, как та же вижуал студия поднимается из таскбара в течение 30 секунд.
VS2008 — 3 секунды на запуск, правда с ssd. 30 секунд на запуск — это совсем что-то плохое с hdd или процессором.
Это было во времена XP и 2003-й студии. Причем речь даже не о холодном старте, а о ресторе из таскбара. Да, лично я на глаз вижу разницу в управлении памятью между XP и Vista/7
Более того, прямо сейчас я запустил онлайн-дефрагментацию. Я бы мог и не упоминать об этом, но я только сейчас об этом ВСПОМНИЛ. 100% дисковая активность практически не влияет на комфортность работы с системой
У меня везде ssd — дефрагментация не нужна :)
Получается, что улучшения видны/заметны в основном на не быстрых компьютерах?
SSD в любом случае медленнее, чем RAM, но конкретно улучшения в кешировании будут наиболее заметны на медленных дисках.

Улучшения, даваемые композитингом заметны вообще практически где угодно. Новое меню пуск — икспишным я уже не могу пользоваться, супербар — забыл о проблемах нехватки места на таскбаре и т.д… Очень много улучшений именно заметных пользователю, но еще есть куча улучшений, приятных лично мне, как программисту и «продвинутому пользователю».
Ну вот и получается, что на быстрых компьютерах vista/w7 медленнее XP — за просто так.

А меню пуск я вообще почти не пользуюсь. У меня таскбар в две строки, верхняя — quick launch и все нужные программы(>40). Нижняя сам таскбар, где видно что запущено и нет проблем.
image
Ну вот и получается, что на быстрых компьютерах vista/w7 медленнее XP — за просто так.

С чего бы? Заметьте, я сейчас даже не прошу подтвердить слова какими нибудь экспериментальными фактами, я прошу дать хоть какое то ВОЗМОЖНОЕ подтверждение Вашим словам.

Кстати, про нетбук на атоме. Я вот покупал один когда они продавались еще с XP. Тормозил, гад. Сейчас он же летает под Win7 HP

Но вообще, я не нанимался Вас переубеждать. Хотите отстаивать позицию «ничего не поменялось» в топике про одно из таких изменений — Ваше право. Sapienti sat
> А почему Вы используете XP?

дык работадатель :(
дома у меня убунту
Торт! Однозначно ТОРТ.
Надо запомнить про решение с мюторентом.
Вы бы сначала попробовали этот «торт».
Хорошо что автор упомянул что utorrent у него не стоит, эдакий теоретик, практика показывает что если установить настройки кеширования согласно рекомендации, то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае). Возврат настроек в дефолт проблему снимает. Так что, во-первых не все статьи одинаковы полезны, во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
Вы бы сначала попробовали торт, перед тем как попробовать советовать попробовать. Последние скриншоты наглядно показывают, что запущен именно мюторрент, с раздачей 5 гигабайтного исошника. Почти весь исошник поместился в свободную память.

> то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае)
Простите, но я опять вынужден просить подтверждения. При любых раскладах, расти должен системный рабочий набор, а не рабочий набор мюторрента. Причем расти из-за кеша неограниченно он просто не может — количество слотов, в которые мепятся файлы ограничено и относительно невелико.

> во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
А вот это вряд ли. Если делаешь управление физической памятью в пользовательском процессе, то как минимум нужно выставлять MinumumWorkingSet во что нибудь большое. Дефолтных 200 килобайт маловато для адекватного кеша, не находите? А без этого, их виртуальная память рано или поздно просто уйдет в своп файл. Отличное решение — кеширование данных из файла на диске в другой файл на диске.
У меня тоже советы из статьи не заработали.
Вводная: uTorrent работает 24/7 на хорошем канале, раздач очень много, памяти 4 Гб.

При настройке торрента в соответствии со статьёй (+ явно процессу uTorrent.exe задаётся самый низкий приоритет) вся оперативная память забивается кэшем, в активных приложениях при IO (запуске, загрузке документов и т. п.) заметны подтормаживания. При закрытии торрента система оживает. Пробовал два режима, без файла подкачки совсем (т. к. тяжёлых приложений нет, самое тяжёлое — Firefox) и с файлом подкачки на 4 Гб — одинаково.

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

А теперь хочу перейти на личности. :-) Пусть и запоздало, но — спасибо вам за ваши статьи, у вас отличные знания относительно операционных систем. И во многом разделяю вашу точку зрения относительно Windows.
Прочитал все три части на одном дыхании. Вы круты. Честно круты.
Думаю, вы побудили не один десяток человек к самообразованию. :)
Нет, если Вы заметили то начал с сомнений в обоснованности мнения человека, «досконально изучившего винду». Своппинесс насколько я себе могу представить, не решает вообще никаких реальных задач.
Суть swapiness в том чтобы сказать ядру «чувак, сохраняй поменьше в своп — у меня IO жутко медленный» (0 < swapiness < 60) и, наоборот, «сохраняй побольше, у меня IO шустрое» (60 < swappiness < 100).
Не совсем. К сожалению, я плохой оратор. Попробую перефразировать. Именно кеширование дает наибольший общий прирост производительности при медленных дисках. Как раз потому, что уменьшать нужно не обращения к свопу, а обращения к диску. Причем на обычных вращающихся дисках чтение и запись одинаково разрушительны для производительности.

При помощи своппинесс можно сказать системе: если тебе вдруг понадобится страница, никогда не трогай память приложений — только кеш. Даже если открыт, скажем, опенофис и Вы не пользуетесь той его частью, которая требует Java — она все это время будет оставаться в памяти. ФИЗИЧЕСКОЙ памяти. При этом не выполняя никаких полезных функций ни для Вас (вы той частью функционала просто не пользуетесь), ни для, очевидно, системы.

Это можно с определенным успехом использовать (к примеру понижать своппинесс до нуля перед выполнением каких нибудь maintanence работ типа обновления индексов и возвращать его на место после окончания), но лично мне очень трудно усмотреть в своппинесс эффективный механизм для оптимального использования физической памяти.
Или вот еще более правильный пример: как минимум Опера (наверное остальные тоже в той или иной степени) сохраняют историю страниц (вместе с результатом рендеринга), а также имеет «Корзину» для закрытых страниц, которые тоже хранятся в памяти. За счет этого ее рабочий набор разрастается порой до внушительных размеров. Под виндой это не страшно, потому что через некоторое время все неиспользуемые страницы постареют, обрежутся, потеряют приоритет, сбросятся в своп и будут использованы для кеширования. При помощи своппинесс можно или вообще не обрезать никого или обрезать по старинке — наобум
swappiness не управляет «скидывать в своп или не скидывать в своп». Он управляет коэффициентом «лучше скинуть» или «лучше не скинуть».

Так, swappiness = 100 вовсе не означает что в своп будет скидываться все подряд. Равно как и swappiness = 0 не говорит о том что своп не будет использоваться вообще.

можно размышлять об этом примерно так:
при swappiness = 100 в своп будет скидываться то, что не запрашивалось 5 минут
при swappiness = 60 в своп будет скидываться то, что не запрашивалось 1 час
при swappiness = 0 в своп будет скидываться то, что не запрашивалось 24 часа.

Это лишь коэффициент и не более того. Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
циферки временные — естественно фейк) для наглядности лишь
В статье по ссылке выше приведен реальный алгоритм работы:
«If swap_tendency is below 100, the kernel will only reclaim page cache pages. Once it goes above that value, however, pages which are part of some process's address space will also be considered for reclaim.»

То есть в прямом смысле, пока swap_tendency (вычисляемый в том числе и на основе swappiness) не пересечет 100 — память процессов трогаться не будет. Да, swappiness всего лишь повышает (или понижает) вероятность использования страницы из памяти процесса (причем в некоторых случаях до нуля), но тем не менее это все такой же совершенно отпотолочный алгоритм, в лучшем случае, призванный повысить responsiveness (уменьшить latency) за счет уменьшения performance (throughput) — размен, который делается очень часто, но в данном случае, как я уже сказал, от меня ускользает логика данного алгоритма.

Ну то есть вместо размышлений которые вижу (и с которыми в большинстве случаев согласен) за реализацией виндового мемори менеджера, здесь я вижу алгоритм вида: «Хм, а что если сделать еще и вот так — чего выйдет?». Это конечно мои личные предпочтения, но я люблю когда перед кодированием обдумывают решение, а не пользуются «методом научного тыка».
ещё раз. Винты бывают слабыми, бывают шустрыми, бывают сервера настолько шустрые, что вообще любые механические винты (и SCSI и SAS) будут для них относительно «слабыми». Но винты используются не только же для свопа, блин. И возня со свопом для слабых винтов может уменьшить отклик для всех остальных операций.

в линухе можно хоть чуть чуть влиять на процесс. Не хотите — не влияйте, в чем проблема-то? Я от swappiness ощущаю больше пользы, чем зла.

да и вообще, админы при тонкой настройке серверов зачастую вообще ядро патчат =). А для десктопа — вон, тот же deluge вообще запрещает сваппинг своей памяти. И правильно делает.
Да я понимаю, что винты бывают разными. Но в том то и суть, что с одной стороны я вижу глобальный мемори менджмент, призванный уменьшить нагрузку на диск вообще (а не только на своп), при этом делая все возможное для того, чтоб приложения оставались responsive. С другой — какие то отпотолочные вычисления (сложение/деление величин, у которых даже типы не сходятся), которые призваны уменьшить давление на своп-раздел. Почему своп раздел такой особенный? Почему именно количество обращений к нему нужно уменьшать? Откуда там деление на 2 и откуда взялся порог в 100? Почему даже размерности складываемых и сравниваемых величин не сходятся (если уж за этим стоит хоть какой то «физический» смысл)?
ну погодите. Если не говорить о ситуации когда своп используется как расширение памяти которой _не_ хватает, то ни о каком изменении времени отклика приложений при своппинге и быть не может. Ситуацию когда памяти не хватает я вообще не рассматривал — тут все относительно просто: тормозить будет в любом случае =)

когда же памяти в целом хватает для рантаймовых данных всех приложений — для чего можно ещё заюзать память? Кеш файловый, кеш файловых систем, кеш «ещё какой-нибудь». При этом непонятно что важнее — закешить вооооот этот воот файлик или оставить в памяти кусок оперы открытой неделю назад. Для рабочих станций важнее явно будет кешить как можно больше скидывая оперу в своп и наплевав на то что обращение к ней потом будет достаточно дорогим — зато данные которые нужны здесь и сейчас будут в кеше. Для ноутбука важнее будет довольствоваться тем что есть, стараясь не дергать винт вообще. А для рядового убунту-юзера вероятно вообще надо будет выбрать нечто среднее, не вдаваясь в крайности.

Вот никто лучше меня самого и никакой великий аналитический алгоритм не угадает что у меня за машина и зачем она мне нужна и какой софт я собираюсь запустить через пять минут.
Памяти всегда не хватает. Иначе никакого управления памятью не нужно было бы городить: нужна страница — возьми свободную. Вот когда свободных уже нет, начинаются вопрос откуда брать память.

Не будет опера сбрасываться в своп. В лучшем случае ее выбросят в stanby/modified, но при первом же обращении вернут на место. Вот если таких обращений не будет очень долго, а все остальные при этом будут действительно использовать свою память вместо того, чтоб тупо держать ее «на всякий случай» — тогда страницы оперы будут переиспользованы (repurposed).

На самом деле и в винде и в линуксе за Вас решили, как будет использоваться память Вашего компьютера. Просто у одних вышло хорошо, у других — не очень
> Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
на столько интеллектуально, что когда заканчивается оперативка виснет gui и насилутся диск, что со свопом, что без…
windows убить сжиранием памяти ничуть не сложнее.
тем не менее, в линухе неоднократно лицезрел «app XXX killed because out of swap space», что восстанавливает работоспособность системы без ребута.

весьма бессмысленный коммент получился у вас)
> Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
Не подскажете, где про это почитать?
список статей есть в исходниках ядра в Documentation/kernel-docs.txt, ищите по кейвордам swap, memory и vm.
kernel-docs.txt смотрел. Хотя читал естественно не все. Можете посоветовать какие нибудь конкретные статьи, который Вам понравились?
Читал что в utorrent есть параметр diskio.flush_files. Если от стоить в true, то utorrent периодически (раз в минуту?) открывает и закрывает файлы (все?). Напишите что-нибудь на этот счёт.
Я конечно извиняюсь, но где найти это самое окно «uTorrent.exe:2768 Properties»?
Спасибо за статьи. Очень познавательно.
А вы пытались свзязаться с авторами uTorrenta?
стиль изложения сильно хромает. при том, что автор вроде и полезную информацию пытается изложить, но как-то всё мутно, скомкано, с непонятными переходами между мыслями. пример полёта шизомысли: «написал на сишарпе, потому что не у всех может оказаться установленная Visual Studio».
потому что кусок кода на сишарпе можно скомпилить и запустить на голой win vista/7, либо на xp на которую только поставлен дотнет.
Вы открыли мне глаза. Не знал, что в .NET входит компилятор шарпа. Это ж теперь простенькие программы можно на любом компьютере писать! Только ради этого стоит его наконец-то по-нормальному выучить.
наверно
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
то есть это ещё нужно сделать загрузчик в виде батника х)
и заниматься этой ерундой при каждом апдейте фреймворка?
Можно в профайл павершелла прописать:
$env:PATH += [System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory() + ";"

Ну или завести переменную FRAMEWORK_PATH и добавлять его. В принципе изменение FRAMEWORK_PATH — задача, сопоставимая по сложности с самим апдейтом фреймворка
нифига не сопоставимая. фреймворк сам себя обновляет, а эту переменну. чтобы поменять на правильную нужно долго копаться в окошках. нафиг такое счастье. буду по старинке извращаться с батничками х)
Фрейворки устанавливаются дополнительные. К примеру после установки четвертого, у Вас останутся каталоги и от 2 и от 3.0 и от 3.5 — пропишите пути в 3.5 и пользуйтесь. Когда понадобится перейти на 4.0 — сможете выполнить команду setx (можете даже сделать такс в таск скедьюлере)
да блин, это всё-равно гемор. не буду я прикладывать к своему скриптику ридми по его запуску. и студию ставить чтобы скомпилировать не буду.
на самом деле если вы действительно хотите разобраться в проблеме, а не потроллить, то
таких каталогов может быть всего 5:
v1.0.3705
v1.1.4322
v2.0.50272
v3.0
v3.5
v4.0.30319

версии до 2 — давно неживые
версии 3.0 и 3.5 — это минорные версии, работающие на все том же CLR версии v2.0.50272. В 3.0 даже нет своих компиляторов, там всего лишь библиотеки wpf,wcf и wf.
В 3.5 есть свой компилятор, он отличается только тем, что поддерживает LINQ.

Никакие патчи не меняют эти версии.

Таким образом, реально версии (каталога) может быть всего два: v2.0.50272 и v4.0.30319
самая распостраненная, вторая, поскольку она идет в комплекте с windows 6.*
и, учитывая, что 2.0 вышла в 2005, а 4.0 в 2010 — не очень то большое разнообразие, не правда ли?
Для распространения скриптиков есть PowerShell. Имеет доступ ко всему .Net (в том числе и P/Invoke, который я использовал в первой части), имеет много сахара для специально для скриптинга/менеджмента (WMI, COM, WS прокси, ремотинг и пр).
Чтобы комиплить студия не нужна.
Я свои проекты на серваках компилирую msbuild'ом, которые входит в поставку .Net Framework'a.
т.е. мюторрент пишет на диск часто используемые данные, так?

можно ли его обвинить в большом количестве записанных данных на системный диск? (который у меня ссд и количество циклов записи на него ограничено, поэтому меня это волнует)
мюторрент пишет на диск скачиваемые данные. Больше ему туда писать нечего. Тут дело в том, что его чтения с диска загрязняют кэш и замедляют другие (очевидно более важные) приложения.
спасибо.
я понял как будто он кеширует часто используемые данные на сист. диск
кстати еще музыка бывает подергивается пока торрент не выключишь, видимо из за этого
Музыка подёргивается из-за прерываний от сетевой карты, хотя с этим должна бороться служба MMCSS.
Музыка может дергаться еще и из-за сильно большой нагрузки на диск (особенно если прослушивается с того же диска). Если же это действительно прерывания, то MMCSS (очень неплохая штука сама по себе) сделать все равно ничего не сможет — прерываниям плевать на приоритеты потоков. Когда выполняется обработчик (или его DPC) — никакие даже самые высокоприоритетные потоки на этом процессоре не планируются.
а что скажешь по поводу тотал командера и его режима отключения кэша при копировании больших файлов?
Спасибо. Сколько пользовался — не знал, что он кеш выключает. То-то в последнее время при копировании больших файлов система практически не отзывалась. Включил, чтобы использовал метод «Копирование / вставка с помощью Проводника виндовс».
Не тестировал :) пока не на чем.
Не ставил тотал коммандер. Но можете посмотреть на уровень приоритета, на который TC кеширует копируемый файл (при включенном кеше). Есть подозрение, что он не использует sequential only (можно проверить в xperf) и кеширует все на уровень 5, чем может вытеснить более важные данные. Пользуюсь FAR-ом (правда все реже) — там есть галка «Использовать системную функцию копирования». Если в TC есть аналог этой галки — рекомендую включить
я хз как им пользоваться…
угу, галка есть
«2. Импортируем в реестр следующий файл:»

Забыли в конце пустую строчку оставить.
Вопрос не по статье, но по памяти: CreateFileMapping с INVALID_HANDLE_VALUE создаст File mapping с размером который я укажу, или с размером округленным в большую сторону до размера страниц?
Просто в документации по этому поводу ничего найти не удалось, а MapViewOfFile спокойно дает мапить регионы больше чем я задал в CreateFileMapping, но вписывающиеся в размер страницы(ну или страниц).
О какой версии uTorrent в исследовании идёт речь? На данный момент существует релиз 2.0.4, бета 2.2 «Griffin» и альфа 3.0. Их билды довольно часто обновляются. Конкретизируйте, пожалуйста.
Как минимум, такое поведение характерно до 2.2.х. 3ью версию не тестировал. Уже думаю о том, чтобы уйти на какой-нибудь другой клиент, ибо юторрент запарил кеш «приоритетными» данными забивать.
Последняя стабильная — которая 2.0.4
Не думаю, что в бетах что то поменялось по поводу кеширования
О том что уторрент имеет данные проблемы с кешированием, я видел как минимум весной. Какие тогда были версии — вам, как интересующемуся, должно быть известно лучше
Интересно было бы почитать анализ работы всевозможных криптеров типа Themida в контексте этой темы.
Вопрос — разговоры о том, что pagefile лучше задать статический, нежели динамический («размер определяет Windows») размер — это миф или же это действительно что-то дает?
Эти разговоры чаще всего основываются на том, что пейджфайл не всегда можно расширить без фрагметации и это правда. С другой стороны он расширяется большими кусками (порядка нескольких гигабайт за раз) и даже если для этого будет выделен дополнительный фрагмент — на производительность это повлияет мало. Так что скорее миф.
Единственно, о чем стоит помнить, это то, что скорость работы в начале диска выше, что иногда может иметь значение.
Нашелся бы спец, который написал бы подобную статью о Linux.
пфффф… доки к ядру не читали? )
Одно дело просто доки, другое разбор на практике и анализ конкретных ситуаций.
И да, не читал)
Кстати, без всякой иронии, я давно ищу книгу уровня Windows Internals для Linux. Я конечно читал kernel-*/Documentation/* — это скорее заметки на полях, чем реальная документация. Я с некоторым успехом пытался читать исходники — они хоть и прокомментированы, но как по мне достаточно плохо (во всяком случае явно недостаточно, чтоб компенсировать отсутствие документации). А учитывая то, что скедьюлеры, мемори менеджеры и модели драйверов иногда меняются по несколько раз за 5-10 лет — это становится как то уж слишком тяжело. Особенно при том, что из того, что я таки осилил не очень вдохновляет на дальнейшее изучение.
Ну не изучайте, кто ж вас заставляет-то =)

Для меня исходники куда более понятны, чем непрозрачные размышления непонятно кого (я про Windows Internals). При этом недостатка информации по работе с памятью ядра линуха я вообще не ощущал никогда.
Читать не хочется, но иногда нужно хотя бы и просто для того, чтоб не спороть какую нибудь глупость в споре. Эдакий reality check — не столько потому, что интересно, сколько потому, что хочется поддерживать квалификацию
тем не менее, /ˈʃed.juːl/ — оригинальное произношение, что важнее; кроме того, именно «шедулер» является устоявшимся вариантом транслитерации этого слова кириллицей.
Это не оригинальное, это британское произношение.
(CA) IPA: /ˈskɛdʒuəl, ˈskɛdʒuːl, ˈʃɛdjuːl, ˈʃɛdʒuːl/
(UK) IPA: /ˈʃɛdjuːl/, SAMPA: /Sedju:l/
(US) IPA: /ˈskɛ.dʒuːl/ or IPA: /ˈskɛd.juːl/

Не знаю чего там было в оригинале, но «sch» в словах school и scheme в британии читаются как sk, что в общем ни о чем не говорит. Более того, во времена гражданской войны в США произношение, очевидно, не отличалось от британского и потом именно у британцев оно поменялось (американцы же начали переделывать написание :-) ).

Что же до официальной транслитерации — то это будет скорее сцхедулер (littera — буква). Если говорить о транскрипции, то она отличается у разных носителей языка и я использую американский вариант потому что большинство докладов по IT тематике используют именно эту транскрипцию.

Например 2:10
> Более того, во времена гражданской войны в США произношение, очевидно, не отличалось от британского и потом именно у британцев оно поменялось (американцы же начали переделывать написание :-) ).

Здесь Вы несколько заблуждаетесь. Слово это попало в английский язык через французский, где оно читалось именно через «ш». Американцы же упростили (как всегда, собственно) правила произношения, уравняв его в правах со словами school, scheme и другими словами греческого происходжения.

Насчёт кириллической версии (оставим за рамками корректный термин, которым её стоит называть), то «шедулер» таки на два десятичных порядка популярнее (если судить по результатам гуглопоиска).

И таки да, я в данном, как и во многих других случаях предпочитаю британский вариант. Аналогично, я скажу bureau de change, а не exchange office (последний, кстати говоря, популярен, в частности, в US и странах СНГ, но не в Европе).
Насчет измнений в британском произношении — я не могу найти статью, но я это не придумал, честно.
Возможно конкретно это слово имело другую историю.

В общем это вопрос личных предпочтений. Мне некомфортно слышать и говорить skɛd.juːl, но при этом писать шедул.
Вероятно, изменения таки были в этом слове в другую сторону (поищите «schedule etymology» и «cédule»), хотя да, описанное Вами нередко встречается (пример: выражение right soon).

Ну и да, на вкус и цвет все фломастеры разные :)
Да, ещё. Есть замечательная книжка, Modern English Usage, вообще говоря, достаточно старая, хотя есть переиздания, «дополненные и исправленные». Там очень подробно рассматриваются всякие подобные вещи, в том числе в этимологией, рассказами, кто, когда и зачем у кого заимствовал и так далее. Очень сожалею, что не купил её полтора года назад в Book Cycle по смешной цене (например, за £1) — надо будет исправить сию оплошность, когда буду там в ближайшее время.
Сказать ничего не могу. В принципе создать экспертную систему по автоматическому обнаружению и решению проблем производительности вполне реально: одна такая встроена в винду, но наверное можно сделать и лучше.
Попробовал utorrent с предлагаемыми настройками.
Не знаю, как там с кешированием и приоритетами, а с отдачей стало заметно хуже, чем было по умолчанию.
Насколько заметно? Помогает ли если вернуть все обратно?
Хмм. А вот таким образом через реестр можно для любых приложений настраивать работу с диском.
А то вчера распаковывал 18 гиговый архив 7zip'ом. Система на 20 минут стала недоступна для работы вообще.
7-zip вроде умеет переходить в бекграунд сам. Но только по явному указанию пользователя. А вообще да, IFEO можно указываться для любых бинарников
Не проверял.
Что там в реестре по умолчанию то было?
По умолчанию там вообще ключа utorrent.exe не было
Как по мне выглядят одинаково. Пики на 150-160 кбпс с периодическими провалами, вызванными скорее сетевой составляющей: от особенностей канала у пиров до особенностей канала у Вас.

Не могли бы Вы сказать, что именно стало заметно хуже?
уже не вижу особых отличий, если честно. скрины выложил чисто для проформы.
просто до того отдача шла практически без провалов. теперь — вот так.
Пара провалов связана с приемом. На сильно ассиметричных каналах (у меня, к примеру, 15 вниз/1 вверх) отсылаемые квитанции забивают весь исходящий канал — у Вас забивают примерно половину. Но в основном скорее всего сеть так и работает. Можно настроить локальную сеть для тестов, и я не думаю, что в полностью контроллируемых условиях будут серьезные отличия (кроме того, что кеш 32-битного мюторрента ограничен примерно полутора гигабайтами и в любой момент может быть сброшен на диск).
А я кстати рад, что убрал их кэш. Сейчас стабильно качает 8-9метров в секунду, без ежеминутных «Disk Overloaded», и полного торможения системы.
а можно как-нибудь сказать винде XP чтобы конкретный процесс она никогда не свопила? ну тойсть ни одну из его страниц?

есть такая прога Intellij IDEA
ей надо в среднем 550 мегов
отходишь от компа на 10 минут
возвращаешься и видишь в таск манагере что размер памяти процесса на 10 мегов меньше размера его виртуальной памяти: 540 и 550
активируешь окно IDEA, оно зависает — всё белое
и дальше в течении двух-трех минут видим как размер памяти растет
когда он выровняется с виртуальным: 550 и 550
то окошко IDEA оживёт и всё будет зашибись летать

на компе 2 гига памяти
памяти общей занято примерно 2 гига из двух
хотя после вашей статьи получается что эти цифры ни о чём
но тем не менне, пускай лучше фаерфоксовские 500 мегов свопятся чем 10 мегов идеи :(
Можно повысить MinWorkingSet процесса. Система никогда не позволяет Working Set падать ниже минимума. Если она не может удовлетворить минимальные требования — процесс просто не запустится.
Постоянно скачиваю и раздаю. Специально (ещё раз, дополнительно) протестировал работу utorrent'а (2.0.4, в последнем rc ещё есть досадные глюки) на разных настройках.

То, что вы написали про utorrent — галиматья.

При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше windows, постоянно идет чтение/запись с/на диск[а] . И наоборот, при включённом встроенном кеше значительно сокращается число чтении/записей с/на диск[а] , увеличилось число последовательных записей при скачивании.

A1lfeG выше # . Включение «их кеша» помогает снизить число обращений к диску, увеличивает число последовательных записей при загрузке. «Их кеш» всегда находится в RAM. У меня при скачивании при любых скоростях никогда не происходит «торможения системы». Что я делаю не так?

То, что вы написали про utorrent — галиматья.
Спасибо за информацию.

При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше windows, постоянно идет чтение/запись с/на диск[а] .
Как насчет методики тестирования? Понимаете, это идет в разрез как с моим пониманием работы кеша, так и с моими тестами.
Extraordinary claims require extraordinary evidence

Включение «их кеша» помогает снизить число обращений к диску, увеличивает число последовательных записей при загрузке.
Кеширование не имеет никакого отношения к последовательности читаемых данных.

«Их кеш» всегда находится в RAM
Не поверите, это как раз системный кеш ГАРАНТИРОВАННО находится в RAM. «Их» кеш может как находиться так и не находиться.

У меня при скачивании при любых скоростях никогда не происходит «торможения системы».
Рад за Вас. Может у Вас просто пропускная способность дисковой подсистемы гораздо выше, чем пропускная способность сети?
Спасибо за информацию.
Пожалуйста, всегда рад помочь.

Может у Вас просто пропускная способность дисковой подсистемы гораздо выше, чем пропускная способность сети
Пропускная способность дисковой подсистемы обычно выше пропускной способности сети. У меня сеть: 4-5 мегабайт/с в мир, 12 мегабайт/с по провайдеру, 128 мегабайт/с локально; диски: 175 мегабайт/с с диска, 300 мегабайт/с с буфера (максимальные показатели).

Не поверите, это как раз системный кеш…
Ну, почему же, поверю. Но «их» кеш позволяет не переполнять системный кеш, которому и без этого есть чем заняться. Или он по объёму неограничен? Я выставил встроенный кеш в 512 мб. Очевидно если выставить объём встроенного кеша слишком большим, то будут проблемы, потому, что данные из/в кеш[а] читаются/пишутся постоянно (Как часто свопится память которая постоянно читается, если есть доступная свободная память). Цена этому большая загрузка процессора и больший объём требуемой память.

Кеширование не имеет никакого отношения к последовательности читаемых данных.
А я что-то писал про последовательное чтение, в каком месте? А вот последовательную запись при включённом встроенном кеше (и отключённом системном кеше при/на записи) utorrent может обеспечить. Лучше, конечно, если кроме него на данный диск больше никто не пишет.

Как насчет методики тестирования?
Журнал производительности (число чтений/записи, время чтений/записи, скорость чтений/записи, длина очереди чтений/записи и т.д.), скачивание всех сезонов доктора хауза (20000 сидов в том числе локальные, ~50Гбайт, 10 мегабайт/с), 4-ёх ядерник (3Ггц), hdd 4 шт (по 2 Гбайта) + 2 внешних, и 8 Гбайт оперативки (Всё хочу ещё 8 поставить, да никак не соберусь ;-)

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

Конечно, при гигабитной сети, одном медленном диске и большой фрагментации, отключение встроенного кеша ничего не даст, скорее ухудшит ситуацию.
*
В последнем предложении конечно же "… включение встроенного кеша...".
И pagefile тоже мониторился.
175 мегабайт/с с диска, 300 мегабайт/с с буфера (максимальные показатели).

А кто Вам сказал, что чтение будет линейным?

Но «их» кеш позволяет не переполнять системный кеш, которому и без этого есть чем заняться.

Что значит «не переполнять»? Система всеми силами стремится максимально его заполнить, чтоб сократить количество дисковых операций.

Или он по объёму неограничен?

Вот я одного не понимаю, зачем Вы, задавая подобные вопросы, выносите суждения, да еще в категорическом тоне. Системный кеш по объему ограничен только размером ОЗУ (пытается заполнить всю свободную память, а при возможности, еще и отобрать немного памяти у процессов и забить кешем еще и ее)

Я выставил встроенный кеш в 512 мб.

Поздравляю, Вы потеряли полгигабайта системного кеша.

Очевидно если выставить объём встроенного кеша слишком большим, то будут проблемы, потому, что данные из/в кеш[а] читаются/пишутся постоянно (Как часто свопится память которая постоянно читается, если есть доступная свободная память). Цена этому большая загрузка процессора и больший объём требуемой память.

Галиматься какая то

А вот последовательную запись при включённом встроенном кеше (и отключённом системном кеше при/на записи) utorrent может обеспечить. Лучше, конечно, если кроме него на данный диск больше никто не пишет.

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

Журнал производительности (число чтений/записи, время чтений/записи, скорость чтений/записи, длина очереди чтений/записи и т.д.), скачивание всех сезонов доктора хауза (20000 сидов в том числе локальные, ~50Гбайт, 10 мегабайт/с), 4-ёх ядерник (3Ггц), hdd 4 шт (по 2 Гбайта) + 2 внешних, и 8 Гбайт оперативки (Всё хочу ещё 8 поставить, да никак не соберусь ;-)

Это методика?

Какой смысл в системном кеше, если при характере работы utorrent он не выполняет своих функций, т.е. кеширование.

Вы знаете, это начинает меня несколько напрягать. Не соизволите подтвердить эту галиматью хоть какими то данными?

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

Все имеют терабайтную коллекцию гей-порно, к которой есть высокий и однородный спрос со стороны пиров. Это все прекрасно, вот только СОВЕРШЕННО не объясняет того факта, что сам мюторрент реализует кеширование (хоть и плохо). Почему не отказаться от кеширования вообще, раз оно не нужно?
А кто Вам сказал, что чтение будет линейным?

В каком месте я говорю, что чтение будет линейным?
Ну а если говорить про линейное чтение. При раздаче полностью загруженного нефрагментированного файла, чтение будет скорее линейным. Так как utorrent будет стараться отдавать нескольким пирам одни и те же наиболее востребованные блоки последовательно, не дергая их с диска (или из системного кеша). А при одновременной загрузке-раздачи брать блоки из своего кеша ещё до их записи на диск (или системный кеш). utorrent не только пишет-читает, он ещё и раздаёт, и готовит данные к раздаче и много чего ещё, что системный кеш не делает. В общем как настроить, так и будет. Благо настройки имеются.

Система всеми силами стремится максимально его заполнить, чтоб сократить количество дисковых операций.
utorrent закачивает доступные части, почти всегда непоследовательно в случайном порядке, и если их сразу передавать в системный кеш, хоть система и попытается записать их с минимальным числом дисковых операций, последовательно писать всё равно не получится. Или она будет ждать когда в кеше файл в 14 гигабайт будет целиком? При включённом встроенном кеше utorrent собирает (по мере доступности) последовательно идущие части и сбрасывает их одним «блоком» и/или последовательно. При этом сбрасывать их можно как в системный кеш, так и прямо на диск.

Системный кеш по объему ограничен только размером ОЗУ
О, а я думал, что у кеша ввода/вывода есть лимит. Даже настроечка в реестре есть по это дело. Ну, бывает, ошибался. Т.е. если писать на диск в случайном порядке 14 гигов, то они будут закешированны и запишутся последовательно? При этом по вашим словам кеш гарантированно в ram, а ram размером 8 гигов. ЭЭэээ… у меня мозг плавится. Конкретней надо писать. Я же не утверждаю, что специалист. Просто пишу что видел и вижу каждый день сам.

Поздравляю, Вы потеряли полгигабайта системного кеша.
Не, вы потеряли дополнительные полгигабайта общего системного кеша, так. При верных настройках utorrent никогда не выделяет, не резервирует, не комитит, и т.д. более чем необходимо. Т.е. не потерял. И, сущие мелочи — подумаешь, гиг туда, гиг сюда…

Галиматься какая то

В каком пункте. Поподробней.

Ога, вот только система может обеспечить глобально…
Ну, пока не реализовали, да? «Глобальный последовательный сброс» на диск, на который никто кроме utorrent'а не пишет и не читает, при этом благодаря своему кешированию (мы же помним, что у нас 14 гигов скачиваются в случайном порядке и 8 гигов оперативки) utorrent сбрасывает последовательно большими блоками (и не важно куда, прямо на диск или в системный кеш) и при этом не читает с этого диска.

Это методика?
И?

Не соизволите подтвердить эту галиматью хоть какими то данными?
И? Мне весе журналы за несколько суток в сколько-то там гигов в двоичном виде сюда запостить? Сдохшие диски по почте прислать?

Все имеют терабайтную коллекцию гей-порно, к которой есть высокий и однородный спрос со стороны пиров.
Чмокни меня в мой блестящий металлический зад. (с)…

Это все прекрасно, вот только СОВЕРШЕННО не объясняет того факта, что сам мюторрент реализует кеширование (хоть и плохо)
Это всё прекрасно объясняет тот факт, что сам мюторрент реализует кеширование вполне неплохо.

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

В каком месте я говорю, что чтение будет линейным?
Где то в районе «175 мегабайт/с с диска». У меня есть некоторые (совершенно необоснованные сомнения), что современные rotational media могут делать random read-ы с такой скоростью.

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

Или она будет ждать когда в кеше файл в 14 гигабайт будет целиком?
Она будет держать в modified списке 200-500 метров данных и потом в один проход головки сольет их на диск. Один disk seek в несколько минут не сильно повлияет на производительность.

О, а я думал, что у кеша ввода/вывода есть лимит. Даже настроечка в реестре есть по это дело
Это другой кеш. Те самые 256-килобайтные слоты, которые используются кеш менеджером для меппинга кешируемых файлов. Физические страницы идут в системный рабочий набор, после отмепливания файла (при использовании слота для другого места в файле или для другого файла), страницы перемещаются из системного рабочего набора в standby список, который и является основным системным кешем. Ну и для записываемых файлов все очень похоже: кешируемый файл меппится в слот, в него копируются данные, а после отпепливания файла из слота — записанные страницы переходят в modified список, в котором сидят до тех пор пока modified page writer не соизволит проснуться и сбросить их на диск.

Ну, пока не реализовали, да?
Сброс страниц в оптимальном порядке реализован. Более того, он реализован общесистемно, в отличие от мюторрента. Вот сброса страниц в духе «ну раз уж мы пришли в эту часть диска почитать чего нибудь, то почему бы и одновременно и не записать» — не реализован. Сомневаюсь, что это реализовано в мюторренте.

И?
Что и? Методика или нет? Контроллируемое окружение? Одинаковые паттерны запросов? Одинаковое состояние сети?

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

1. Ведь при раздаче utorrent читает разные блоки, а не одни и те же. При загрузке запись одних и тех же блоков происходит однократно и по возможности последовательно без фрагментации. Что здесь кешировать?
2. Это все прекрасно, вот только СОВЕРШЕННО не объясняет того факта, что сам мюторрент реализует кеширование (хоть и плохо)
1. Это всё прекрасно объясняет тот факт, что сам мюторрент реализует кеширование вполне неплохо.

Мне кажется Вы начали спорить ради спора. В таком случае, YOU WON!!! Мне это неинтересно.

1. Ведь при раздаче utorrent читает разные блоки, а не одни и те же. При загрузке запись одних и тех же блоков происходит однократно и по возможности последовательно без фрагментации. Что здесь кешировать?
2. Почему не отказаться от кеширования вообще, раз оно не нужно?
1. При последовательной потоковой загрузке, при записи в предварительно размеченную нефрагментированную область диска можно, но это фантастика, особенно в части загрузки, это же p2p как никак.

Не соизволите развернуто пояснить одно из Ваших утверждений: либо о том, что кешировать нечего, либо о том, что кешировать надо, но ИСКЛЮЧИТЕЛЬНО собственным велосипедом.
Присоединяюсь к leotsarev и к вопросу:
>>Чем закончилось дело?

Ибо годы спустя мюторрент всё так же очень криво работает, а что хуже всего из версии в версию поведение меняется, такое впечатление, что они до сих пор пытаются методом тыка улучшить работу с диском :(
Очень интересная статья (все три части). Спасибо за нее!

Что касается uTorrent, я разделяю всеобщее волнение по этому поводу, так как это тот практический момент статьи, с которым сталкивается почти каждый.

В связи с этим, я хочу отметить, что Ваша компетенция во вопросах работы с памятью под вопрос не ставится. Но Вы сами признались, что торрентами не пользуетесь. Поэтому, ситуация, когда критика Вашего подхода к его настройкам оправдана, вполне может быть. Не имея времени и желания вдаваться в теорию, я просто настроил на одной машине его по Вашим рекомендациям, и оставил умолчания на другой машине. Их конфигурации похожи, но, к сожалению, не идентичны. Посмотрим что будет )
Очень хорошо, что Вы решили не верить на слово и попробовать. Я всецело поддерживаю подобную практику и, более того, пытаюсь сам делать reality check на каждом выполняемом шаге (именно из-за этого в статьях довольно много скриншотов). С другой стороны я не доверяю оценкам «на глаз» — люди склонны давать оценки, которые больше согласуются с их внутренними убеждениями (идеально было бы сделать double blind trial, но в данном случае обычный скурпулезный сбор логов вполне достаточен).

Например, в случае конкретно мюторрента может присутствовать еще какая нибудь «оптимизация», включаемая вместе с включением системного кеша, но я сильно сомневаюсь.
Ну вообщем, результат тестирования оказался странен. После трех часов работы мюторрента компьютер «с твиками» стал очень не отзывчив, а окно мюторрента периодически становилось «не отвечающим». К сожалению, пока я не убил мюторрент, посмотреть любую системную информацию было не возможно. Так что реальной информации, кроме тестов «на глаз» у меня нет. Возможно дело и не в твиках было.
Это в общем странно. На всякий случай спрошу, система Vista+? Стоят ли какие нибудь «ускорители» типа eboostr?
Вообще говоря, это безобразие. Безобразие сплошное, а не статья.

Причем такое уже было со мной во времена (по-моему) NT, когда я впервые наткнулся на утилиты Руссиновича.

Вдруг стало понятно, что система (Windows) развивается не только в сторону «разноцветных финтифлюшек» и раздувания многогигобайтных .Net.

Я опять зауважал Windows!
Спасибо за статью, но по поводу рекомендаций для uTorrent присоединюсь к критике.
После отключения кеша появляется треск и возрастает количество обращений к диску:



После включения кеша треск прекращается и обращения к диску происходят заметно реже:



За разницу в масштабе больно не бейте, оригинальные файлы профайлера прилагаются:
narod.ru/disk/27201087000/utorrent_etl.rar.html
Спасибо за тест. Можно спросить, о каком из кешей идет речь?
О кеше uTorrent, четыре галки на вкладке Disk Cache (2 выключено/2 включено и наоборот).
И еще один вопрос. На обоих графиках практически весь доступ диска показан красным (это приоритет >= Normal). Здесь есть два варианта: 1. Артефакт от самого xperf (при анализе дисковой активности лог лучше собирать в память — а сбрасывать только в самом конце), 2. По какой то причине не применились значения приоритетов из IFEO (не могли бы Вы проверить в Process Explorer-е действительные значения приоритетов)?
Склоняюсь к версии, что это сам xperf. То есть при включенном системном кеше, мюторрент выполняет больше операций ввода/вывода (которые удовлетворяются из памяти) и каждая из них записывается в лог — соответственно лог растет быстрее и сбрасывать его на диск приходится чаще — сейчас докачаю логи и сравню размеры
Народ.ру меня не любит, открыть файлы не могу, но размеры одинаковы (я так понимаю это был циклический трейс). По скриншотам видно, что в первом случае было почти на порядок больше файловых (не дисковых) операций, соответственно лог рос быстрее
Операций и правда намного больше, хотя скорость скачки/раздачи не менялась, да и промежуток времени примерно один.

Увеличение количества операций — вполне ожидаемо. Когда мюторрент осуществляет собственное кеширование — он просто берет данные из собственной памяти (если они конечно не сброшены в пейджфайл), когда используется системный кеш — мюторрент выполняет обычную операцию типа ReadFile и данные из собственной памяти достает уже система.
А может это глюк самого мюторрента, вдруг галки включения системного кеша не работают?
Верхний график (с системным кешем) скорее всего ходил к диску, так что дело наверное не в xperf. Мне стало еще интереснее взглянуть на логи
Лог от xperf пишется на другой физический диск. Значения приоритетов как раз сработали, uTorrent работает с I/O Priority: Very Low, в Resource Monitor тоже стоит Background.
Не могли бы Вы переложить логи куда нибудь в более дружелюбное место? Хочется взглянуть на то, что там происходит.
Скачал, посмотрел. Вижу гораздо больше дисковых операций в первом случае. Такое ощущение, что мюторрент лучше локализует свои запросы, когда включено его собственное кеширование. Я попробую спросить у их саппорта
forum.utorrent.com/viewtopic.php?pid=539008
Проблема в том, что uTorrent в режиме системного кеша читает блоками по 12 кб в среднем, а в режиме собственного кеша — блоками по 130 кб в среднем. Отсюда в 10 раз большее количество перепозиционирований головки
Не могли бы Вы провести еще один эксперимент?
Удалите IoPriority — оставьте только PagePriority. Я не уверен, может быть система разбивает низкоприоритетеный ввод/вывод на более мелкие части.

Заранее спасибо
Проверил на синтетике — низкоприоритетные чтения не бьются, но на всякий случай проверьте все таки на реальном торренте
Модифицировал abuseio чтоб добавить конкуренции — да, система бьет низкоприоритетное чтение на мелкие части. Что ж, буду знать. Протестируйте, пожалуйста, только с pagepriority — если подтвердится — проапдейчу пост
И еще одна вещь, если не затруднит. Меня волнует, что запись происходит из процесса самого мюторрента, а не из системного modified page writer-а. Не могли бы Вы добавить во флаги fileio и запустить трейс до старта мюторрента? В данном случае меня интересует только включенный системный кеш/выключенный кеш торрента (как открываются файлы, если наоборот я и так знаю)
Открывает нормально (в смысле без write_through, которого я уж было ожидал — странно, что записи идут минуя кеш). Записывает много, но блоками по полмегабайта, что хорошо. Вот читает все еще мелкими блоками и часто, что плохо. Причем это уже именно юторрент, а не винда (это Summary table с File IO, сгруппированный по Process: utorrent.exe/Event type: Read):

Пожалуй надо продолжить тред в поддержке
А у меня uTorrent отлично работает с дефолтовыми настройками и ничего от него не тормозит — поэтому я не парюсь.
Тоже очень верный подход. Недостатки мюторрентового кеша я написал. Если это несущественно — отлично, тем более, как выясняется, похоже у мюторрента разный шаблон обращений к диску при смене с его внутреннего кеширования на системное
Win7 x64, 4Gb, i7.
Очень интересует, почему при выполнении сильного свопа перестают работать кнопки на таскбаре (супербаре), невозможно вызвать контекстное меню программ (чтобы закрыть их), невозможно вызвать контекстное меню таскбара, чтобы запустить таск-менеджер, невозможно запустить таск-менеджер по ctrl+shift+Esc, и даже Ctrl+Alt+Delete может сработать через несколько минут. Такое может наблюдаться при склейке больших панорам в помощью smartblend или при долгих ресурсоёмких операциях в Adobe Photoshop CS5 (несмотря на жёсткую установку не использовать больше 2Гб в нём). Где же эта хвалёная отзывчивость Win7? Почему даже системный Task Manager может висеть минутами в таких ситуациях, не давая убить программу, почему ему изначально не дают максимальный приоритет?

p.s. удивительно, но на одноядернике на XP такие вещи, включая таскбар и таскменеджер были более отзывчивыми.
Автор, я так и не понял — надо делать экзекуции с utorrent или нет?
Пока не стоит. Я свяжусь с авторами мюторрента, чтобы уточнить
win 7 x64, q6600, 4gb ram
включение кеша винды примерно через 2 часа загадило всю оперативку и замедлило систему до безобразия. выключение кеша винды освободило примерно 3 гигабайта памяти. такие пироги.
Это странно. Для прояснения ситуации, не могли бы Вы ответить на несколько вопросов.
Не подскажете, что в данном случае означает «загадило всю оперативку»? Проверьте пожалуйста Page Priority потоков utorrent.
В какой момент произошло «освобождение памяти». Проверьте при помощи RamMap, какие файлы и на каком уровне приоритета закешированы. Кроме того, для полноты картины, проверьте распределение кеша по приоритетам.

Спасибо
«загадило всю оперативку» — использование памяти на ~98% при практически чистой системе (фубар, миранда, скайп, мюторрент). без кеша винды моя система в таких условиях использовала от силы 30% памяти. очищение памяти произошло либо после того, как я отключил кеш винды, либо после перезапуска мюторрента (контрольный выстрел), сейчас не вспомню. кстати, использование памяти после этого упало до 16%, что на мой неискушенный взгляд говорит о том, что мюторрент вытеснил из оперативной памяти чуть ли не половину системы. да, вся информация почерпнута из вкладки performance пресловутого task manager'а и моих наблюдений за отзывчивостью системы.

да, забыл главное — никаких правок в реестр я не вносил. вполне возможно, с ними всё было бы гораздо иначе, но у меня уже пропало желание чинить то, что не сломано.
да, забыл главное — никаких правок в реестр я не вносил. вполне возможно, с ними всё было бы гораздо иначе, но у меня уже пропало желание чинить то, что не сломано.
Хм, в этом была ВСЯ СУТЬ. Использовать кеш с низким приоритетом, чтоб не вытеснять всю систему. О том, что без изменений мюторрент ведет к cache thrashing-у давно известно. Именно это привело к авторы мюторрента стали реализовывать собственное кеширование — здесь я предложил (более правильное на мой взгляд) решение этой проблемы. Решение пока не полное из-за разного паттерна чтения для случаев использования собственного и системного кешей, но я попробую уговорить разработчиков сменить такое поведение.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.

Articles