The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Новая версия BitTorrent-клиента Transmission 3.0"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Ссылки "<<" и ">>" открывают первые и последние 10 сообщений.
. "Новая версия BitTorrent-клиента Transmission 3.0" +3 +/
Сообщение от Аноним (209), 24-Май-20, 16:19 
> нет, совершенно необязательно

Его и его механизм весьма детально разжевали в LKML. И, естественно, починили. Заколоченая как 12309 инкарнация была именно проблемой того что случается при активной записи на медленный стораж, когда ядро отращивает адский буфер, проги просят память - ща дадим, погодите, только выжмем буфер. Они и ждут пока гигаз выдавит все это и отдаст память.

> (он, в общем и целом, вероятнее всего _кэшем_ был вызван - который память жрал,
> вымывался быстрее чем заполнялся и не работал) -

В конкретно 12309 кэш как таковой виноват только тем что он вообще есть и место собой в системной памяти видите ли занял, тогда как это можно отобрать и софту отдать. А то что все это совсем не быстро в определенной конфигурации и программы взвисают...

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

> и даже если возникал при записи, а transmission при verify таки и пописывает,

При verify пишутся какие-то крохи, в resume файле - что-то типа bit map какие части проверены.

> помечая валидные чанки, то это обязательно дожна была быть именно запись при активном
> линейном чтении, забивающем кэш,

Там крохи какие-то, несколько кило. И пишется resume файл не на каждый пук, его вроде подбуферизовывают и лишь изредка синкают. Может потому и "теряют X мегабайт" если клиент некорректно вырубился не скинув это (затронутые чанки не засчитаются за проверенные). Рехэш разумеется найдет данные если хэш блока верный.

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

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

> баг был один - резкая деградация системного планировщика disk io.

Как планировщик IO вообще поможет, если в 12309 прога встряла при выделении себе памяти и ядро вкалывает чтобы память очистить? Пока оно не отожмет у кеша память - прога не разморозится, хоть там что. Единственная альтернатива - сообщить ей что запрошенное выделение памяти не удалось, но тогда прога вообще скорее всего упадет/словит SIGSEGV. А какие варианты?!

Фикс был в лимитировании размера кэша для тормозных сторажей, так что системная память во первых не выжирается в такой ситуации, во вторых выжимка занимает меньше времени. Эта инкарнация и починилась.

А прочие "12309-like" - другие взаимодействия. Так что если кто валил все баги в 1 кучу - ну тогда и кукуйте без фикса. Быть тупицами вообще так себе.

> Причем с  совершенно точно известным местом, где его еще не было - 2.6.18

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

> возник - у божка "всеработало", и ему было наплевать.

Задеклареный баг исследовали и починили, а если кто думал под шумок вывалить туда 20 других багов и сказать что это то же самое - ага, ща, это так не работает. И хрен воспроизведешь даже если захочешь.

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

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

> Как поступают в этом случае люди, заинтересованные в качестве своего продукта? Правильно:
> добиваются воспроизводимости

Кто и в каком объеме это должен делать? До каких пор? И кто оплатит весь этот банкет? Хотя-бы миллионы возможных комбо железок и время на возню со всем этим парком? Даже сверхжирные коммерческие корпы занимаются качеством до известного предела и не бита сверх необходимого минимума. Бабло видите ли считают.

А по логике вещей, у кого проблема тот и суетится. Вплоть до высылки конфиги деву или оплаты выезда дева или хотя-бы доступа к конфиге. Блин, чудес не бывает и если у девов оно не воспроизводится (очень частый случай) - да, дальнейшее не совсем просто. Это либо диагностируется тем кому оно надо либо он что-то придумывает чтобы мощно подыграть/мотивировать минимально заинтересованным в этом.

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

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

> и важные полировки глюкал, начинают поштучно накатывать патчи, пока не получится
> поймать проблему.

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

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

Собственно он для того и нужен. А сделать из него ломового кодера и багрепродусера - блин, ну это ж тебе не СССР где полагали что гнать профессоров на картошку эффективно, там у людей все дома по части управления проектами.

> он вообще откатывать правки не умеет,

Git log не подтверждает этот тезис.

> поскольку не умеет пользоваться vcs по назначению. Только вперед, к неведомой цели.)

Торвальдс накодил git и не умеет им пользоваться. Нимб не жмет, гуру vcs?!

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

Железо и софт стали сложными, требования и приоритеты изменились, скелеты в шкафу местами остались, а возможных комбинаций квинтиллионы. То что в каких-то краевых случаях что-то работает как-то не так удивляться может только рак. И если кто думает что это уникально для линуха - там вон прогер из майкрософта высказал совсем другие идеи. И почему-то не в пользу винды.

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

Этот ваш 2.6.18 на половине актуального железа тупо не работал. И никак не могу вспомнить никакой особой low latency у того ядра.

> а сказку про "настоящую многозадачную операционную систему" - рассказывать про
> проклятую-венду, угу.

Чудес не бывает. Если винч положить до состояния когда он по всему блину в час по чайной ложке телепает, грех удивляться старту программ полчаса, ведь системные либы наверное из астрала прочитаются? И прочие файлы с иконками и каким еще барахлом не требуют IO. Только не говори что ты никогда не видел допустим тормозящую винду, где реакции на переключение окошка можно минутами ждать.

- Доктор, когда я так делаю, мне больно!
- А вы так не делайте!

> - а не ты должен был вместо нее думать, на какой
> бы диск что бы такое положить, чтоб ей жилось легче.

Тут рассказывали не так давно что система, блабла, тупит, эн минут, если память кончается. Даже тест выложили. Я им и померил у меня - через 5 секунд OOM killer пристрелил проблемный процесс и был таков. Нет, конечно если хочется демонстративно прострелить пятку и верещать, это можно. Но мне кажется что есть менее мучительные способы достичь просветления.

> P.S. http://bugzilla.kernel.org/show_bug.cgi?id=12309

Можно подумать я это не видел. Еще и смежные дебаты в LKML, чтоли, по поводу что за баг.

> Надо еще на вебархив наехать, dmca там какой вспомнить или еще чего.

Торвальдсу то? С чего? Он вроде хоть и едкий чувак, но обычно по делу.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Новая версия BitTorrent-клиента Transmission 3.0, opennews, 23-Май-20, 09:56  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру