|
Notes |
|
|
(0012569)
|
|
zed
|
|
22-08-2013 19:40
|
|
Судя по скриншоту - словил дедлок:
> AIsDeadLock = True |
|
|
|
|
|
|
|
|
>Судя по скриншоту - словил дедлок:
>> 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 и более потока и какой из них получит отлуп так же решает библиотека. |
|
|
|
|
|
Хреново, что оно зависает. Очень хреново. Даже если там база битая. Я бы понял, если бы оно возвращало ошибку при обращении к любому тайлу этой базы, даже если бы оно возвращало ошибку при обращении к любой из баз карты, но тупой зависон это не дело. |
|
|
|
|
|
Судя по всему для тайлохранилищ нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой. |
|
|
|
(0012577)
|
|
zed
|
|
23-08-2013 07:10
|
|
> Хреново, что оно зависает. Очень хреново. Даже если там база битая
Воспроизводится?
> нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой
Да, тоже были такие мысли. |
|
|
|
|
> Воспроизводится?
В том то и дело, что нет. Лучше бы воспроизводилось, а так непонятно как лечить и как проверять. То что такие баги случаются сомнений не вызывает. Тот же Parasite упоминал. А вот то что оно случается очень редко только затрудняет поиск, но не позволяет забить на эту багу.
>> нужно срочно делать многопоточную тестилку что бы проверять их под нагрузкой
>Да, тоже были такие мысли.
Может займешься? |
|
|
|
(0012579)
|
|
zed
|
|
23-08-2013 07:17
|
|
|
|
|
(0012580)
|
|
Garl
|
|
23-08-2013 12:19
|
|
|
ещё замечено зависание при Беркли + карта заполнения |
|
|
|
(0012581)
|
|
zed
|
|
23-08-2013 12:56
|
|
>Беркли + карта заполнения
Тут именно так и описано. |
|
|
|
|
У меня это и повторяемо, и проверяемо - как минимум раз в неделю я вынужден перепроверять кэш, начатый быть качаемым напрямую в Беркли. Виснет, да - причем тем чаще, чем больше кэша (по размеру, судя по всему). Непредсказуемо, причины зависона не выявлены. Просто в один прекрасный момент ВЕСЬ кэш Беркли отваливается (включая и те карты, в которые не качалось - но которые в пределах того же саса). Лечится рестартом САСа (предваряемым безусловной проверкой кэша - ибо всегда находится что-то битое).
Куда нажимать?
Статистику с dbstat попробую собрать в следующий зависон (ориентировочно - в понедельник оно с вероятностьюв 99% зависнет). Что-то еще? Говорите сразу - соберу все что нужно. :) |
|
|
|
|
|
У меня кстати, кэш совсем небольшой, только то что надергалось лазаньем по карте. И все равно иногда вешается. |
|
|
|
(0012729)
|
|
zed
|
|
01-09-2013 04:50
|
|
|
|
|
(0012732)
|
|
zed
|
|
01-09-2013 09:14
|
|
|
Возможно и AV в 0002117 (тоже на db.get) как-то связаны. |
|
|
|
(0012733)
|
|
zed
|
|
01-09-2013 09:18
|
|
>Говорите сразу - соберу все что нужно
Да, ещё желательно информацию по запущенным потокам и конкретный id зависшего потока, потому как в выводе db_stat эти id могут быть упомянуты. |
|
|
|
|
>информацию по запущенным потокам и конкретный id зависшего потока
Куда нажимать? |
|
|
|
(0012736)
|
|
zed
|
|
01-09-2013 15:10
|
|
|
|
|
|
Пока не зависло (с пятницы) - хотя по всем прикидкам уже давно бы пора.
Из изменений - в пятницу я посадил всего SASа на одно ядро (чтобы если вдруг зависнет - не отжирал 100% ресурсов и не тормозил другие задачи). И вот ровно с того момента он и не виснет пока что. Возможно, что тут есть какая-то связь. Ждемс... |
|
|
|
|
|
Будешь ждать до второго пришествия. Ясно же, что дело в многопоточном обращении к dll беркли. |
|
|
|
|
>дело в многопоточном обращении к dll беркли.
Так САСовые потоки никто и не зарезал - как качалось всё плотненько в пару десятков проходов, так и качается. ДЛЛка САСом нагружена ровно так же как и всегда.
Я лишь в винде САСу дал только одно ядро, через системный affinity - чтобы оно на весь камень на 100% не лезло, если зависнет. Со стороны САСа никаких изменений не делал. И вот с того раза - не зависло. Может - просто совпадение, может - действительно глюк зависит от многоядерности камня. Еще подождем маленько, посмотрим. |
|
|
|
|
Ну вот мы не пережили очередных выходных - и успешненько зависли.
Прилагаю в архиве (всё собрано еще до выхода из САСа - прямо из-под него):
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 со стороны САС (а в Беркли есть некоторые оговорки, при использовании его в много-поточных приложениях), можно сделать вывод, что наблюдается какая-то ошибка в библиотеке. Возможный вариант лечения - ещё более агрессивная блокировка потоков со стороны САС. Сейчас САС не разрешает двум потокам одновременно писать в одну БД, а можно попробовать запретить вообще одновременный доступ ко всему кэшу.
|
|
|
|
|
>При попытке чтения информации о закэшированных страницах в env, либа вошла в рекурсию.
Вот она наверное и в САСе так вошла - коль скоро тот сам по себе не висит, а вот окошки задач пожирают 100% камня. Как раз очень похоже на попадание в пустой бесконечный цикл...
>Потому что ты проводил эксперименты на релизной сборке. %facepalm%
А если посмотреть на шапку имеющегося в архиве скриншота - и таки найти там до боли знакомое словцо ".Nightly"? %double facepalm%
>на сей раз с доп. инфой по конкретным ID зависших потоков
Я выше уже спрашивал - куда конкретно нажимать, чтобы было именно то что тебе нужно. Конкретного ответа (вроде коммандлайнов с db_stat) не получил - посему собрал то, что нашел на тему потоков.
Если имелись ввиду потоки записи\чтения в файлы - то таковых не было. Сас просто держал открытыми ENV+несколько файлов (было видно по анлокеру), но никаких операций с ними не было. Дисковая активность была равна нулю за все то время, что оно изволило висеть.
>повтори свой эксперимент на свежей ночнушке без ограничения affinity
Будет ровно то же самое - я гарантирую это. Вероятность появления - 100%, время появления - от пары дней до пары недель.
На чистом кэше смысла нет проверять - на маленьком кэше такого у меня вообще никогда не было. Чем больше кэш - тем больше\чаще проявляется. Такое ощущение, что при большом кэше оно просто мечется туда-сюда, разбираясь - где у него что лежит, и (возможно) где-то тупит. Возможно, мультитредовось и синхронизация потоков как раз сюда же. Чем больше кэша - тем дольше поиски и больше туплений.
Но это только догадка. |
|
|
|
|
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.
|
|
|
|
|
>и никаких ошибок в открытии кэша 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? |
|
|
|
|
Мыло.
PS: да, при попытке доступа свежезапущенного саса к этому файлу (в первой же строчке "Обработка файла: N:\SAS\cache_db\Both\z13\0\0\2.1.sdb\z13\x677\y416.png ...") - получил то же самое эпичное вставание САСом на 100% одного ядра (больше никаких SLSов не подгружал). Подождемс немного. Авось сам продерется.... |
|
|
|
|
Кидаю мылом еще и SLS к этому всему.
Кинь себе ENV + z13\0\0\2.1.sdb, и грузани SLS. Будет сабжевая картина.
Вопрос остается в том, почему бьется LSN базы при длительной скачке. |
|
|
|
(0012770)
|
|
zed
|
|
10-09-2013 06:21
|
|
>почему бьется LSN базы
Это ты наверняка делал "Reset LSN" при помощи sdb_util. И в общем, обнулёный LSN не проблема, если конечно был ручной сброс. А вот если его никто не трогал и он вдруг стал нулевым, то да - беда. |
|
|
|
|
>Это ты наверняка делал "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 |
|
|
|
|
>висит, значит БД повреждена.
Так это ж следствие, а не причина. Он и должен висеть, если БД повреждена. :)
А причина, собссно - "Почему БД повреждается без малейшей видимой причины". Начинаем качать - БД в порядке, хоп - повредилась ни с того ни с сего (и это не глючный накопитель под нею - это именно что софтовая проблема). Это и нужно полечить. |
|
|
|
|
>отключить флаг асинхронной записи в лог в DB_CONFIG: set_flags DB_TXN_WRITE_NOSYNC off
Сейчас попробую. Ибо мОчи уже никакой нет. |
|
|
|
|
Работает с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
Пока не зависло.
Оставляем на выходные покачать "в полную силу". |
|
|
|
|
А у меня с этим флагом 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
|
|
|
|
|
>Оставляем на выходные покачать "в полную силу".
Все еще не зависло с 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. |
|
|
|
|
|
До сбора статистики скрин с потоками, но оно продолжало висеть, я могу ещё раз подвесить 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 (который при ошибках создаётся в корневой папке программы) появляется? |
|
|
|
|
>>Оставляем на выходные покачать "в полную силу".
>Все еще не зависло с 10го числа с set_flags DB_TXN_WRITE_NOSYNC off
...и таки все еще не зависло. Качает себе... |
|
|
|
|
|
На удивление, у меня тоже зависание исчезло. Фаза Луны не та? Тикет пока не закрывайте. |
|
|
|
|
|
Так что, может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off и закроем все эти инциденты связанные с тайлохранилищем на беркли? |
|
|
|
|
Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?
|
|
|
|
(0013222)
|
|
zed
|
|
04-11-2013 13:14
|
|
>может сделаем дефолтным set_flags DB_TXN_WRITE_NOSYNC off
Уже давно сделано. И в sdb_util внесены соответствующие изменения. |
|
|
|
|
>Не поверишь - 10 минут назад заходил в этот тикет, чтобы узнать этот флаг... :) Ибо последняя ночнушка успешно зависла по старому сценарию через ~ 10мин от начала скачки в 4 потока.
>Поменял флаг. Перезапустил. Будем еще посмотреть. Не закрывай пока?
Хреново. А я надеялся, что можно закрывать и делать релиз. |
|
|
|
(0013225)
|
|
zed
|
|
04-11-2013 14:35
|
|
|
Судя по тому, что флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки. |
|
|
|
|
>Хреново. А я надеялся, что можно закрывать и делать релиз.
Ну кэш-то (и DB_CONFIG) был создан несколько ранее, прошлыми версиями...Вот, исправил флаг. Посмотрим. Дай неделю-другую времени? |
|
|
|
(0013227)
|
|
zed
|
|
04-11-2013 14:38
|
|
|
Предлагаю делать релиз (если есть желание зарелизиться) не обращая внимания на данный тикет. |
|
|
|
|
|
Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить, а нам доделать еще пару мелких хотелок. |
|
|
|
(0013229)
|
|
zed
|
|
04-11-2013 14:49
|
|
>Давай назначим релиз на 121111
Да без проблем. И не хочу тебя огорчать, но на дворе уже 13-й год, так что только: 131111
А ещё красивая дата будет через месяц: 131211 или 131212 или 131213 (пятница 13-го):) |
|
|
|
|
>флаг этот таки пришлось прописывать вручную, там был ещё старый конфиг от старой ночнушки.
Да. Но завис-то свежий экзешник, и в этом вся беда. Не должон он виснуть (даже при самых тупых настройках), я так считаю. Глючить, еррорить - таки да, но виснуть и бить кэш..?
PS: с исправленным флагом - пока работает. ~ 2 часа уже. |
|
|
|
(0013231)
|
|
zed
|
04-11-2013 14:54
(edited on: 04-11-2013 14:55) |
|
>Но завис-то свежий экзешник, и в этом вся беда.
Завис потому что кэш испортился, а кэш испортился потому что небыло флага. Я ссылку приводил (0002108:0012773), по которой разработки либы утверждают, что зависание при доступе к испорченной БД, они считают нормальной ситуацией. Поэтому только флаг нас и спасёт. И я рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей.
|
|
|
|
|
>А ещё красивая дата будет через месяц: 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]" с настройками по-умолчанию. |
|
|
|
|
>рекомендую запустить новую версию sdb_util и с её помощью обновить конфиги у всех старых кэшей
Так уже ручками прописал флаг и так.
Пока что работает вроде. Нужно просто больше времени на тестирование. |
|
|
|
|
>Давай назначим релиз на 121111 :) Как раз будет неделька Паразиту потестить
Вроде работает - с вышеуказанным флагом, прописанным ручками. |
|
CallStack.png (38,500) 22-08-2013 19:35
fffffff.rar (2,742,163) 09-09-2013 06:13