Загрузка...
Ошибка

Ошибка: HDD перегружен (Торренты и винты)

Ответить на тему

Jeune

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

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


Хотите подсказки вроде тех, что на картинках, воспользуйтесь переводом из подписи*.
Предложены направления борьбы, а не синяя пилюля.
Предполагается минимальное осмысление написанного, а не банальное копирование чисел и галок (представьте, что они стоят на картинке в случайном порядке).
Оптимально держать закачки/раздачи не на том же жёстком диске, где стоит работающая ОС. Аналогичное можно сказать и о файле подкачки, с другой стороны последний может усугубить перегрузку диска с закачками, если будет на нём. Встречаются случаи, когда при быстром скачивании/раздаче стремительно заполняется ОЗУ (чаще из-за Windows-кэширования, но и собственный кэш µTorrent'а может разрастаться, если не фиксирован), что заставляет ОС сбрасывать "лишнее" из ОЗУ в файл подкачки. Если файл подкачки будет на том же диске, что и закачки, даже система может тормозить, не говоря уже о скачивании. Вот почему Windows-кэширование записи в µTorrent'е по умолчанию выключено. В упомянутых случаях важно ограничить рост потребления памяти, отключив Windows-кэширование чтения и/или зафиксировав кэш клиента.
Немного уточню выбор размера фиксированного кэша. Периодически понаблюдайте за максимальным числом активных отдач, нажав на левой панели 4-ю кнопку показа активных торрентов. Получите оценку достаточного фиксированного размера кэша чтения, умножив это число на 5-10 МБайт (столько достаточно для каждого потока, для извлечения пользы от read-ahead винта - спасибо nazyura). Минимум выделения кэша на каждую приличную раздачу проистекает из наличия внутреннего кэша диска и обязательного избыточного чтения диском в собственный кэш (современные считывают за раз по несколько дорожек). Разумно было бы перекинуть содержимое дискового кэша в кэш клиента. Больше кэш винта, больше можно выделить на каждую кэшируемую раздачу.
При отдаче µT кэширует на 100 секунд среднепиковой (за какое-то время, вероятно тоже 100 секунд) скорости отдачи. Так что умножив вашу максимальную скорость отдачи на 100сек, получите максимально возможную загрузку собственного кэша чтения и максимальный из вменяемых размер кэша чтения. Больше для чтения не понадобится.
Посматривая на эти оценки, выбираем разумное значение, одинаковое для собственных кэшей чтения и записи. Уточняем размер, наблюдая в статистике диска на вкладке "Скорость" за заполнением обоих кэшей. Можно уменьшить фиксированный размер, если в пике кэши далеки от полного заполнения, увеличить - если близки.
Периодическая дефрагментация дисков тоже не мешает. Владельцы объёмистых дисков, глядя на десятки свободных гигабайт, не задумываются, что диск, заполненный более чем на 88% (свободных 12%, столько же изначально зарезервировано под рост MFT), дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону, свободного места для маневра просто нет. Так что избавиться от перегрузки диска в таком случае можно, освободив >15% объёма - столько же обычно требуют (должны, ибо используют виндовые API) дефрагментаторы. Стоит добавить к 15% ещё несколько гигабайт - закачки сплошь немалые.
Хотя линейные скорости чтения/записи диска на первый взгляд заметно больше сетевых, излишне беспорядочное перемещение головок может сильно испортить реальные скорости. Поэтому в случае многозадачности (проги помимо клиента, активно использующие диск, да и просто некстати свопящая винда) делу теоретически может помочь NCQ (требует переключения контроллера жёстких дисков из режима эмуляции (совместимости с) IDE для SATA-устройств в нативный SATA), но чаще вредит (и NCQ, и AHCI). Ускорение в нативном режиме (проверялось что угодно, кроме торрентов) замечалось почему-то на отдельных, не встроенных контроллерах (?) и далеко не для всех HDD, да и выигрыш невелик при включенном кэшировании. А имитация многопоточного чтения несколькими экземплярами HD_Speed недвусмысленно намекает, что многие диски лучше ворочают торренты в режиме эмуляции IDE (PATA).
Мда, неотключаемый AHCI у некоторых ноутбуков может даже заставить ограничиться одной активной раздачей!.
Отключение Windows-кэширования чтения с диска радикально снижает потребление ресурсов (памяти и процессорного времени) при высокоскоростной отдаче (упоминаю сразу, чтоб не прошло мимо вашего внимания).
раздаваемые p2p клиентом файлы, не имеет смысла кешировать, необходимость повторного обращения к тому или иному блоку за разумное время его пребывания в кеше весьма маловероятно. их нужно только упреждающе крупноблочно читать. в рамках nt5 - их нужно читать с запретом кеширования ОС, благодаря чему та, в большинстве случаев, не будет разбивать запрос на мелкие, и соответственно возлагать ответственность на реализацию многопоточности на накопитель.
Резонно для небольшого числа подключенных личеров на торрент, но иногда их бывает сотни и тысячи.

пример

А вот для нескольких копий клиента Windows-кэширования чтения с диска точно не помешает, т.к. один и тот же торрент (даже одному и тому же пиру; BitComet, например, любит цепляться ко всем) может раздаваться разными копиями, так зачем считывать с диска одно и тоже?
Необходимость собственное кэширование клиента
Жёсткие диски и сами кэшируют, но не всегда хорошо - см. Скорость HDD при многопоточном чтении. Так что не помешает собственное кэширование, которое поболее виндового знает о торрентах. Хотя и здесь не стоит ожидать, что считанное из кэша в разы превысит считанное с диска, зато собственное кэширование может обеспечить чтение с диска бОльшими порциями, чем поддержать сдающий диск. Только оно и не даёт дискам со слабым многопоточным чтением свалиться в режим случайного доступа.
С учётом иных целей можно даже мириться с каким-то превышением считанного с диска над отосланным.
Эффективность собственного кэширования чтения (и ваших настроек его) можно выяснить сопоставлением прочитанного "Из файла" в статистике диска на вкладке "Скорость" с отданным в статусной строке при условии net.calc_overhead = false (всё равно отданное останется чуть завышенным).
+ Если снять галку с "Отключать кэширование чтения при малых скоростях отдачи", можно сравнивать объёмы считанного "Из файла" и "Из кэша", со снятой галкой отосланное совпадает с прочитанным из кэша. Будет точнее, только это уже будет режим постоянно включенного кэширования, чья эффективность, по идее, ниже.
Не забывайте про удобную кнопку сброса статистики диска.

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

http://forum.ixbt.com/topic.cgi?id=11:39869-6#150
Если для приложения включено Windows-кэширование, тогда актуальными для него становятся результаты тестирования с блоком 64КБайт.
Если выключено, актуальны блоки 16 и 128 КБайт. uTorrent в этом случае читает в свой кэш блоками 128КБайт, а мимо своего кэша (и из кэша тоже) - блоками 16КБайт. Чтение мимо кэша будет при отключенном собственном кэше чтения или при скорости отдачи <40КБайт/с (опция "Отключать кэширование при низкой скорости отдачи").
Самсунги при потоках >4 лучше читают блоками 16КБайт, блоками 128КБайт похуже, ещё хуже - блоками 64КБайт.
При потоках <4 рост скорости многопоточного чтения с размером блока заметен слабо.
Следовательно, в uTorrent для самсунгов F1-F3 желательно включать упомянутую опцию, отключать кэширование чтения виндой и даже собственное кэширование чтения.
Самсунги заметно сдают на быстром скачивании, если одновременно занять его ещё чем-либо, например, хэшировать обновлённый большой торрент.
wd1001fals многопоточно читает блоками 16КБайт на порядок лучше, чем 64КБайт. Что ж, вестерну в uT абсолютно противопоказано виндовое кэширование чтения (нужна нижняя галка в Настройках - Кэширования).
Вообще, вестерны заметнее других винтов не любят далёкого разнесение потоков чтения, следовательно компактное размещение раздач им особенно не помешает.
hitachi 7k1000.b (hdt721010sla360) блоками 64КБайт многопоточно читает чуть получше вестерна и сколько-то лучше себя (цифр нет), но блоками 16КБайт. Как знать, может кэширование виндой ему не повредит, если с блоком 128КБайт будет плохо.
2. Другие настройки клиента.
Огорчу владельцев (вполне современных) дисков WD и Hitachi, суммарная скорость многопоточного чтения несколькими экземплярами HD_Speed ограничена несколькими МБайт/с, при числе потоков более 4-х к ним присоединяются самсунги.
[Подробнее об эффективности управления многопоточным чтением у разных hdd.]
Так что поправьте невменяемые числа слотов отдачи (их скорее стоит уменьшать при превышении других рекомендованных) и активных торрентов поближе к рекомендуемым Оптимизатором (Мастером) скорости. Кстати, µT считает активными те, чьи скорости превышают пороги queue.slow_dl_threshold или queue.slow_ul_threshold (1000Байт/с по умолчанию), заданные в Настройках - Дополнительно, - именно такие ограничиваем в настройках, в то время как для трекера активные те, что периодически посылают отчёты, в частности о том, что запущены.
3. Перегрузка винта и процессора на малых скоростях обмена, тормоза аудио-видео при работающем клиенте, да и всего, что активно использует жёсткий диск.
Если перечисленное случается при небольших скоростях обмена, стоит убедиться, что контроллер диска работает в соответствующем режиме, а не PIO к примеру (диспетчер устройств - IDE ATA/ATAPI контроллеры или что там у вас - загляните в свойства каждого канала - Дополнительно, смотрите Текущий режим передачи. Можно в EVEREST'е: Хранение данных - *ATA, там смотрите Активный режим.
 
▲ Наверх