Улучшить работу с большим количеством файлов при скачивании

[kotobod]

Думаю, многие уже заметили, как при добавлении в скачивание папки с большим количеством файлом (в основном мелких), например библиотеки с книгами или музыкальный архив, когда количество файлов превышает несколько тысяч, а то и десятки тысяч в списке для скачивания, то fly просто виснет. Повторные запуски не надолго его оживляют после убивания процесса, но стоит например открыть список скачиваемых файлов, то проблема повторяется вновь. Иногда, после долгих раздумий, список файлов очереди для скачивания все-таки все-таки открывается, но стоит только в нем что-то удалить, то получаем опять фриз. Очень древняя проблема и помню ее на протяжении всех лет пользования FlyLink. Может как-то можно это дело оптимизировать? И да, еще частенько после такого накрывается медным тазом база sqlite, об ошибке который Fly постоянно начинает сигнализировать. Приходится тупо ее убивать в папке и заново все шарить и хешировать. В итоге, мне так ни разу и не удалось скачать какую-нибудь библиотеку через Fly.

[parihaaraka]

+100500
Мало того, что тормоза в большим количеством файлов, так их еще и хрен удалишь - всё зависает намертво, а хард начинает сходить с ума.
Автору пора раскурить паттерны разработки с использованием СУБД, и, в идеале, сделать работу с БД только с использованием какой-нибудь
древней версии ansi стандарта через ODBC, чтобы желающие могли подсунуть свою субд (например, Postgresql) и админить ее.

[pavel.pimenov]

Запустите флай с ключем трассировки start FlylinkDC_x64.exe /sqltrace
и после пришлите созданный файл лога sqltrace.log для анализа
хочется увидеть какой запрос там тормозит

[parihaaraka]

Моделировать это снова не хочется, пока сижу на eiskaltdc++. Дело почти 100% не в субд, и именно об этом речь (несколько десятков тысяч записей в базе - ерунда).
Да, выступаю сейчас с несколько абстрактной позиции, могу быть не прав, прошу прощения заранее. Но таки что может делать программа долго, очень долго.. реально долго для того, чтобы очистить _полностью все задачи_(минут сорок ждал, не дождался)? Активных закачек, пускай, десяток. Значит, видимо, получается delete from download_queue where tth not in ('1','2','3',..'10'), а дальше подчистить мусор от незавершенных заданий (или наоборот - не суть вопроса). Но как этой простой процедурой можно нагнуть компьютер целиком и надолго? Можно сделать предположение. После первых недоуменных прибиваний процесса была попытка удалять небольшими порциями - папочками по несколько десятков файлов. И эффект наблюдался пропорциональный, т.е. такая папочка удалялась из очереди с минуту. Напрашивается вывод: либо кошмарные запросы к базе (вряд ли) без нужных индексов, либо каждое удаление файла ведет к перестройке всего дерева даже невидимых файлов, и дальше лавинообразно рефрешится куча чего-то (может и база обновляется для каждого файла, что в сумме и дает такую скорость - вариантов множество).. По крайней мере, даже если устранить эту, очевидно, архитектурную проблему в разумные сроки невозможно, стоило бы сделать временное простое решение по прибиванию ВСЕХ задач целиком, чтобы можно было хоть как-то выкрутиться. Наверняка, это несложно.

[pavel.pimenov]

Добавить функцию "удалить все закачки" можно - сегодня вечером попробую приделать.
хотя очень хотелось бы локализовать вашу проблему
если 40 минут то там где-то дедлок и виновата никак не база

[parihaaraka]

Дедлок предполагает взаимное _ожидание_ двух потоков или процессов, пока каждый не освободит ресурс, занятый другим. А в данном случае программа не ждет - винчестер трещит как сумасшедший. Я бы даже дал программе поработать столько, сколько нужно, чтобы очистить очередь, но побоялся, что хард дырку протрет

[pavel.pimenov]

нужно было в последний момент снять дамп памяти и прислать мне - я бы тогда посмотрел где висит
просто очень странно что 40 минут
скажите какие вы хоть каталоги качали и у кого?
я повторю у себя эксперимент

[parihaaraka]

Ткнул на скачивание папки, не вдаваясь в детали (обои на рабочий стол или типа того), а внутри оказалась страшная куча файлов в подкаталогах (да и самих подкаталогов уровня 3-4 немало). А дальше, как в первом посте этой темы, на каждое движение - несколько секунд пауза. Удаление уже описал. А детали - что и у кого - остались в анналах истории.

[pavel.pimenov]

число файло сколько? 10 100 тыс?

[parihaaraka]

Если бы я знал, что Вы, Павел, настолько доступны и активны, я бы не поленился собрать побольше информации об инциденте, может даже отладить бы сам попытался. Теперь-то уж детали не скажу. Наверное, 1-2 десятка тысяч от силы. Файлы в большинстве своем оказались мелкие - порядка 100кб.

[pavel.pimenov]

Я когда-то тестировал проблему с большим кол-во каталогов и файлов но в плане хеширования были жалобы
и кто-то мне даже подарил вот такие батники
https://yadi.sk/d/_Vaf05sYgDk7o
они генерят много файлов и каталогов для теста
я попробую их использовать для эмуляции большой очереди закачек

[pavel.pimenov]

с билда 18547 добавил функцию быстрого удаление всей очереди - доступно через меню контекстное в очереди
обновите бетку чарез часок - сможете проверить