Настройка кэширования и другие способы уменьшения нагрузки на HDD

[dixen18 7]

Торренты, винты, кэширование

Жалуясь на винт не забывайте указывать модель, режим контроллера - SATA или IDE (эмуляция). BIOS, диспетчер устройств, Everest, Victoria 4, HDDScan, HD Tune и куча других прог под виндой для жёстких дисков помогут с этим и многим другим.

ОС тоже стоит упоминать.

Микрофак

0. Чётко различайте кэш Windows (всегда в ОЗУ), собственный кэш клиента (нормально в ОЗУ), кэш/буфер диска (в ОЗУ диска).

1. Windows-кэширование для клиента (только для него, не другим программам) отключает нижняя пара галок настроек кэширования.

2. В норме (анормальная ситуация вытеснения в своп приведена ниже) собственный кэш клиента находится в памяти (ОЗУ). Об этом же обычно написано в первых строках вкладки Кэширование/Disk Cache настроек клиента.

3. Буфер диска неотключаем, хотя дисковыми программами можно отключить такие фичи как Read look-ahead (линейная скорость упадёт раз в 8), Write cache. Настройки клиента и Windows к нему никак не относятся.

На первый взгляд оффтоп, однако причины и меры пересекаются, так что не пропускайте.

Что-то пожирает оперативную память (ОЗУ), при выключении торрент-клиента память освобождается

Открыть текст

В большей степени характерно для Win7.

Далее по форме "виновник - решение".

1. Windows-кэширование для клиента

- Отключение Windows-кэширования полностью (поставить нижнюю пару галок в настройках кэширования).

2. Собственный кэш клиента (видно потребление у процесса utorrent*.exe в диспетчере задач и рост заполнения собственного кэша в "Статистике диска" на вкладке "Скорость" клиента)

- Установка фиксированного размера собственного кэша клиента. Размер обсуждается в тексте.

- Если фиксированный размер задан, но не спасает, пробуйте снять соседнюю галку "Уменьшать использование памяти кэшем" (она может подглючивать).

- Поиграйте нижеупомянутыми параметрами из Настроек - Дополнительно.

http://rutracker.org/forum/viewtopic.php?p...5#24649665[Клац

- См.пункт 5. Не вина собственного кэша, но его неудержимый рост налицо.

- (ut2.1) bt.prioritize_partial_pieces = false ->*true (осенило, проверяйте - должно способствовать).

- Отдельная независимая возможность ограничить хаотичность скачивания блоков, сократить число незавершённых частей в собственном кэше (к сожалению, и завершённые части могут зависнуть в кэше): 22) Как заставить utorrent скачивать части последовательно (для online просмотра). bt.sequential_files будет помягче, чем bt.sequential_download.

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

- См.пункт 6. Небесспорные, но тоже возможности.

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

3. Настройки кэширования действительны только для того ПК, на котором запущен клиент.

Пример. Конфигурация с µT на ПК1 и раздачами на ПК2. Жалоба на заполнение ОЗУ ПК2 под завязку системным кэшем.

Второй винде, на которой лежат раздачи, неизвестно и безразлично отключение Windows-кэширования в клиенте, находящемся на первом ПК. Вот на этом первом и отключится Windows-кэширование для µT. А вторая винда будет мужественно кэшировать любые чтения, пока её не ограничат в этом. Поищите твики реестра.

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

~ Закачки на внешнем диске Клац

~ Сетевой диск Клац

4. Несовместимое ПО - категория условная, в новых версиях могут устранить принципиальную несовместимость, в старых - найти решение.

См. Справка - Справка/Мануал - Incompatibilities или по-русски Клац

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

Неслабо может выступить Spider Guard Доктора Веба - и процессор с памятью загрузит, и uTorrent с Проводником подвесит... GuardMailRu (служба и процесс).

- Отключить, не поможет - деинсталлировать.

4+. Плохо настроенное ПО примыкает к несовместимому по диверсионным способностям.

Брандмауэр AVAST'а (находится в списке нерекомендованных) при быстром скачивании может грузить память до 100% и процессор, даже мышь притормозить.

Настройка AVAST. Ниже настройка Comodo Firewall Pro.

- Собственно, любой антивир/брандмауэр может гастролировать при неудачных настройках, поэтому проштудируйте тему Описание настроек различных Firewall(ов)/Antivirus(ов) для работы с P2P.

- Не- и рекомендованные антивиры/файрволы, а также многое другое см.в теме Как защитить Ваш компьютер.

5. Сжатие (вероятно и шифрование) раздач, папок/разделов/дисков, их содержащих. А что вы хотели? - для расжатия приходится считывать с диска много больше (если не весь файл) реально запрошенного для передачи.

- Уберите сжатие для файлов раздачи в Свойствах - Дополнительно файлов (>16...64КБайт) раздач, папок/разделов/дисков, их содержащих, убрав галку с "Сжимать содержимое для экономии места на диске". Для явного отображения сжатых цветом в Проводнике выполнить Сервис - Свойства папки... - на вкладке "Вид" отметить галкой "Отображать сжатые или зашифрованные файлы NTFS другим цветом", нажать "Применить ко всем папкам".

6. Понижение всевозможных приоритетов для процесса uTorrent.exe:

а) В частности, импортировать в реестр следующий файл, т.е. скопировать нижеследующее в текстовый файл, заменить расширение .txt на .REG и запустить полученный файл (для отображения расширений файлов необходимо снять галку "Скрывать расширения для зарегистрированных типов файлов" в Панели управления - Свойства папки - Вид).

;--------- для Vista, Win7 текст для копирования ниже -------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utorrent.exe\PerfOptions]

"IoPriority"=dword:00000000

"PagePriority"=dword:00000001

;--------- текст для копирования выше ----------------------------------

б) Далее можно попробовать заменить собственное кэширование на виндовое, сняв все (можно только основные) или только для чтения галки на вкладке "Кэширование". Более-менее оправдано для Висты-Семёрки, т.к. кэширование там организовано эффективнее, чем в XP, а проблема встречается чаще. Всё ж есть данные, что при отключении собственного кэша появляется треск и возрастает количество обращений к диску.

Идеи пункта взяты из тут , с приоритетами по раздельности и вместе действительно стоит поиграть (в случае XP кто-то уже пробовал без заметного успеха, но вроде цель всё же была совсем иная...). Следует учитывать, однако, что автор статьи по ссылке не пользуется торрентами и на момент написания не осознал в полной мере их специфики, а именно: повторных запросов из кэша практически нет, кэширование необходимо лишь для организации более-менее последовательного фрагментарного чтения/записи с/на диск[а].

7. Особенности версий (худо-бедно меняются) или билдов (случаются эксперименты и баги)

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

Замечу, вместо переустановки обычно достаточно заменить исполняемый файл µT на скачанный с официального сайта. Иногда следует перепроверить настройки, особенно дополнительные (в частности, bt.transp_disposition по разному кодируется для версий 1.8.1-1.8.2 и последующих), кому-то проще снести settings.* в папке настроек %APPDATA%/uTorrent (если вы не переносили в папку приложения) и настроить всё с нуля.

Потакая ленивым любителям готового, продолжаю потихоньку дописывать "готовое" в начало (и не только), заодно пытаюсь правильно расставить акценты.

Чем мы грузим диски. Почему возникает сообщение, соответствует ли оно реальной перегрузке

Открыть текст

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

Хорошо бы знать, что заставляет клиент выдавать сообщение о перегрузке. Сразу приходит на ум некий таймаут операций ввода-вывода. В мануалах и FAQ'ах постоянно упоминается, что сообщение о перегрузке не соответствует реальности при старте закачки, когда создаются/зануляются файлы-пустышки. Намёк на таймаут.

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

Поясняющий пример:

Вообще, организовать максимально быстрое случайное чтение торрентами легко. Например 70iops x 16Кбайт ~ 1МБайт/с. Т.е. с тарифом 8mbps и полностью отключенным в uTorrent кэшированием уже получается, с каналом >70mbps и включенным собственным кэшированием клиента тоже (хотя неслабый канал и одновременно полная его загрузка уже не выглядят типичными): 70iops x 128Кбайт ~ 9МБайт/с.

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

Полное отключение кэширования записи уже не столь критично: хотя блоки 16КБайт практически перестанут (если только в settings.dat не включено последовательное скачивание частей) объединяться в клиенте (см.статистику диска), но всё же винт [контроллер, драйвер] кэширует и объединяет (только смежные блоки) перед записью на поверхность.

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

Какими бы искусственными приведенные нагрузки не выглядели, обратите внимание, как недалеки безобидные торренты от нагрузок, вызвавших обсуждение [это о тестировании по хоботовскому FAQ п.15], ну и не забудьте про соотношение длительностей этих нагрузок. Понятно, всякие зелёные (малооборотистые) и/или тихие (с мин.ААМ, соответственно макс.временем доступа) нагрузить под завязку ещё проще...

Любопытна дискуссия на пару страниц о допустимости и степени нагрузки при тестировании новых дисков по методу FAQ п.15, а также при раздаче-закачке торрентов и по DC++.

Вот мы и приходим к простой мысли, что реальную нагрузку стоит описывать (соответственно, контролировать) объёмом ввода/вывода (записи/чтения) и характером (размер блока, темп позиционирований), а не наличием/отсутствием сообщения клиента. Инструменты контроля в разнообразии предоставляет ОС, сторонние проги (статистика HAB, например) и сам клиент.

Новые сигейты и в смарте кое-что сообщают (начало, ниже примеры). Статистика винта на примере ST31500341AS

Заглянув в Диспетчер задач и включив показ столбцов прочитанных/записанных байт, вы можете обнаружить там процесс jqs.exe Это Java Quick Starter, попадает на ПК с Java-машиной jre 6, фигурирующей в аплете ПУ "Установка и удаление программ" как Java 6 Update 23 (текущая версия, возможны и предыдущие). На двух разных ПК с WinXPsp3, что я проверил, этот процесс читает ~1 ГБайт/час (25 ГБайт/сутки) с системного раздела, на порядок больше антивира - сравните с uTorrent! Постоянство объясняется просто: jqs перечитывает основные библиотеки jre, чтоб снова вернуть их в виндовый кэш (находится в ОЗУ), как только винда выбрасывает их оттуда.

Раз уж есть повод для отключения jqs, найдётся и способ.

Много меньше, но всё ещё немало мучают винт антивиры и svchost (который от имени System), что обслуживает пару десятков служб, запуск большей части которых стоит перевести в режим 'Отключено' или 'Вручную'.

Из отзыва на WD15EARS с Advanced Format (AF):

При копировании с одного жесткого диска на другой 1 Тб мелких файлов без отключения индексирования и записи даты обращения к файлу, скорость падала до 10 Мб/сек, после отключения - стабильные 80 Мб/сек.

А вот появился и местный пример удачного отключения индексирования, а ведь начиналось с безапелляционного заявления: "перепробовал все до одного решения, указанные в шапке". Будьте и вы внимательней, чтобы не тратить своё время на открытие (или мучительное осознание) давно известного)))

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

Кроме индексирования упомяну восстановление системы. Не раз замечал, что оно упорно отслеживает регулярные изменения .dat-файлов uT, возможно и за записью очередного куска закачки приглядывает - лишняя нагрузка.

Фоновая дефрагментация и оптимизация тоже под подозрением.

Перегрузка диска при скачивании (сюда подтянутся рекомендации)

Открыть текст

При скачивании сообщение о перегрузке диска соответствует переполнение собственного кэша, поэтому смотрите п.2 1-го спойлера.

- Галка Pre-allocate all files /Размещать все файлы сразу в Настройках - Общие и diskio.no_zero = true (подробности, особенности и глюки см.в п.2. Другие настройки клиента.).

- (ut2.1) bt.prioritize_partial_pieces = false ->*true (осенило, проверяйте - должно способствовать).

Стоит поиграть с:

diskio.flush_files

(ut2.2.1) diskio.max_write_que

1. Настройка кэширования и другие способы уменьшения нагрузки на винт.

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

Открыть текст

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

Здесь направления борьбы, а не синяя пилюля.

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

Оптимально держать закачки/раздачи не на том же жёстком диске, где стоит работающая ОС. Аналогичное можно сказать и о файле подкачки, с другой стороны последний может усугубить перегрузку диска с закачками, если будет на нём. Встречаются случаи, когда при быстром скачивании/раздаче стремительно заполняется ОЗУ (чаще из-за Windows-кэширования, но и собственный кэш µTorrent'а может разрастаться, если не фиксирован), что заставляет ОС сбрасывать "лишнее" из ОЗУ в файл подкачки. Пример. Если файл подкачки будет на том же диске, что и закачки, даже система может тормозить, не говоря уже о скачивании. Вот почему Windows-кэширование записи в µTorrent'е по умолчанию выключено. В упомянутых случаях важно ограничить рост потребления памяти, отключив Windows-кэширование чтения и/или зафиксировав кэш клиента.

Размер собственного кэша µT

Немного уточню выбор размера фиксированного кэша.

Оценка минимально необходимого размера кэша чтения

Открыть текст

Периодически понаблюдайте за максимальным числом активных отдач, нажав на левой панели 4-ю кнопку показа активных торрентов. Получите оценку достаточного фиксированного размера кэша чтения, умножив это число на 5-10 МБайт (столько достаточно каждому потоку для извлечения пользы от read-ahead винта - спасибо nazyura). Минимум выделения кэша на каждую приличную раздачу проистекает из наличия внутреннего кэша диска и обязательного избыточного чтения диском в собственный кэш (современные считывают за раз по несколько дорожек). Разумно было бы перекинуть содержимое дискового кэша в кэш клиента. Больше кэш винта, больше можно выделить на каждую кэшируемую раздачу.

Оценка максимально достижимого заполнения кэша чтения

Открыть текст

При отдаче µT кэширует на 100 секунд среднепиковой (за какое-то время, вероятно тоже 100 секунд) скорости отдачи (с сохранением содержимого какое-то время при падении скорости). Так что умножив вашу максимальную скорость отдачи на 100сек, получите максимально возможную загрузку собственного кэша чтения и максимальный из вменяемых размер кэша чтения. Больше для чтения не понадобится.

Например, 128МБ кэша достаточно для отдачи 1.28Мбайт/с (полосы 10Mбит).

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

До недавнего времени с кэшированием записи проблем вроде бы не было, ныне но что-то неладно у µT с Win7. Хотя нижеследующее в какой-то степени касается и записи, рекомендую первый спойлер в случае с проблемами кэширования при скачивании.

Дефрагментаторы и десятки свободных гигабайт не всегда гарантируют от фрагментации раздач

Открыть текст

Периодическая дефрагментация дисков тоже не мешает. Владельцы объёмистых дисков, глядя на десятки свободных гигабайт, не задумываются, что диск, заполненный более чем на 88% (свободных 12%, столько же изначально зарезервировано под рост MFT), дефрагментировать толком не получается - API дефрагментации не может перемещать данные в MFT зону, свободного места для маневра просто нет. Так что избавиться от перегрузки диска в таком случае можно, освободив >15% объёма - столько же обычно требуют (должны, ибо используют виндовые API) дефрагментаторы. Стоит добавить к 15% ещё несколько гигабайт - закачки сплошь немалые. Не особо надейтесь на сниженные требования свободного места некоторых дефрагментаторов, мелкие файлы они смогут осилить, для нормальных раздач понадобится дополнительное свободное место порядка размера наибольшего файла раздела.

Галка Pre-allocate all files /Размещать все файлы сразу в Настройках - Общие тоже борется с фрагментацией при нескольких параллельных закачках.

NCQ не особый помощник для µT, AHCI тоже под вопросом

Открыть текст

Хотя линейные скорости чтения/записи диска на первый взгляд заметно больше сетевых, излишне беспорядочное перемещение головок может сильно испортить реальные скорости. Поэтому в случае многозадачности (проги помимо клиента, активно использующие диск, да и просто некстати свопящая винда) делу теоретически может помочь NCQ (требует переключения контроллера жёстких дисков из режима эмуляции (совместимости с) IDE для SATA-устройств в нативный SATA), но чаще вредит (и NCQ, и AHCI). Ускорение в нативном режиме (проверялось что угодно, кроме торрентов) замечалось почему-то на отдельных, не встроенных контроллерах (?) и далеко не для всех HDD, да и выигрыш невелик при включенном кэшировании. А имитация многопоточного чтения несколькими экземплярами HD_Speed недвусмысленно намекает, что многие диски лучше ворочают торренты в режиме эмуляции IDE (PATA).

Мда, неотключаемый AHCI у некоторых ноутбуков может даже заставить ограничиться одной активной раздачей!

Следует отметить, запросы µT к диску сами по себе не образуют очередь, в каждый момент выполняется не более одного.

http://forum.utorrent.com/viewtopic.php?pid=443838#p443838

Поэтому NCQ может помочь лишь косвенно, переупорядочивая единственный текущий запрос µT вкупе с чужими запросами. Стоит самостоятельно проверить (и поделиться результатами) всем любителям загружать винты параллельными приложениями.

Кстати, NCQ отдыхает с USB Removable, USB-контроллеры NCQ не поддерживают.

Использование для торрентов винтов раздельно (россыпью) меньше нагружает последних, чем в RAID'е (есть и такие экспериментаторы). Прикидки по этому поводу.

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

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

Резонно для небольшого числа подключенных личеров на торрент, но иногда их бывает сотни.

пример

Открыть текст

А вот для нескольких копий клиента Windows-кэширования чтения с диска точно не помешает, т.к. один и тот же торрент (даже одному и тому же пиру; BitComet, например, любит цепляться сразу ко всем копиям) может раздаваться разными копиями, так зачем считывать с диска одно и тоже?

Необходимость собственного кэширования клиента

Открыть текст

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

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

Эффективность собственного кэширования чтения

Открыть текст

Эффективность собственного кэширования чтения (и ваших настроек его) можно выяснить сопоставлением прочитанного "Из файла" в статистике диска на вкладке "Скорость" с отданным в статусной строке при условии net.calc_overhead = false (всё равно отданное останется чуть завышенным).

+ Если снять галку с "Отключать кэширование чтения при малых скоростях отдачи", можно сравнивать объёмы считанного "Из файла" и "Из кэша", со снятой галкой отосланное совпадает с прочитанным из кэша. Будет точнее, только это уже будет режим постоянно включенного кэширования, чья эффективность, по идее, ниже.

Не забывайте про удобную кнопку сброса статистики диска.

Дополнения/уточнения - с.6 тут

О дисках (пример: что можно подстроить по результатам тестирования несколькими копиями HD_Speed)

Открыть текст

Статейка

Если для приложения включено Windows-кэширование, тогда актуальными для него становятся результаты тестирования с блоком 64КБайт.

Если выключено, актуальны блоки 16 и 128 КБайт. uTorrent в этом случае читает в свой кэш блоками 128КБайт, а мимо своего кэша (и из кэша тоже) - блоками 16КБайт. Чтение мимо кэша будет при отключенном собственном кэше чтения или при скорости отдачи <40КБайт/с (опция "Отключать кэширование при низкой скорости отдачи").

Поведение HDD зависит от хост-контроллера материнской платы и его режима, драйвера, прошивки (firmware) жёсткого диска. Обычно прошивки корректируются под конкретные модели, не меняя общего поведения, поэтому характерное поведение винта определяется производителем в значительно большей степени, чем, например, семейством. Для этой темы поведение винта и поведение прошивки - одно и то же. Заметные положительные изменения поведения замечены у дисков Hitachi в цепочке прошивок 28A - 39C (последняя с разблокированным AAM, с последующими небесшумный позиционер Хитачи утихомирить сложнее) - 3EA - 3MA (в пределах 3хх можно и апгрейдить, и даунгрейдить), незначительные - у Самсунгов.

В конце 2010 появился трёхблинный WD20EARS-00MVWB0, Firmware: 51.0AB51 с весьма достойной многопоточностью у выровненного. Разумеется, дело в новой прошивке. У WD5000AAKX тоже очень неплохо с многопоточным чтением. К сожалению, у WD10EALX обычная старая убогая "норма". Плюс возможные глюки с новым интерфейсом.

Самсунги при потоках >4 лучше читают блоками 16КБайт, блоками 128КБайт похуже, ещё хуже - блоками 64КБайт.

При потоках <4 рост скорости многопоточного чтения с размером блока заметен слабо.

Следовательно, в uTorrent для самсунгов F1-F3 желательно включать упомянутую опцию, отключать кэширование чтения виндой и даже собственное кэширование чтения.

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

Семейство SpinPoint F3. HD502HJ (контроллер Intel ICH9R, режим IDE), рекомендации.

wd1001fals многопоточно читает блоками 16КБайт на порядок лучше, чем 64КБайт. Что ж, вестерну в uT абсолютно противопоказано виндовое кэширование чтения (нужна нижняя галка в Настройках - Кэширования).

WD1001FALS (контроллер Intel ICH9R, режим IDE), рекомендации.

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

hitachi 7k1000.b (hdt721010sla360) блоками 64КБайт многопоточно читает чуть получше вестерна и сколько-то лучше себя (цифр нет), но блоками 16КБайт. Как знать, может кэширование виндой ему не повредит, если с блоком 128КБайт будет плохо.

Обратите внимание на пункт 5 первого спойлера о памяти, в равной степени он касается перегрузки диска.

2. Другие настройки клиента.

Текст о Размещать все файлы сразу /Распределять место сразу /Pre-allocate all files (размещение файлов закачки до начала скачивания, выделение им места - не более; см.эту опцию по пути Настройки -> Общие) и diskio.no_zero (опция из Настроек -> Дополнительно, позволяющая отключить заполнение нулями созданных файлов) приходится вытаскивать из продолжающего поста, где он мирно покоился, пока связка uT2&Win7 не воплотили в жизнь пожелание о перегрузке диска при закачке самым неприятным образом - watch your wishes)))

Кстати, в uT2.2 присутствует глюк с неработающим выбором diskio.no_zero: нули прописываются в создающиеся файлы независимо от его значения, винт хорошо нагружается этим процессом, раздачи поэтому приостанавливаются (начало обсуждения длиной в страничку).

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

Сообщение о перегрузке диска сразу после добавления торрента длится по понятным причинам ограниченное время (пока созданные для закачки файлы-пустышки заполняется нулями, зато случайно не всплывёт в недокачанном детском мультике свежестёртое порно) и не соответствует реальной перегрузке. В каждом FAQ'е и мануале об этом пишется 3-4 раза. Там же обещают подправить именно эту ситуацию в скором времени (только всё никак, если не считать решением diskio.no_zero = true по умолчанию начиная с 1.8.3).

Без админских прав для отмены заполнения нулями хватает разрешения на обслуживание томов / Perform volume maintenance tasks в групповых политиках. Для

Vista, Win7 с учётом умолчального diskio.no_zero = true достаточно отключения UAC или тех же админских прав.

Получение для пользователя (без админских прав) права на обслуживание томов / Perform volume maintenance tasks

Открыть текст

а. Пуск - Выполнить secpol.msc - Локальные политики - Назначения прав пользователя (выделить)

или

Панель управления - Администрирование - Локальная политика безопасности - Локальные политики - Назначения прав пользователя

или

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

б. Двойной щелчок по политике

Выполнение задач по обслуживанию томов (Win7),

она же Запуск операций по обслуживанию тома (winXP),

она же Perform volume maintenance tasks.

в. Добавить своего пользователя, после перезагрузки изменения сработают.

Проверка на прописывание нулей

Открыть текст

Создаём бестрекерный (чтоб скачивание не испортило картину) торрент-файл для любого большого файла (>10-100МБайт).

Добавляем торрент в список клиента. Далее можно просмотреть созданный файл-пустышку WinHex'ом на предмет ненулевых байтов.

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

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

Кстати, передёргивание Pre-allocate all files остаётся пока единственной мерой борьбы с ошибочным отказом µT писать большие файлы на NTFS-разделы (случается и такое - см.пример), если не считать совсем уж странных.

Огорчу владельцев (вполне современных) дисков WD и Hitachi, суммарная скорость многопоточного чтения несколькими экземплярами HD_Speed ограничена несколькими МБайт/с, при числе потоков более 4-х к ним присоединяются самсунги.

[Подробнее об эффективности управления многопоточным чтением у разных hdd.]

Так что поправьте невменяемые числа слотов отдачи (их скорее стоит уменьшать при превышении других рекомендаций; ко всему прочему формально на каждый слот отдачи всякого активного торрента должно приходиться не менее 1КБайт/с канала отдачи) и активных торрентов поближе к рекомендуемым Оптимизатором (Мастером) скорости. Кстати, µT считает активными те, чьи скорости превышают пороги queue.slow_dl_threshold или queue.slow_ul_threshold (1000Байт/с по умолчанию), заданные в Настройках - Дополнительно, - именно такие ограничиваем в настройках, в то время как для трекера активные те, что периодически посылают отчёты, в частности о том, что запущены.

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

Если перечисленное случается при небольших скоростях обмена, стоит убедиться, что контроллер диска работает в соответствующем режиме, а не PIO, MWDMA или UDMA Mode 0-4 к примеру. Для PATA-дисков или SATA с включенным в BIOS'е режиме эмуляции (Legacy, Compatible) см.диспетчер устройств - IDE ATA/ATAPI контроллеры - загляните в свойства каждого канала - Дополнительные параметры, смотрите Текущий режим передачи. Для винтов PATA можно в EVEREST'е: Хранение данных - ATA, там смотрите Активный режим. Также можно посмотреть в HDDScan (достойная программа для HDD/SSD под Windows), далее Identity Info - DMA/PIO Support, какой режим помечен как Selected.

Источник