Архив-1: Ошибка: Диск перегружен (Настройка кэширования и другие способы уменьшения нагрузки на HDD) [Ответы в 1-м посте] 26.05.2014 [867941]

Торренты и винты
1. Настройка кэширования и другие способы уменьшение нагрузки на винт. Хотите подсказки вроде тех, что на картинках, воспользуйтесь переводом из подписи*.
Здесь направления борьбы, а не синяя пилюля.
Предполагается минимальное осмысление написанного, а не банальное копирование чисел и галок (представьте, что они стоят на картинке в случайном порядке).
Оптимально держать закачки/раздачи не на том же жёстком диске, где стоит работающая ОС. Аналогичное можно сказать и о файле подкачки, с другой стороны последний может усугубить перегрузку диска с закачками, если будет на нём. Встречаются случаи, когда при быстром скачивании/раздаче стремительно заполняется ОЗУ (чаще из-за Windows-кэширования, но и собственный кэш µTorrent'а может разрастаться, если не фиксирован), что заставляет ОС сбрасывать "лишнее" из ОЗУ в файл подкачки. Если файл подкачки будет на том же диске, что и закачки, даже система может тормозить, не говоря уже о скачивании. Вот почему Windows-кэширование записи в µTorrent'е по умолчанию выключено. В упомянутых случаях важно ограничить рост потребления памяти, отключив Windows-кэширование чтения и/или зафиксировав кэш клиента.
Размер собственного кэша µT
Немного уточню выбор размера фиксированного кэша. Посматривая на эти оценки, выбираем разумное значение, одинаковое для собственных кэшей чтения и записи. Уточняем размер, наблюдая в статистике диска на вкладке "Скорость" заполнение обоих кэшей. Можно уменьшить фиксированный размер, если в пике кэши далеки от полного заполнения, увеличить - если близки.
Периодическая дефрагментация дисков тоже не мешает. Владельцы объёмистых дисков, глядя на десятки свободных гигабайт, не задумываются, что диск, заполненный более чем на 88% (свободных 12%, столько же изначально зарезервировано под рост MFT), дефрагментировать толком не получается - API дефрагментации не может перемещать данные в MFT зону, свободного места для маневра просто нет. Так что избавиться от перегрузки диска в таком случае можно, освободив >15% объёма - столько же обычно требуют (должны, ибо используют виндовые API) дефрагментаторы. Стоит добавить к 15% ещё несколько гигабайт - закачки сплошь немалые.
Хотя линейные скорости чтения/записи диска на первый взгляд заметно больше сетевых, излишне беспорядочное перемещение головок может сильно испортить реальные скорости. Поэтому в случае многозадачности (проги помимо клиента, активно использующие диск, да и просто некстати свопящая винда) делу теоретически может помочь NCQ (требует переключения контроллера жёстких дисков из режима эмуляции (совместимости с) IDE для SATA-устройств в нативный SATA), но чаще вредит (и NCQ, и AHCI). Ускорение в нативном режиме (проверялось что угодно, кроме торрентов) замечалось почему-то на отдельных, не встроенных контроллерах (?) и далеко не для всех HDD, да и выигрыш невелик при включенном кэшировании. А имитация многопоточного чтения несколькими экземплярами HD_Speed недвусмысленно намекает, что многие диски лучше ворочают торренты в режиме эмуляции IDE (PATA).
Мда, неотключаемый AHCI у некоторых ноутбуков может даже заставить ограничиться одной активной раздачей!.
Отключение Windows-кэширования чтения с диска радикально снижает потребление ресурсов (памяти и процессорного времени) при высокоскоростной отдаче (упоминаю сразу, чтоб не прошло мимо вашего внимания). Резонно для небольшого числа подключенных личеров на торрент, но иногда их бывает сотни и тысячи. А вот для нескольких копий клиента Windows-кэширования чтения с диска точно не помешает, т.к. один и тот же торрент (даже одному и тому же пиру; BitComet, например, любит цепляться ко всем) может раздаваться разными копиями, так зачем считывать с диска одно и тоже?
Необходимость собственное кэширование клиента
Жёсткие диски и сами кэшируют, но не всегда хорошо - см. Скорость HDD при многопоточном чтении. Так что не помешает собственное кэширование, которое поболее виндового знает о торрентах. Хотя и здесь не стоит ожидать, что считанное из кэша в разы превысит считанное с диска, зато собственное кэширование может обеспечить чтение с диска бОльшими порциями, чем поддержать сдающий диск. Только оно и не даёт дискам со слабым многопоточным чтением свалиться в режим случайного доступа.
С учётом иных целей можно даже мириться с каким-то превышением считанного с диска над отосланным.
Эффективность собственного кэширования чтения (и ваших настроек его) можно выяснить сопоставлением прочитанного "Из файла" в статистике диска на вкладке "Скорость" с отданным в статусной строке при условии net.calc_overhead = false (всё равно отданное останется чуть завышенным).
+ Если снять галку с "Отключать кэширование чтения при малых скоростях отдачи", можно сравнивать объёмы считанного "Из файла" и "Из кэша", со снятой галкой отосланное совпадает с прочитанным из кэша. Будет точнее, только это уже будет режим постоянно включенного кэширования, чья эффективность, по идее, ниже.
Не забывайте про удобную кнопку сброса статистики диска. 2. Другие настройки клиента.
Огорчу владельцев (вполне современных) дисков WD и Hitachi, суммарная скорость многопоточного чтения несколькими экземплярами HD_Speed ограничена несколькими МБайт/с, при числе потоков более 4-х к ним присоединяются самсунги.
[Подробнее об эффективности управления многопоточным чтением у разных hdd.]
Так что поправьте невменяемые числа слотов отдачи (их скорее стоит уменьшать при превышении других рекомендованных) и активных торрентов поближе к рекомендуемым Оптимизатором (Мастером) скорости. Кстати, µT считает активными те, чьи скорости превышают пороги queue.slow_dl_threshold или queue.slow_ul_threshold (1000Байт/с по умолчанию), заданные в Настройках - Дополнительно, - именно такие ограничиваем в настройках, в то время как для трекера активные те, что периодически посылают отчёты, в частности о том, что запущены.
3. Перегрузка винта и процессора на малых скоростях обмена, тормоза аудио-видео при работающем клиенте, да и всего, что активно использует жёсткий диск.
Если перечисленное случается при небольших скоростях обмена, стоит убедиться, что контроллер диска работает в соответствующем режиме, а не PIO к примеру (диспетчер устройств - IDE ATA/ATAPI контроллеры - загляните в свойства каждого канала - Дополнительно, смотрите Текущий режим передачи. Можно в EVEREST'е: Хранение данных - *ATA, там смотрите Активный режим.).
4. Неприятности.
Конфигурация с µT на ПК1 и раздачами на ПК2. Жалоба на заполнение ОЗУ под завязку системным кэшем.
Второй винде, на которой лежат раздачи, неизвестно и безразлично отключение Windows-кэширования в клиенте, находящемся на первом ПК. Вот на этом первом и отключится Windows-кэширование для µT. А вторая Win7 будет мужественно кэшировать любые чтения, пока ей не ограничить кэш. Поищите твики реестра для этого.
Вообще, по возможности стоит держать клиент "поближе" к раздаваемым файлам. Сопутствующие ссылки:
~ Закачки на внешнем диске https://rutr.life/forum/viewtopic.php?p=22725985#22725985
~ Сетевой диск https://rutr.life/forum/viewtopic.php?p=29651979#29651979

---

Продолжение - через 3 поста https://rutr.life/forum/viewtopic.php?p=18707776#18707776
Дополнения/уточнения - с.6 https://rutr.life/forum/viewtopic.php?p=31769989#31769989

не помогает!!!!!!!

h

перегрузке диска способствует настройка "Pre-allocate all files" на вкладке "General". если µторрент запускается из-под админа, надо зайти на закладку "Advanced", найти там "diskio.no_zero" и переключить в "true".
по умолчанию, на нтфс, когда µторрент создаёт файл, ему приходится забивать его нулями. то есть он не сам это делает, это сама винда так делает ради безопасности, т.к. на выделенном файлу месте могут находиться останки прежде удалённых файлов, к которым доступ кому попало давать некомильфо. естественно если вы качаете файло на 40 гиг на USB-винт, такое забивание нулями займёт пресс времени. если же есть админские права, то винда позволяет отменить запись нулей в созданный файл — типа, раз ты админ, то сам знаешь что делаешь. именно это и делает опция diskio.no_zero.
по очевидным причинам, под вистой со включенным UAC, это работать не будет. когда прав нет, µторрент не ругается, просто работает по-старинке, забивая файл нулями.

Если меры из моего сообщения выше не помогают... По опции 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 или тех же админских прав.
Кстати, передёргивание Pre-allocate all files остаётся пока единственной мерой борьбы с ошибочным отказом µT писать большие файлы на NTFS-разделы (случается и такое - см.выше), если не считать совсем уж странных.
А USB-винтам в мануале вообще не обещается эффективность твикинга кэширования. В этом случае остаются работоспособными ограничение максимального количества активных закачек в настройках очерёдности (меньше головки мечутся), останов отдачи (опять же головки меньше скачут) и ограничение общей скорости приёма (приведение в соответствие с реальной скоростью записи на диск). Выбирайте, что удобнее вам и тормозному винту, но только после провала твикинга кэширования и прочего, упомянутого в сообщении выше.
При перегрузках из-за скоростной отдачи (почти мечта ) меры те же, точнее "там же", но уже в отношении кэширования чтения и отдачи.

качаю фильм 15ГБ. заметил такую ошибку и падение скачки. версия ЮТоррент 1.6. увеличил кеш до 50мб, поубирал все раздачи кроме этой. diskio.no_zero в этой старой версии нету. вобщем почитал и ничего не помогло. что делать тогда? перейти на последнюю версию и пробовать включить diskio.no_zero?

За что отвечает опция diskio.use_partfile=true ?? У меня версия utorrent 1.8.2.

Отвечает за запись излишка частей, принадлежащих выбранным и пропущенным файлам одновременно, в отдельный файл ~uTorrentPartFile_*.dat . Переходные части нужны целиком для проверки/хэширования.
В случае *false пропущенные файлы, содержащие лишь куски переходных частей, будут размещены на диске.
На будущее, задавайте вопросы в соответствующих темах.

А из-за чего может возникать такая ошибка? Имеется два диска C и D когда закачиваю на D через Bitcomet 0.70 то он подвисает и не качает, а utorrent 1.7.7. пишет HDD перегружен, это все когда пытаюсь сохранить на D, если сохранять на другой диск то все в порядке, и файлы то небольшие 1.36 ГБ, неделю назад все нормально было, что могло такого случится то..
Да кстати если с фтп качать на этот диск ФТП качалка тоже подвисает.

Ребята, не стал открывать новую тему- может кто-то здесь сходу подскажет.
Вчера совершенно неожиданно торрент перестал делать отдачу файлов. Выглядит это так: у меня 2 своих раздачи, и полтора десятка где я сидер. Периодически кто-то по ним начинает скачивание и запрос системы идет ко мне - начинается отдача с какой-то минимальной скоростью - 3кб.-1кб.\сек и уже через секунду эта скорость начинает падать по 0,1-0,2 кб. за какждое обновление и через 10 секунд доходит до 0, все и отдача прекращается. И это происходит постоянно по всем позициям. В результате отдача 0 и все.При этом закачка идет со скоростью 230 кб.\сек
Честно перерыл форум - не нашел похожей темы. Прогнал speedtest.net/ - выдает ошибку на определение скорости upload. Поставил заплатку Half-open_limit_fix_3.6. В итоге открытых 100 портов. Ничего в софте вчера-позавчера не делал - никак не пойму что сломалось, но при нулевой отдаче через пару недель рейтинга вообще не будет. Только хотел новую раздачу делать.
Пожл помогите специалисты добрые

JokerNikita
Сегодня на 2-х собственных раздачах отдача у вас есть (по 5 КБайт/с усреднённо, наверное). Остальных у вас в профиле нет (загляните). Если в клиенте при этом остальные имеются и ошибок нет, у вас не прописан анонс трекера (адрес) или прописан на другой аккаунт (другой пасскей). Вроде этого: http://bt*.rutr.life/announce.php?uk=пасскей&; .
См. в свойствах торрента или на вкладке "Трекеры".

---

Cellx
Возможно, у вас диск D: работает в режиме PIO. См. в диспетчере устройств контроллеры дисков.
Это написано чуть выше - https://rutr.life/forum/viewtopic.php?p=18023764#18023764 в последней (на сегодня) строке

---

Винту активация этой опции не вредит, ему как раз легче не прописывать нули. Прописана отключенной из паранойи для пущей безопасности, чтоб в нестёртое место не попала чувствительная информация. В новых версиях включена по умолчанию (уже писалось на этой странице https://rutr.life/forum/viewtopic.php?p=18707776#18707776 ).

здраствуйте ребята, у меня тоже была такая проблема, но поставил в настройках "diskio.no_zero" и все пропало, качает на скорости 10 мегабайт в сек отлично, но у меня вопрос, а это не вредит винту?

друзья, у меня проблема.
при добавлении нового файла в торрент, выбивается предыдущий и пишет Ошибка!

тыщ
спасибо) а почему же сразу нельзя включать эту опцию? почему по умолчанию она выключена, зачем насиловать винты?

Для владелцев 1.7.х и ниже, сделай так:

и ошибка не будет.

Да кстати тоже интересно как это на винте скажется, ничего с ним не случится?

Cellx
написали же, что винту это не вредит, ему наооборот легче так работать))
ребята есть еще один вопрос, у меня отдает на скорости 10 мегабайт в сек и притормаживает система немного, можно как нить убрать загрузку винта?

Ограничь канал на отдачу; поубивай процессы, нагружающие конкретный винт

в версии 1.8.3 diskio.no_zero = true стоит по дефолту

Lance
спс))) а сколько примерно отдачу сделать?
nfk.user
ну никак додумались)))

На твоё усмотрение. Зависит от диска. Как притормаживать перестанет- норм.

5 поставил, вроде норм идет)))

100-мегабитный канал? Начало https://rutr.life/forum/viewtopic.php?p=18023764#18023764 и ниже https://rutr.life/forum/viewtopic.php?p=18707776#18707776 (там всё равно подробнее).
Можно отключить кэширование винды. Если SATA-диск, переключить в БИОСе в настоящий (нативный) режим SATA из режима эмуляции IDE (вопрос для тематического форума). Дефрагментация. Наконец ограничить число активных торрентов.
Ограничивать скорость просто, но не спортивно - может тогда тариф сменить?

тыщ
ну 100 мегабит толька в локалке, на локальном трекере такая скорость) diskio no. zero я включил, при качании торрентов винт не перегружается, просто при отдаче система тормозит, но торрент не пишет, что диск перегружен, вообщем ограничил да 5 мегабайт и все норм и винт не грузит и система норм рабоатает))
а эта тема проситана вдоль и поперек))
но все равно спасибо за советы))

Столкнулся с переполнением диска на двух компьютерах. На обоих - µTorrent 1.8.2, русский, работали более чем месяц нормально. На одном сначала помогло удаление кучи старых завершенных закачек, хотя они и были неактивны, но через несколько дней - опять всё по старому. Создалось впечатление, что подобная ошибка возникает при количестве DHT > 300 нодов.
Результатом проб всяких разных способов, предложенных тут в топике и найденных вообще по инету стал такой способ:
Заранее предупреждаю, я не особо хакер, и не уверен, что этот способ безопасен и подойдёт всем. Если кто, хорошо владеющий матчастью, откомментирует - буду премного благодарен, и не только я
1. Заходим в реестр (Пуск - Выполнить - regedit)
2. Находим там строчку HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP
- если MSTCP отсутствует - заходим в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD и создаём там новый ключ (key) MSTCP
3. Создаём там (если отсутствует) новый строковый параметр (Edit - New - String value), который обзываем MaxConnections (он задаёт максимальное количество одновременных подключений)
4. Задаём ему значение до 512 (максимум для Win 98).
5. В настройках µTorrent меняем значение net.max_halfopen на выставленное, лучше ставить на 10-20% меньше.
Взято частично отсюда: http://support.microsoft.com/kb/158474/EN-US/ . В принципе, касается Wni 98/Me, но и на XP вроде как заработало, если это только не Тёмные Силы Электричества исправили проблему

Как я понимаю, всеравно у каждого свой индивидуальный способ решения этой проблемы как был, так и останется, но мне помогло только diskio.no_zero = true.
В дополнение к включению этой опции всякие выкрутасы с кешами помогают на очень слабых компах. На быстрых их крутить бесполезно.
Спасибо человеку, который открыл глаза на все это.

Лично мне помогло не ставить больше одной закачки в клиенте...

улыбнуло...

Была и у меня эта дурацкая ошибка про disk overloaded. Избавился отключением опции diskio.no_zero = true. ибо стоит ее включить и проблема снова появляется и никакие шаманские танцы с бубном не помогают. Но изза disk overloaded появилась другая проблема: значит включаю utorrent и минут 10-15 скорость отдачи хорошая(под 1 мб), но потом она почему то падает до 80 кб. Перезапуск не помогает - проблема возвращается. Переустановка клиента тоже не помогает. Изза чего это может быть?? и как с этим бороться?? до disk overloaded была постоянно отличная скорость отдачи. Так ведь весь рейтинг загубится и получу бан.. Неужели только винду переустанавливать? Не хотелось бы...
PS. у мя Windows 7 RC. Мож изза этого?

Mr.3Dx
это стоит? https://rutr.life/forum/viewtopic.php?t=1002417
дрова на сетевую обновленные?