|
Notes |
|
|
|
|
Вот опять залипло. "Queue: 0". И почемуто только OSM MAPNIK и Mapsurfer. Слои Bing или OSM CycleMap не глючат. Перезапуск программы решает проблему. |
|
|
|
(0013453)
|
|
gma
|
|
29-12-2013 08:32
|
|
Аналогично. Всё собирался создать инц., да грешил на свою машину. Если достаточно долго (мин. 5--10) сёрфить по любой карте -- она сначала начинает тормозить, а потом перестаёт скачиваться вовсе. При этом загрузка по области (если запущена параллельно) продолжается, как ни в чём не бывало. Замечено в течение последнего года на разных версиях, в т.ч. ночнушках. Перезагрузка помогает всегда.
Win-vistahome. |
|
|
|
(0013456)
|
|
zed
|
|
29-12-2013 11:14
|
|
|
Проверьте воспроизводимость на текущей ночнушке. |
|
|
|
|
|
|
|
(0013474)
|
|
zed
|
|
31-12-2013 11:28
|
|
|
У меня не воспроизводится. Можно по шагам, на чистой ночнушке? |
|
|
|
|
Сложно объяснить... Просто выбираю OSM MAPNIK и дергаю карту туда сюда на монике с разрешением 1680*1080. В какойто момент карта перестает загружаться. Переключаюсь на mapsurfer. Опять дергаю туда-сюда. И эта зависает. Переключение опять на MAPNIK н помогает.
Может сделать каокй-то билд, к которому можно было бы подключиться дебагером и получить дамп? А дамп потом можно было бы посмотреть у тебя на машине. |
|
|
|
(0013477)
|
|
zed
|
|
31-12-2013 11:41
|
|
В ночнушке идёт SASPlanet.Debug.exe который ловит ошибки, но если там что-то тихо-мирно просто висит, то тут мало что поможет.
Раз проблема только на OSM, наверное имеет смысл сделать дамп запросов на сервер любым снифером. Может там что-то крайне неожиданное прилетает от сервера и сокет просто остаётся в подвешенном состоянии. И можно попробовать в zmp ограничить или наоборот увеличить число подключений к серверу (MaxConnectionsCount) и прописать в хидерах "Connection: Close".
Но не факт, что проблема в http-стеке. Может просто глючит очередь или ещё в одном из тысячи возможных мест... |
|
|
|
|
|
А еще, возможно просто есть отличие между отправляемым САС.Планетой запросом и запросом из браузера. И сервер по этой разнице начинает банить такие запросы. |
|
|
|
|
|
Может какие-то логи добавить для отладки? |
|
|
|
(0013535)
|
|
gma
|
|
11-01-2014 08:03
|
|
|
"У меня не воспроизводится. Можно по шагам, на чистой ночнушке?" вчерашняя 1400110 -- воспроизводится, м.б. чуть позже, чем на прошлогодних. По шагам: запускаю САС, выбираю карту (в моём случае это любые спутники, вчера тестировал на Imagery2) и стрелочками двигаю карту (z16, если важно) вверх, вниз, влево, вправо. Минут 5--7 всё летает, потом начинает подтормаживать, а минут через 15--20 от начала и вовсе встаёт (именно эта карта, которая тестировалась -- остальные поначалу помогают растормаживать и с ними всё нормально, а потом только другие и качаются). Принудительная загрузка конкретных тайлов (на правой кнопке) работает, т.е. тормоза не абсолютные, а только на сёрфинг. И, как я говорил выше, закачка по областям тоже работает нормально. |
|
|
|
(0013536)
|
|
zed
|
|
11-01-2014 08:10
|
|
> и стрелочками двигаю карту (z16, если важно) вверх, вниз, влево, вправо
Так может клинит именно это перемещение? Плавную анимацию отключать пробовали? |
|
|
|
(0013549)
|
|
zed
|
|
12-01-2014 14:38
|
|
|
Да, есть такое-то странное поведение на этой карте. До полного "залипания" довести ситуацию не получилось, но то, что тайлы начинают качаться медленно и не все, это факт. Причём, все запросы ушедшие на сервер возвращаются с 200 ОК, но вот очередь тайлов может быстренько скатиться до 0 (с 32-х), скачав при этом всего несколько тайлов. |
|
|
|
(0013550)
|
|
zed
|
|
12-01-2014 15:13
|
|
Понял почему счётчик слетает до нуля. Если загрузка тайлов очень медленная (по 15 сек. на тайл), то по TTL (30 сек.) этот поток будет успешно прибит и очередь обнулится. Но вопрос, почему эти тайлы начинают вдруг так медленно качаться, остаётся открытым.
|
|
|
|
(0013555)
|
|
gma
|
|
12-01-2014 17:07
|
|
"Так может клинит именно это перемещение?" -- нет, программе равно, чем её перемещают, мышкой или клавой.
"Плавную анимацию отключать пробовали?" -- не отключается. Там есть "Аним. при масштабировании" -- она у меня выключена по умолчанию. И есть "Движение по инерции" -- вот оно, будучи выключенным, всё равно продолжается. Вер: 140110.7793.
Кстати, обратный счётчик показывает цены на яхты, но где-то не здесь. Впрочем, это отдельный баг и оформлять его нужно соотв. ) |
|
|
|
(0013556)
|
|
zed
|
|
12-01-2014 17:09
|
|
|
Со счётчиком всё в порядке. |
|
|
|
(0013557)
|
|
zed
|
|
12-01-2014 17:58
|
|
|
В общем, полечил загадочное поведение 0002301:0013549, а по поводу снижения скорости загрузки, я без понятия. У меня это торможение наблюдается практически сразу после запуска (RAM-кэш + активная смена зума и позиции, не дожидаясь окончания загрузки тайлов). Но снифером видно, что все потоки качают, но сервер отдаёт очень медленно. Ну, или может это мы вдруг начинаем спать между приёмом пакетов - но с чего бы? Тем более, что при закачке того же гугла всё летает. |
|
|
|
|
|
И после рестарта приложения все опять работает без тормозов. И выкачка региона тайлов, как говорит gma, работает нормально. Чем отлиается реализация выкачки региона и экрана? |
|
|
|
(0013559)
|
|
zed
|
|
12-01-2014 18:13
|
|
> И после рестарта приложения все опять работает без тормозов.
Перезапуск не обязательное условие. Можно просто переключиться на другую карту и/или подождать некоторый таймаут, пока SAS не закроет все соединения с этим сервером или пока сервер не решит, что можно уже и не тормозить.
> И выкачка региона тайлов, как говорит gma, работает нормально. Чем отлиается реализация выкачки региона и экрана?
У меня эти вещи работают одинаково медленно. И реализация там ничем не отличается - закачка идёт через одну и туже очередь. |
|
|
|
|
|
С перезапуском ты продолжаешь работать с той же картой. То есть, врядли это тормоза на стороне сервера. Можно посчитать задержку между прибытием пакета на сетевуху и появлением ее на экране. |
|
|
|
(0013561)
|
|
zed
|
|
12-01-2014 18:20
|
|
А вот у меня, перезапуск не помогает. Только что проверил. Видно я сегодня за вечер уже порядком поднадоел серверу.
> Можно посчитать задержку между прибытием пакета на сетевуху и появлением ее на экране.
Вы для начала, посчитайте скорость прибытия пакетов на сетевуху. Т.е. нужны убедительные доказательства, что это тормозит не сервер и что это не проявления своеобразного бана. А то, что в браузере всё работает - совсем не показатель. Там же куки и все дела, а тут - робот. |
|
|
|
|
|
Дело в том, что скорость прибытия пакетов на сетевуху зависит от скорости их выкачки. Если приложение тормозит, то и на той стороне посылают с задержкой. |
|
|
|
|
Ок. попробую посчитать скорость ответа на HTTP запрос
|
|
|
|
(0013564)
|
|
zed
|
|
12-01-2014 18:24
|
|
|
Поставьте кэширующий прокси между SAS и сервером. Пускай прокси выкачивает без задержек, если у него получится и отдаёт тайлы SAS-у. |
|
|
|
|
Похоже, тормозит именно SAS. Ответ от WEB сервера приходит сразу. А вот новые запросы SAS отправляет с задержкой. Ща выложу лог проксисервера и попробую поснифить.
Хм... может в системе не хватает ресурсов. Может надо стараться переиспользовать сокеты? |
|
|
|
(0013566)
|
|
zed
|
|
12-01-2014 19:24
|
|
|
|
|
|
|
Вот к примеру залип на 3 сек начиная с "!-<12/01 21:11:25". |
|
|
|
|
>Keep-Alive же?
В логе видно, как выделяются постоянно новые ТЦП порты |
|
|
|
|
Запись "!->12/01 21:11:27 [127.0.0.1:61011>3128] (t3 421) >Proxy in:7426 out:253
" похоже означает закрытие сокета на строне SAS. |
|
|
|
(0013570)
|
|
zed
|
|
12-01-2014 19:41
|
|
> Ответ от WEB сервера приходит сразу
Приход ответа, это не мгновенная операция в любом случае. И из ваших логов можно только увидеть, когда ответ начал приходить, но не видно, когда же он пришёл целиком. У меня некоторые тайлы по 20 секунд грузились и в снифере было хорошо видно, как приходят "пакеты". |
|
|
|
(0013571)
|
|
zed
|
|
12-01-2014 19:42
|
|
> В логе видно, как выделяются постоянно новые ТЦП порты
Значит виноват прокси. Через снифер порты не выделяются и я наблюдаю честный Keep-Alive (OSM MAPNIK). |
|
|
|
(0013572)
|
|
zed
|
|
12-01-2014 19:45
|
|
|
И для тестов лучше в zmp прописать MaxConnectToServerCount=1 и в скрипте убрать генерирование a/b/c префиксов в url (и слать всегда, скажем, на "а"). |
|
|
|
(0013573)
|
|
zed
|
|
12-01-2014 19:59
|
|
У меня, кстати, было опять начало качать быстро, но насёрфив около 800 тайлов оно таки начало тормозить. Хотя всё шло в один поток и с Keep-Alive. И после перезапуска SAS, оно хоть и начало ходить через другой порт, но всё так же медленно, с самого же первого тайла.
Так что тут (конкретно на карте OSM MAPNIK), SAS однозначно ни при чём.
|
|
|
|
|
|
Поймал зависон. Ваершарк показвыает, что никаких пакетов со стороны SAS не уходит. У мну WinXP SP3. |
|
|
|
|
А через 58сек соединение с OSM закрылось. На попытки подвигать карту OSM никак не реагирует. Закрытие подключения инициировал OSM.
|
|
|
|
(0013576)
|
|
zed
|
|
12-01-2014 21:06
|
|
> никаких пакетов со стороны SAS не уходит
Это скорее всего баг с очисткой очереди 0002312 - нужно проверять в завтрашней ночнушке.
> На попытки подвигать карту OSM никак не реагирует
Т.е. не отвечает на запросы или SAS их не шлёт? |
|
|
|
|
|
SAS не завис. На мышь и клаву реагирует. Просто не шлет запросы на веб сервер. |
|
|
|
|
А этот баг с очисткой очереди, как-то объясняет, почему, если переключиться на другую карту, то она работает?
|
|
|
|
(0013579)
|
|
zed
|
|
12-01-2014 21:11
|
|
|
Да. Но этот баг на смещение карты не завязан, т.е. закачка должна была возобновиться. |
|
|
|
|
|
Я ждал минуты 4-5. Закачка не возобновилась. |
|
|
|
(0013581)
|
|
zed
|
|
12-01-2014 21:16
|
|
Она должна была начаться мгновенно после смещения карты (если конечно в кэше тайлов нету).
А по логу (sas-osm) я никаких замечаний не вижу. |
|
|
|
|
> Она должна была начаться мгновенно после смещения карты (если конечно в кэше тайлов нету).
Я переключил SAS в режим Internet. Кеш не должен был использоваться. Но по ощущениям, SAS еще кеширует в памяти. Еще я в ZMP добавил MaxConnectToServerCount=1, но подключений было 3шт (судя по pcap файлу)
> А по логу (sas-osm) я никаких замечаний не вижу.
Ага. Ничего необычного. Но на последнем тайле все наглухо остановилоась и SAS больше не пробовал что-либо качать. |
|
|
|
(0013583)
|
|
zed
|
|
12-01-2014 21:27
|
|
>но подключений было 3шт (судя по pcap файлу)
Потому что у сервера алиасы a/b/c:
a.tile.openstreetmap.org
b.tile.openstreetmap.org
c.tile.openstreetmap.org
и я рекомендовал исправить скрипт, чтобы оно всегда шло на a.tile.openstreetmap.org
>Но по ощущениям, SAS еще кеширует в памяти
Да, где-то в конфигах есть переменная TileMaxAgeInInternet |
|
|
|
|
|
Предлагаю нашпиговать SAS логами и выдать мне на растерзание. |
|
|
|
(0013585)
|
|
zed
|
12-01-2014 21:37
(edited on: 12-01-2014 21:38) |
|
Надо подумать, что именно мониторить.
Попробуйте завтра взять ночнушку, включить у карты RAM-кэш и в режиме интернет+кэш погонять до посинения.
Почему RAM-кэш, а не просто режим Интернет? Потому что у первого есть конфиги, доступные через zmp:
UseMemCache - использовать кэш в памяти (при CacheType=9 (RAM-кэш) отключение данной опции приведёт к ошибке), включено по-умолчанию
MemCacheCapacity - количество тайлов кэшируемых в память. По-умолчанию = 100
MemCacheTTL - время жизни тайлов (в миллисекундах), кэшируемых в память. По-умолчанию = 60000 мс. (1 мин.)
MemCacheClearStrategy - стратегия очистки (по TTL) кэшируемых в память тайлов. Принимает значения: 0 - удалять ВСЕ тайлы из мем-кэша, если истёк TTL у самого СТАРОГО тайла; 1 - удалять ВСЕ тайлы из мем-кэша, если истёк TTL у самого МОЛОДОГО тайла; 2 - удалять только те тайлы, у которых истёк TTL. По-умолчанию включён режим 1.
RestartDownloadOnMemCacheTTL - автоматически перезакачивать тайлы в пределах видимой области экрана при очистке мем-кэша (работает только если UseMemCache=1). По-умолчанию отключено.
Описание формата пользовательских карт zmp
|
|
|
|
(0013586)
|
|
zed
|
|
12-01-2014 21:53
|
|
|
Кстати, в режиме Интернет, оно пишет в кэш и перезаписывает существующие тайлы. Возможно каким-то боком зависает запись в кэш, а все потоки его дружно ждут. |
|
|
|
|
|
Это объясняет, почему другие карты продолжают работать? |
|
|
|
|
Для включения RAM Cache нужно добавить в zmp только это?
UseMemCache=1 |
|
|
|
(0013589)
|
|
zed
|
12-01-2014 22:06
(edited on: 12-01-2014 22:07) |
|
> Это объясняет, почему другие карты продолжают работать?
Зависание кэша? Естественно - у каждой карты свой кэш и своя качалка.
> Для включения RAM
Для включения - достаточно в гуе зайти в настройки карты (Ctr+Alt+P) и выбрать "Тип кэша - ОЗУ". А в zmp можно уменьшить MemCacheTTL до 15000 (15 секунд) или количество кэшируемых тайлов. Но это уже на усмотрение.
|
|
|
|
|
|
|
|
(0013591)
|
|
zed
|
|
12-01-2014 22:11
|
|
|
И вдогонку, по тем же 3 кнопкам Ctr+Alt+P, в самом низу есть надпись: "Разрешено скачивание" и в поле - "Да". Так вот, когда оно перестанет качать, загляните сюда, возможно оно там что-то интересное напишет. |
|
|
|
|
|
Воспроизвел на SAS.Planet.Nightly.140113.7797. Кеш - RAM. Когда зависло, размер очерели == 0 и при перемещении карты не увеличивался. Похоже, что SAS не добавляет тайлы в очередь. |
|
|
|
|
Мне кажется, где-то увеличивается счетчик подключения к серверу и не декрементируется.
|
|
|
|
(0013595)
|
|
zed
|
|
13-01-2014 20:03
|
|
Приложил сборку для тестов. Запустить Dbgview.exe, затем SASPlanet.exe, добиться зависания и сбросить лог дебагера сюда. Дебажные сообщения выводятся только для одного класса TUiTileDownload, на всякий случай в архиве исходник этого класса, где видно когда и какие сообщения выводятся (и какие вообще могут быть).
Сообщения с текстом "Nothing to do", кроме "Nothing to do: if VNeedDownload" когда тайлы есть в кэше, следует рассматривать как крайне подозрительные. |
|
|
|
|
|
Во время загрузки в лог что-то должно выводиться? Я запустил, скачал несколко тайлов, но ничего не вижу в dbgview |
|
|
|
(0013597)
|
|
zed
|
|
13-01-2014 20:15
|
|
|
Да, должны бежать строчки очень активно. |
|
|
|
|
Не пишет. Моя программа пишет, а SAS - не пишет.
#include <Windows.h>
int main() {
OutputDebugString("123\n");
} |
|
|
|
(0013599)
|
|
zed
|
|
13-01-2014 20:28
|
|
Вот блин :(
Вариант - скачать виртуалку http://yadi.sk/d/bZ3bEBzMC2biN и попробовать запустить там. Тем более, там вы при желании сможете запустить SAS прямо под отладчиком и посмотреть как минимум на имена потоков и их наличие в момент бага. Ну и брекпоинты, тоже полезная вещь. |
|
|
|
|
|
файлы от 27.03.2013.. это точно последнее? |
|
|
|
|
|
У меня есть CBuilder6. Дай плз сурсы от SAS.Planet.Nightly.140113.7797 |
|
|
|
|
Нашел сурсы. Что выполняется при перемещении карты?
Где бряки ставить?
|
|
|
|
|
|
Мне кажется вы фигней занимаетесь. В первую очередь нужно проверить где затык: в сервере, подсистеме загрузки или в загрузчике видимой области. Последний отсекается очень просто. После того как тайлы качаться перестали нажимаем Ctrl-A и запускаем скачивание текущего экрана как области. Если качается, то ошибка именно в загрузке видимой области, если нет, то в подсистеме загрузки. |
|
|
|
(0013607)
|
|
zed
|
|
14-01-2014 09:19
|
|
>файлы от 27.03.2013.. это точно последнее?
В виртуалке - старые исходники и компоненты, но их легко обновить:
- зайти в папку c:\SASPlanet и выполнить в консоли 2 команды "hg pull" (затянуть свежие сорцы с сервера) и "hg update -C" (применить обновление и отбросить локальные изменения)
- зайти в папку C:\Program Files\CodeGear\RAD Studio\5.0\lib_sas, удалить папку pascalscript и выполнить те же 2 команды: "hg pull" и "hg update -C"
После этого можно запускать SASPlanet.dpr.
>У меня есть CBuilder6
Не подойдёт.
>Что выполняется при перемещении карты?
В u_UiTileDownload.pas вызывается TUiTileDownload.OnPosChange; Соответственно, поток который ставить тайлы в очередь закачки, будет называться TUiTileDownload (он создаётся вот так: VDownloadTask := TBackgroundTask.Create)
Очередь запросов в u_InterfaceQueue.pas, поток, который обрабатывает очередь - u_TileRequestQueueProcessorThread.pas (имя потока в дебагере TTileRequestQueueProcessorThread, количество потоков во время загрузки ограничено значением MaxConnectToServerCount). |
|
|
|
(0013608)
|
|
zed
|
|
14-01-2014 09:23
|
|
>нужно проверить где затык: в сервере, подсистеме загрузки или в загрузчике видимой области
Сервер уже исключили. И очень большое подозрение именно на загрузчика видимой области (читай второе сообщение 0002301:0013453), именно на него (TUiTileDownload) я и натыкал дебажных сообщений, чтобы понять, где там может быть затык.
У себя я так и не смог воспроизвести, поэтому вся надежда на dmytro_ovdiienko |
|
|
|
(0013610)
|
|
zed
|
|
14-01-2014 09:53
|
|
dmytro_ovdiienko
И да, если будете расставлять бряки в отладчике, то в папке Maps лучше оставить только одну карту, иначе в OnPosChange будут прилетать мусорные сообщения от всех остальных карт. |
|
|
|
|
>Сервер уже исключили. И очень большое подозрение именно на загрузчика видимой области (читай второе сообщение 0002301:0013453), именно на него (TUiTileDownload) я и натыкал дебажных сообщений, чтобы понять, где там может быть затык.
Ну так я и описал способ в этом убедиться на 100% даже без отладчика. |
|
|
|
(0013612)
|
|
zed
|
|
14-01-2014 10:14
|
|
|
Ну убедились, а дальше что? Как баг найти? |
|
|
|
|
|
Ок. Я сначала еще раз проверю, что поблема в выкачке. Потом буду дебажить. Хотя не уверен, что у меня получится это на виртуалке. На Win7, например, почему-то не воспроизводится. Может, это какаято особенность моей ОС. |
|
|
|
|
|
И мне нужны исходники того кода, с которым собирался Дебаг, который мне выдал zed. |
|
|
|
(0013615)
|
|
zed
|
|
14-01-2014 10:32
|
|
|
Я уже объяснил, как получить сорцы 0002301:0013607, а единственное отличие моего дебага - изменения в u_UiTileDownload.pas, который я также приложил в аттаче. Так что заменив его, вы получите идентичную копию сборки. |
|
|
|
|
> Ну убедились, а дальше что? Как баг найти?
Точно убедились? Я не уверен, что баг именно в TUiTileDownload. Не так уж много там кода. |
|
|
|
(0013617)
|
|
zed
|
|
14-01-2014 10:50
|
|
|
Тут одно из двух: либо прилетает OnPosChange и где-то в TUiTileDownload не обрабатывается, либо не прилетает и тогда проблема выше. |
|
|
|
|
> Тут одно из двух: либо прилетает OnPosChange и где-то в TUiTileDownload не обрабатывается, либо не прилетает и тогда проблема выше.
Если бы это было бы так, то не было бы такого:
> Вот опять залипло. "Queue: 0". |
|
|
|
(0013619)
|
|
zed
|
|
14-01-2014 11:41
|
|
|
Именно такое и было бы :) |
|
|
|
|
|
Я про "либо не прилетает" |
|
|
|
(0013621)
|
|
zed
|
|
14-01-2014 11:51
|
|
|
Да в обоих случаях счётчик будет стоять на нуле. Ты посмотри, где он увеличивается. |
|
|
|
|
|
Если бы не прилетало событие, тогда другие карты тоже бы не работали. Верно? |
|
|
|
(0013624)
|
|
zed
|
|
14-01-2014 13:04
|
|
|
Если карта вдруг не отписалась от уведомлений, то да. Вот и выходит, что затык в TUiTileDownload. |
|
|
|
|
|
|
|
(0013626)
|
|
zed
|
|
14-01-2014 13:38
|
|
|
Отписка происходит только в момент уничтожения карты (TUiTileDownload.Destroy), поэтому, практически - нет. |
|
|
|
(0013627)
|
|
gma
|
|
15-01-2014 08:40
|
|
|
"После того как тайлы качаться перестали нажимаем Ctrl-A и запускаем скачивание текущего экрана как области" -- Дождался затыка, запустил закачку области -- пошла на ура на хорошей скорости. Экран после этого всё равно не завёлся. |
|
|
|
|
|
Имхо чем пытаться починить TUiTileDownload лучше сразу его переписать полностью. То есть завести массивчик отправленных запросов и итератор тайлов как поля объекта. Убрать оттуда отдельный поток для каждой карты, а завести один поток на все карты, который будет дергать активные. Выкинуть тот семафор нафиг. И тд. |
|
|
|
(0013629)
|
|
zed
|
|
15-01-2014 10:27
|
|
>Дождался затыка, запустил закачку области
Удалось ли собрать дополнительную информацию при помощи dbgview во время затыка?
>Имхо чем пытаться починить TUiTileDownload лучше сразу его переписать полностью
Поскольку неизвестно в чём баг, то нет никаких гарантий, что ты его не перенесёшь в новую реализацию. Сейчас по твоим словам реализация простая до предела и глючить там нечему (а оно таки глючит), но предлагаешь усложнить реализацию на порядок, в надежде избавиться от глюка. Где логика? Хотя, несомненно, ты можешь попробовать всё переписать как запланировал, возможно и поможет. Но dmytro_ovdiienko и gma я бы попросил продолжить поиск бага в текущей реализации, а не ждать нового движка от vdemidov.
Мне кажется, что OnPosChange должен прилетать и скорее всего мы стартуем поток, но где-то в if/then с завидным постоянством выходим в отсутствующий else блок (куда я напихал OutpuDebugString) и ничего не делаем. И это может быть проблема не собственно TUiTileDownload, а каких-то внешних факторов. |
|
|
|
(0013630)
|
|
zed
|
|
15-01-2014 10:31
|
|
gma
>Экран после этого всё равно не завёлся
И небольшое уточнение терминологии: "затык" это когда карта перестаёт качать и Queue: 0? Показания счётчика в этом случае очень важно. |
|
|
|
(0013631)
|
|
gma
|
|
15-01-2014 16:02
|
|
"И небольшое уточнение терминологии: "затык" это когда карта перестаёт качать и Queue: 0? Показания счётчика в этом случае очень важно" -- Да, когда перестаёт качать. Про счётчик я выше уже говорил, что в норме! он показывает количество лун у марса, иногда у земли, но это число ни от чего не зависит.
Сегодня на работе скачал Dbw и попробовал добиться результата с ним -- ничего не вышло, качает как миленькая, дошло до почти трёх тысяч (почти час качал) и тут рабочее время кончилось. Но раньше я ОСМ такими объёмами никогда не качал, да и вообще настройки у меня сильно отличаются, не знаю, важно ли это. |
|
|
|
(0013633)
|
|
zed
|
|
15-01-2014 16:40
|
|
> Про счётчик я выше уже говорил, что в норме!
Что в норме? Он-то в норме, это и так ясно, но должен быть равен нулю, если зависло. Если не равен нулю, значит не зависло, а просто идёт очень медленная загрузка тайлов в фоне.
> он показывает количество лун у марса, иногда у земли, но это число ни от чего не зависит.
А я вам ответил, что со счётчиком всё в порядке. Может вы просто не понимаете, что он отображает или перевод вводит в заблуждение. В английском варианте этот счётчик называется Queue - Очередь. В него записывается число тайлов поставленных в очередь на загрузку. Каждая карта имеет свою собственну очередь, но счётчик показывает суммарное число для всех отображаемых карт. К тому же, есть ещё такой момент - для каждой карты введён лимит на количество тайлов, одномоментно находящихся в очереди. И по-умолчанию этот лимит равен 32. Таким образом, если включена одна карта на HD мониторе, то для загрузки экрана нужно скачать порядка 50 тайлов. Карта ставит в очередь 32 штуки и ждёт, пока скачается хотя бы один. В этот момент счётчик показывает эти самые 32. Как только тайл скачался, счётчик становится 31, карта тут же добавляет ещё один тайл в очередь и опять ждёт. При этом операция может произойти настолько быстро, что смены цифр 32 - 31 - 32 вы можете и не увидеть, поэтому некоторое время в Queue будет отображаться 32, а потом начнёт падать до нуля. Или может закачаться сразу 4 тайла (по-умолчанию каждая карта качается в 4 потока), тогда счётчик упадёт до 28, а потом опять увеличится до 32 и уже это изменение счётчика вы можете заметить.
Соответственно, если включены 2 карты, то счётчик будет крутиться возле 64-х и не выше, хотя вообще, нужно загрузить 100 тайлов (условно), чтобы обновить экран. |
|
|
|
(0013637)
|
|
gma
|
|
16-01-2014 10:04
|
|
|
"если включены 2 карты, то счётчик будет крутиться возле 64-х и не выше" -- включена как правило одна карта, лун у марса две, у земли -- одна, вот примерно эти числа он мне и показывает чаще всего, иногда 7, 4 или другое что, но логики в его показаниях я не могу найти. В скачанном дебаге САСовый счётчик показывал всё правильно, у меня он может полчаса показывать единицу, независимо от происходящего на экране. |
|
|
|
(0013644)
|
|
nvet
|
|
17-01-2014 21:50
|
|
Остановка закачки в Ui может происходить на разных картах.У меня например наблюдается для спутника Гугла после скачки нескольких тысяч тайлов.
После остановки, под отладчиком нашел "подозрительные" места в коде:
-в модуле TBackgroundTask в процедуре Execute в строке 134 переменная VOperatonID принимает значение 0.
-в результате в модуле TUiTileDownload в процедуре DoProcessDownloadRequests в строке 377,378 происходит обход кода закачки.
Если закачка идет, VOperatonID имеет значение не равное 0. |
|
|
|
(0013646)
|
|
zed
|
|
18-01-2014 18:44
|
|
> в модуле TBackgroundTask в процедуре Execute в строке 134 переменная VOperatonID принимает значение 0
Значит поток был только что создан и это первая задача. 0 - абсолютно нормальное значение.
> в результате в модуле TUiTileDownload в процедуре DoProcessDownloadRequests в строке 377,378 происходит обход кода закачки
Имеется в виду проверка "if ACancelNotifier.IsOperationCanceled(AOperationID) then"? Первый раз может и сработать, если карта движется и прежде чем мы дошли до этой строчки у нас уже успела стартануть новая задача (должны были прилететь вот сюда, отменить старую задачу и увеличить счётчик следующей операции).
И обновите свою версию исходников, сейчас на строках 377,378 выполняются совсем другие операции. |
|
|
|
(0013648)
|
|
nvet
|
18-01-2014 20:16
(edited on: 18-01-2014 20:42) |
|
> Имеется в виду проверка
Да, эта самая проверка(нов 407 строка).
Попробую повторить остановку на свежей ночной сборке.
Если будет, то и на обновленных исходниках.
Проверка на версии SAS 140118.7798
Карта спутник гугл.Остановка произошла на 1926 тайлах,осталось 0.
Загрузка по контекстному меню происходит, счетчик при этом увеличивается на 1(1927 и т.д.).
Перемещения карты мышкой и стрелками к загрузке не приводят,очередь загрузки стоит на нуле во время перемещений.
|
|
|
|
(0013651)
|
|
zed
|
|
20-01-2014 08:27
|
|
|
Если кому-то удастся воспроизвести баг на виртуалке под дебагером, то эту виртуалку можно поставить на паузу и выложить её куда-нить на обменник, а ссылку запостить тут. Я думаю должно сработать. |
|
|
|
(0013689)
|
|
zed
|
|
27-01-2014 16:29
|
|
|
Куда все пропали? Жду логов от дебажной сборки из старого аттача. |
|
|
|
(0013696)
|
|
zed
|
|
29-01-2014 16:34
|
|
|
Словил я его. Висело в WaitForMultipleObjects из-за логической ошибки использования семафора. |
|
|
|
|
|
Спасибо. Теперь, когда проблема найдена, она кажется очевидной, но вот поди ж ты - сколько времени понадобилось что бы ее выловить. |
|
SAS.DeBug.2301.7z (2,672,234) 13-01-2014 19:56