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

Возможно это не связано с перегрузкой диска. Тогда именно эту проблему я решаю общим ограничением закачки или раздачи, всё зависит, что важнее. Раздачи и Закачки они связаны всё-таки, и то и другое отправляет/получает ответ о доставке пакетов (обратный трафик). Попробуйте и вы и немного (процентов на 10-15 от ширины канала) скинуть скорость закачки в Настройки, Скорость "Макс.скорость загрузок". Ещё, как вариант, поднять число Соединений, там же. На вкладке Дополнительно увеличить net.max_halfopen до 20-40 (если Win7). Если WinXP, то сначала надо пропатчить tcpip.sys (патч примерно так и называется Half-open limit fix) Если это при старте закачки на несколько гиг, или почти сразу же после старта, то для начала https://rutr.life/forum/viewtopic.php?p=52399529#52399529
Для diskio.no_zero=true понадобятся права Админа и отключение UAC (зависит от винды, но в 1-ом посте это есть):
Перегрузка диска при скачивании (сюда подтягиваются рекомендации)
римерные настройки кэширования для борьбы с перегрузкой диска - подстраивайте по ситуации

Постом выше ещё чуток добавил, но вероятно это не поможет, раз было всё нормально с другой версией. Поэтому я выключаю автообновление. - это полуоткрытых? Обычно столько не советуют ставить. Большое число может приводить к бану от провайдера, как результат - падение скорости. Лучше поставить 20-40. Проблема сразу после 3.1.3 началась? КЭШа хватает? (снизу вкладка Скорость, График: Статистика диска)
Вот ещё нашёл табличку рекомендуемых параметов по количеству соединений, одновременных раздач, закачек http://forum.utorrent.com/viewtopic.php?id=58404
Тот, у кого была схожа проблема изменил натройки по совету табличи и проблема пропала:
Максимальное число соединений= 500 (но я бы снизил до 300-400)
Максимум присоединённых пиров на торрент= 40
Число слотов раздачи на торрент= 20
Можно попробовать ещё откатиться к предыдущим версиям. После стандартного удаления через Винду, для Win7 ввести в проводнике:
%AppData%\uTorrent
и всё там "шлёпнуть" (если жалко потерять раздачи, то хотя бы файлы settings.dat и settings.dat.old). Открыть Блокнот, вставить в него кусок теста на выбор (от разрядности винды 32 или 64) и сохранить, сменив расширение файла txt на REG , после чего 2 раза клинуть, и на вопрос о добавлении в реестр ответить "ДА":
для x86 (32-bit): для x64 (64-bit): Теперь можно попробовать поставить более старые версии.

Если говорить о собственном КЭШе uTorrent'а, то он зависит от максимальных скоростей загрузки и отдачи, diskio.cache_reduce_minutes (стандартно 9, это скорость устаревания блоков, в минутах; необходимо включить "Удалять устаревшие блоки из кэша" ), diskio.cache_stripe (размер загружаемых данных за 1 раз с диска в кэш чтения, в килобайтах - менять крайне осторожно умножением на 2, стандарт 128). И конечно же - наличие свободной памяти. Если свободной памяти остаётся 3 и больше гигабайт, то это хорошо. Поэтому кэш и приведённые выше параметы нужно ставить адекватными возможностям именно вашего компа.
Что касается размера кэша:
Пример: скорость входящая и исходящая 24000 килоБит/с. 24000/1024 = 23.4375 мегаБит/с (если уже в МагаБитах, то делить на 1024 не надо, только на 8), 23.4375 / 8 = 2.93 мегаБайт/с (приблизительно). Значит за 1 секунду может быть получено и отправлено 2.93+2.93=5.86мб/с. Если винчестр не жалко, то хватит и 32мб (это по умолчанию, даже не нужно ставить галочку "Вместо выбора использовать..."). Если жалко винчестер, увеличиваем КЭШ на сколько не жалко (оставив память и другим програмам), или в хотя бы в 10-20 раз (т.е. для примера на 20 секунд 5.86мб*20=117.2мб). Если размер кэша кажется большим, то уменьшаем его.
Кажется у 2.0.4 нет diskio.cache_stripe и читает он всегда по 128кб, значит диск при чтении будет дёргать чаще и средствами uTorrent'а это не решить. Перед дальнейшим прочтением проверяем наличие в Настройки, Дополнительно параметра diskio.cache_reduce_minutes (проверил в 2.2.1 нету, вероятно в 2.0.4 тоже) , если её нету, то дальше можно не читать.
После выбора размера кэша, основная задача его удержать:
Если кэш заполняется быстро (т.е. загрузка+раздача=Заданый размер кэша), то для контроля заполнения кэша Чтения уменьшить diskio.cache_reduce_minutes. Постепенно снижаем, и смотрим за разрастанием кэша. Снижать ниже 3 наверно не стоит, на крайний случай 2. Можно поставить галочку "Освобождать память, если кэш не используется". Плюс последнего пункта, что данные, к которым нет запроса будут быстро удаляться из кэша Чтения и он будет занимать значительно меньше памяти. Минус - если в течении 2-3 минут такой блок сново потребуется, то придётся его ещё раз загружать с диска. Я предпочитаю "Удалять устаревшие блоки из кэша"=ВКЛ, "Освобождать память, если кэш не используется."=ВЫКЛ.
После всего этого понаблюдать за кэшем с часик при одновременно полной радаче и загрузке. Если кэш постоянно полный, то или увеличиваем его или снижаем diskio.cache_reduce_minutes (крайний случай жадности/нехватки памяти "Освобождать память, если кэш не используется."=ВКЛ). Если же кэш в таких условиях постоянно недозаполнен - или уменьшаем его, или увеличиваем diskio.cache_reduce_minutes
Для владельцев 3.х.х и тех, у кого есть diskio.cache_stripe:
Хотя более опытный и уважаемый тыщ, на примере скриншота считат соотношение 1 чтения с диска к 5 из кэша приемлемым (идеальное 1 к 8, т.к 128кб с диска / 16кб на отправку ), то мне это кажется совсем не хорошо. Его можно понять, он не знает ширину вашего канал, объём свободной памяти, скорости винчестеров и т.д. При своих 8 гб памяти (и свободной 5гб) у меня низкая скорость, 1.5 мб/с приёма и 85 кб/с отдачи, поэтому позволяю себе увеличивать кэш от 256 до 512 мб (выше редко), и diskio.cache_stripe=4096 (т.е. загрузка в кэш ведётся блоками по 4мб, а не по умолчанию =128 кб), коэффициент № чтения с диска/кеша получается 1 к (от 52 до 20 - падает со временем, это нормально). Идеальный должен быть 1 к 256 (т.к. 4096кб с вничентера / 16кб отправляемые блоки). Но процент "Объём" загруженого с диска к отправленому становится значительно хуже, т.е. "улетевшего в трубу" очень много. Но пока это соотношение количества Чтений с диска/из памяти выше 1.5-2 раза идеального при мениших значениях diskio.cache_stripe, оно выгодней для снижения нагрузки на винчестер. Винчестер такая железка, что ей значительно быстрей сделать 1 чтение на 1024кб, чем 8 мелких по 128кб с промежутками по времени. Увеличени diskio.cache_stripe со 128 до 256 увеличит скорость заполнения кэша чтения в 2 раза, поэтому увеличить осторожно умножая на 2. Удерживать рост кэша как написано выше. Если не помогает, придётся вернуть diskio.cache_stripe=128.

Если падения скорости всё же связано с записью/чтением, то немного не соглашусь с Чтение и запись могут тормозить как друг-друга, так и сами себя.
Скорость канала в идеальном случае 61440 килобит/ 8 / 1024=7.5 мб/с. Даже если одновременно идёт полная загрузка в обе стороны и забыть про обратный трайк, то это 15 мб/с, что для современного винчестера (даже при чтении+записи вразброс) не много. Всё упирается в Число операций чтений и записи, что значительно замедляет выполнение этих операций (спойлером выше для Arifis написал про это подробнее).
Ещё добавлю к основным советам тыщ
"Удалять устаревшие блоки" - установить флажок
"Освобождать память, если не кэшируется" - снять флажок.
Поставить флажок "Вместо автовыбора использовать указаный размер кэша" и поставить кэш хотя бы 128-256. Но если сново вернуться к математике, то 15мб * 60сек = 900 мб/мин, вот она пиковая пропускная способность в минуту (хотя тут считается, что ставить кеши 1гб и больше - удел Лузеров). При том, что устаревание кэша diskio.cache_redise_minuts=9 (9 минут, по умолчанию, а не 1). uTorrent 3.1 своими силами у меня не кэшируте запись (полные части записываются сразу же, возможно баг 3.х.х версий). Что бы бороться с Частыми записями пользуюсь стронней программой SuperCache, выставив на 3 важных раздела по 300 мб памяти на каждый, и таймаутом сохранения по 10-30 секунд. (как вариант - программа eboostr), но это требует бОльших свободных объёмов памяти. И тут сразу возникает вопрос нецелесообразности использования компов для Торрентов, Мулов и DC, при высокоскоросном канале интернета и наличии памяти 512мб-1гб памяти под WinXP и 2-3гб под Win7. Тут уж или нагрузка на диск с возможными тормозами, или увеличение памяти.
Скорость при записи CD/DVD падает потому, что это медленное устройство (особенно, если это UDMA2, думаю более медленных уже не осталось) и нельзя допустить провала в поступающих данных, поэтому процессор бросает много сил на синхранизацию с медленным устройством. Будь буфер у DVD-RW 16-64мб, было бы проще, но типичный размер (даже для SATA версий) 2мб.

Мне недавно как раз советовали уйти с 3.х.х. на 2.2.1, а ещё раньше на 2.0.4. Особенно не спешу переходить, т.к. проблем почти никогда не испытываю (возможно из-за сторонних програм). Может запущу как отдельные копии, что бы не переустанавливать и погляжу. По скрину - скорости канала не знаю, но думаю раздача шла не один десяток минут (может и несколько часов), и за всё это время кэш чтения достиг 13.1мб из максимальных 128мб. Я как раз и говорил, что если "Освобождать память, если не кэшируется" флажок= ВКЛ, то не используется Весь указаный КЭШ под чтение, только небольшой кусочек. Если его ВЫКЛ, то быстрое соединение "слопает" его весьма быстро. Если ещё будет и закачка работать, то выделеный объём под Чтение будет ограничиваться Скачаным.

Кэш чтения занят полностью, со временем может опять упасть скорость. Если не хочется добавлять ещё кэша, можно попробовать уменьшить diskio.cache_reduse_minutes (скорость устаревания блоков в кэше в минутах) чуть-чуть (от стандартного значения вниз на 1 или на 2, по умолчанию 9). Если кэш Чтения и всё равно будет держаться на максимуме, можно diskio.cache_redise_minuts=3 (или 2), ниже наверно не стоит.
Можно приподнять diskio.cache_stripe до 256 или 512 (тогда "Средняя" скорость заполнения кэша Чтения ускорится в 2 или 4 раза, если раздача порезана на части более 128кб, иначе ничего не изменится), на время можно ещё снизить diskio.cache_redise_minuts, что бы это компенсировать. Главное что бы кэш Чтения долго не был занят на 100% (на скрине это 205 из 205). Это снизит количество обращений к винчестеру - поднимет процент "№" чтений кэш/диск, но и увеличит общий "Объём" скачаного с винчестера (но не отданного в сеть).
Меняя значение diskio.coalesce_write_size можно изменить Средний размер записи на диск, а значит и частоту сохранений. Стандартное значение =2097152 (в байтах, т.е. это 2мб). Почему-то у меня в версии 3.1 объединение смежных блоков не работает, даже если значение будет в нексколько раз больше размера части, а вот принудительное уменьшение Среднего размера записи работает (т.е. при размере части 4мб и diskio.coalesce_write_size=16мб, записываться будет всё равно 4мб не дожидаясь соседних частей, а если задать diskio.coalesce_write_size=2мб, то часть 4мб порежется по 2мб). Т.е. при уменьшении значения, это ускоряет освобождение кэша, но увеличится число записей. Если поднять, то сохранения будут реже, и медленей освобождаться кэш (это если нужно разгрузить диск слишком частыми сохранениями, ценой увеличения кэша).

Вот это проверили? Что бы это работало, нужны права Администратора или отключеный UAC (более подробно в самом первом посте 2. Другие настройки клиента) Он вполне объяснимый. Если diskio.no_zero было = false (или =true но нет прав Админа/включен UAC), то это вызвало тормоза при создании большого файла, а если ещё нет флажка "Отключить Windows-кэширование записи на диск", то возможно Виндовс быстро съела память. Поэтому проверьте ещё "Отключить Windows-кэширование записи на диск" и поставьте флажок.
Канал быстрый, а интерфейс USB 2.0 медленный. Если с него ещё и ведётся раздача, то запаса скорости почти не остаётся - любые дополнительные операции с диском (попытка узнать свободный объём диска, взвесить размер папки, узнать что-то через MediaInfo, проигрывать с него аудио-видео) вызовут тормоза, снижение скорости загрузки/отдачи. Даже для 30 секунд кэша при 10мб/с чтение + 10мб/с запись, кеш нужен 30*20мб=600мб. Если памяти достаточно, КЭШ можно увеличить до 1200мб. Если столько памяти нет/жалко, то использование медленного HDD нецелесообразно, т.к. постоянно будет риск сообщения "Диск перегружен" и подвисание компьютера.
Ещё посоветую попробовать убрать флажок "Освобождать память, если кэш не используется". Вкючение функции значительно снижает затраты памяти под кэш чтения, но увеличивает частоту обращения к диску. Если повезёт, часть данных будет взято из кэша винчестера. Но если появятся "тормоза" из-за частых обращений, флажок убираем.
p.s. Если верить документации, то у диска конроллер SATA-2. Если у компьютёра есть внешний раъём eSata, и при этом Бокс разбирается, а сам диск имеет стандартный разьём SATA, то можно было бы подключить его напрямую, что повысило бы скорость передачи данных и температуру, что без дополнительного охлаждения может снизить срок службы винчестера.

Настройки, Дополнительно: net.max_halfopen (от 20 до 40, больше не желательно)
Я бы попробовал:
1. "Максимально число соединений"=500.
2. "Максимум присоединённых пиров на 1 торрент"=100
Если закачка не будет разгоняться до прежней скорости, при явно большом числе сидов на раздаче, поднимать верхнее значение с шагом +50, второе с шагом +5
Если есть антивирус и/или файрвол, лучше добавиь uTorrent в список исключений на проверку трафика.
Снять флажок "Освобождать память, если кэш не используется".
Если скорость закачки вернулась к прежним 9-10мб, можно ограничить "Макс. скорость загрузок" до 7500, посмотреть на рост отдачи.
После всего этого, хотелось бы глянуть скрин: Скорость, График: Статистика диска.