SASGIS - SAS.Планета
View Issue Details
0002108SAS.Планета[All Projects] Багpublic22-08-2013 19:3511-11-2013 08:41
vdemidov 
zed 
normalmajorsometimes
resolvedfixed 
.Nightly 
131111131111 
0002108: BerkeleyDB: зависание при обращении к тайлохранилищу
Во время работы завис поток отрисовывающий основной растровый слой интерфейса. Так как это было под отладчиком смог посмотреть кто завис. Оказалось обращение к беркли.
Беркли неверсионный. Стандартные настройки, других копий программы не запущено. Работало отображение карты и слоя и закачка видимой области в режиме "Кэш+Интернет", отображение карты заполнения для главной карты на +1 зум
Активно двигал и зумил карту

BerkeleyDB, зависание
related to 0002117resolved zed AV при вызове 'libdb51.dll' 
has duplicate 0002125closed  Зависание программы при выходе 
has duplicate 0002468closed vdemidov Тайлохранилище BerkeleyDB зависает при наличии поврежденных баз 
png CallStack.png (38,500) 22-08-2013 19:35
http://www.sasgis.org/mantis/file_download.php?file_id=1480&type=bug
png

rar fffffff.rar (2,742,163) 09-09-2013 06:13
http://www.sasgis.org/mantis/file_download.php?file_id=1504&type=bug
png procexp.png (38,415) 10-09-2013 04:51
http://www.sasgis.org/mantis/file_download.php?file_id=1508&type=bug
png

rar zzz.rar (2,236,017) 10-09-2013 05:34
http://www.sasgis.org/mantis/file_download.php?file_id=1509&type=bug
zip error_kosmo.zip (359,806) 18-09-2013 12:50
http://www.sasgis.org/mantis/file_download.php?file_id=1516&type=bug
zip hang_google.zip (537,474) 18-09-2013 21:18
http://www.sasgis.org/mantis/file_download.php?file_id=1518&type=bug
Issue History
22-08-2013 19:35vdemidovNew Issue
22-08-2013 19:35vdemidovStatusnew => assigned
22-08-2013 19:35vdemidovAssigned To => zed
22-08-2013 19:35vdemidovFile Added: CallStack.png
22-08-2013 19:40zedNote Added: 0012569
22-08-2013 19:44vdemidovNote Added: 0012570
22-08-2013 19:46vdemidovSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=5643#r5643
22-08-2013 19:50vdemidovNote Added: 0012571
22-08-2013 19:51zedNote Added: 0012572
22-08-2013 19:57zedNote Added: 0012573
23-08-2013 06:49vdemidovNote Added: 0012575
23-08-2013 06:56vdemidovNote Added: 0012576
23-08-2013 07:10zedNote Added: 0012577
23-08-2013 07:15vdemidovNote Added: 0012578
23-08-2013 07:17zedNote Added: 0012579
23-08-2013 12:19GarlNote Added: 0012580
23-08-2013 12:56zedNote Added: 0012581
30-08-2013 10:45vdemidovTag Attached: BerkeleyDB
30-08-2013 10:45vdemidovTag Attached: зависание
30-08-2013 10:57vdemidovTarget Version => 131111
31-08-2013 06:20zedRelationship addedrelated to 0002125
31-08-2013 16:00ParasiteNote Added: 0012727
31-08-2013 21:53vdemidovNote Added: 0012728
01-09-2013 04:50zedNote Added: 0012729
01-09-2013 09:11zedRelationship replacedhas duplicate 0002125
01-09-2013 09:12zedRelationship addedrelated to 0002117
01-09-2013 09:14zedNote Added: 0012732
01-09-2013 09:15zedSeverityminor => major
01-09-2013 09:15zedReproducibilityhave not tried => sometimes
01-09-2013 09:15zedSummaryБерклиДБ зависание при обращении к тайлохранилищу => BerkeleyDB: зависание при обращении к тайлохранилищу
01-09-2013 09:18zedNote Added: 0012733
01-09-2013 15:09ParasiteNote Added: 0012735
01-09-2013 15:10zedNote Added: 0012736
03-09-2013 12:02zedStatusassigned => feedback
03-09-2013 15:12ParasiteNote Added: 0012743
03-09-2013 20:39vdemidovNote Added: 0012745
03-09-2013 20:39vdemidovStatusfeedback => assigned
03-09-2013 20:39vdemidovStatusassigned => feedback
04-09-2013 02:58ParasiteNote Added: 0012746
09-09-2013 06:10ParasiteNote Added: 0012755
09-09-2013 06:13ParasiteFile Added: fffffff.rar
09-09-2013 11:18zedNote Added: 0012756
09-09-2013 11:41zedNote Edited: 0012756bug_revision_view_page.php?bugnote_id=12756#r5695
10-09-2013 03:03ParasiteNote Added: 0012758
10-09-2013 03:38ParasiteNote Added: 0012759
10-09-2013 04:05GarlNote Added: 0012760
10-09-2013 04:51zedFile Added: procexp.png
10-09-2013 04:54zedNote Added: 0012761
10-09-2013 05:34ParasiteFile Added: zzz.rar
10-09-2013 05:51ParasiteNote Added: 0012762
10-09-2013 05:53zedNote Added: 0012763
10-09-2013 05:53ParasiteNote Edited: 0012762bug_revision_view_page.php?bugnote_id=12762#r5697
10-09-2013 05:54zedNote Edited: 0012763bug_revision_view_page.php?bugnote_id=12763#r5699
10-09-2013 05:55ParasiteNote Added: 0012764
10-09-2013 05:59zedNote Added: 0012765
10-09-2013 06:04ParasiteNote Added: 0012766
10-09-2013 06:04zedNote Added: 0012767
10-09-2013 06:07ParasiteNote Edited: 0012766bug_revision_view_page.php?bugnote_id=12766#r5701
10-09-2013 06:08ParasiteNote Edited: 0012766bug_revision_view_page.php?bugnote_id=12766#r5702
10-09-2013 06:15ParasiteNote Added: 0012768
10-09-2013 06:18ParasiteNote Added: 0012769
10-09-2013 06:21zedNote Added: 0012770
10-09-2013 06:29ParasiteNote Added: 0012771
10-09-2013 06:31zedNote Added: 0012772
10-09-2013 06:33zedNote Edited: 0012772bug_revision_view_page.php?bugnote_id=12772#r5704
10-09-2013 06:57zedNote Added: 0012773
10-09-2013 07:07ParasiteNote Added: 0012774
10-09-2013 07:08ParasiteNote Added: 0012775
13-09-2013 10:08ParasiteNote Added: 0012783
15-09-2013 01:05rudepravoNote Added: 0012790
15-09-2013 07:45zedNote Added: 0012792
18-09-2013 12:50rudepravoFile Added: error_kosmo.zip
18-09-2013 12:52rudepravoNote Added: 0012818
18-09-2013 12:53rudepravoNote Edited: 0012818bug_revision_view_page.php?bugnote_id=12818#r5710
18-09-2013 13:36ParasiteNote Added: 0012819
18-09-2013 14:36zedNote Added: 0012820
18-09-2013 17:43rudepravoNote Added: 0012834
18-09-2013 17:47zedNote Added: 0012835
18-09-2013 21:18rudepravoNote Added: 0012836
18-09-2013 21:18rudepravoFile Added: hang_google.zip
18-09-2013 21:19rudepravoNote Edited: 0012836bug_revision_view_page.php?bugnote_id=12836#r5714
18-09-2013 21:21rudepravoNote Edited: 0012836bug_revision_view_page.php?bugnote_id=12836#r5715
19-09-2013 04:10GarlNote Added: 0012838
19-09-2013 10:07zedNote Added: 0012843
27-09-2013 05:31ParasiteNote Added: 0012973
29-09-2013 19:50rudepravoNote Added: 0012989
04-11-2013 13:01vdemidovNote Added: 0013220
04-11-2013 13:01vdemidovStatusfeedback => assigned
04-11-2013 13:09ParasiteNote Added: 0013221
04-11-2013 13:09ParasiteNote Edited: 0013221bug_revision_view_page.php?bugnote_id=13221#r5815
04-11-2013 13:14zedNote Added: 0013222
04-11-2013 14:28vdemidovNote Added: 0013224
04-11-2013 14:35zedNote Added: 0013225
04-11-2013 14:36ParasiteNote Added: 0013226
04-11-2013 14:38zedNote Added: 0013227
04-11-2013 14:46vdemidovNote Added: 0013228
04-11-2013 14:49zedNote Added: 0013229
04-11-2013 14:50ParasiteNote Added: 0013230
04-11-2013 14:54zedNote Added: 0013231
04-11-2013 14:55zedNote Edited: 0013231bug_revision_view_page.php?bugnote_id=13231#r5817
04-11-2013 14:55zedNote Edited: 0013231bug_revision_view_page.php?bugnote_id=13231#r5818
04-11-2013 14:59vdemidovNote Added: 0013232
04-11-2013 15:02GarlNote Added: 0013233
04-11-2013 15:05zedNote Added: 0013234
04-11-2013 15:16ParasiteNote Added: 0013235
11-11-2013 02:26ParasiteNote Added: 0013237
11-11-2013 08:41zedStatusassigned => resolved
11-11-2013 08:41zedFixed in Version => 131111
11-11-2013 08:41zedResolutionopen => fixed
24-07-2014 12:10zedRelationship addedhas duplicate 0002468

Notes
(0012569)
zed   
22-08-2013 19:40   
Судя по скриншоту - словил дедлок:
> AIsDeadLock = True
(0012570)
vdemidov   
22-08-2013 19:44   
И как с этим бороться?
(0012571)
vdemidov   
22-08-2013 19:50   
>Судя по скриншоту - словил дедлок:
>> AIsDeadLock = True
Не факт. Возможно просто осталось неинициализированное занчение левое. Обрати внимание, что I = 0, а зависло на
ret := db.get(db, PDB_TXN(ATxn), @dbtKey, @dbtData, AFlag);
то есть еще до любых записей в AIsDeadLock
(0012572)
zed   
22-08-2013 19:51   
Закрыть САС, в DB_CONFIG добавить строчку: set_verbose DB_VERB_DEADLOCK on

И если словишь ещё раз, то ничего не трогая, пока оно висит, нужно собрать статистику: db_stat -C A -h %путь_до_папки_env% (утилиту db_stat брать из комплекта sdb_util)
(0012573)
zed   
22-08-2013 19:57   
Ну, я не знаю почему оно может зависнуть внутри db.get кроме как из-за дедлока. Хотя в теории функция должна была сразу же вернуть результат DB_LOCK_DEADLOCK

Там как бы настраиваемое поведение при дедлоках: оно может ждать какой-то тайматут или вышибать сразу. Причём, при дедлоке будет заблокировано 2 и более потока и какой из них получит отлуп так же решает библиотека.
(0012575)
vdemidov   
23-08-2013 06:49   
Хреново, что оно зависает. Очень хреново. Даже если там база битая. Я бы понял, если бы оно возвращало ошибку при обращении к любому тайлу этой базы, даже если бы оно возвращало ошибку при обращении к любой из баз карты, но тупой зависон это не дело.
(0012576)
vdemidov   
23-08-2013 06:56   
Судя по всему для тайлохранилищ нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой.
(0012577)
zed   
23-08-2013 07:10   
> Хреново, что оно зависает. Очень хреново. Даже если там база битая
Воспроизводится?

> нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой
Да, тоже были такие мысли.
(0012578)
vdemidov   
23-08-2013 07:15   
> Воспроизводится?
В том то и дело, что нет. Лучше бы воспроизводилось, а так непонятно как лечить и как проверять. То что такие баги случаются сомнений не вызывает. Тот же Parasite упоминал. А вот то что оно случается очень редко только затрудняет поиск, но не позволяет забить на эту багу.

>> нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой
>Да, тоже были такие мысли.
Может займешься?
(0012579)
zed   
23-08-2013 07:17   
> Может займешься?
Не.
(0012580)
Garl   
23-08-2013 12:19   
ещё замечено зависание при Беркли + карта заполнения
(0012581)
zed   
23-08-2013 12:56   
>Беркли + карта заполнения
Тут именно так и описано.
(0012727)
Parasite   
31-08-2013 16:00   
У меня это и повторяемо, и проверяемо - как минимум раз в неделю я вынужден перепроверять кэш, начатый быть качаемым напрямую в Беркли. Виснет, да - причем тем чаще, чем больше кэша (по размеру, судя по всему). Непредсказуемо, причины зависона не выявлены. Просто в один прекрасный момент ВЕСЬ кэш Беркли отваливается (включая и те карты, в которые не качалось - но которые в пределах того же саса). Лечится рестартом САСа (предваряемым безусловной проверкой кэша - ибо всегда находится что-то битое).

Куда нажимать?
Статистику с dbstat попробую собрать в следующий зависон (ориентировочно - в понедельник оно с вероятностьюв 99% зависнет). Что-то еще? Говорите сразу - соберу все что нужно. :)
(0012728)
vdemidov   
31-08-2013 21:53   
У меня кстати, кэш совсем небольшой, только то что надергалось лазаньем по карте. И все равно иногда вешается.
(0012729)
zed   
01-09-2013 04:50   
>Куда нажимать?
0002125:0012723
(0012732)
zed   
01-09-2013 09:14   
Возможно и AV в 0002117 (тоже на db.get) как-то связаны.
(0012733)
zed   
01-09-2013 09:18   
>Говорите сразу - соберу все что нужно
Да, ещё желательно информацию по запущенным потокам и конкретный id зависшего потока, потому как в выводе db_stat эти id могут быть упомянуты.
(0012735)
Parasite   
01-09-2013 15:09   
>информацию по запущенным потокам и конкретный id зависшего потока
Куда нажимать?
(0012736)
zed   
01-09-2013 15:10   
ProcessMonitor в помощь.
(0012743)
Parasite   
03-09-2013 15:12   
Пока не зависло (с пятницы) - хотя по всем прикидкам уже давно бы пора.

Из изменений - в пятницу я посадил всего SASа на одно ядро (чтобы если вдруг зависнет - не отжирал 100% ресурсов и не тормозил другие задачи). И вот ровно с того момента он и не виснет пока что. Возможно, что тут есть какая-то связь. Ждемс...
(0012745)
vdemidov   
03-09-2013 20:39   
Будешь ждать до второго пришествия. Ясно же, что дело в многопоточном обращении к dll беркли.
(0012746)
Parasite   
04-09-2013 02:58   
>дело в многопоточном обращении к dll беркли.
Так САСовые потоки никто и не зарезал - как качалось всё плотненько в пару десятков проходов, так и качается. ДЛЛка САСом нагружена ровно так же как и всегда.

Я лишь в винде САСу дал только одно ядро, через системный affinity - чтобы оно на весь камень на 100% не лезло, если зависнет. Со стороны САСа никаких изменений не делал. И вот с того раза - не зависло. Может - просто совпадение, может - действительно глюк зависит от многоядерности камня. Еще подождем маленько, посмотрим.
(0012755)
Parasite   
09-09-2013 06:10   
Ну вот мы не пережили очередных выходных - и успешненько зависли.

Прилагаю в архиве (всё собрано еще до выхода из САСа - прямо из-под него):

1. 6 логов от db_stat по порядку, согласно указанным zed'ом командам.
Команды н.1 и н.4 в данном случае почему-то отрабатывают бесконечно долго (ждал более полдня - так и не закруглились, снял принудительно), генерируя огромнейший лог под 400Мб на каждый (на момент снятия задач). Почему так - не знаю, дома такая же статистика (на бОльшем кэше) отрабатывала буквально за пару секунд.

2. Собственно скриншот САСа. Видно, что карта включена сама по себе - но уже отвалилась (в кэше этот район точно есть). Зависли, собственно, все 4 потока качаемые в BOTH. Два других потока - SAT и Decarta - качались ОК, но очень печально - так как уже САС встал на 100% камня.

3. Собственно всю папку ENV - она небольшая. Кому интересно - могут попытаться натравить на нее статистику на своей стороне.

4. Инфу по тредам САСа.

5. После сбора статистики была предпринята попытка выхода из саса штатным образом. Сас задумался, примерно через минуту ожидания вывалил еррор, и на этот раз завис окончательно. Снял по трем кнопкам. Еррор прилагаю в архиве.
ELF не создался.
(0012756)
zed   
09-09-2013 11:18   
(edited on: 09-09-2013 11:41)
>Команды н.1 и н.4 в данном случае почему-то отрабатывают бесконечно долго
При попытке чтения информации о закэшированных страницах в env, либа вошла в рекурсию. Страницы в кэше env хранятся в т.н. "хэш-слотах" и как видно из логов, там всего было 257 слотов. Первые 102 слота прочитались нормально, а вот при попытке взять информацию по 103-му слоту, произошёл облом - информация вернулась (11 страниц в слоте), а потом ещё раз вернулась, и ещё раз, и ещё... и так до бесконечности, пока процесс не был прерван вручную.

>Инфу по тредам САСа
Я просил конкретные ID потоков, которые грузят камень. В логах указано, что на момент снятия статистики было 2 активные транзакции на запись (в разные БД и дедлоков между ними не наблюдается).

>ELF не создался
Потому что ты проводил эксперименты на релизной сборке. %facepalm%

Parasite
Если не сложно, повтори свой эксперимент на 1) дебажной 2) свежей ночнушке 3) без ограничения affinity 4) и на сей раз с доп. инфой по конкретным ID зависших потоков. И кэш желательно заведи "с нуля", для чистоты эксперимента.

Если исключить логическую ошибку использования BDB со стороны САС (а в Беркли есть некоторые оговорки, при использовании его в много-поточных приложениях), можно сделать вывод, что наблюдается какая-то ошибка в библиотеке. Возможный вариант лечения - ещё более агрессивная блокировка потоков со стороны САС. Сейчас САС не разрешает двум потокам одновременно писать в одну БД, а можно попробовать запретить вообще одновременный доступ ко всему кэшу.

(0012758)
Parasite   
10-09-2013 03:03   
>При попытке чтения информации о закэшированных страницах в env, либа вошла в рекурсию.
Вот она наверное и в САСе так вошла - коль скоро тот сам по себе не висит, а вот окошки задач пожирают 100% камня. Как раз очень похоже на попадание в пустой бесконечный цикл...

>Потому что ты проводил эксперименты на релизной сборке. %facepalm%
А если посмотреть на шапку имеющегося в архиве скриншота - и таки найти там до боли знакомое словцо ".Nightly"? %double facepalm%

>на сей раз с доп. инфой по конкретным ID зависших потоков
Я выше уже спрашивал - куда конкретно нажимать, чтобы было именно то что тебе нужно. Конкретного ответа (вроде коммандлайнов с db_stat) не получил - посему собрал то, что нашел на тему потоков.
Если имелись ввиду потоки записи\чтения в файлы - то таковых не было. Сас просто держал открытыми ENV+несколько файлов (было видно по анлокеру), но никаких операций с ними не было. Дисковая активность была равна нулю за все то время, что оно изволило висеть.

>повтори свой эксперимент на свежей ночнушке без ограничения affinity
Будет ровно то же самое - я гарантирую это. Вероятность появления - 100%, время появления - от пары дней до пары недель.
На чистом кэше смысла нет проверять - на маленьком кэше такого у меня вообще никогда не было. Чем больше кэш - тем больше\чаще проявляется. Такое ощущение, что при большом кэше оно просто мечется туда-сюда, разбираясь - где у него что лежит, и (возможно) где-то тупит. Возможно, мультитредовось и синхронизация потоков как раз сюда же. Чем больше кэша - тем дольше поиски и больше туплений.
Но это только догадка.
(0012759)
Parasite   
10-09-2013 03:38   
UPD: (пере)запущенное вчера - покачало немного, и за ночь опять зависло. То есть, на этот раз не прожило и суток. Тот же кэш, тот же САС, те же симптомы.

Собрать полностью всю статистику заново? Или что-то отдельное (напиши)? Пока не закрываю - жду.
(0012760)
Garl   
10-09-2013 04:05   
> Чем больше кэш - тем больше\чаще проявляется.
меня терзают аналогичные сомнения.
проверить пока не могу (в отпуске)
(0012761)
zed   
10-09-2013 04:54   
>и таки найти там до боли знакомое словцо ".Nightly"? %double facepalm%
Ага, только дебажная версия пишет ".Nightly -=Debug=-". Запускать нужно SASPlanet.Debug.exe из архива с ночнушкой.

>Я выше уже спрашивал - куда конкретно нажимать
Приложил скриншот. Вот, хотелось бы получить такое и по зависшему САС.

>Собрать полностью всю статистику заново? Или что-то отдельное (напиши)? Пока не закрываю - жду.
Да, собери всю.
(0012762)
Parasite   
10-09-2013 05:51   
(edited on: 10-09-2013 05:53)
>только дебажная версия пишет ".Nightly -=Debug=-".
К сожалению, работать на таких версиях (особенно из числа последних) совершенно невозможно ввиду их крайней любви к полнейшему (сабжевому) зависанию всего САСа намертво, до состояния "белое окно, не реагирующее ни на что". Не удается сохранить SLS. Кэш портится в безусловном порядке. Потом требуется весьма долгое время на его проверку\восстановление. Это - не работа.

Напомню, что в данном конкретном случае это не тестирование\повторение бага как таковое - а сбор инфы в тикет из-под САСа выполняющего определенную задачу на моей стороне, от которого требуется результат в виде кэша. То есть, безостановочная работа всей задачи в данном конкретном случае первична, а все тесты - вторичны. С текущими ночнушками - это терять наработанное ~раз в сутки и безостановочно проверять это все по кругу тогда, когда нужен результат как можно скорее (ибо версии на сервере умирают).

Эта версия, которой я качаю - худо-бедно работает, дает сохранить SLS, и не валит кэш при зависании. Рестарт САСа, и в 95% случаев можно продолжать качать дальше. Переключиться на САМУЮ ПОСЛЕДНЮЮ дебажку я смогу только тогда, когда докачается искомое, я его перепроверю, заархивирую и отдам заказчику. И вот тогда уже можно лично ине тренироваться на каких угодно кошечках на этом огромном кэше. Не раньше. Но результат будет еще более печальный, ибо последние ночнушки я пробовал совсем недавно - и там все было весьма грустно. Виснет-сс.

Кстати, ранееобсужденный глюк с плодящимися логами в папке ENV (подросшими до размера в 60Гб к тому времени) САС свежайшей ночнушки решил весьма оригинально: при свежем холодном запуске и обращении к этой карте - уперся в плотную дисковую активность на пару суток (были кучи READ в логи, судя по файлмону), а потом просто убил все эти логи (все эти 60Гб) подчистую. Размер баз не изменился.
Кэш уехал на перекачку дырок....:(

>Да, собери всю.
Лови архив. САС не вырубаю - если что, говори что еще нужно.

(0012763)
zed   
10-09-2013 05:53   
(edited on: 10-09-2013 05:54)
Ну вот, и ситуация совсем другая. Висит поток с tid 6980 в db.get и никаких ошибок в открытии кэша env. Поток пытается прочитать страницу 21894 из z13\0\0\2.1.sdb, эта страница есть в кэше env:

Cache #1:
BH hash table (257 hash slots)
bucket #: priority, I/O wait, [mutex]
    pageno, file, ref, LSN, address, priority, flags
...
bucket 230: 0 (0 dirty)[!Set]
    21894, # 9, 0, 0/0, 0x1d5dc0, 3706260707
    16902, #1, 0, 1556/3547065, 0x178328, 113579
    19302, # 8, 0, 1556/3300306, 0x1969a8, 109644
...

Единственная особенность этой страницы от всех остальных - у неё обнулён LSN.

(0012764)
Parasite   
10-09-2013 05:55   
>и никаких ошибок в открытии кэша env.
Да, и все 6 db_stat отработали как положено - быстро и без рекурсий.
Но сас все равно висит.

>Единственная особенность этой страницы от всех остальных - у неё обнулён LSN.
Мои действия?
(0012765)
zed   
10-09-2013 05:59   
>Напомню, что в данном конкретном случае это не тестирование\повторение бага как таковое - а сбор инфы
А запустить из соседней папочки ещё один экземпляр спецом для тестов?

>Мои действия?
Наблюдай дальше и собирай логи у вновь-зависших САС. Если они все будут висеть на страницах с обнулённым LSN, то будет симптом.
(0012766)
Parasite   
10-09-2013 06:04   
(edited on: 10-09-2013 06:08)
>А запустить из соседней папочки ещё один экземпляр спецом для тестов?
[s]Нужен[/s] Весьма желателен большой кэш - а копировать текущие ~ 100Гб еще и в соседнюю папочку - увы, места нет. :(

>Наблюдай дальше и собирай логи у вновь-зависших САС. Если они все будут висеть на страницах с обнулённым LSN, то будет симптом.
Легко.
То есть, от этого вот зависшего - больше ничего не надо? Перезапускаю, и стартую заново.

(0012767)
zed   
10-09-2013 06:04   
А кинься в меня этим файлом z13\0\0\2.1.sdb?
(0012768)
Parasite   
10-09-2013 06:15   
Мыло.

PS: да, при попытке доступа свежезапущенного саса к этому файлу (в первой же строчке "Обработка файла: N:\SAS\cache_db\Both\z13\0\0\2.1.sdb\z13\x677\y416.png ...") - получил то же самое эпичное вставание САСом на 100% одного ядра (больше никаких SLSов не подгружал). Подождемс немного. Авось сам продерется....
(0012769)
Parasite   
10-09-2013 06:18   
Кидаю мылом еще и SLS к этому всему.
Кинь себе ENV + z13\0\0\2.1.sdb, и грузани SLS. Будет сабжевая картина.

Вопрос остается в том, почему бьется LSN базы при длительной скачке.
(0012770)
zed   
10-09-2013 06:21   
>почему бьется LSN базы
Это ты наверняка делал "Reset LSN" при помощи sdb_util. И в общем, обнулёный LSN не проблема, если конечно был ручной сброс. А вот если его никто не трогал и он вдруг стал нулевым, то да - беда.
(0012771)
Parasite   
10-09-2013 06:29   
>Это ты наверняка делал "Reset LSN" при помощи sdb_util. И в общем, обнулёный LSN не проблема, если конечно был ручной сброс. А вот если его никто не трогал и он вдруг стал нулевым, то да - беда.
Никто ничего не делал.
Оставлено с пятницы вечера, чтобы за выходные на свободном канале накачало в полную силу. В понедельник прихожу - а оно давно висит. Само. Что-то укачивает, быстро и надежно - но в определенный момент почему-то встает раком, и на этом всё.
И оно постоянно так. Было бы оно результатом моих действий - я бы и тикета не поднимал бы... :(

PS: вот прямо сейчас починил оный sdb твоей утилью ("Restore .bad files", или как там - трогался только ОДИН файл) - всё, САС поехал качать как обычно. Ждем, пока зависнет в очередной раз. САМ.
(0012772)
zed   
10-09-2013 06:31   
(edited on: 10-09-2013 06:33)
Вот что обнаружилось внутри sdb:

page 21893: btree leaf: LSN [1556][3733254]: level 1
    prev: 22021 next: 22022 entries: 4 offset: 528
    [000] 1012 len: 8 data: 000000000006c6b8
    [001] 776 len: 233 data: ...
    [002] 764 len: 8 data: 000000000006c6b9
    [003] 528 len: 233 data: ...
page 0: invalid: LSN [0][0]: level 0
    prev: 0 next: 0 entries: 0 offset: 0
page 21895: btree leaf: LSN [1555][5886106]: level 1
    prev: 21894 next: 21362 entries: 4 offset: 528
...

т.е. на месте искомой страницы 21894 у нас зияет дыра: "invalid: LSN [0][0]". Таки надо запускать db_verify.

(0012773)
zed   
10-09-2013 06:57   
Ага, оказывается проблема стара как мир: BerkeleyDB hangs trying to read corrupted database

И с этим зависанием походу ничего не сделаешь: висит, значит БД повреждена.

Единственное, что могу предложить - отключить флаг асинхронной записи в лог в DB_CONFIG: set_flags DB_TXN_WRITE_NOSYNC off
(0012774)
Parasite   
10-09-2013 07:07   
>висит, значит БД повреждена.
Так это ж следствие, а не причина. Он и должен висеть, если БД повреждена. :)

А причина, собссно - "Почему БД повреждается без малейшей видимой причины". Начинаем качать - БД в порядке, хоп - повредилась ни с того ни с сего (и это не глючный накопитель под нею - это именно что софтовая проблема). Это и нужно полечить.
(0012775)
Parasite   
10-09-2013 07:08   
>отключить флаг асинхронной записи в лог в DB_CONFIG: set_flags DB_TXN_WRITE_NOSYNC off
Сейчас попробую. Ибо мОчи уже никакой нет.
(0012783)
Parasite   
13-09-2013 10:08   
Работает с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
Пока не зависло.
Оставляем на выходные покачать "в полную силу".
(0012790)
rudepravo   
15-09-2013 01:05   
А у меня с этим флагом DB_TXN_WRITE_NOSYNC off всё равно висла. Вы скажите что сделать надо, какую статистику собрать - предоставлю.

Если требуется - дам доступ на машину для отладки.
(0012792)
zed   
15-09-2013 07:45   
>Вы скажите что сделать надо, какую статистику собрать - предоставлю.
Приплыли. Перечитайте сообщения этого тикета с самого начала - я только что в популярной форме объяснил Parasite что конкретно мне нужно. Вот и вы плиз соберите такую же статистику как и он, что приложена в последнем аттаче (zzz.rar).
(0012818)
rudepravo   
18-09-2013 12:52   
(edited on: 18-09-2013 12:53)
Завис на скачивании Космоснимков, лог собрал в кучу. Симптомы - экран пустой, программа грузит проц. В аттаче error_kosmo.zip

Версия - ночнушка 7499

(0012819)
Parasite   
18-09-2013 13:36   
>Оставляем на выходные покачать "в полную силу".
Все еще не зависло с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
(0012820)
zed   
18-09-2013 14:36   
>Завис на скачивании Космоснимков
Судя по скриншоту - скачивание в режиме просмотра, а не через загрузку выделенной области? И тайлов-то скачалось совсем ничего...

>В аттаче error_kosmo.zip
По стеку зависших потоков видно, что эврика там пытается перехватить какой-то эксепшен, но видимо безуспешно и всё висит. Причём зависшие потоки в логах env не числятся вообще, хотя в стеке вызовов есть отсыл к libdb51.dll и очевидно, что ошибка прилетела оттуда. Да и по завершённым транзакциям видно, что было 2 отменённых транзакции, что как бы намекает.

На момент снятия статистики в БД шла запись в файл z14\4\2\18.9.sdb так что по идее, после аварийного завершения САС там будет незавершённая транзакция. Хотя, может на этой операции всё и отвалилось к чертям, а остальные потоки уже висят из-за того, что не могут получить доступ к либе.

P.S. Кстати, спасибо за стек вызовов зависших потоков, и на будущее - его можно сделать ещё немного более информативным.

P.P.S. А в какой момент был сделан скриншот с потоками - до сбора статистики по env или после? А то что-то я на скриншоте не нахожу пары потоков, что маячат в env.
(0012834)
rudepravo   
18-09-2013 17:43   
До сбора статистики скрин с потоками, но оно продолжало висеть, я могу ещё раз подвесить SAS )))
(0012835)
zed   
18-09-2013 17:47   
>я могу ещё раз подвесить SAS
Ну так, пробуйте. Может вылезет стабильная воспроизводимость. И после каждого глюка или перед очередной попыткой подвесить САС, запускайте db_verify, чтобы было видно что и где на самом деле бъётся.
(0012836)
rudepravo   
18-09-2013 21:18   
(edited on: 18-09-2013 21:21)
db_verify отработал на базе. Вот ещё завис - в аттаче hang_google.zip.

Завис при выходе, качал в пакетном режиме, всё скачалось, при попытке выхода из SAS - всё померло.

в каталоге after - состояние db_stat после всех скриншотов, в корневом - до.

PS: Блд!!!! Качал гугл, а натравил на космоснимки.

(0012838)
Garl   
19-09-2013 04:10   
>Завис при выходе, качал в пакетном режиме, всё скачалось, при попытке выхода из SAS - всё померло.

подтверждаю!
вот такие выкрутасы замечены неоднократно. логику зависаний поймать не удаётся.
скорее всего гдето происходят утечки, которые стопорят затем выход из SAS.
(0012843)
zed   
19-09-2013 10:07   
>Качал гугл, а натравил на космоснимки.
Но похоже и на космоснимках тоже что-то шло не очень гладко:

6286 Number of transactions begun
75 Number of transactions aborted
6211 Number of transactions committed

Возможно это число дедлоков (75), которые таки удалось разрулить. Я так понимаю в DB_CONFIG такой строчки нету: set_verbose DB_VERB_DEADLOCK on? Её таки тоже стоит добавить и мониторить содержимое файла msg.log в папке с кэшем карты (cache_db\sat\msg.log).

И sdb.log (который при ошибках создаётся в корневой папке программы) появляется?
(0012973)
Parasite   
27-09-2013 05:31   
>>Оставляем на выходные покачать "в полную силу".
>Все еще не зависло с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
...и таки все еще не зависло. Качает себе...
(0012989)
rudepravo   
29-09-2013 19:50   
На удивление, у меня тоже зависание исчезло. Фаза Луны не та? Тикет пока не закрывайте.
(0013220)
vdemidov   
04-11-2013 13:01   
Так что, может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off и закроем все эти инциденты связанные с тайлохранилищем на беркли?
(0013221)
Parasite   
04-11-2013 13:09   
Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?

(0013222)
zed   
04-11-2013 13:14   
>может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off
Уже давно сделано. И в sdb_util внесены соответствующие изменения.
(0013224)
vdemidov   
04-11-2013 14:28   
>Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
>Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?
Хреново. А я надеялся, что можно закрывать и делать релиз.
(0013225)
zed   
04-11-2013 14:35   
Судя по тому, что флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки.
(0013226)
Parasite   
04-11-2013 14:36   
>Хреново. А я надеялся, что можно закрывать и делать релиз.
Ну кэш-то (и DB_CONFIG) был создан несколько ранее, прошлыми версиями...Вот, исправил флаг. Посмотрим. Дай неделю-другую времени?
(0013227)
zed   
04-11-2013 14:38   
Предлагаю делать релиз (если есть желание зарелизиться) не обращая внимания на данный тикет.
(0013228)
vdemidov   
04-11-2013 14:46   
Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить, а нам доделать еще пару мелких хотелок.
(0013229)
zed   
04-11-2013 14:49   
>Давай назначим релиз на 121111
Да без проблем. И не хочу тебя огорчать, но на дворе уже 13-й год, так что только: 131111

А ещё красивая дата будет через месяц: 131211 или 131212 или 131213 (пятница 13-го):)
(0013230)
Parasite   
04-11-2013 14:50   
>флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки.
Да. Но завис-то свежий экзешник, и в этом вся беда. Не должон он виснуть (даже при самых тупых настройках), я так считаю. Глючить, еррорить - таки да, но виснуть и бить кэш..?

PS: с исправленным флагом - пока работает. ~ 2 часа уже.
(0013231)
zed   
04-11-2013 14:54   
(edited on: 04-11-2013 14:55)
>Но завис-то свежий экзешник, и в этом вся беда.
Завис потому что кэш испортился, а кэш испортился потому что небыло флага. Я ссылку приводил (0002108:0012773), по которой разработки либы утверждают, что зависание при доступе к испорченной БД, они считают нормальной ситуацией. Поэтому только флаг нас и спасёт. И я рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей.

(0013232)
vdemidov   
04-11-2013 14:59   
>А ещё красивая дата будет через месяц: 131211 или 131212 или 131213 (пятница 13-го):)
ИМХО 131111 все таки лучше :)
(0013233)
Garl   
04-11-2013 15:02   
>И я рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей.
а на пальцах это как?
(0013234)
zed   
04-11-2013 15:05   
Это значит выполнить "Recover environment [cmd: db_recover -v]" с настройками по-умолчанию.
(0013235)
Parasite   
04-11-2013 15:16   
>рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей
Так уже ручками прописал флаг и так.
Пока что работает вроде. Нужно просто больше времени на тестирование.
(0013237)
Parasite   
11-11-2013 02:26   
>Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить
Вроде работает - с вышеуказанным флагом, прописанным ручками.