0002108: 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 (5141x)
Total Views	5141
Last View	22-11-2024 03:11

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

SASGIS