Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 171
Вы круты! :) Таких доступных(и полезных) и толково написанных статей я давно не читал!
Вопрос «чайника», не лазившего столь далеко в дебри Windows. Насколько ваши рецепты помогают на XP?
С одной стороны, описание CreateFile говорит, что новых флагов со времён XP вроде и не появлялось, с другой — в документе, который вы подкинули, про XP ни слова.
С одной стороны, описание CreateFile говорит, что новых флагов со времён XP вроде и не появлялось, с другой — в документе, который вы подкинули, про XP ни слова.
Рецепты конкретно из этой статьи — никак.
А почему Вы используете XP?
А почему Вы используете XP?
У меня дома три ноута разного возраста, на одном предустановлена XP, на другом Vista, на третьем Win7. Думаю, что у многих так же. Не вижу смысла покупать новую версию ОС для старого железа, тем более, пока старая еще поддерживается — достаточно просто держать включенными все обновления.
Ну, вдруг он из тех психов, что покупают софт за деньги :)
На самом деле «используете XP» — это неправильная формулировка, звучит как будто для этого нужно прилагать усилия. Правильнее спросить «почему вы не переходите на новую версию», тогда понятно, что усилия нужны не использовать XP. А для любых усилий, как известно нужны веские основания (что-то не работает, что-то тормозит, там красивее или безопаснее). Пока достаточных оснований не накопится у конкретного человека, он не станет переходить.
На самом деле «используете XP» — это неправильная формулировка, звучит как будто для этого нужно прилагать усилия. Правильнее спросить «почему вы не переходите на новую версию», тогда понятно, что усилия нужны не использовать XP. А для любых усилий, как известно нужны веские основания (что-то не работает, что-то тормозит, там красивее или безопаснее). Пока достаточных оснований не накопится у конкретного человека, он не станет переходить.
Я вот пока не могу. Мне три дня надо убить на то, чтобы всё переставить и настроить. Работает, обновляется — что ещё надо?
Я тоже использую только лицензионный софт (в том числе Windows).
> Правильнее спросить «почему вы не переходите на новую версию»
В общем да, но такая формулировка имеет смысл только если за последние 10 лет не покупался новый компьютер. В противном случае (даже если речь идет о самосборе без предустановленной системы) стоит говорить о миграции с одной XP на другую или о миграции же с XP на что то более новое.
Люди продолжают мигрировать на XP на новых боксах потому, что считают, что ничего не изменилось.
Вот приоритеты памяти и суперфетч — пара примеров того, что видно пользователю. Еще композитинг, супербар, работающий поиск и пр…
> Правильнее спросить «почему вы не переходите на новую версию»
В общем да, но такая формулировка имеет смысл только если за последние 10 лет не покупался новый компьютер. В противном случае (даже если речь идет о самосборе без предустановленной системы) стоит говорить о миграции с одной XP на другую или о миграции же с XP на что то более новое.
Люди продолжают мигрировать на XP на новых боксах потому, что считают, что ничего не изменилось.
Вот приоритеты памяти и суперфетч — пара примеров того, что видно пользователю. Еще композитинг, супербар, работающий поиск и пр…
При апгрейде железа не нужно никуда мигрировать. Если система при обновлении железа валится в BSOD в 99% случаев помогает накатывание поверх с сохранением всех установленных программ и настроек.
Не апгрейде железа, а покупке нового компьютера. 10 лет назад у меня был винт на 10 гиг, материнская плата, не поддерживающая ни современных процессоров, ни современной памяти, ни современных слотов расширения (в том числе для графической карты). Что там говорить — там не было даже USB. Речь идет о полной смене компьютера. Лично я уже и забыл сколько раз «переезжал» на совершенно новое железо за последние 10 лет, но менее привязанные к технике люди гарантированно «переезжали» как минимум пару раз.
Я отчётливо вижу как работает 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 секунд.
Из-за суперфетч я уже забыл, как та же вижуал студия поднимается из таскбара в течение 30 секунд.
VS2008 — 3 секунды на запуск, правда с ssd. 30 секунд на запуск — это совсем что-то плохое с hdd или процессором.
Это было во времена XP и 2003-й студии. Причем речь даже не о холодном старте, а о ресторе из таскбара. Да, лично я на глаз вижу разницу в управлении памятью между XP и Vista/7
Более того, прямо сейчас я запустил онлайн-дефрагментацию. Я бы мог и не упоминать об этом, но я только сейчас об этом ВСПОМНИЛ. 100% дисковая активность практически не влияет на комфортность работы с системой
У меня везде ssd — дефрагментация не нужна :)
Получается, что улучшения видны/заметны в основном на не быстрых компьютерах?
Получается, что улучшения видны/заметны в основном на не быстрых компьютерах?
SSD в любом случае медленнее, чем RAM, но конкретно улучшения в кешировании будут наиболее заметны на медленных дисках.
Улучшения, даваемые композитингом заметны вообще практически где угодно. Новое меню пуск — икспишным я уже не могу пользоваться, супербар — забыл о проблемах нехватки места на таскбаре и т.д… Очень много улучшений именно заметных пользователю, но еще есть куча улучшений, приятных лично мне, как программисту и «продвинутому пользователю».
Улучшения, даваемые композитингом заметны вообще практически где угодно. Новое меню пуск — икспишным я уже не могу пользоваться, супербар — забыл о проблемах нехватки места на таскбаре и т.д… Очень много улучшений именно заметных пользователю, но еще есть куча улучшений, приятных лично мне, как программисту и «продвинутому пользователю».
Ну вот и получается, что на быстрых компьютерах vista/w7 медленнее XP — за просто так.
А меню пуск я вообще почти не пользуюсь. У меня таскбар в две строки, верхняя — quick launch и все нужные программы(>40). Нижняя сам таскбар, где видно что запущено и нет проблем.
А меню пуск я вообще почти не пользуюсь. У меня таскбар в две строки, верхняя — quick launch и все нужные программы(>40). Нижняя сам таскбар, где видно что запущено и нет проблем.
Ну вот и получается, что на быстрых компьютерах vista/w7 медленнее XP — за просто так.
С чего бы? Заметьте, я сейчас даже не прошу подтвердить слова какими нибудь экспериментальными фактами, я прошу дать хоть какое то ВОЗМОЖНОЕ подтверждение Вашим словам.
Кстати, про нетбук на атоме. Я вот покупал один когда они продавались еще с XP. Тормозил, гад. Сейчас он же летает под Win7 HP
Но вообще, я не нанимался Вас переубеждать. Хотите отстаивать позицию «ничего не поменялось» в топике про одно из таких изменений — Ваше право. Sapienti sat
> А почему Вы используете XP?
дык работадатель :(
дома у меня убунту
дык работадатель :(
дома у меня убунту
Торт! Однозначно ТОРТ.
Надо запомнить про решение с мюторентом.
Надо запомнить про решение с мюторентом.
Вы бы сначала попробовали этот «торт».
Хорошо что автор упомянул что utorrent у него не стоит, эдакий теоретик, практика показывает что если установить настройки кеширования согласно рекомендации, то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае). Возврат настроек в дефолт проблему снимает. Так что, во-первых не все статьи одинаковы полезны, во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
Хорошо что автор упомянул что utorrent у него не стоит, эдакий теоретик, практика показывает что если установить настройки кеширования согласно рекомендации, то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае). Возврат настроек в дефолт проблему снимает. Так что, во-первых не все статьи одинаковы полезны, во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
Вы бы сначала попробовали торт, перед тем как попробовать советовать попробовать. Последние скриншоты наглядно показывают, что запущен именно мюторрент, с раздачей 5 гигабайтного исошника. Почти весь исошник поместился в свободную память.
> то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае)
Простите, но я опять вынужден просить подтверждения. При любых раскладах, расти должен системный рабочий набор, а не рабочий набор мюторрента. Причем расти из-за кеша неограниченно он просто не может — количество слотов, в которые мепятся файлы ограничено и относительно невелико.
> во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
А вот это вряд ли. Если делаешь управление физической памятью в пользовательском процессе, то как минимум нужно выставлять MinumumWorkingSet во что нибудь большое. Дефолтных 200 килобайт маловато для адекватного кеша, не находите? А без этого, их виртуальная память рано или поздно просто уйдет в своп файл. Отличное решение — кеширование данных из файла на диске в другой файл на диске.
> то utorrent начинает отъедать память пока не упрется в ее физический предел (4 Гб в моем случае)
Простите, но я опять вынужден просить подтверждения. При любых раскладах, расти должен системный рабочий набор, а не рабочий набор мюторрента. Причем расти из-за кеша неограниченно он просто не может — количество слотов, в которые мепятся файлы ограничено и относительно невелико.
> во-вторых разработчики utorrent все-таки в работе с памятью и кешем windows понимают больше автора.
А вот это вряд ли. Если делаешь управление физической памятью в пользовательском процессе, то как минимум нужно выставлять MinumumWorkingSet во что нибудь большое. Дефолтных 200 килобайт маловато для адекватного кеша, не находите? А без этого, их виртуальная память рано или поздно просто уйдет в своп файл. Отличное решение — кеширование данных из файла на диске в другой файл на диске.
У меня тоже советы из статьи не заработали.
Вводная: uTorrent работает 24/7 на хорошем канале, раздач очень много, памяти 4 Гб.
При настройке торрента в соответствии со статьёй (+ явно процессу uTorrent.exe задаётся самый низкий приоритет) вся оперативная память забивается кэшем, в активных приложениях при IO (запуске, загрузке документов и т. п.) заметны подтормаживания. При закрытии торрента система оживает. Пробовал два режима, без файла подкачки совсем (т. к. тяжёлых приложений нет, самое тяжёлое — Firefox) и с файлом подкачки на 4 Гб — одинаково.
При включении кэша самого мюторрента даже всего на 200 Мб и отключения кэша Windows нагрузка на диск остаётся такой же невысокой (лишних чтений так и так нет), но системный кэш не распухает, всегда есть запас свободной памяти. Подтормаживания в активных приложениях могут возникать только при перехэшировании файлов, когда диск и CPU работают по-максимуму.
А теперь хочу перейти на личности. :-) Пусть и запоздало, но — спасибо вам за ваши статьи, у вас отличные знания относительно операционных систем. И во многом разделяю вашу точку зрения относительно Windows.
Вводная: uTorrent работает 24/7 на хорошем канале, раздач очень много, памяти 4 Гб.
При настройке торрента в соответствии со статьёй (+ явно процессу uTorrent.exe задаётся самый низкий приоритет) вся оперативная память забивается кэшем, в активных приложениях при IO (запуске, загрузке документов и т. п.) заметны подтормаживания. При закрытии торрента система оживает. Пробовал два режима, без файла подкачки совсем (т. к. тяжёлых приложений нет, самое тяжёлое — Firefox) и с файлом подкачки на 4 Гб — одинаково.
При включении кэша самого мюторрента даже всего на 200 Мб и отключения кэша Windows нагрузка на диск остаётся такой же невысокой (лишних чтений так и так нет), но системный кэш не распухает, всегда есть запас свободной памяти. Подтормаживания в активных приложениях могут возникать только при перехэшировании файлов, когда диск и CPU работают по-максимуму.
А теперь хочу перейти на личности. :-) Пусть и запоздало, но — спасибо вам за ваши статьи, у вас отличные знания относительно операционных систем. И во многом разделяю вашу точку зрения относительно Windows.
Прочитал все три части на одном дыхании. Вы круты. Честно круты.
Думаю, вы побудили не один десяток человек к самообразованию. :)
Думаю, вы побудили не один десяток человек к самообразованию. :)
/proc/sys/vm/swappiness в Windows XP? Как это?
Нет, если Вы заметили то начал с сомнений в обоснованности мнения человека, «досконально изучившего винду». Своппинесс насколько я себе могу представить, не решает вообще никаких реальных задач.
Суть swapiness в том чтобы сказать ядру «чувак, сохраняй поменьше в своп — у меня IO жутко медленный» (0 < swapiness < 60) и, наоборот, «сохраняй побольше, у меня IO шустрое» (60 < swappiness < 100).
Не совсем. К сожалению, я плохой оратор. Попробую перефразировать. Именно кеширование дает наибольший общий прирост производительности при медленных дисках. Как раз потому, что уменьшать нужно не обращения к свопу, а обращения к диску. Причем на обычных вращающихся дисках чтение и запись одинаково разрушительны для производительности.
При помощи своппинесс можно сказать системе: если тебе вдруг понадобится страница, никогда не трогай память приложений — только кеш. Даже если открыт, скажем, опенофис и Вы не пользуетесь той его частью, которая требует Java — она все это время будет оставаться в памяти. ФИЗИЧЕСКОЙ памяти. При этом не выполняя никаких полезных функций ни для Вас (вы той частью функционала просто не пользуетесь), ни для, очевидно, системы.
Это можно с определенным успехом использовать (к примеру понижать своппинесс до нуля перед выполнением каких нибудь maintanence работ типа обновления индексов и возвращать его на место после окончания), но лично мне очень трудно усмотреть в своппинесс эффективный механизм для оптимального использования физической памяти.
При помощи своппинесс можно сказать системе: если тебе вдруг понадобится страница, никогда не трогай память приложений — только кеш. Даже если открыт, скажем, опенофис и Вы не пользуетесь той его частью, которая требует Java — она все это время будет оставаться в памяти. ФИЗИЧЕСКОЙ памяти. При этом не выполняя никаких полезных функций ни для Вас (вы той частью функционала просто не пользуетесь), ни для, очевидно, системы.
Это можно с определенным успехом использовать (к примеру понижать своппинесс до нуля перед выполнением каких нибудь maintanence работ типа обновления индексов и возвращать его на место после окончания), но лично мне очень трудно усмотреть в своппинесс эффективный механизм для оптимального использования физической памяти.
Или вот еще более правильный пример: как минимум Опера (наверное остальные тоже в той или иной степени) сохраняют историю страниц (вместе с результатом рендеринга), а также имеет «Корзину» для закрытых страниц, которые тоже хранятся в памяти. За счет этого ее рабочий набор разрастается порой до внушительных размеров. Под виндой это не страшно, потому что через некоторое время все неиспользуемые страницы постареют, обрежутся, потеряют приоритет, сбросятся в своп и будут использованы для кеширования. При помощи своппинесс можно или вообще не обрезать никого или обрезать по старинке — наобум
swappiness не управляет «скидывать в своп или не скидывать в своп». Он управляет коэффициентом «лучше скинуть» или «лучше не скинуть».
Так, swappiness = 100 вовсе не означает что в своп будет скидываться все подряд. Равно как и swappiness = 0 не говорит о том что своп не будет использоваться вообще.
можно размышлять об этом примерно так:
при swappiness = 100 в своп будет скидываться то, что не запрашивалось 5 минут
при swappiness = 60 в своп будет скидываться то, что не запрашивалось 1 час
при swappiness = 0 в своп будет скидываться то, что не запрашивалось 24 часа.
Это лишь коэффициент и не более того. Помимо 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) — размен, который делается очень часто, но в данном случае, как я уже сказал, от меня ускользает логика данного алгоритма.
Ну то есть вместо размышлений которые вижу (и с которыми в большинстве случаев согласен) за реализацией виндового мемори менеджера, здесь я вижу алгоритм вида: «Хм, а что если сделать еще и вот так — чего выйдет?». Это конечно мои личные предпочтения, но я люблю когда перед кодированием обдумывают решение, а не пользуются «методом научного тыка».
«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 вообще запрещает сваппинг своей памяти. И правильно делает.
в линухе можно хоть чуть чуть влиять на процесс. Не хотите — не влияйте, в чем проблема-то? Я от swappiness ощущаю больше пользы, чем зла.
да и вообще, админы при тонкой настройке серверов зачастую вообще ядро патчат =). А для десктопа — вон, тот же deluge вообще запрещает сваппинг своей памяти. И правильно делает.
Да я понимаю, что винты бывают разными. Но в том то и суть, что с одной стороны я вижу глобальный мемори менджмент, призванный уменьшить нагрузку на диск вообще (а не только на своп), при этом делая все возможное для того, чтоб приложения оставались responsive. С другой — какие то отпотолочные вычисления (сложение/деление величин, у которых даже типы не сходятся), которые призваны уменьшить давление на своп-раздел. Почему своп раздел такой особенный? Почему именно количество обращений к нему нужно уменьшать? Откуда там деление на 2 и откуда взялся порог в 100? Почему даже размерности складываемых и сравниваемых величин не сходятся (если уж за этим стоит хоть какой то «физический» смысл)?
ну погодите. Если не говорить о ситуации когда своп используется как расширение памяти которой _не_ хватает, то ни о каком изменении времени отклика приложений при своппинге и быть не может. Ситуацию когда памяти не хватает я вообще не рассматривал — тут все относительно просто: тормозить будет в любом случае =)
когда же памяти в целом хватает для рантаймовых данных всех приложений — для чего можно ещё заюзать память? Кеш файловый, кеш файловых систем, кеш «ещё какой-нибудь». При этом непонятно что важнее — закешить вооооот этот воот файлик или оставить в памяти кусок оперы открытой неделю назад. Для рабочих станций важнее явно будет кешить как можно больше скидывая оперу в своп и наплевав на то что обращение к ней потом будет достаточно дорогим — зато данные которые нужны здесь и сейчас будут в кеше. Для ноутбука важнее будет довольствоваться тем что есть, стараясь не дергать винт вообще. А для рядового убунту-юзера вероятно вообще надо будет выбрать нечто среднее, не вдаваясь в крайности.
Вот никто лучше меня самого и никакой великий аналитический алгоритм не угадает что у меня за машина и зачем она мне нужна и какой софт я собираюсь запустить через пять минут.
когда же памяти в целом хватает для рантаймовых данных всех приложений — для чего можно ещё заюзать память? Кеш файловый, кеш файловых систем, кеш «ещё какой-нибудь». При этом непонятно что важнее — закешить вооооот этот воот файлик или оставить в памяти кусок оперы открытой неделю назад. Для рабочих станций важнее явно будет кешить как можно больше скидывая оперу в своп и наплевав на то что обращение к ней потом будет достаточно дорогим — зато данные которые нужны здесь и сейчас будут в кеше. Для ноутбука важнее будет довольствоваться тем что есть, стараясь не дергать винт вообще. А для рядового убунту-юзера вероятно вообще надо будет выбрать нечто среднее, не вдаваясь в крайности.
Вот никто лучше меня самого и никакой великий аналитический алгоритм не угадает что у меня за машина и зачем она мне нужна и какой софт я собираюсь запустить через пять минут.
Памяти всегда не хватает. Иначе никакого управления памятью не нужно было бы городить: нужна страница — возьми свободную. Вот когда свободных уже нет, начинаются вопрос откуда брать память.
Не будет опера сбрасываться в своп. В лучшем случае ее выбросят в stanby/modified, но при первом же обращении вернут на место. Вот если таких обращений не будет очень долго, а все остальные при этом будут действительно использовать свою память вместо того, чтоб тупо держать ее «на всякий случай» — тогда страницы оперы будут переиспользованы (repurposed).
На самом деле и в винде и в линуксе за Вас решили, как будет использоваться память Вашего компьютера. Просто у одних вышло хорошо, у других — не очень
Не будет опера сбрасываться в своп. В лучшем случае ее выбросят в stanby/modified, но при первом же обращении вернут на место. Вот если таких обращений не будет очень долго, а все остальные при этом будут действительно использовать свою память вместо того, чтоб тупо держать ее «на всякий случай» — тогда страницы оперы будут переиспользованы (repurposed).
На самом деле и в винде и в линуксе за Вас решили, как будет использоваться память Вашего компьютера. Просто у одних вышло хорошо, у других — не очень
> Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
на столько интеллектуально, что когда заканчивается оперативка виснет gui и насилутся диск, что со свопом, что без…
на столько интеллектуально, что когда заканчивается оперативка виснет gui и насилутся диск, что со свопом, что без…
> Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
Не подскажете, где про это почитать?
Не подскажете, где про это почитать?
Читал что в utorrent есть параметр diskio.flush_files. Если от стоить в true, то utorrent периодически (раз в минуту?) открывает и закрывает файлы (все?). Напишите что-нибудь на этот счёт.
Я конечно извиняюсь, но где найти это самое окно «uTorrent.exe:2768 Properties»?
Process Explorer
Скачать можно с: technet.microsoft.com/ru-ru/sysinternals/bb896653.aspx
Скачать можно с: technet.microsoft.com/ru-ru/sysinternals/bb896653.aspx
Спасибо за статьи. Очень познавательно.
А вы пытались свзязаться с авторами uTorrenta?
А вы пытались свзязаться с авторами uTorrenta?
стиль изложения сильно хромает. при том, что автор вроде и полезную информацию пытается изложить, но как-то всё мутно, скомкано, с непонятными переходами между мыслями. пример полёта шизомысли: «написал на сишарпе, потому что не у всех может оказаться установленная Visual Studio».
потому что кусок кода на сишарпе можно скомпилить и запустить на голой win vista/7, либо на xp на которую только поставлен дотнет.
Вы открыли мне глаза. Не знал, что в .NET входит компилятор шарпа. Это ж теперь простенькие программы можно на любом компьютере писать! Только ради этого стоит его наконец-то по-нормальному выучить.
а как его запустить?
наверно
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
то есть это ещё нужно сделать загрузчик в виде батника х)
а в PATH прописать не?
и заниматься этой ерундой при каждом апдейте фреймворка?
Можно в профайл павершелла прописать:
$env:PATH += [System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory() + ";"
Ну или завести переменную FRAMEWORK_PATH и добавлять его. В принципе изменение FRAMEWORK_PATH — задача, сопоставимая по сложности с самим апдейтом фреймворка
$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 — не очень то большое разнообразие, не правда ли?
таких каталогов может быть всего 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.
Я свои проекты на серваках компилирую msbuild'ом, которые входит в поставку .Net Framework'a.
т.е. мюторрент пишет на диск часто используемые данные, так?
можно ли его обвинить в большом количестве записанных данных на системный диск? (который у меня ссд и количество циклов записи на него ограничено, поэтому меня это волнует)
можно ли его обвинить в большом количестве записанных данных на системный диск? (который у меня ссд и количество циклов записи на него ограничено, поэтому меня это волнует)
мюторрент пишет на диск скачиваемые данные. Больше ему туда писать нечего. Тут дело в том, что его чтения с диска загрязняют кэш и замедляют другие (очевидно более важные) приложения.
спасибо.
я понял как будто он кеширует часто используемые данные на сист. диск
я понял как будто он кеширует часто используемые данные на сист. диск
кстати еще музыка бывает подергивается пока торрент не выключишь, видимо из за этого
Музыка подёргивается из-за прерываний от сетевой карты, хотя с этим должна бороться служба MMCSS.
Музыка может дергаться еще и из-за сильно большой нагрузки на диск (особенно если прослушивается с того же диска). Если же это действительно прерывания, то MMCSS (очень неплохая штука сама по себе) сделать все равно ничего не сможет — прерываниям плевать на приоритеты потоков. Когда выполняется обработчик (или его DPC) — никакие даже самые высокоприоритетные потоки на этом процессоре не планируются.
а что скажешь по поводу тотал командера и его режима отключения кэша при копировании больших файлов?
Спасибо. Сколько пользовался — не знал, что он кеш выключает. То-то в последнее время при копировании больших файлов система практически не отзывалась. Включил, чтобы использовал метод «Копирование / вставка с помощью Проводника виндовс».
Не ставил тотал коммандер. Но можете посмотреть на уровень приоритета, на который TC кеширует копируемый файл (при включенном кеше). Есть подозрение, что он не использует sequential only (можно проверить в xperf) и кеширует все на уровень 5, чем может вытеснить более важные данные. Пользуюсь FAR-ом (правда все реже) — там есть галка «Использовать системную функцию копирования». Если в TC есть аналог этой галки — рекомендую включить
«2. Импортируем в реестр следующий файл:»
Забыли в конце пустую строчку оставить.
Забыли в конце пустую строчку оставить.
Вопрос не по статье, но по памяти: CreateFileMapping с INVALID_HANDLE_VALUE создаст File mapping с размером который я укажу, или с размером округленным в большую сторону до размера страниц?
Просто в документации по этому поводу ничего найти не удалось, а MapViewOfFile спокойно дает мапить регионы больше чем я задал в CreateFileMapping, но вписывающиеся в размер страницы(ну или страниц).
Просто в документации по этому поводу ничего найти не удалось, а 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). При этом недостатка информации по работе с памятью ядра линуха я вообще не ощущал никогда.
Для меня исходники куда более понятны, чем непрозрачные размышления непонятно кого (я про Windows Internals). При этом недостатка информации по работе с памятью ядра линуха я вообще не ощущал никогда.
> шедулеры
fixed
fixed
Кнопка Audio (US)
Прямая ссылка
Шедьюл — это британское произношение. Британцы пока что не являются законодателями мод в IT :-)
Прямая ссылка
Шедьюл — это британское произношение. Британцы пока что не являются законодателями мод в IT :-)
тем не менее, /ˈʃ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
(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 и странах СНГ, но не в Европе).
Здесь Вы несколько заблуждаетесь. Слово это попало в английский язык через французский, где оно читалось именно через «ш». Американцы же упростили (как всегда, собственно) правила произношения, уравняв его в правах со словами school, scheme и другими словами греческого происходжения.
Насчёт кириллической версии (оставим за рамками корректный термин, которым её стоит называть), то «шедулер» таки на два десятичных порядка популярнее (если судить по результатам гуглопоиска).
И таки да, я в данном, как и во многих других случаях предпочитаю британский вариант. Аналогично, я скажу bureau de change, а не exchange office (последний, кстати говоря, популярен, в частности, в US и странах СНГ, но не в Европе).
Насчет измнений в британском произношении — я не могу найти статью, но я это не придумал, честно.
Возможно конкретно это слово имело другую историю.
В общем это вопрос личных предпочтений. Мне некомфортно слышать и говорить skɛd.juːl, но при этом писать шедул.
Возможно конкретно это слово имело другую историю.
В общем это вопрос личных предпочтений. Мне некомфортно слышать и говорить skɛd.juːl, но при этом писать шедул.
Вероятно, изменения таки были в этом слове в другую сторону (поищите «schedule etymology» и «cédule»), хотя да, описанное Вами нередко встречается (пример: выражение right soon).
Ну и да, на вкус и цвет все фломастеры разные :)
Ну и да, на вкус и цвет все фломастеры разные :)
Да, ещё. Есть замечательная книжка, Modern English Usage, вообще говоря, достаточно старая, хотя есть переиздания, «дополненные и исправленные». Там очень подробно рассматриваются всякие подобные вещи, в том числе в этимологией, рассказами, кто, когда и зачем у кого заимствовал и так далее. Очень сожалею, что не купил её полтора года назад в Book Cycle по смешной цене (например, за £1) — надо будет исправить сию оплошность, когда буду там в ближайшее время.
amirul, а что скажете о soluto.com?
Попробовал utorrent с предлагаемыми настройками.
Не знаю, как там с кешированием и приоритетами, а с отдачей стало заметно хуже, чем было по умолчанию.
Не знаю, как там с кешированием и приоритетами, а с отдачей стало заметно хуже, чем было по умолчанию.
utorrent 2.0.4
Насколько заметно? Помогает ли если вернуть все обратно?
Хмм. А вот таким образом через реестр можно для любых приложений настраивать работу с диском.
А то вчера распаковывал 18 гиговый архив 7zip'ом. Система на 20 минут стала недоступна для работы вообще.
А то вчера распаковывал 18 гиговый архив 7zip'ом. Система на 20 минут стала недоступна для работы вообще.
Не проверял.
Что там в реестре по умолчанию то было?
Что там в реестре по умолчанию то было?
По умолчанию там вообще ключа utorrent.exe не было
Кеш торрента 4put.ru/pictures/max/63/196281.jpg
Кеш винды по описанной методике 4put.ru/pictures/max/63/196282.jpg
К сожалению, времени и желания создавать идеальные условия не было — поэтому масштаб немножко разный.
Кеш винды по описанной методике 4put.ru/pictures/max/63/196282.jpg
К сожалению, времени и желания создавать идеальные условия не было — поэтому масштаб немножко разный.
Как по мне выглядят одинаково. Пики на 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 мегов идеи :(
есть такая прога Intellij IDEA
ей надо в среднем 550 мегов
отходишь от компа на 10 минут
возвращаешься и видишь в таск манагере что размер памяти процесса на 10 мегов меньше размера его виртуальной памяти: 540 и 550
активируешь окно IDEA, оно зависает — всё белое
и дальше в течении двух-трех минут видим как размер памяти растет
когда он выровняется с виртуальным: 550 и 550
то окошко IDEA оживёт и всё будет зашибись летать
на компе 2 гига памяти
памяти общей занято примерно 2 гига из двух
хотя после вашей статьи получается что эти цифры ни о чём
но тем не менне, пускай лучше фаерфоксовские 500 мегов свопятся чем 10 мегов идеи :(
Постоянно скачиваю и раздаю. Специально (ещё раз, дополнительно) протестировал работу utorrent'а (2.0.4, в последнем rc ещё есть досадные глюки) на разных настройках.
То, что вы написали про utorrent — галиматья.
При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше windows, постоянно идет чтение/запись с/на диск[а] . И наоборот, при включённом встроенном кеше значительно сокращается число чтении/записей с/на диск[а] , увеличилось число последовательных записей при скачивании.
A1lfeG выше # . Включение «их кеша» помогает снизить число обращений к диску, увеличивает число последовательных записей при загрузке. «Их кеш» всегда находится в RAM. У меня при скачивании при любых скоростях никогда не происходит «торможения системы». Что я делаю не так?
То, что вы написали про utorrent — галиматья.
При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше windows, постоянно идет чтение/запись с/на диск[а] . И наоборот, при включённом встроенном кеше значительно сокращается число чтении/записей с/на диск[а] , увеличилось число последовательных записей при скачивании.
A1lfeG выше # . Включение «их кеша» помогает снизить число обращений к диску, увеличивает число последовательных записей при загрузке. «Их кеш» всегда находится в RAM. У меня при скачивании при любых скоростях никогда не происходит «торможения системы». Что я делаю не так?
То, что вы написали про utorrent — галиматья.
Спасибо за информацию.
При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше windows, постоянно идет чтение/запись с/на диск[а] .
Как насчет методики тестирования? Понимаете, это идет в разрез как с моим пониманием работы кеша, так и с моими тестами.
Extraordinary claims require extraordinary evidence
Включение «их кеша» помогает снизить число обращений к диску, увеличивает число последовательных записей при загрузке.
Кеширование не имеет никакого отношения к последовательности читаемых данных.
«Их кеш» всегда находится в RAM
Не поверите, это как раз системный кеш ГАРАНТИРОВАННО находится в RAM. «Их» кеш может как находиться так и не находиться.
У меня при скачивании при любых скоростях никогда не происходит «торможения системы».
Рад за Вас. Может у Вас просто пропускная способность дисковой подсистемы гораздо выше, чем пропускная способность сети?
Спасибо за информацию.
При большой скорости скачивания/раздачи больших файлов и отключённом встроенном кеше и включённом кеше 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 читает разные блоки, а не одни и те же. При загрузке запись одних и тех же блоков происходит однократно и по возможности последовательно без фрагментации. Что здесь кешировать?
Конечно, при гигабитной сети, одном медленном диске и большой фрагментации, отключение встроенного кеша ничего не даст, скорее ухудшит ситуацию.
Пожалуйста, всегда рад помочь.
Может у Вас просто пропускная способность дисковой подсистемы гораздо выше, чем пропускная способность сети
Пропускная способность дисковой подсистемы обычно выше пропускной способности сети. У меня сеть: 4-5 мегабайт/с в мир, 12 мегабайт/с по провайдеру, 128 мегабайт/с локально; диски: 175 мегабайт/с с диска, 300 мегабайт/с с буфера (максимальные показатели).
Не поверите, это как раз системный кеш…
Ну, почему же, поверю. Но «их» кеш позволяет не переполнять системный кеш, которому и без этого есть чем заняться. Или он по объёму неограничен? Я выставил встроенный кеш в 512 мб. Очевидно если выставить объём встроенного кеша слишком большим, то будут проблемы, потому, что данные из/в кеш[а] читаются/пишутся постоянно (Как часто свопится память которая постоянно читается, если есть доступная свободная память). Цена этому большая загрузка процессора и больший объём требуемой память.
Кеширование не имеет никакого отношения к последовательности читаемых данных.
А я что-то писал про последовательное чтение, в каком месте? А вот последовательную запись при включённом встроенном кеше (и отключённом системном кеше при/на записи) utorrent может обеспечить. Лучше, конечно, если кроме него на данный диск больше никто не пишет.
Как насчет методики тестирования?
Журнал производительности (число чтений/записи, время чтений/записи, скорость чтений/записи, длина очереди чтений/записи и т.д.), скачивание всех сезонов доктора хауза (20000 сидов в том числе локальные, ~50Гбайт, 10 мегабайт/с), 4-ёх ядерник (3Ггц), hdd 4 шт (по 2 Гбайта) + 2 внешних, и 8 Гбайт оперативки (Всё хочу ещё 8 поставить, да никак не соберусь ;-)
Какой смысл в системном кеше, если при характере работы utorrent он не выполняет своих функций, т.е. кеширование. Ведь при раздаче utorrent читает разные блоки, а не одни и те же. При загрузке запись одних и тех же блоков происходит однократно и по возможности последовательно без фрагментации. Что здесь кешировать?
Конечно, при гигабитной сети, одном медленном диске и большой фрагментации, отключение встроенного кеша ничего не даст, скорее ухудшит ситуацию.
*
В последнем предложении конечно же "… включение встроенного кеша...".
И pagefile тоже мониторился.
В последнем предложении конечно же "… включение встроенного кеша...".
И 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 как никак.
Не соизволите развернуто пояснить одно из Ваших утверждений: либо о том, что кешировать нечего, либо о том, что кешировать надо, но ИСКЛЮЧИТЕЛЬНО собственным велосипедом.
Где то в районе «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 как никак.
Не соизволите развернуто пояснить одно из Ваших утверждений: либо о том, что кешировать нечего, либо о том, что кешировать надо, но ИСКЛЮЧИТЕЛЬНО собственным велосипедом.
Вопрос снят habrahabr.ru/blogs/windows7/107637/#comment_3402552
Попробую связаться с авторами
Попробую связаться с авторами
Очень интересная статья (все три части). Спасибо за нее!
Что касается uTorrent, я разделяю всеобщее волнение по этому поводу, так как это тот практический момент статьи, с которым сталкивается почти каждый.
В связи с этим, я хочу отметить, что Ваша компетенция во вопросах работы с памятью под вопрос не ставится. Но Вы сами признались, что торрентами не пользуетесь. Поэтому, ситуация, когда критика Вашего подхода к его настройкам оправдана, вполне может быть. Не имея времени и желания вдаваться в теорию, я просто настроил на одной машине его по Вашим рекомендациям, и оставил умолчания на другой машине. Их конфигурации похожи, но, к сожалению, не идентичны. Посмотрим что будет )
Что касается uTorrent, я разделяю всеобщее волнение по этому поводу, так как это тот практический момент статьи, с которым сталкивается почти каждый.
В связи с этим, я хочу отметить, что Ваша компетенция во вопросах работы с памятью под вопрос не ставится. Но Вы сами признались, что торрентами не пользуетесь. Поэтому, ситуация, когда критика Вашего подхода к его настройкам оправдана, вполне может быть. Не имея времени и желания вдаваться в теорию, я просто настроил на одной машине его по Вашим рекомендациям, и оставил умолчания на другой машине. Их конфигурации похожи, но, к сожалению, не идентичны. Посмотрим что будет )
Очень хорошо, что Вы решили не верить на слово и попробовать. Я всецело поддерживаю подобную практику и, более того, пытаюсь сам делать reality check на каждом выполняемом шаге (именно из-за этого в статьях довольно много скриншотов). С другой стороны я не доверяю оценкам «на глаз» — люди склонны давать оценки, которые больше согласуются с их внутренними убеждениями (идеально было бы сделать double blind trial, но в данном случае обычный скурпулезный сбор логов вполне достаточен).
Например, в случае конкретно мюторрента может присутствовать еще какая нибудь «оптимизация», включаемая вместе с включением системного кеша, но я сильно сомневаюсь.
Например, в случае конкретно мюторрента может присутствовать еще какая нибудь «оптимизация», включаемая вместе с включением системного кеша, но я сильно сомневаюсь.
Ну вообщем, результат тестирования оказался странен. После трех часов работы мюторрента компьютер «с твиками» стал очень не отзывчив, а окно мюторрента периодически становилось «не отвечающим». К сожалению, пока я не убил мюторрент, посмотреть любую системную информацию было не возможно. Так что реальной информации, кроме тестов «на глаз» у меня нет. Возможно дело и не в твиках было.
Вообще говоря, это безобразие. Безобразие сплошное, а не статья.
Причем такое уже было со мной во времена (по-моему) NT, когда я впервые наткнулся на утилиты Руссиновича.
Вдруг стало понятно, что система (Windows) развивается не только в сторону «разноцветных финтифлюшек» и раздувания многогигобайтных .Net.
Я опять зауважал Windows!
Причем такое уже было со мной во времена (по-моему) NT, когда я впервые наткнулся на утилиты Руссиновича.
Вдруг стало понятно, что система (Windows) развивается не только в сторону «разноцветных финтифлюшек» и раздувания многогигобайтных .Net.
Я опять зауважал Windows!
Спасибо за статью, но по поводу рекомендаций для uTorrent присоединюсь к критике.
После отключения кеша появляется треск и возрастает количество обращений к диску:
После включения кеша треск прекращается и обращения к диску происходят заметно реже:
За разницу в масштабе больно не бейте, оригинальные файлы профайлера прилагаются:
narod.ru/disk/27201087000/utorrent_etl.rar.html
После отключения кеша появляется треск и возрастает количество обращений к диску:
После включения кеша треск прекращается и обращения к диску происходят заметно реже:
За разницу в масштабе больно не бейте, оригинальные файлы профайлера прилагаются:
narod.ru/disk/27201087000/utorrent_etl.rar.html
Спасибо за тест. Можно спросить, о каком из кешей идет речь?
И еще один вопрос. На обоих графиках практически весь доступ диска показан красным (это приоритет >= 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 раз большее количество перепозиционирований головки
Проблема в том, что uTorrent в режиме системного кеша читает блоками по 12 кб в среднем, а в режиме собственного кеша — блоками по 130 кб в среднем. Отсюда в 10 раз большее количество перепозиционирований головки
Не могли бы Вы провести еще один эксперимент?
Удалите IoPriority — оставьте только PagePriority. Я не уверен, может быть система разбивает низкоприоритетеный ввод/вывод на более мелкие части.
Заранее спасибо
Удалите IoPriority — оставьте только 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 такие вещи, включая таскбар и таскменеджер были более отзывчивыми.
Очень интересует, почему при выполнении сильного свопа перестают работать кнопки на таскбаре (супербаре), невозможно вызвать контекстное меню программ (чтобы закрыть их), невозможно вызвать контекстное меню таскбара, чтобы запустить таск-менеджер, невозможно запустить таск-менеджер по 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 гигабайта памяти. такие пироги.
включение кеша винды примерно через 2 часа загадило всю оперативку и замедлило систему до безобразия. выключение кеша винды освободило примерно 3 гигабайта памяти. такие пироги.
Это странно. Для прояснения ситуации, не могли бы Вы ответить на несколько вопросов.
Не подскажете, что в данном случае означает «загадило всю оперативку»? Проверьте пожалуйста Page Priority потоков utorrent.
В какой момент произошло «освобождение памяти». Проверьте при помощи RamMap, какие файлы и на каком уровне приоритета закешированы. Кроме того, для полноты картины, проверьте распределение кеша по приоритетам.
Спасибо
Не подскажете, что в данном случае означает «загадило всю оперативку»? Проверьте пожалуйста Page Priority потоков utorrent.
В какой момент произошло «освобождение памяти». Проверьте при помощи RamMap, какие файлы и на каком уровне приоритета закешированы. Кроме того, для полноты картины, проверьте распределение кеша по приоритетам.
Спасибо
«загадило всю оперативку» — использование памяти на ~98% при практически чистой системе (фубар, миранда, скайп, мюторрент). без кеша винды моя система в таких условиях использовала от силы 30% памяти. очищение памяти произошло либо после того, как я отключил кеш винды, либо после перезапуска мюторрента (контрольный выстрел), сейчас не вспомню. кстати, использование памяти после этого упало до 16%, что на мой неискушенный взгляд говорит о том, что мюторрент вытеснил из оперативной памяти чуть ли не половину системы. да, вся информация почерпнута из вкладки performance пресловутого task manager'а и моих наблюдений за отзывчивостью системы.
да, забыл главное — никаких правок в реестр я не вносил. вполне возможно, с ними всё было бы гораздо иначе, но у меня уже пропало желание чинить то, что не сломано.
да, забыл главное — никаких правок в реестр я не вносил. вполне возможно, с ними всё было бы гораздо иначе, но у меня уже пропало желание чинить то, что не сломано.
да, забыл главное — никаких правок в реестр я не вносил. вполне возможно, с ними всё было бы гораздо иначе, но у меня уже пропало желание чинить то, что не сломано.
Хм, в этом была ВСЯ СУТЬ. Использовать кеш с низким приоритетом, чтоб не вытеснять всю систему. О том, что без изменений мюторрент ведет к cache thrashing-у давно известно. Именно это привело к авторы мюторрента стали реализовывать собственное кеширование — здесь я предложил (более правильное на мой взгляд) решение этой проблемы. Решение пока не полное из-за разного паттерна чтения для случаев использования собственного и системного кешей, но я попробую уговорить разработчиков сменить такое поведение.
Хм, в этом была ВСЯ СУТЬ. Использовать кеш с низким приоритетом, чтоб не вытеснять всю систему. О том, что без изменений мюторрент ведет к cache thrashing-у давно известно. Именно это привело к авторы мюторрента стали реализовывать собственное кеширование — здесь я предложил (более правильное на мой взгляд) решение этой проблемы. Решение пока не полное из-за разного паттерна чтения для случаев использования собственного и системного кешей, но я попробую уговорить разработчиков сменить такое поведение.
Одобряю.
До какой версии uTorrent актуален этот хак?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Here be dragons: Управление памятью в Windows как оно есть [3/3]