Использование в Sas.Планета кеша в формате Berkeley

[zed]

пережимать кеш не придется?

Нет.

[Tolik]

Сегодня предпринял некоторые шаги по оптимизации Беркли. Должно заработать немного быстрее.

И немного менее надёжно?

[zed]

Я попытался сделать 2 вещи:
Первое: Раньше, каждый тайл проходил под одной транзакцией. Т.е. открывается транзакция, тайл пишется в лог, закрывается транзакция (commit) -> тайл сохраняется в БД. Сейчас я сделал (надеюсь) так, чтобы под одной транзакцией проходило 100 тайлов (число взял с "потока"), т.е. открывается транзакция, в лог пишется 100 тайлов (или меньше, если сработал тайм аут), делается коммит и все эти сто тайлов разом сохраняются в БД. Естественно, если ранее мы рисковали потерять один тайл (при крахе САСа или ОС), то сейчас рискуем сотней (на каждую открытую БД). Сотня тайлов, это примерно 2 экрана в FullHD (в режиме просмотра). Поскольку, крах системы/программы явление статистически редкое, то можно сказать, надёжность сильно не пострадала. С точки зрения быстродействия, теоретически, мы уменьшаем число дёрганий головок винта - у нас идёт относительно последовательная запись пачки тайлов вначале в лог, потом в БД.
Второе: ввёл кэширование "пустых" запросов к БД (см. баг 1200). Это на надёжности БД никаким боком не отразилось, а вот на быстродействие могло повлиять вполне себе положительно. Но само кэширование я ещё толком не успел оттестировать, так что оно может и не работает как задумывалось. Надо брать FileMon, включать дебагера на полную катушку и смотреть потайлово, что там происходит.

[zed]

Оттестировал кэширование пустых запросов - теперь оно работает как задумано (был баг). Эффективность можно оценить по счётчикам производительности (в окошке DebugInfo): GetTileInfo - реальные обращение в БД за тайлом и LoadTile - обращения САСа к тайлохранилищу. В режиме загрузки тайлов из интернета (именно тогда проявляется баг 1200) счётчик GetTileInfo перестал бешено расти, чего, собственно, я и добивался.

[guf]

На релизе 120808 беркли достаточно стабилен, чтоб на него переносить имеющийся кеш из пофайлового хранения? Или пока все еще рано?

п.с. Спасибо Вам огроменное за релиз с беркли

[zed]

Пока никто не жаловался. Можете пробовать переносить.

[guf]

Ну, собственно, понеслось конвертирование. Юзаю именно стабильные релиз а не ночные сборки.
Во первых порадовала скорость. Тормозит по сравнению с тайловым кешем не критично и по моему быстрее тех ночных сборок, которые я тестил раньше (в теме писал про это). Правда сама прога стала тормозить сильнее и пара вопросов возникла, но не по беркли а вообще, в вопросах новичков сейчас спрошу, может кто подскажет. Ну и стабильность порадовала. 2 ошибки вылетали из-за контроллера дискового, дох на множестве операций, но он и без беркли пару раз дох до этого. Зато при сносе папки evn кеш спокойно работать снова начинает. Первый раз конвертировать пробывал он читать не захотел, но так как ошибка не повторилась и я параметры еще правил, то видимо это вина кривых рук моих.

По конверту. Я не знаю, всплывал ли такой вопрос раньше, но так как после выхода релизов в постах вопроса небыло то пишу тут его:
При конвертировании россии из тайлов в беркли при запуске экспорта по нескольким выделениям одного кеша с пересекающимися слоями часть файлов в беркли получаются при верификации битыми. Я на архивном кеше 2-х словев пробывал 2 раза, оба раза из 340 файлов 15-20 были при верефекации битыми. Если паралельно работать с разными слоями то проблем нет, если за раз делать 1 выделение на 1 слое то тоже проблем нет. Я так понимаю, это оборотная сторона использования беркли? Не критично, но интересует, как поведет себя программа, если в режиме "только чтение" будет работать программа, запущеная по сети в нескольких экземплярах с 1 кешем? Не побъет его? В .zmp там физически будет отсутствовать ссылка на скачивание кеша. Качать то я так понимаю всеравно разумнее в тайлах а дальше уже конвертить.

Второй момент. В соседней теме кешем GE делятся. И у меня он есть. После тестового конверта карт и гибрида стал его конвертить. Для начала выложеный в теме весь мир на z1-z8.
И вот тут сразу у меня проблема возникла: в исходном кеше 10 933 тайлов, а при выделении всего мира и конверте конвертится (по счетчику) 10 925 тайлов. Где тут грабли? Или плюнуть и забыть? Просто не хочу, чтоб потом, при конверте уже по выделению моему потерялись бы тайлы. Чтоб было понятнее, вот содержимое файла выделения:

Код: Выделить всё

[HIGHLIGHTING]
zoom=1
PointLon_1=-180
PointLat_1=90
PointLon_2=180
PointLat_2=90
PointLon_3=180
PointLat_3=-90
PointLon_4=-180
PointLat_4=-90
PointLon_5=-180
PointLat_5=90

Вот соержимое params.txt который конвертирует из тайлов в беркли:

Код: Выделить всё

[PARAMS]
pnum=15
GUID={00000000-0000-0000-0000-100000000105}
name=GE (Google Earth)1
name_en=GE (Google Earth)1
name_uk=GE (Google Earth)1
ParentSubMenu=Google
ParentSubMenu_en=Google
ParentSubMenu_uk=Google
asLayer=0
DefURLBase=http://127.0.0.1:8081/jpegfile?db=earth&ver=0&date=0&
EPSG=4326
NameInCache=f:\cache\ge
separator=1
Ext=.jpg
UseDwn=1
Usestick=1
UseGenPrevious=1
Usedel=1
Usesave=1
UsePreloadPage=0
Sleep=0
ContentType=image/jpeg,image/jpg
BanIfLen=0
MaxConnectToServerCount=12
CacheType=2
[ViewInfo]
EPSG=3785

Вот содержимое файла params.txt, который уже с беркли непосредственно работает после конвертирования:

Код: Выделить всё

[PARAMS]
pnum=5
GUID={00000000-0000-0000-0000-000000000105}
name=GE (Google Earth)
name_en=GE (Google Earth)
name_uk=GE (Google Earth)
ParentSubMenu=Google
ParentSubMenu_en=Google
ParentSubMenu_uk=Google
asLayer=0
DefURLBase=http://127.0.0.1:8081/jpegfile?db=earth&ver=0&date=0&
EPSG=4326
NameInCache=ge
separator=1
Ext=.jpg
UseDwn=1
Usestick=1
UseGenPrevious=1
Usedel=1
Usesave=1
UsePreloadPage=0
Sleep=0
ContentType=image/jpeg,image/jpg
BanIfLen=0
MaxConnectToServerCount=12
CacheType=6
[ViewInfo]
EPSG=3785

За образец брал их из .zmp в комплекте с прогой и вроде не менял ничего критичного.

И еще несколько вопросов.
Как можно посчитать количество тайлов в кеше? Например конвертировать буду sat по выделнию на куче уровней, как мне проверить, все ли сконвертировалось, если по количеству файлов или общему весу не вариант?
И как программа будет с kml викимапии работать? Или лучше всетаки не конвертить вику этого слоя в беркли?

[zed]

Зато при сносе папки evn кеш спокойно работать снова начинает.

Не надо удалять папку env. Если проблемы с кэшем, то используйте утилиту sdb_util (идёт в комплекте с релизом).

Я так понимаю, это оборотная сторона использования беркли?

Нет. Может баг, а может ещё что.

Не критично, но интересует, как поведет себя программа, если в режиме "только чтение" будет работать программа, запущеная по сети в нескольких экземплярах с 1 кешем? Не побъет его?

Не побъёт.

Качать то я так понимаю всеравно разумнее в тайлах а дальше уже конвертить.

Если на запись будет работать одна копия САС, то никаких проблем.

в исходном кеше 10 933 тайлов, а при выделении всего мира и конверте конвертится (по счетчику) 10 925 тайлов. Где тут грабли? Или плюнуть и забыть?

Включите карту заполнения да посмотрите где чего не хватает (и действительно ли не хватает). Может там tne были?

И как программа будет с kml викимапии работать?

Нормально будет работать.

Как можно посчитать количество тайлов в кеше? Например конвертировать буду sat по выделнию на куче уровней, как мне проверить, все ли сконвертировалось, если по количеству файлов или общему весу не вариант?

Опять же - включайте карту заполнения и проверяйте визуально.

[Dima2000]

Вопрос по теме, как убедиться в правильности преобразования в беркли, остаётся открытым. db_stat нифига не выдаёт количества файлов в конкретном .sdb. Единственный реальный предложенный метод - при преобразовании оставлять исходные файлы, потом преобразовывать из беркли обратно в новую папку и тупо сравнивать содержимое исходной и новой папок. Как именно сравнивать, по количеству файлов, по размеру или побитно - на выбор. Соответственно требуется тройное место на диске и куча времени ...

[Parasite]

Любители считать тайлы в произвольном выделении - уехали СЮДА.