Низкая скорость хеширования маленьких файлов #993
Comments
|
From Pavel.Pimenov@gmail.com on March 22, 2013 09:33:10 Т.е. поток завис? Можете эти файлы завернуть в архив и кинуть мне в личку через обменник. Status: Accepted |
|
From mike.kor...@gmail.com on March 22, 2013 11:02:50 Старые также работали, поток не завис хеширование идет по 3-10файлов в секунду. |
|
From zippoz...@gmail.com on March 22, 2013 11:09:18 Позволю предположить - железо виновато? В данном случае наверняка WD Грин какой-нить. |
|
From mike.kor...@gmail.com on March 22, 2013 19:51:16 http://yadi.sk/d/Dz9ShIhQ3TZOK - это архив более 300000 файлов, упаковывался 7z со скоростью более 2МБ/с, против 30-60кб/с хеширования. Диск зеленый, большой, кэш 64Мб, системный кэш еще больше (вся папка там 2 раза уместилась бы), произвольный доступ около 20мс, линейная скорость чтения 100-48МБ/с, раздача с него была и в момент архивации (архив писался на тот же диск). |
|
From Pavel.Pimenov@gmail.com on March 23, 2013 01:22:44 Скачал. поставил под профайлером на тест. |
|
From Pavel.Pimenov@gmail.com on March 23, 2013 02:01:28 Пока заметил баг Статус пишет 5 файлов/час https://www.box.net/shared/f3nj0amw6njvk4v39ifq Хотя по логу файлики обрабатываются шустрее: Status: Started |
|
From mike.kor...@gmail.com on March 23, 2013 15:59:37 Думаю, проблема может быть с лог-файлом, у меня он оказался сильно фрагментирован.
|
|
From Pavel.Pimenov@gmail.com on March 27, 2013 09:22:06 Провел тестирование разными способами открывать файлики Attachment: atlfile-atlfilemapping-boost-maped-file-benchmark.png |
|
From Pavel.Pimenov@gmail.com on March 27, 2013 09:23:25 А какой файл лога фрагментирован - имя какое? если отключить логи у вас станет намного лучше? |
|
From mike.kor...@gmail.com on March 28, 2013 18:06:04 Файл, естественно, тот, в который пишутся наши грандиозные успехи хеширования Settings\Logs\System.log Вообще, хеширование всегда странно себя вело. В данном случае, наблюдаю асинхронность составления списка для хеширования и сам процесс хеширования. Так количество и объем файлов растет независимо от того стоит ли хеширование на паузе или нет. А если нажать отмену хеширования - оно не прекращается и об этом есть записи в логе. В моем случае, из-за специфичной структуры хешируемой папки (очень много вложенных папок, а в них много коротких файлов, размером 1-2 кластера) чтение папок и файлов входит в конкуренцию и не получается последовательного чтения с диска, видимо при составлении списка чтение папок идет с растущим отрывом от места фактического хеширования. Attachment: FlyLink_slow_hashing2.png |
|
From Pavel.Pimenov@gmail.com on March 28, 2013 19:21:04 Я вашу структуру каталогов себе установил для теста. |
|
From mike.kor...@gmail.com on November 05, 2013 12:21:23 Все еще актуально. DC++ хеширует в несколько раз а то и на порядок быстрее. |
|
From Pavel.Pimenov@gmail.com on November 05, 2013 18:18:28 Можешь в функции bool HashManager::getMediaInfo(const string& p_name, CFlyMediaInfo& p_media, int64_t p_size, const TTHValue& p_tth, bool p_force /* = false*/) в начале поставить return false; и сравнить скорость? |
|
From mike.kor...@gmail.com on November 05, 2013 20:56:06 Скомпилировал с изменением. |
|
From Pavel.Pimenov@gmail.com on November 09, 2013 00:47:56 Получается медиаинфа тут не виновата. |
From mike.kor...@gmail.com on March 22, 2013 16:54:55
Устанавливаем флайлинк, выбираем для расшаривания папку с множеством мелких файлов (сотни и тысячи байт).
Смотрим на статус хеширования.
Низкая скорость это не ошибка вычисления, она держится продолжительное время > 8часов.
Attachment: FlyLink_slow_hashing.png
Original issue: http://code.google.com/p/flylinkdc/issues/detail?id=956
The text was updated successfully, but these errors were encountered: