View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002108SAS.Планета[All Projects] Багpublic22-08-2013 19:3511-11-2013 08:41
Reportervdemidov 
Assigned Tozed 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version.Nightly 
Target Version131111Fixed in Version131111 
Summary0002108: BerkeleyDB: зависание при обращении к тайлохранилищу
DescriptionВо время работы завис поток отрисовывающий основной растровый слой интерфейса. Так как это было под отладчиком смог посмотреть кто завис. Оказалось обращение к беркли.
Steps To ReproduceБеркли неверсионный. Стандартные настройки, других копий программы не запущено. Работало отображение карты и слоя и закачка видимой области в режиме "Кэш+Интернет", отображение карты заполнения для главной карты на +1 зум
Активно двигал и зумил карту

TagsBerkeleyDB, зависание
Attached Filespng file icon CallStack.png [^] (38,500 bytes) 22-08-2013 19:35


rar file icon fffffff.rar [^] (2,742,163 bytes) 09-09-2013 06:13
png file icon procexp.png [^] (38,415 bytes) 10-09-2013 04:51


rar file icon zzz.rar [^] (2,236,017 bytes) 10-09-2013 05:34
zip file icon error_kosmo.zip [^] (359,806 bytes) 18-09-2013 12:50
zip file icon hang_google.zip [^] (537,474 bytes) 18-09-2013 21:18

- Relationships
related to 0002117resolvedzed AV при вызове 'libdb51.dll' 
has duplicate 0002125closed Зависание программы при выходе 
has duplicate 0002468closedvdemidov Тайлохранилище BerkeleyDB зависает при наличии поврежденных баз 

-  Notes
(0012569)
zed (manager)
22-08-2013 19:40

Судя по скриншоту - словил дедлок:
> AIsDeadLock = True
(0012570)
vdemidov (manager)
22-08-2013 19:44

И как с этим бороться?
(0012571)
vdemidov (manager)
22-08-2013 19:50

>Судя по скриншоту - словил дедлок:
>> AIsDeadLock = True
Не факт. Возможно просто осталось неинициализированное занчение левое. Обрати внимание, что I = 0, а зависло на
ret := db.get(db, PDB_TXN(ATxn), @dbtKey, @dbtData, AFlag);
то есть еще до любых записей в AIsDeadLock
(0012572)
zed (manager)
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 (manager)
22-08-2013 19:57

Ну, я не знаю почему оно может зависнуть внутри db.get кроме как из-за дедлока. Хотя в теории функция должна была сразу же вернуть результат DB_LOCK_DEADLOCK

Там как бы настраиваемое поведение при дедлоках: оно может ждать какой-то тайматут или вышибать сразу. Причём, при дедлоке будет заблокировано 2 и более потока и какой из них получит отлуп так же решает библиотека.
(0012575)
vdemidov (manager)
23-08-2013 06:49

Хреново, что оно зависает. Очень хреново. Даже если там база битая. Я бы понял, если бы оно возвращало ошибку при обращении к любому тайлу этой базы, даже если бы оно возвращало ошибку при обращении к любой из баз карты, но тупой зависон это не дело.
(0012576)
vdemidov (manager)
23-08-2013 06:56

Судя по всему для тайлохранилищ нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой.
(0012577)
zed (manager)
23-08-2013 07:10

> Хреново, что оно зависает. Очень хреново. Даже если там база битая
Воспроизводится?

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

> Воспроизводится?
В том то и дело, что нет. Лучше бы воспроизводилось, а так непонятно как лечить и как проверять. То что такие баги случаются сомнений не вызывает. Тот же Parasite упоминал. А вот то что оно случается очень редко только затрудняет поиск, но не позволяет забить на эту багу.

>> нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой
>Да, тоже были такие мысли.
Может займешься?
(0012579)
zed (manager)
23-08-2013 07:17

> Может займешься?
Не.
(0012580)
Garl (manager)
23-08-2013 12:19

ещё замечено зависание при Беркли + карта заполнения
(0012581)
zed (manager)
23-08-2013 12:56

>Беркли + карта заполнения
Тут именно так и описано.
(0012727)
Parasite (administrator)
31-08-2013 16:00

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

Куда нажимать?
Статистику с dbstat попробую собрать в следующий зависон (ориентировочно - в понедельник оно с вероятностьюв 99% зависнет). Что-то еще? Говорите сразу - соберу все что нужно. :)
(0012728)
vdemidov (manager)
31-08-2013 21:53

У меня кстати, кэш совсем небольшой, только то что надергалось лазаньем по карте. И все равно иногда вешается.
(0012729)
zed (manager)
01-09-2013 04:50

>Куда нажимать?
0002125:0012723
(0012732)
zed (manager)
01-09-2013 09:14

Возможно и AV в 0002117 (тоже на db.get) как-то связаны.
(0012733)
zed (manager)
01-09-2013 09:18

>Говорите сразу - соберу все что нужно
Да, ещё желательно информацию по запущенным потокам и конкретный id зависшего потока, потому как в выводе db_stat эти id могут быть упомянуты.
(0012735)
Parasite (administrator)
01-09-2013 15:09

>информацию по запущенным потокам и конкретный id зависшего потока
Куда нажимать?
(0012736)
zed (manager)
01-09-2013 15:10

ProcessMonitor в помощь.
(0012743)
Parasite (administrator)
03-09-2013 15:12

Пока не зависло (с пятницы) - хотя по всем прикидкам уже давно бы пора.

Из изменений - в пятницу я посадил всего SASа на одно ядро (чтобы если вдруг зависнет - не отжирал 100% ресурсов и не тормозил другие задачи). И вот ровно с того момента он и не виснет пока что. Возможно, что тут есть какая-то связь. Ждемс...
(0012745)
vdemidov (manager)
03-09-2013 20:39

Будешь ждать до второго пришествия. Ясно же, что дело в многопоточном обращении к dll беркли.
(0012746)
Parasite (administrator)
04-09-2013 02:58

>дело в многопоточном обращении к dll беркли.
Так САСовые потоки никто и не зарезал - как качалось всё плотненько в пару десятков проходов, так и качается. ДЛЛка САСом нагружена ровно так же как и всегда.

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

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

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

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

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

UPD: (пере)запущенное вчера - покачало немного, и за ночь опять зависло. То есть, на этот раз не прожило и суток. Тот же кэш, тот же САС, те же симптомы.

Собрать полностью всю статистику заново? Или что-то отдельное (напиши)? Пока не закрываю - жду.
(0012760)
Garl (manager)
10-09-2013 04:05

> Чем больше кэш - тем больше\чаще проявляется.
меня терзают аналогичные сомнения.
проверить пока не могу (в отпуске)
(0012761)
zed (manager)
10-09-2013 04:54

>и таки найти там до боли знакомое словцо ".Nightly"? %double facepalm%
Ага, только дебажная версия пишет ".Nightly -=Debug=-". Запускать нужно SASPlanet.Debug.exe из архива с ночнушкой.

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

>Собрать полностью всю статистику заново? Или что-то отдельное (напиши)? Пока не закрываю - жду.
Да, собери всю.
(0012762)
Parasite (administrator)
10-09-2013 05:51
edited on: 10-09-2013 05:53

>только дебажная версия пишет ".Nightly -=Debug=-".
К сожалению, работать на таких версиях (особенно из числа последних) совершенно невозможно ввиду их крайней любви к полнейшему (сабжевому) зависанию всего САСа намертво, до состояния "белое окно, не реагирующее ни на что". Не удается сохранить SLS. Кэш портится в безусловном порядке. Потом требуется весьма долгое время на его проверку\восстановление. Это - не работа.

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

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

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

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

(0012763)
zed (manager)
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 (administrator)
10-09-2013 05:55

>и никаких ошибок в открытии кэша env.
Да, и все 6 db_stat отработали как положено - быстро и без рекурсий.
Но сас все равно висит.

>Единственная особенность этой страницы от всех остальных - у неё обнулён LSN.
Мои действия?
(0012765)
zed (manager)
10-09-2013 05:59

>Напомню, что в данном конкретном случае это не тестирование\повторение бага как таковое - а сбор инфы
А запустить из соседней папочки ещё один экземпляр спецом для тестов?

>Мои действия?
Наблюдай дальше и собирай логи у вновь-зависших САС. Если они все будут висеть на страницах с обнулённым LSN, то будет симптом.
(0012766)
Parasite (administrator)
10-09-2013 06:04
edited on: 10-09-2013 06:08

>А запустить из соседней папочки ещё один экземпляр спецом для тестов?
[s]Нужен[/s] Весьма желателен большой кэш - а копировать текущие ~ 100Гб еще и в соседнюю папочку - увы, места нет. :(

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

(0012767)
zed (manager)
10-09-2013 06:04

А кинься в меня этим файлом z13\0\0\2.1.sdb?
(0012768)
Parasite (administrator)
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 (administrator)
10-09-2013 06:18

Кидаю мылом еще и SLS к этому всему.
Кинь себе ENV + z13\0\0\2.1.sdb, и грузани SLS. Будет сабжевая картина.

Вопрос остается в том, почему бьется LSN базы при длительной скачке.
(0012770)
zed (manager)
10-09-2013 06:21

>почему бьется LSN базы
Это ты наверняка делал "Reset LSN" при помощи sdb_util. И в общем, обнулёный LSN не проблема, если конечно был ручной сброс. А вот если его никто не трогал и он вдруг стал нулевым, то да - беда.
(0012771)
Parasite (administrator)
10-09-2013 06:29

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

PS: вот прямо сейчас починил оный sdb твоей утилью ("Restore .bad files", или как там - трогался только ОДИН файл) - всё, САС поехал качать как обычно. Ждем, пока зависнет в очередной раз. САМ.
(0012772)
zed (manager)
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 (manager)
10-09-2013 06:57

Ага, оказывается проблема стара как мир: BerkeleyDB hangs trying to read corrupted database

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

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

>висит, значит БД повреждена.
Так это ж следствие, а не причина. Он и должен висеть, если БД повреждена. :)

А причина, собссно - "Почему БД повреждается без малейшей видимой причины". Начинаем качать - БД в порядке, хоп - повредилась ни с того ни с сего (и это не глючный накопитель под нею - это именно что софтовая проблема). Это и нужно полечить.
(0012775)
Parasite (administrator)
10-09-2013 07:08

>отключить флаг асинхронной записи в лог в DB_CONFIG: set_flags DB_TXN_WRITE_NOSYNC off
Сейчас попробую. Ибо мОчи уже никакой нет.
(0012783)
Parasite (administrator)
13-09-2013 10:08

Работает с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
Пока не зависло.
Оставляем на выходные покачать "в полную силу".
(0012790)
rudepravo (reporter)
15-09-2013 01:05

А у меня с этим флагом DB_TXN_WRITE_NOSYNC off всё равно висла. Вы скажите что сделать надо, какую статистику собрать - предоставлю.

Если требуется - дам доступ на машину для отладки.
(0012792)
zed (manager)
15-09-2013 07:45

>Вы скажите что сделать надо, какую статистику собрать - предоставлю.
Приплыли. Перечитайте сообщения этого тикета с самого начала - я только что в популярной форме объяснил Parasite что конкретно мне нужно. Вот и вы плиз соберите такую же статистику как и он, что приложена в последнем аттаче (zzz.rar).
(0012818)
rudepravo (reporter)
18-09-2013 12:52
edited on: 18-09-2013 12:53

Завис на скачивании Космоснимков, лог собрал в кучу. Симптомы - экран пустой, программа грузит проц. В аттаче error_kosmo.zip

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

(0012819)
Parasite (administrator)
18-09-2013 13:36

>Оставляем на выходные покачать "в полную силу".
Все еще не зависло с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
(0012820)
zed (manager)
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 (reporter)
18-09-2013 17:43

До сбора статистики скрин с потоками, но оно продолжало висеть, я могу ещё раз подвесить SAS )))
(0012835)
zed (manager)
18-09-2013 17:47

>я могу ещё раз подвесить SAS
Ну так, пробуйте. Может вылезет стабильная воспроизводимость. И после каждого глюка или перед очередной попыткой подвесить САС, запускайте db_verify, чтобы было видно что и где на самом деле бъётся.
(0012836)
rudepravo (reporter)
18-09-2013 21:18
edited on: 18-09-2013 21:21

db_verify отработал на базе. Вот ещё завис - в аттаче hang_google.zip.

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

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

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

(0012838)
Garl (manager)
19-09-2013 04:10

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

подтверждаю!
вот такие выкрутасы замечены неоднократно. логику зависаний поймать не удаётся.
скорее всего гдето происходят утечки, которые стопорят затем выход из SAS.
(0012843)
zed (manager)
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 (administrator)
27-09-2013 05:31

>>Оставляем на выходные покачать "в полную силу".
>Все еще не зависло с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
...и таки все еще не зависло. Качает себе...
(0012989)
rudepravo (reporter)
29-09-2013 19:50

На удивление, у меня тоже зависание исчезло. Фаза Луны не та? Тикет пока не закрывайте.
(0013220)
vdemidov (manager)
04-11-2013 13:01

Так что, может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off и закроем все эти инциденты связанные с тайлохранилищем на беркли?
(0013221)
Parasite (administrator)
04-11-2013 13:09
edited on: 04-11-2013 13:09

Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?

(0013222)
zed (manager)
04-11-2013 13:14

>может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off
Уже давно сделано. И в sdb_util внесены соответствующие изменения.
(0013224)
vdemidov (manager)
04-11-2013 14:28

>Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
>Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?
Хреново. А я надеялся, что можно закрывать и делать релиз.
(0013225)
zed (manager)
04-11-2013 14:35

Судя по тому, что флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки.
(0013226)
Parasite (administrator)
04-11-2013 14:36

>Хреново. А я надеялся, что можно закрывать и делать релиз.
Ну кэш-то (и DB_CONFIG) был создан несколько ранее, прошлыми версиями...Вот, исправил флаг. Посмотрим. Дай неделю-другую времени?
(0013227)
zed (manager)
04-11-2013 14:38

Предлагаю делать релиз (если есть желание зарелизиться) не обращая внимания на данный тикет.
(0013228)
vdemidov (manager)
04-11-2013 14:46

Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить, а нам доделать еще пару мелких хотелок.
(0013229)
zed (manager)
04-11-2013 14:49

>Давай назначим релиз на 121111
Да без проблем. И не хочу тебя огорчать, но на дворе уже 13-й год, так что только: 131111

А ещё красивая дата будет через месяц: 131211 или 131212 или 131213 (пятница 13-го):)
(0013230)
Parasite (administrator)
04-11-2013 14:50

>флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки.
Да. Но завис-то свежий экзешник, и в этом вся беда. Не должон он виснуть (даже при самых тупых настройках), я так считаю. Глючить, еррорить - таки да, но виснуть и бить кэш..?

PS: с исправленным флагом - пока работает. ~ 2 часа уже.
(0013231)
zed (manager)
04-11-2013 14:54
edited on: 04-11-2013 14:55

>Но завис-то свежий экзешник, и в этом вся беда.
Завис потому что кэш испортился, а кэш испортился потому что небыло флага. Я ссылку приводил (0002108:0012773), по которой разработки либы утверждают, что зависание при доступе к испорченной БД, они считают нормальной ситуацией. Поэтому только флаг нас и спасёт. И я рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей.

(0013232)
vdemidov (manager)
04-11-2013 14:59

>А ещё красивая дата будет через месяц: 131211 или 131212 или 131213 (пятница 13-го):)
ИМХО 131111 все таки лучше :)
(0013233)
Garl (manager)
04-11-2013 15:02

>И я рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей.
а на пальцах это как?
(0013234)
zed (manager)
04-11-2013 15:05

Это значит выполнить "Recover environment [cmd: db_recover -v]" с настройками по-умолчанию.
(0013235)
Parasite (administrator)
04-11-2013 15:16

>рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей
Так уже ручками прописал флаг и так.
Пока что работает вроде. Нужно просто больше времени на тестирование.
(0013237)
Parasite (administrator)
11-11-2013 02:26

>Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить
Вроде работает - с вышеуказанным флагом, прописанным ручками.

- Users who viewed this issue
User List Anonymous (4024x)
Total Views 4024
Last View 13-08-2020 17:54

- Issue History
Date Modified Username Field Change
22-08-2013 19:35 vdemidov New Issue
22-08-2013 19:35 vdemidov Status new => assigned
22-08-2013 19:35 vdemidov Assigned To => zed
22-08-2013 19:35 vdemidov File Added: CallStack.png
22-08-2013 19:40 zed Note Added: 0012569
22-08-2013 19:44 vdemidov Note Added: 0012570
22-08-2013 19:46 vdemidov Steps to Reproduce Updated View Revisions
22-08-2013 19:50 vdemidov Note Added: 0012571
22-08-2013 19:51 zed Note Added: 0012572
22-08-2013 19:57 zed Note Added: 0012573
23-08-2013 06:49 vdemidov Note Added: 0012575
23-08-2013 06:56 vdemidov Note Added: 0012576
23-08-2013 07:10 zed Note Added: 0012577
23-08-2013 07:15 vdemidov Note Added: 0012578
23-08-2013 07:17 zed Note Added: 0012579
23-08-2013 12:19 Garl Note Added: 0012580
23-08-2013 12:56 zed Note Added: 0012581
30-08-2013 10:45 vdemidov Tag Attached: BerkeleyDB
30-08-2013 10:45 vdemidov Tag Attached: зависание
30-08-2013 10:57 vdemidov Target Version => 131111
31-08-2013 06:20 zed Relationship added related to 0002125
31-08-2013 16:00 Parasite Note Added: 0012727
31-08-2013 21:53 vdemidov Note Added: 0012728
01-09-2013 04:50 zed Note Added: 0012729
01-09-2013 09:11 zed Relationship replaced has duplicate 0002125
01-09-2013 09:12 zed Relationship added related to 0002117
01-09-2013 09:14 zed Note Added: 0012732
01-09-2013 09:15 zed Severity minor => major
01-09-2013 09:15 zed Reproducibility have not tried => sometimes
01-09-2013 09:15 zed Summary БерклиДБ зависание при обращении к тайлохранилищу => BerkeleyDB: зависание при обращении к тайлохранилищу
01-09-2013 09:18 zed Note Added: 0012733
01-09-2013 15:09 Parasite Note Added: 0012735
01-09-2013 15:10 zed Note Added: 0012736
03-09-2013 12:02 zed Status assigned => feedback
03-09-2013 15:12 Parasite Note Added: 0012743
03-09-2013 20:39 vdemidov Note Added: 0012745
03-09-2013 20:39 vdemidov Status feedback => assigned
03-09-2013 20:39 vdemidov Status assigned => feedback
04-09-2013 02:58 Parasite Note Added: 0012746
09-09-2013 06:10 Parasite Note Added: 0012755
09-09-2013 06:13 Parasite File Added: fffffff.rar
09-09-2013 11:18 zed Note Added: 0012756
09-09-2013 11:41 zed Note Edited: 0012756 View Revisions
10-09-2013 03:03 Parasite Note Added: 0012758
10-09-2013 03:38 Parasite Note Added: 0012759
10-09-2013 04:05 Garl Note Added: 0012760
10-09-2013 04:51 zed File Added: procexp.png
10-09-2013 04:54 zed Note Added: 0012761
10-09-2013 05:34 Parasite File Added: zzz.rar
10-09-2013 05:51 Parasite Note Added: 0012762
10-09-2013 05:53 zed Note Added: 0012763
10-09-2013 05:53 Parasite Note Edited: 0012762 View Revisions
10-09-2013 05:54 zed Note Edited: 0012763 View Revisions
10-09-2013 05:55 Parasite Note Added: 0012764
10-09-2013 05:59 zed Note Added: 0012765
10-09-2013 06:04 Parasite Note Added: 0012766
10-09-2013 06:04 zed Note Added: 0012767
10-09-2013 06:07 Parasite Note Edited: 0012766 View Revisions
10-09-2013 06:08 Parasite Note Edited: 0012766 View Revisions
10-09-2013 06:15 Parasite Note Added: 0012768
10-09-2013 06:18 Parasite Note Added: 0012769
10-09-2013 06:21 zed Note Added: 0012770
10-09-2013 06:29 Parasite Note Added: 0012771
10-09-2013 06:31 zed Note Added: 0012772
10-09-2013 06:33 zed Note Edited: 0012772 View Revisions
10-09-2013 06:57 zed Note Added: 0012773
10-09-2013 07:07 Parasite Note Added: 0012774
10-09-2013 07:08 Parasite Note Added: 0012775
13-09-2013 10:08 Parasite Note Added: 0012783
15-09-2013 01:05 rudepravo Note Added: 0012790
15-09-2013 07:45 zed Note Added: 0012792
18-09-2013 12:50 rudepravo File Added: error_kosmo.zip
18-09-2013 12:52 rudepravo Note Added: 0012818
18-09-2013 12:53 rudepravo Note Edited: 0012818 View Revisions
18-09-2013 13:36 Parasite Note Added: 0012819
18-09-2013 14:36 zed Note Added: 0012820
18-09-2013 17:43 rudepravo Note Added: 0012834
18-09-2013 17:47 zed Note Added: 0012835
18-09-2013 21:18 rudepravo Note Added: 0012836
18-09-2013 21:18 rudepravo File Added: hang_google.zip
18-09-2013 21:19 rudepravo Note Edited: 0012836 View Revisions
18-09-2013 21:21 rudepravo Note Edited: 0012836 View Revisions
19-09-2013 04:10 Garl Note Added: 0012838
19-09-2013 10:07 zed Note Added: 0012843
27-09-2013 05:31 Parasite Note Added: 0012973
29-09-2013 19:50 rudepravo Note Added: 0012989
04-11-2013 13:01 vdemidov Note Added: 0013220
04-11-2013 13:01 vdemidov Status feedback => assigned
04-11-2013 13:09 Parasite Note Added: 0013221
04-11-2013 13:09 Parasite Note Edited: 0013221 View Revisions
04-11-2013 13:14 zed Note Added: 0013222
04-11-2013 14:28 vdemidov Note Added: 0013224
04-11-2013 14:35 zed Note Added: 0013225
04-11-2013 14:36 Parasite Note Added: 0013226
04-11-2013 14:38 zed Note Added: 0013227
04-11-2013 14:46 vdemidov Note Added: 0013228
04-11-2013 14:49 zed Note Added: 0013229
04-11-2013 14:50 Parasite Note Added: 0013230
04-11-2013 14:54 zed Note Added: 0013231
04-11-2013 14:55 zed Note Edited: 0013231 View Revisions
04-11-2013 14:55 zed Note Edited: 0013231 View Revisions
04-11-2013 14:59 vdemidov Note Added: 0013232
04-11-2013 15:02 Garl Note Added: 0013233
04-11-2013 15:05 zed Note Added: 0013234
04-11-2013 15:16 Parasite Note Added: 0013235
11-11-2013 02:26 Parasite Note Added: 0013237
11-11-2013 08:41 zed Status assigned => resolved
11-11-2013 08:41 zed Fixed in Version => 131111
11-11-2013 08:41 zed Resolution open => fixed
24-07-2014 12:10 zed Relationship added has duplicate 0002468



Copyright © 2007 - 2020 SAS.Planet Team