0001592: Попытка отмены задания закачки при долгих операциях внутри закачки -> зависание САСа

Notes
(0009067) Dima2000 (developer) 28-09-2012 14:55	Поясню, в п.3 и п.4 САС подготавливает в RAM полный список тайлов, попадающих в полигон для последующей работы. И время такой подготовки зависит в основном от общего количества тайлов в ограничивающем прямоугольнике. И от количества точек в полигоне. Потому на подробных зумах и больших областях будет долго. На z24 можно и не дождаться или памяти не хватит. :) Насколько я знаю, тайловый кэш при этом ещё не задействуется, подготовка чисто математическая операция, проверка каждого тайла в ограничивающем прямоугольнике на попадание в полигон.

(0009069) vdemidov (manager) 28-09-2012 15:12	>Поясню, в п.3 и п.4 САС подготавливает в RAM полный список тайлов, попадающих в полигон для последующей работы. И время такой подготовки зависит в основном от общего количества тайлов в ограничивающем прямоугольнике. И от количества точек в полигоне. Потому на подробных зумах и больших областях будет долго. На z24 можно и не дождаться или памяти не хватит. :) Неправильно понимаете. Список никакой не строится. Память не выделяется. Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень.

(0009070) Dima2000 (developer) 28-09-2012 15:53	Да, насчёт памяти был не прав, память подвела, осознал.

(0009072) Parasite (administrator) 29-09-2012 05:23	>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Нельзя ли в тот тупой подсчет встроить возможность нормальной отмены по кнопке, а не через зависон и перезапуск САСа? Пускай оно строит все что ему надо, и как умеет - но отмена есть отмена: надо прекратить строить (на любом этапе) и выйти наружу.

(0009074) Parasite (administrator) 29-09-2012 05:38	>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. PS: значит ли это, что и при простом тайловом кэше зависание будет иметь место? Если так, то надо подредактировать шапку.

(0009076) vdemidov (manager) 29-09-2012 12:41	Проверяй. Тебе виднее.

(0009077) Parasite (administrator) 29-09-2012 13:38 edited on: 29-09-2012 13:43	При обычном тайловом кэше строки начинают бежать практически с момента старта задачи - никаких несколько-минутных ожиданий нет, и проверить сабж не удается. То есть, какая-то зависимость времени подсчета тайлов в полигоне от типа хранилища - таки есть. Может действительно какие-нибудь индексы в Беркли читает? Или просто открытие БОЛЬШОЙ базы занимает долгое время...

(0009086) zed (manager) 30-09-2012 14:57	Parasite >При обычном тайловом кэше строки начинают бежать практически с момента старта задачи А вот и не правда! Этот глюк одинаково воспроизводится на любом типе кэша и это именно тормоз подсчёта тайлов сложного выделения (непрямоугольного), при большом количестве тайлов. Никаких индексов БД не считывает... vdemidov >Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень. Как именно? Через отдельный поток?

(0009087) Dima2000 (developer) 30-09-2012 15:13	[offtopic on] >Как именно? Через отдельный поток? Мне тоже интересно как. А то давно хочу предложить метод ухода от перебора всех тайлов через проверку более крупных тайлов на меньших зумах, но это много писанины и будут ли его делать неясно. А самому ... не до того. Может это на форуме лучше обсуждать? [offtopic off] Если одинаковое выделение запускается за разное время для разных типов хранилища, то надо бы проверить что тормозит и вылетает, создание итератора (подсчёт количества тайлов в полигоне) или уже далее, "открытие БД" (не уверен что под этим подразумевается). Приложите образец выделения, на котором есть существенная разница в времени запуска и проверять ...

(0009089) vdemidov (manager) 30-09-2012 19:40	>>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень. > Как именно? Через отдельный поток? Нет конечно. Чисто алгоритмически это количество тайлов в области просчитывается за логарифмическое время от площади области. >Мне тоже интересно как. А то давно хочу предложить метод ухода от перебора всех тайлов через проверку более крупных тайлов на меньших зумах, но это много писанины и будут ли его делать неясно. А самому ... не до того. Да. Что-то вроде этого. Оно у меня даже реализованное почти есть. Посмотри в отедльном репо юнит u_PoligonToTileIndexer.pas если интересно.

(0009090) zed (manager) 30-09-2012 19:55 edited on: 30-09-2012 20:00	Даже супер-совершенный алгоритм будет отнимать какое-то время, т.е. всё-равно остаётся вероятность появление глюка с зависанием САСа. Т.е. кроме улучшения собственно алго, нужно ещё и саму логику работы качалки изменить и не заставлять её висеть, пока идут расчёты (завести отдельный пул потоков на это дело). P.S. Я когда-то пытался использовать AsyncCalls - можно воспользоваться, дабы для каждой мелочёвки не заводить свой пул.

(0009093) Parasite (administrator) 01-10-2012 03:54	>А вот и не правда! Этот глюк одинаково воспроизводится на любом типе кэша и это именно тормоз подсчёта тайлов сложного выделения (непрямоугольного), при большом количестве тайлов. Я могу записать видео, собссно. При моих объемах скачки и параллельном тикете об останавливании закачек - я этот процесс наблюдаю помногу, ежедневно, и знаю наизусть. При тайловом кэше: выделение (допустим, весь мир на 15м зуме - это много миллионов тайлов)->открывается окошечко закачки (уже с цифрами)->ТУТ ЖЕ начинают бежать строки о наличии в кэше. Беркли: выделение (допустим, весь мир на 15м зуме - это много миллионов тайлов)->открывается окошечко закачки (БЕЗ цифр)->стоИт только рамка от окошечка (винт в это время напряжно работает, и если вот тут стопорнуть - то и будет сабжевый зависон)->так оно стоит кучку минут, всякую фигню обо мне думает (вместо циферок статистики по тайлам пока что показываются тильды "~")->появляются все циферки и начинают бежать строки о наличии в кэше. Вот тут уже можно отменять. Это наблюдается при БОЛЬШИХ кэшах в беркли - от десятка гигабайт и выше по нарастающей. При мелких кэшах беркли - всё практически мгновенно. Кстати, то же самое (долгая инициализация) и просто при свежем старте саса, в прошлый раз закрытом где-то на глубоком зуме - и при старте он восстанавливает прошлый вид окна и соответственно сразу хочет открытия этого болшогт глубоко-зумного кэша. Тоже проходит какое-то время (заметно более долгое чем с тайловым кэшем) пока картинка появляется... Могу разогнать FileMon и посмотреть, что же именно оно читает в это время. Скажи, если надо. >Никаких индексов БД не считывает... Значит хранилище типа Беркли доставляет дополнительных тормозов при инициализации себя уже после подсчета числа тайлов, и просто накладывается на процесс старта закачки по ходу дела. При тайловом кэше подсчет того же выделения на том же зуме выполняется мгновенно, повторюсь. Там циферки TOTAL в окошке появляются сразу. И вообще, не вижу причин подсчитывать что-то несколько минут на весьма простом квадратном выделении всего мира на одном зуме - я в уме эти Х*Y быстрее посчитаю, даже с миллионами. :) >Даже супер-совершенный алгоритм будет отнимать какое-то время, т.е. всё-равно остаётся вероятность появление глюка с зависанием САСа. Глюк появляется не от внутренней работы саса, а от попытки прерывания пользователем. То есть, подозреваю, что алгоритм не отрабатывает прерывание и нормальный выход из себя любимого - и "теряется в астрале" буде прерван сасом. Если ничего не трогать - то всё работает как надо. Но программерам таки виднее. :)

(0009094) zed (manager) 01-10-2012 06:37	>Могу разогнать FileMon Разгони. И ещё посмотри в окошке DebugInfo сколько там тратится времени на считывание тайлов из кэша. Смотреть желательно сразу же после длительного старта САСа.

(0009097) Dima2000 (developer) 01-10-2012 21:08	>И вообще, не вижу причин подсчитывать что-то несколько минут на весьма простом квадратном выделении всего мира на одном зуме Ну это вопрос отдельный, я не вижу особого смысла ускорять подсчёт для лишь прямоугольных выделений, слишком частный случай, тем более что и так быстро (по вашим же словам, при файловом кэше). Хотя это и довольно просто: проверить полигон на ровно 5 точек, проверить тайловые координаты всех точек на попарное точное совпадение (тут будет аж 8 вариантов! 4 варианта в каком углу начинается полигон и 2 варианта обхода) - значит прямоугольник. Писать столько кода? А надо ли? Тормоза с беркли появляются уже потом, после подсчёта, но до вывода текста в форму. Так что да, зависание именно из-за каких-то операций с беркли.

(0009100) Parasite (administrator) 02-10-2012 04:05	>я не вижу особого смысла ускорять подсчёт для лишь прямоугольных выделений, слишком частный случай >... >Писать столько кода? А надо ли? Ускорять подсчет никто и не просит - просят исключить зависон САСа при нажатии на "ОТМЕНИТЬ", когда один случайный тычок может поставить раком кучку идущих параллельно закачек в том же САСе. Я даже не против что оно по несколько минут думает перед началом скачки - и пусть бы ее, это весьма малая кровь за юзание базовода...лишь бы не висло! Оно ж при зависании еще и соседний кэш бьет, если рядом идет скачка в беркли в том же сасе. :( Да, и на тайловом кэше всё считается практически моментально НА ТОМ ЖЕ ВЫДЕЛЕНИИ ТОГО ЖЕ ЗУМА ТОЙ ЖЕ КАРТЫ (они у меня, собссно, в отдельных файлах - так что за идентичность выделений ручаюсь). Может ведь, когда захочет... :) Тормоза идут откуда угодно еще, но не из подсчета тайлов в полигоне. PS: сегодня будем потестировать с ФайлМоном - чего же оно там тормозит при начале скачки...

(0009106) vdemidov (manager) 02-10-2012 08:20	Проверишь в завтрашней ночнушке. Поправил пару мелочей, которые могли влиять.

(0009134) Parasite (administrator) 03-10-2012 10:19 edited on: 03-10-2012 10:24	>Проверишь в завтрашней ночнушке. Поправил пару мелочей, которые могли влиять. Хорошо. Пока что - результаты вчерашнего ковыряния с файлмоном: Карта - Яндекс.Гибрид штатный, ЗМП в составе саса Полигон выделения - файл yahyb_RF.hlg отсюда: http://parasite.kicks-ass.org/vBulletin/showthread.php?t=106 Зум: 14й. Винда: 2003Serv, на ХП - то же самое. FS: NTFS Отркываем полигон, пытаемся грузиться в кэш Беркли штатным образом. некоторый кэш этого зума на диске уже присутствует (прокачано примерно 50% от полигона). Лог файловых операций с начала нажатия на кнопку СКАЧАТЬ: ----------- 8:54:28,6309297 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\SASPlanet.exe SUCCESS CreationTime: 05.09.2012 19:31:50, LastAccessTime: 18.09.2012 21:18:43, LastWriteTime: 04.09.2012 17:40:16, ChangeTime: 03.10.2012 8:40:45, AllocationSize: 4 866 048, EndOfFile: 4 864 000, FileAttributes: A 8:58:08,4739651 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,4740076 SASPlanet.exe 2776 IRP_MJ_READ I:\$Directory SUCCESS Offset: 0, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 8:58:08,5135749 SASPlanet.exe 2776 IRP_MJ_FLUSH_BUFFERS I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5161108 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5163968 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5170011 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS CreationTime: 29.09.2012 4:16:42, LastAccessTime: 29.09.2012 4:16:42, LastWriteTime: 03.10.2012 0:49:56, ChangeTime: 03.10.2012 0:49:56, AllocationSize: 76 410 880, EndOfFile: 76 409 856, FileAttributes: A 8:58:08,5172990 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 8:58:08,5176189 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 8:58:08,5178838 SASPlanet.exe 2776 IRP_MJ_FLUSH_BUFFERS I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5187117 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5189718 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS 8:58:08,5192970 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,5196242 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,5199284 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,5202163 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 8:58:08,5204961 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 512 8:58:08,5206229 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 8:58:08,5296399 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS 8:58:08,5299620 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,5302501 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Opened 8:58:08,5305253 SASPlanet.exe 2776 IRP_MJ_QUERY_VOLUME_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryInformationVolume, VolumeCreationTime: 05.04.2012 19:10:21, VolumeSerialNumber: E817-A748, SupportsObjects: True, VolumeLabel: USBo 8:58:08,5307832 SASPlanet.exe 2776 IRP_MJ_QUERY_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryAllInformationFile, CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, FileAttributes: A, AllocationSize: 33 554 432, EndOfFile: 33 551 360, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2000000004d5d, EaSize: 0, Access: Generic Read, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Byte 8:58:08,5310503 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 890 112, Length: 1 024 8:58:08,5313466 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 1 024 8:58:08,5316155 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 855 296, Length: 1 024 8:58:08,5318604 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 1 024, Length: 1 024 8:58:08,5321107 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 761 088, Length: 1 024 8:58:08,5323508 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 2 048, Length: 1 024 8:58:08,5325939 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS 8:58:08,5329028 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A 8:58:08,5331962 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Opened 8:58:08,5335071 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 8:58:08,5337693 SASPlanet.exe 2776 IRP_MJ_QUERY_VOLUME_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryInformationVolume, VolumeCreationTime: 05.04.2012 19:10:21, VolumeSerialNumber: E817-A748, SupportsObjects: True, VolumeLabel: USBo 8:58:08,5340048 SASPlanet.exe 2776 IRP_MJ_QUERY_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryAllInformationFile, CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, FileAttributes: A, AllocationSize: 33 554 432, EndOfFile: 33 551 360, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2000000004d5d, EaSize: 0, Access: Generic Read/Write, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Byte 8:58:08,5342803 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 11 173 888, Length: 1 024 8:58:08,5345862 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 3 072, Length: 1 024 8:58:08,5348322 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 683 264, Length: 1 024 8:58:08,5350910 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 30 538 752, Length: 1 024 8:58:08,5351060 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 30 535 680, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 8:58:08,5480376 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 684 288, Length: 1 024 8:58:08,5482855 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 7 087 104, Length: 1 024 .......итд ----------- Явно виден гап в 4 минуты (!) при старте операций - строки 1 и 2 в логе, в кое время САС просто стоит и ничего не делает. Загрузка камня при этом не меняется, так что явно ничего не считает настолько усиленно 4 минуты... Скрин этого процесса (сабжевый, который и нельзя прерывать а то зависнет) - в шапке. Старт того же самого, но в тайловый кэш - начинается, как и следовало ожидать, мгновенно.

(0009167) vdemidov (manager) 05-10-2012 12:17	Ну так как, зависание все еще есть?

(0009174) Parasite (administrator) 05-10-2012 12:54	Сегодня буду тестить.

(0009229) Parasite (administrator) 07-10-2012 08:57 edited on: 07-10-2012 08:58	Потестил. Некоторое подвисание при отмене - осталось, но если подождать около минуты - то отрабатывает и выходит нормально. Жестко и навсегда САС уже не зависает, спасибо. Нельзя ли как-то его вообще исключить (чтобы выход осуществлялся мгновенно - как при тайловом кэше)? Неизвестно, как этот минутный коматоз всей программы может повлиять на параллельно идущие закачки в Беркли - возможно, что там тайминги на операции или еще что-то...Ерроров вроде не вылазит, но мало ли. PS: долгий старт перед началом первой закачки, тот что на скрине вверху - остался.

(0009233) zed (manager) 07-10-2012 10:01	Я никак не могу понять, как у тебя тайловый кэш стартует мгновенно? Там же ж выполняется один и тот же код по подсчёту количества тайлов, причём вне зависимости от типа выделения. Хоть мега-сложное, хоть простое квадратное - идёт тупой перебор: while Next(VTile) do begin Inc(FTilesTotal); end; Вот он и тормозит. На любом типе кэша (да и кэш тут совершенно ни при чём, тебе ж FileMon всю правду показал!).

(0009239) Parasite (administrator) 07-10-2012 10:37 edited on: 07-10-2012 10:38	>Я никак не могу понять, как у тебя тайловый кэш стартует мгновенно? А я откуда знаю? Я не в теме программинга сабжа - я лишь констатирую факт. Если бы меня тайловый кэш стартовал по 4 минуты - я был бы первым, кто про это написал бы. :) Дело в том, что при юзании Беркли - сас 4 минуты просто стоИт и ничего не делает. Он НЕ считает тайлы по 4 минуты - он делает что-то еще, уникальное именно для беркли-кэша. И это не файловые операции. PS: а число УЖЕ подсчитанных тайлов выводится сразу при загрузке выделения, ПЕРЕД стартом закачки (в том самом окне со вкладками "СКАЧАТЬ\СФОРМИРОВАТЬ\СКЛЕИТЬ...". Там все уже подсчитано, и оно выводится моментально для обоих типов кэша. При нажатии СКАЧАТЬ - тайловый кэш стартует моментально, а беркли - >4мин, см.лог файлмона выше).

(0009242) zed (manager) 07-10-2012 10:48	Скажу так: описанная тобой ситуация, чтобы тормозил только Беркли - не воспроизводится. У меня тормозит одинаково на любом кэше: 1. Распаковываем чистую ночнушку. Сегодняшнюю. 2. Ничё не трогаем, находимся на z1, в меню Операции - Операции с выделенной областью, выбираем "По размеру экрана" -> Скачать -> ставим z19 3. Безнадёжно висим до второго пришествия, без возможности отмены Вот только скажи, что у тебя там всё стартует и отменяется мгновенно!

(0009243) Parasite (administrator) 07-10-2012 10:50	>идёт тупой перебор: Возможно, как раз этот тупой перебор как раз и пролетает практически мгновенно (особенно на мое 8и-головой серверной конфигурации и соответствующей весьма быстрой FullBuffered-RAM с контролем\коррекцией ошибок), а вот ПОТОМ что-то весьма задумчивое накладывается поверх, и происходит это именно при Беркли-кэше (а тайловые операции уходят по другой ветке)...?

(0009244) Parasite (administrator) 07-10-2012 10:51	>Вот только скажи, что у тебя там всё стартует и отменяется мгновенно! 19й не пробовал. На 14м, тайловый кэш - стартует за <1 sec. Беркли - >4мин. Могу проверить на 19м если хочешь.

(0009246) zed (manager) 07-10-2012 10:53	Хочу. Можешь прямо под отладчиком и проверить. Брекпоинтов ты уже понаставил, сейчас запусти новую закачку и смотри в каких строках он будет надолго подвисать.

(0009254) Parasite (administrator) 07-10-2012 11:13	19й уровень. старт всего 19го уровня в Tile: меньше минуты, загрузка 100% по ОДНОМУ камню в ВиртБоксе. Уже поехало качать. старт всего 19го уровня в Berkeley: >10 минут, до сих пор думает, загрузка 100% по ОДНОМУ камню (и это без виртуалки).

(0009260) zed (manager) 07-10-2012 12:11	Мда, дошло до того, что вот эта вот строка: VTileIterator := TTileIteratorByPolygon.Create(FPolyProjected); в TThreadDownloadTiles.Execute для тайлового кэша отрабатывает быстрее, чем для Беркли... казалось бы, а причём тут вообще тип кэша?

(0009261) vdemidov (manager) 07-10-2012 12:20	Почему ты думаешь, что там затык именно на строке VTileIterator := TTileIteratorByPolygon.Create(FPolyProjected); ???? С чего ты вообще это взял?

(0009262) zed (manager) 07-10-2012 12:24	Это Parasite так говорит в аське). Он поставил бряк сразу после этой строки и кэш Беркли доходит до неё гораздо медленнее, чем тайловый.

(0009263) vdemidov (manager) 07-10-2012 12:26	Так может там пауза просто где-то раньше. Пусть поставит бряк перед ней. :)

(0009265) Parasite (administrator) 07-10-2012 15:49	Недолго музыка играла... При попытке отмены случайно начатого z19 на весь мир - всё опять качественненько зависло, и так и не разродилось хотя честно ждал >3 часа. Ну и до кучи (при окончании терпения и снятии через 3 кнопки) побило соседний качаемый в Беркли кэш. Тикет в силе. :(

(0009272) vdemidov (manager) 07-10-2012 20:22	Посмотри именно в отладчике, раз уж он у тебя есть на чем оно застопорилось. Нужно нажать Pause в делфе, а потом внизу в окне тредов двойным кликом выбрать главный тред. И в стеке смотреть какие функции сейчас выполняются.

(0009277) Parasite (administrator) 08-10-2012 04:57	>Посмотри именно в отладчике, раз уж он у тебя есть на чем оно застопорилось. Отладчик в виртуалке - а в ней нету большого беркли-кэша, и свободного места нет чтобы скопировать в туда. Впрочем, сабж повторяется на ура и без виртуалки - по совету зеда: выбрать весь мир, и попробовать начать качать на 19м уровне или глубже. Получаем висящее окошко по типу приложенного выше (качать не начинает, и ждать можно доооолго). Если там нажать ВЫХОД - то будет сабжевый зависон на как минимум 3 часа, про который я и писал вчера. Можешь попробовать у себя. А различия во времени старта при разных типах кэша - буду сегодня еще тестить. Напишу, если что найду. Этот тикет не такой критичный, как соседний 1264 - с тем вообще жизни нет... :(

(0009403) vdemidov (manager) 09-10-2012 13:18	Исправил. Теперь интерфейс не подвисает. Но имейте в виду, если выделить весь мир и нажать закачку на 19 зуме, то считать оно будет ооооочень долго. Отменить можно. Но это только закроет окошко закачки, а сам вычислительный тред будет жить пока или не закончит расчет, или не будет закрыто все приложение.

(0009405) vasketsov (manager) 09-10-2012 13:50	>сам вычислительный тред будет жить пока или не закончит расчет, или не будет закрыто все приложение А нельзя ему какой-то флаг впендюрить, чтобы можно было его понюхать и прекратить расчёт, а не ждать, пока "или не закончит расчет, или не будет закрыто все приложение". зы. Ура, хинты пропали ))

(0009406) zed (manager) 09-10-2012 13:55	Вкинуть в TTileIteratorByPolygon экземпляр CancelNotifier да и всё? Можно даже параметром по-умолчанию со значением nil.

(0009411) vdemidov (manager) 09-10-2012 14:02	Лучше пусть кто-то сделает нормальный алгоритм. Эффективнее будет.

(0009412) zed (manager) 09-10-2012 14:04	Кто-то ж говорил, что уже почти всё сделано и лежит себе в тестовом репо ;)

(0009418) vdemidov (manager) 09-10-2012 14:19	Да лежит. Но настроения доделывать просто нету :( Меня эта особенность работы совсем не напрягает.

Users who viewed this issue
User List	Anonymous (4123x)
Total Views	4123
Last View	21-11-2024 09:32

Issue History
Date Modified	Username	Field	Change
28-09-2012 05:06	Parasite	New Issue
28-09-2012 07:44	Tolik	Summary	Попытка отмены задания при идущих операциях Berkly -> зависание САСа => Попытка отмены задания при идущих операциях Berkeley -> зависание САСа
28-09-2012 07:44	Tolik	Description Updated	View Revisions
28-09-2012 14:55	Dima2000	Note Added: 0009067
28-09-2012 15:12	vdemidov	Note Added: 0009069
28-09-2012 15:53	Dima2000	Note Added: 0009070
29-09-2012 05:23	Parasite	Note Added: 0009072
29-09-2012 05:38	Parasite	Note Added: 0009074
29-09-2012 12:41	vdemidov	Note Added: 0009076
29-09-2012 12:41	vdemidov	Status	new => feedback
29-09-2012 13:38	Parasite	Note Added: 0009077
29-09-2012 13:38	Parasite	Status	feedback => new
29-09-2012 13:43	Parasite	Note Edited: 0009077	View Revisions
30-09-2012 14:57	zed	Note Added: 0009086
30-09-2012 15:13	Dima2000	Note Added: 0009087
30-09-2012 17:16	Tolik	Status	new => acknowledged
30-09-2012 19:40	vdemidov	Note Added: 0009089
30-09-2012 19:55	zed	Note Added: 0009090
30-09-2012 20:00	zed	Note Edited: 0009090	View Revisions
01-10-2012 03:54	Parasite	Note Added: 0009093
01-10-2012 06:37	zed	Note Added: 0009094
01-10-2012 21:08	Dima2000	Note Added: 0009097
02-10-2012 04:05	Parasite	Note Added: 0009100
02-10-2012 08:20	vdemidov	Note Added: 0009106
02-10-2012 08:20	vdemidov	Status	acknowledged => feedback
03-10-2012 10:19	Parasite	Note Added: 0009134
03-10-2012 10:19	Parasite	Status	feedback => new
03-10-2012 10:19	Parasite	Note Edited: 0009134	View Revisions
03-10-2012 10:20	Parasite	File Added: Clipboard0222.jpg
03-10-2012 10:21	Parasite	Note Edited: 0009134	View Revisions
03-10-2012 10:24	Parasite	Note Edited: 0009134	View Revisions
05-10-2012 12:17	vdemidov	Note Added: 0009167
05-10-2012 12:17	vdemidov	Status	new => feedback
05-10-2012 12:54	Parasite	Note Added: 0009174
05-10-2012 12:54	Parasite	Status	feedback => new
05-10-2012 12:55	vdemidov	Status	new => feedback
07-10-2012 08:57	Parasite	Note Added: 0009229
07-10-2012 08:57	Parasite	Status	feedback => new
07-10-2012 08:58	Parasite	Note Edited: 0009229	View Revisions
07-10-2012 10:01	zed	Note Added: 0009233
07-10-2012 10:37	Parasite	Note Added: 0009239
07-10-2012 10:38	Parasite	Note Edited: 0009239	View Revisions
07-10-2012 10:48	zed	Note Added: 0009242
07-10-2012 10:50	Parasite	Note Added: 0009243
07-10-2012 10:51	Parasite	Note Added: 0009244
07-10-2012 10:53	zed	Note Added: 0009246
07-10-2012 11:13	Parasite	Note Added: 0009254
07-10-2012 12:11	zed	Note Added: 0009260
07-10-2012 12:20	vdemidov	Note Added: 0009261
07-10-2012 12:24	zed	Note Added: 0009262
07-10-2012 12:26	vdemidov	Note Added: 0009263
07-10-2012 15:49	Parasite	Note Added: 0009265
07-10-2012 20:22	vdemidov	Note Added: 0009272
08-10-2012 04:57	Parasite	Note Added: 0009277
08-10-2012 13:26	vdemidov	Status	new => confirmed
08-10-2012 13:28	vdemidov	Product Version	.Nightly => 110418
08-10-2012 13:28	vdemidov	Target Version	=> 121010
08-10-2012 13:28	vdemidov	Summary	Попытка отмены задания при идущих операциях Berkeley -> зависание САСа => Попытка отмены задания закачки при долгих операциях внутри закачки -> зависание САСа
08-10-2012 13:29	vdemidov	Description Updated	View Revisions
09-10-2012 08:35	vdemidov	Assigned To	=> vdemidov
09-10-2012 08:35	vdemidov	Status	confirmed => assigned
09-10-2012 13:18	vdemidov	Note Added: 0009403
09-10-2012 13:18	vdemidov	Status	assigned => resolved
09-10-2012 13:18	vdemidov	Fixed in Version	=> 121010
09-10-2012 13:18	vdemidov	Resolution	open => fixed
09-10-2012 13:50	vasketsov	Note Added: 0009405
09-10-2012 13:55	zed	Note Added: 0009406
09-10-2012 14:02	vdemidov	Note Added: 0009411
09-10-2012 14:04	zed	Note Added: 0009412
09-10-2012 14:19	vdemidov	Note Added: 0009418

Relationships

SASGIS