View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001592SAS.Планета[All Projects] Багpublic28-09-2012 05:0609-10-2012 14:19
ReporterParasite 
Assigned Tovdemidov 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformWindowsOSServerOS Version2003
Product Version110418 
Target Version121010Fixed in Version121010 
Summary0001592: Попытка отмены задания закачки при долгих операциях внутри закачки -> зависание САСа
DescriptionПри попытке отмены задания на скачку в то время, когда идут операции по подсчету количества тайлов в большом полигоне - получаем зависание всего САСа.
Steps To Reproduce1. Наработать достаточно большой кэш в Беркли.
2. Дать очередное задание САСу на прокачку в этот же кэш (с пропуском уже существующего).
3. При начале отработки задачи - САС на некоторое время задумается (не виснет, а читает индексы кэша либо еще что-то подготавливает. Работает, то бишь). Строки в окне закачки в этот момент еще не появляются - оно чистое.
4. Это время подготовки зависит, как я понимаю, от размера всего кэша\области выделения. На больших регионах может занимать несколько минут.

5. Если в этот момент нажать в том окне "ОТМЕНА" - получаем жесткое зависание всего САСа. Надо таки дождаться пока САС начнет отрабатывать задание (когда побегут строки с инфой о наличии тайла в кэше), и только тогда отменять.
TagsNo tags attached.
Attached Filesjpg file icon Clipboard0222.jpg [^] (39,279 bytes) 03-10-2012 10:20

- Relationships

-  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 (3019x)
Total Views 3019
Last View 10-08-2020 08:46

- 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



Copyright © 2007 - 2020 SAS.Planet Team