> ФС тут ни при чёмЕсли клинит system-wide так что тормозит вообще все - очень даже при чем. Это означает что диск тормозит и когда некая программа просит операцию, операция не выполняется немедленно а оседает в немеряной очереди операций. И программа висит в соотв. вызове ожидая пока операционка отпедалит эту операцию. Если очередь большая а диск/ФС тормозные - получаем вот такой вот дец. Как раз общесистемный - клинить начинает любую программу которую угораздило хоть что-то с файлами делать и это не было асинхронной операцией.
А скажи, клевый у меня телепатор? :)
> — Deluge пересчитывает 2,5ГБ файл за пять секунд, если тот в кэше,
Трансмишн, как ни странно, тоже. Потому что чудес не бывает.
> ничего не тормозя. Trasmission всё время лезет на диск как слон в посудную лавку.
В общем случае в реалистичном сценарии (ака куча разных торрентов, явно превышающих объем оперативки) торенты в кэш не лезут и большую часть времени с точки зрения ОС будет cache miss. Тем более что ОС не знает что попросят следующим вот так сходу.
У трансмишна кстати с неких пор есть настройки встроенного буфера. Поскольку клиент намного лучше ОС знает что он будет читать и писать дальше, этот буфер имеет смысл и может изрядно разгрузить диск, сделав I/O менее хаотичным и более крупноблочным. Если диск совсем гэ а оперативы много - можно этот встроенный кэш увеличить. Трансмишн станет жрать больше памяти но заметно разгрузит диск.
>> 1) ФС зашилась и тормозит?
> Разработчики Transmission, которые не используют буферизацию ФС, очевидно.
Буферизация ФС для торрентов в большинстве случаев будет лажаться. Просто потому что это в своем нативном виде совершенно рандомный доступ и как правило к весьма большому объему данных, много больше чем есть оперативы. По поводу чего почти всегда будет беспонтовый cache miss. По этому поводу есть ряд стратегий по борьбе с этим. В частности - засунуть менеджер кэша и локальный кэш в апликуху. Этот кэш в курсе того что качается и что потребуется записывать. И в курсе что хотят ремотные пиры и что они захотят чуть попозже. Поэтому он может затолкаьт в себя заранее крупными блоками и потом цедить пирам по мере их возможностей. Сильно разгрузив диск, благо механическому диску очень неудобно когда его долбят мелкими рандомныим запросами - он больше гоняет головы туда-сюда чем читает/пишет. А вот такой кэш может нехило разгрузить диск. Попробуй увеличить.
>> 2) Ну а где был планировщик ввода вывода?
[...]
> Во FreeBSD нет планировщика I/O. А какой есть — слишком примитивный, чтобы
> иметь альтернативы. Пора бы это уже знать.
Я как-то не обязан в чужих инвалидностях детально разбираться. Собственно планировщик ввода вывода должен в такой ситуации попилить более-менее честно то что есть на всех. Ж@па конечно никуда не денется, но ее масштаб сократится. В том плане что программы будут в среднем меньше висеть в системных вызовах, так что времена их реакции улучшатся.
> Чуть не поперхнулся чаем. Тебе же говорят, что Deluge не тормозит, а
> Transmission тормозит.
Значит где-то есть разница в логике работы с диском. Может быть у Deluge встроенный буфер здоровый по дефолту, например.
> А ты наоборот своё гнёшь. Разуй глазки. Может у тебя Transmission
> единственной программой работает, у меня — нет,
(глядя на работающий трансмишн) у меня он висит в трее пока я печатаю это сообщение. Ничего не клинит. Ну то-есть вообще совсем. Я такое не лю и потому предпринял ряд мер к тому чтобы подобные ситуации в принципе возникать не могли.
1) System и data диски у меня разнесены. Поэтому даже абсолютный завал винтов с данными запросами не вызовет подвисания всех системных программ (вообщем всего что не работало с data дисками).
2) Я настроил трансмишну достаточно внятный кэш.
3) Я уверен что ФС в крейсерском режиме у меня не зашивается и не фрагментирована что пиндец.
4) Я сделал FULL-дефраг торрентов, положив темпарь на один физический диск и финальное назначение на другой. Так что файл чисто физически вынужден отдефрагментироваться при переносе из темпаря в финальную локацию.
5) Кстати для системы SSD - вещь. Правда от конфигурационной диры трансмиссии я его избавил. Чтоб не протирался лишний раз.
> и лишний раз проверку запускать нужно заранее планировать тормоза
> на несколько минут, чтобы ничего в других программах не делать.
Ну я не виноват что из тебя системщик столь хреновый что у тебя дисковая подсистема зашивается настолько что все остальные программы тоже пролетают. У меня такого нет, потому что я сам себе не враг. У меня такие ситуации исключены на уровне дизайна локаций файловой системы. То-есть, я понимая причину таких тормозов просто изничтожил не то что тормоза, а потенциал для их возникновения вообще. При упомянутом разделении локаций просто не возникнет ситуация когда система и программы в ней будут курить бамбук попав в немерянную очередь запросов к диску.
>> настолько раком - грош цена такой wannabe-многозадачной операционке в базарный день.
> Если обычное приложение общается с диском как со своей собственностью,
Для тупых намекаю что делить ресурсы - как раз обязанность многозадачной системы. Не дос чай и не винды 3.1 с кооперативной многозадачностью.
> то тут либо оно МЕДЛЕННО работает, но само, либо БЫСТРО, но тормозит всё остальное.
Ну да, иногда в апликухах вставляют холостые циклы для компенсации дефективности работы операционки. Но это вообще-то воркэраундинг гунявости разделения ресурсов операционкой.
> Облажались разработчики Transmission, не могли придумать более прямого пути для
> проверки файла.
По изначальной задумке, апликухи о таких вещах вообще знать ничего не должны. Если им это приходится узнавать - то только в силу гунявости операционок или криворукости тех кто ими рулит. Правда просто?
