|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
db20mln, можешь сделать валидацию security3.fdb ? gfix -v -full security3.fdb -user SYSDBA есс-но, при остановленном сервере ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2016, 20:46 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
db20mlnКомбинации факторов из-за которых может происходить - код клиента, база, udf/udr, настройки fb, настройки сервака, железо. Каждый фактор пришлось исключать тестами. облегчу дальнейшее тестирование. Факторы, из-за которых может происходить: - код клиента - нет. - база - разве что при повреждении, а так - нет. - udf/udr - да - настройки FB - нет - настройки сервака - нет - железо - ... может быть. так что, если проблема остается, даже после тщательной проверки udf (типа, оно 100% не глючное), то тогда - баг в сервере. Причем, воспроизводимый скорее всего только твоей специфической нагрузкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2016, 20:48 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovИ не забудь, что "fb_lock_print -s -a -w" при зависании надо снимать именно с security3.fdb. Но лучше сними с обоих баз. Чтобы наверняка. К сожалению сервер уже переведен на 2.5. Если получится воспроизвести на локальном - сделаю. hvladможешь сделать валидацию security3.fdb ? Делал, ошибок нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 11:29 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
После перевода на 2.5: При удалении записей из одной таблицы (через IBExpert), выдало: "unknown ISC error 0." Повторялось даже на пустой таблице после реконнекта. Исчезло после того как повторил запрос с названием таблицы в кавычках "TASK" и больше не воспроизводилось. TASK - это таблица со списком задач для воркеров, т.е. в нее пишутся и читаются данные во время обработок, но не сильно интенсивно (по сравнению с другими таблицами). PS: Вроде это даже не ошибка, но на всякий случай написал. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 11:42 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
db20mlnК сожалению сервер уже переведен на 2.5. Мне в 100501-й раз повторить рецепт плавной миграции?.. Второй сервер рядом со старым - master-master репликация - постепенный перенос нагрузки с одного сервера на другой. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 11:46 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovМне в 100501-й раз повторить рецепт плавной миграции?.. Второй сервер рядом со старым - master-master репликация - постепенный перенос нагрузки с одного сервера на другой. Делал по http://www.ibase.ru/prevver/ С репликацией FB не сталкивался, поэтому если бы не получилось - скорее делал бы через создание базы из скрипта и заливку данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 11:53 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
db20mlnделал бы через создание базы из скрипта и заливку данных. И в каком месте это плавная миграция? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 11:57 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovИ в каком месте это плавная миграция? А в чем преимущество миграции через репликацию, где почитать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 12:16 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
db20mlnА в чем преимущество миграции через репликацию, где почитать? В том, что тебе не нужно сидеть ночами переливая базу и пользователи не страдают. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2016, 12:41 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Добрый день! Тоже обнаружил подобную проблему на 3.0 classic + debian (виртуалка под VMWare 6.5) На 3.0.1/debian9 на 200 коннектах + запросы с web'а ложили сервер через 4 часа. После обновления клиентских библиотек до 3.0.4 время жизни сервера увеличилось, но раз в 2 дня стабильный ступор. Переехали на 3.0.5/debian10 на прошлой неделе. Вчера сервер опять сложился. Время жизни - 4 дня. Я так понял из треда следующий этап - это переезд на SS? p.s. UDF не использую, база ~20G c несколькими большими таблицами с логами, есть триггера на коннект. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 16:47 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
18.02.2019 16:47, slrb пишет: есть триггера на коннект. и небось к MON$-таблицам в них обращаешься?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:00 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Мимопроходящий18.02.2019 16:47, slrb пишет: есть триггера на коннект. и небось к MON$-таблицам в них обращаешься?.. Есть такое, рублю зависшие транзакции раз в 12 часов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:44 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
18.02.2019 17:44, slrb пишет: > Есть такое, рублю зависшие транзакции раз в 12 часов. не нужно ЭТО делать ТАКИМ способом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:49 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
slrb, скрипт по крону пускай, нечего торкать mon$ на коннект. Любое обращение к mon$ заставляет сервер собирать всю информацию о коннектах, вплоть до препарированных запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:53 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Мимопроходящий18.02.2019 17:44, slrb пишет: > Есть такое, рублю зависшие транзакции раз в 12 часов. не нужно ЭТО делать ТАКИМ способом. Спасибо за наводку (под 2.5 работало без вопросов). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:55 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
kdvslrb, скрипт по крону пускай, нечего торкать mon$ на коннект. Любое обращение к mon$ заставляет сервер собирать всю информацию о коннектах, вплоть до препарированных запросов. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 17:57 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
slrbСпасибо за наводку (под 2.5 работало без вопросов). при 4т соединений на 2.5 точно не работает ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 18:27 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
kdvslrb, скрипт по крону пускай, нечего торкать mon$ на коннект. kdv дело говорит. Поддерживаю. У меня на промышленных базах именно так. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 08:54 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Тоже бьюсь с этой проблемой. Думал в трешке пофиксено. Заметил только, что хуже становится на плохой сети, когда много ошибок 10054 Убивание "висяков" помогает, но несильно - как повезет ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 21:20 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Игорь-PicoMed, мне интересно, как кривая сеть может быть "пофиксена" в Firebird 3. К примеру, у нас много серверов на обслуживании, которые круглосуточно работают, и если бы эти сервера падали каждые четыре часа - это был бы апофеоз. Даже раз в сутки или в несколько дней - это уже ненормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 21:53 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
kdvИгорь-PicoMed, мне интересно, как кривая сеть может быть "пофиксена" в Firebird 3. К примеру, у нас много серверов на обслуживании, которые круглосуточно работают, и если бы эти сервера падали каждые четыре часа - это был бы апофеоз. Даже раз в сутки или в несколько дней - это уже ненормально. Главный вопрос - где ошибка. В сети или в FB. У меня 43 сервера с одинаковыми базами по структуре (версии FB и конфигурации идентичные), из них 6 страдают этой болезнью. 4 из них - это виртуалка (VMWare). Один вообще - печалька - перегружаем каждую ночь. Еще один - то работает дней 20, то раза три в день падает. Дыр в дисках/базах нет. Из падучих серверов ни один не живет больше 20 дней без перезагрузки, при этом по остальным - есть экземпляры которые по несколько лет не перегружались - и ни ни одного сбоя. Естественно собираем статистику чтобы не превращать работу в кошмар. Пытаюсь на стенде смоделировать ситуацию. Пока - не выходит. От нагрузки (количества юзеров) статистика по сбоям не зависит. Закономерностей нет, кроме уровня хреновости сети, и то что на виртуалке время жизни короче - о чем и писал выше. Хуже всего, что падает именно FB и именно по ошибке доступа к Security Database или lock-менеджеру. Другие сетевые службы работают исправно. Поэтому и вопрос - где фиксить или кому вилы в зад втыкать. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 13:35 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
Игорь-PicoMedУ меня 43 сервера с одинаковыми базами по структуре (версии FB и конфигурации идентичные), из них 6 страдают этой болезнью. 4 из них - это виртуалка (VMWare). Один вообще - печалька - перегружаем каждую ночь. для меня подобная информация - ключевая. Это значит, что у виртуалок надо пошагово менять настройки сети (сетевых "карт"). Я не спец по сети, но если сервер А не глючит, а сервер Б глючит, при этом сервер Б на виртуалке, то я не полезу "настраивать ФБ". Для меня очевидно, что проблема в виртуалке. Причем, слово "виртуалка" необязательно, отличие может быть в чем-то другом, и это отличие и надо фиксить, разве нет? Я как-то не улавливаю логики, почему надо фиксить ФБ, если при одинаковой версии и конфигурации у него проблемы на 6ти серверах из 43. p.s. расскажу историю. В одной конторе лет 10 назад была куча ошибок 10054, и явных сбоев коннектов. А мы в то время выпустили версию FBScanner, который мог определить, с какой стороны (клиент или сервер) оборвался коннект, и почему. Поставили, запустили. И ... ошибки 10054 прекратились совсем. Ок. Я сделал вывод, что поскольку FBScanner вносит задержку в передачу данных, видимо, на серваке есть какое-то ПО, которое без этих задержек "не успевает". Оказалось что да, стояла там какая-то фигня от HP, которая перехватывала пакеты. Её обновили, и 10054 пропали. Это не намёк на FBscanner, а намёк на то, что проблемы с сетью нужно искать какими-нибудь снифтерами, которые могут анализировать причины сетевых ошибок. В ряде случаев это могут быть вообще железные тестеры сети. Также припоминаю случай, где одна дефективная сетевая карта на клиентском компе гадила в сеть при выключении компа, что приводило к периодическим падениям другого сервера с IB (это было вообще лет 20 назад). Так что вариантов подобных глюков - масса. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 14:16 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
У нас всё на виртуалках. Думаю даже, что всё на VMware. Проблем нет ни с ФБ, ни с МС, ни с Оракулом. Связь с филиалами, мягко говоря, не ахти. Поэтому и связались с VMware. Их решения позволяют минимизировать проблемы в сети. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:35 |
|
Зависание базы - новые коннекты не реагируют, старые работают
|
|||
---|---|---|---|
#18+
21.02.2019 15:35, KreatorXXI пишет: > Поэтому и связались с VMware. > Их решения позволяют минимизировать проблемы в сети. как это? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2019, 15:39 |
|
|
start [/forum/moderation_log.php?user_name=inferno100]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
89ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 734ms |
total: | 941ms |
0 / 0 |