Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ? / Firebird, InterBase

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

18 сообщений из 18, страница 1 из 1

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640065

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hi all

Дано:
1) два инстанса на одном linux-хосте, оба LI-T3.0.0.31129, порты прослушки: 3330 и 3333.
2) isql на виндовой тачке, клиент версии WI-V2.5.3.26730
3) в databases.conf обоих ФБ прописаны одни и те же алиас + база: oltp30b = /var/db/fb30/oltp30b.fdb

Лезу первым аттачем:

Код: plaintext

1.
2.

C:\MIX\firebird>isql -q 192.168.0.220/333 3 :oltp30b
Database:  192.168.0.220/3333:oltp30b
-- OK --

Лезу вторым аттачем, но вместо ввода команды вручную достаю её из истории и не гляжу на номер порта:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

C:\MIX\firebird>isql -q 192.168.0.220/333 0 :oltp30b
Statement failed, SQLSTATE = 08001
I/O error during "lock" operation for file "oltp30b"
-Error while trying to open file
-Resource temporarily unavailable
SQL> show database;
Command error: show database

Поняв ошибку, покидаю isql:

Код: plaintext

SQL> quit;

Лезу теперь на консоль сервера и ввожу команду "Кто открыл файл /var/db/fb30/oltp30b.fdb ?":

Код: plaintext

1.
2.
3.
4.
5.

$ lsof /var/db/fb30/oltp30b.fdb
COMMAND    PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird  1031 firebird  245uW  REG    8,4  2818048 6554803 oltp30b.fdb
firebird 26453 firebird    8u   REG    8,4  2818048 6554803 oltp30b.fdb
firebird 26453 firebird    9u   REG    8,4  2818048 6554803 oltp30b.fdb

С первой строкой всё понятно, это ФБ на порту 3333.
Вторая строка - это ФБ, который ломился к базе, до получил облом:

Код: plaintext

1.
2.
3.
4.
5.

$ ps aux|grep 26453|grep -v grep
firebird 26453  0.2  0.0 357216  3428 ?        Sl   16:45   0:02  /opt/fb30 /bin/firebird

$ grep -i remoteserviceport  /opt/fb30 /firebird.conf
RemoteServicePort = 333 0

Не веря своим глазам, вытаскиваю список всех файлов, которые открыты этим Firebird-инстансом (с pid = 26453):

Код: plaintext

1.
2.
3.
4.
5.

$ ls -l /proc/26453/fd
total 0
lrwx------ 1 firebird firebird 64 May 13 16:46 0 -> socket:[5160726]
lrwx------ 1 firebird firebird 64 May 13 16:49 8 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 16:49 9 -> /var/db/fb30/oltp30b.fdb

Файл базы, как видим:
1) открыт, хотя пр коннекте к нему был облом
2) присутствует в списке ДВА раза (хотя в случае 100500 успешно выполненных TCP-коннектов всё будет наоборот- 1 строка с именем файла базы).

Кто-нить может объяснить, ЧТО ЭТО ??

...

Рейтинг:

0 / 0

13.05.2014, 17:17

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640243

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

В общем, изабэлло как бэ это уже...
При краше ФБ остаются какие-то неубиваемые фантомные коннекты. Именно в том кол-ве, которое было непосредственно перед крашем. НЕ удаляются ни через 5 минут, ни через 5 часов - проверено уже не один раз.
Соотв-но, ни о какой валидации базейки речи быть не может. Да и процесс ФБ может при этом "застрять" так, что его не рестартанёшь корректным способом (/etc/init.d/fb*** restart) - выводит "красный [failed]".

Создал core-4426 и пусть меня дальше бьют, но истина дороже.

...

Рейтинг:

0 / 0

13.05.2014, 19:54

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640257

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Таблоид,

даже не начну ничего выяснять, пока ты не уберешь к чертовой матери зоопарк с несколькими инстансами и портами.

...

Рейтинг:

0 / 0

13.05.2014, 20:28

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640265

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrдаже не начну ничего выяснять, пока ты не уберешь к чертовой матери зоопарк с несколькими инстансами и портами.хм!.. паазвольте-с!! что незаконного в нескольких инстансах на одной машине ?
да и некуда мне убирать их - все остальные нормальные серваки заняты :(
А еще - как тогда сопоставлять произв-сть разных сборок (я про патчики всякие, которые иногда тут приходится применять) ?

...

Рейтинг:

0 / 0

13.05.2014, 20:42

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640270

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

ТаблоидВ общем, изабэлло как бэ это уже...
При краше ФБ остаются какие-то неубиваемые фантомные коннекты. Именно в том кол-ве, которое было непосредственно перед крашем. НЕ удаляются ни через 5 минут, ни через 5 часов - проверено уже не один раз.
каким именно образом к этой [пока что мифической] проблеме имеют отношения инстансы и порты? Если никакого, то нафига упоминать их в трекере, да и в этом топике тоже? Чтобы всех запутать?

...

Рейтинг:

0 / 0

13.05.2014, 20:57

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640275

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitr каким именно образом к этой [пока что мифической] проблеме имеют отношения инстансы и порты? Если никакого, то нафига упоминать их в трекере, да и в этом топике тоже? Чтобы всех запутать?Проблема сейчас выглядит так, что файл базы остаётся открытым. Что именно приводит к этому - еще не знаю. Может, коннект с ошибочно указываемым портом, а может и сочетание: краш + имевшаяся до этого попытка установить такой коннект (с неверным портом).
Буду исследовать.

...

Рейтинг:

0 / 0

13.05.2014, 21:10

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640278

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

ТаблоидБуду исследовать.
и это правильно. Вот только письма писать надо когда все выяснишь. Любишь ты рубить сплеча.

...

Рейтинг:

0 / 0

13.05.2014, 21:18

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640364

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrТаблоидБуду исследовать.
и это правильно. Вот только письма писать надо когда все выяснишь. Любишь ты рубить сплеча.Ну-с, вроде бы прояснилось. Пишу пока сюда, до трекера дойти всегда успею.
Заранее извиняйте, что не всё будет понятно: речь идёт об OLTP-тесте, который находится на финишной стадии, но еще не публиковался. Монстры же (ДЕ, Влад и ДС) - поймут, он есть у них вместе с описаловом.

1) рестартую ФБ
2) запускаю на новой базе тест, имитирующий OLTP-нагрузку, 60 аттачей (скрипт теста и батники я недавно высылал всем Источникам Света + ДСу :))
3) даю им поработать минут 5-7
4) стартую коннект к этой же базе, порт как у всех остальных (иначе не влезу, ес-сно). Даю ему задание - скрипт,заваливающий ФБ

Код: plaintext

1.
2.
3.

SQL> recreate table t(id int primary key, x int, y int); commit;
SQL> create index t_yx on t computed by( iif( ( select sum(y) from t tx where tx.x = t.x ) < 1000, id, -1 ) );
SQL> commit;
SQL> insert into t values( 1, 100, 300);

ФБ валится (примерно полминуты-минуту), все молотилки вылетают из isql, но там их поджидает цикл в батнике. И цикл этот заставит их выполнить новый коннект.
Даю поработать им так еще минуты три, после чего корректно останавливаю тест, создавая на сервере стоп-файл.
Все молотилки примерно через минуту "самозакроются" ввиду выброса ими user-defined исключения по имени 'ex_test_candellation'

подробнееМолотилки регулярно проверяют наличие хотя бы одной строки в external-таблице, которая смаплена на файл с именем 'stoptest.txt'.
Если там будет записано что-то типа '1' || ascii_char(13), то молотилки выбросят эксепшн и вывалятся из "своих" .sql-скриптов.
При этом, ввиду того что произошло именно исключение , будет логирование оного силами isql'я в STDERR-файл.
Батник же проверяет в STDERR-файле после каждого возврата из isql наличие именно этого слова ('ex_test_candellation'). Если оно там есть, он немедленно прекратит свою работу.

Последняя молотилка завершилась в 22:40:

её STDERR-лог

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

22:40:29.281 Statement failed, SQLSTATE = 42000
22:40:29.281 exception 23
22:40:29.281 -EX_TEST_CANCELLATION
22:40:29.281 -test_has_been_cancelled (external text file 'stoptest' is not empty)
22:40:29.281 -At procedure 'SP_CHECK_TO_STOP_WORK' line: 16, col: 9
22:40:29.281 At procedure 'SP_PAY_TO_SUPPLIER' line: 24, col: 5
22:40:29.281 After line 300 in file tmp_oltp_accountant.tmp
22:40:29.281 Statement failed, SQLSTATE = HY000
22:40:29.281 exception 23
22:40:29.281 -EX_TEST_CANCELLATION
22:40:29.281 -test_has_been_cancelled (external text file 'stoptest' is not empty)
22:40:29.281 After line 313 in file tmp_oltp_accountant.tmp

Ну, а дальше ввожу:
1) "Кто открыл файл "/var/db/fb30/oltp30b.fdb" ?

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.

$ date; lsof /var/db/fb30/oltp30b.fdb
Tue May 13 22:41:17 MSK 2014
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird 1468 firebird   32uW  REG    8,4  7258112 6554803 /var/db/fb30/oltp30b.fdb

$ date; lsof /var/db/fb30/oltp30b.fdb
Tue May 13 22:41:42 MSK 2014
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird 1468 firebird   32uW  REG    8,4  7258112 6554803 /var/db/fb30/oltp30b.fdb

$ date; lsof /var/db/fb30/oltp30b.fdb
Tue May 13 22:43:12 MSK 2014
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird 1468 firebird   32uW  REG    8,4  7258112 6554803 /var/db/fb30/oltp30b.fdb

$ date; lsof /var/db/fb30/oltp30b.fdb
Tue May 13 22:53:16 MSK 2014
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird 1468 firebird   32uW  REG    8,4  7258112 6554803 /var/db/fb30/oltp30b.fdb

$ date; lsof /var/db/fb30/oltp30b.fdb
Tue May 13 23:01:54 MSK 2014
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
firebird 1468 firebird   32uW  REG    8,4  7258112 6554803 /var/db/fb30/oltp30b.fdb

2) "Что за файлы держит открытыми процесс с pid = 1468 ?"

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.

$ date; ls -l /proc/1468/fd
Tue May 13 22:43:22 MSK 2014
total 0
lrwx------ 1 firebird firebird 64 May 13 22:36 0 -> socket:[5210634]
lrwx------ 1 firebird firebird 64 May 13 22:36 1 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 13 22:36 2 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 13 22:36 27 -> /tmp/firebird/fb_lock_0408000000000000b304640000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 3 -> /tmp/firebird/fb_trace_dKbwDg
lrwx------ 1 firebird firebird 64 May 13 22:36 31 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 13 22:36 32 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 4 -> /opt/fb30trnk/security3.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 5 -> /tmp/firebird/fb_lock_0408000000000000f21fc00000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 60 -> /tmp/fb_table_pjMj9T (deleted)


$ date; ls -l /proc/1468/fd
Tue May 13 22:44:33 MSK 2014
total 0
lrwx------ 1 firebird firebird 64 May 13 22:36 0 -> socket:[5210634]
lrwx------ 1 firebird firebird 64 May 13 22:36 1 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 13 22:36 2 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 13 22:36 27 -> /tmp/firebird/fb_lock_0408000000000000b304640000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 3 -> /tmp/firebird/fb_trace_dKbwDg
lrwx------ 1 firebird firebird 64 May 13 22:36 31 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 13 22:36 32 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 4 -> /opt/fb30trnk/security3.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 5 -> /tmp/firebird/fb_lock_0408000000000000f21fc00000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 60 -> /tmp/fb_table_pjMj9T (deleted)

$ date; ls -l /proc/1468/fd
Tue May 13 22:53:19 MSK 2014
total 0
lrwx------ 1 firebird firebird 64 May 13 22:36 0 -> socket:[5210634]
lrwx------ 1 firebird firebird 64 May 13 22:36 1 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 13 22:36 2 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 13 22:36 27 -> /tmp/firebird/fb_lock_0408000000000000b304640000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 3 -> /tmp/firebird/fb_trace_dKbwDg
lrwx------ 1 firebird firebird 64 May 13 22:36 31 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 13 22:36 32 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 4 -> /opt/fb30trnk/security3.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 5 -> /tmp/firebird/fb_lock_0408000000000000f21fc00000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 60 -> /tmp/fb_table_pjMj9T (deleted)

$ date; ls -l /proc/1468/fd
Tue May 13 23:01:49 MSK 2014
total 0
lrwx------ 1 firebird firebird 64 May 13 22:36 0 -> socket:[5210634]
lrwx------ 1 firebird firebird 64 May 13 22:36 1 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 13 22:36 2 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 13 22:36 27 -> /tmp/firebird/fb_lock_0408000000000000b304640000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 3 -> /tmp/firebird/fb_trace_dKbwDg
lrwx------ 1 firebird firebird 64 May 13 22:36 31 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 13 22:36 32 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 4 -> /opt/fb30trnk/security3.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 5 -> /tmp/firebird/fb_lock_0408000000000000f21fc00000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 60 -> /tmp/fb_table_pjMj9T (deleted)

$ date; ls -l /proc/1468/fd
Tue May 13 23:03:51 MSK 2014
total 0
lrwx------ 1 firebird firebird 64 May 13 22:36 0 -> socket:[5210634]
lrwx------ 1 firebird firebird 64 May 13 22:36 1 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 13 22:36 2 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 13 22:36 27 -> /tmp/firebird/fb_lock_0408000000000000b304640000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 3 -> /tmp/firebird/fb_trace_dKbwDg
lrwx------ 1 firebird firebird 64 May 13 22:36 31 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 13 22:36 32 -> /var/db/fb30/oltp30b.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 4 -> /opt/fb30trnk/security3.fdb
lrwx------ 1 firebird firebird 64 May 13 22:36 5 -> /tmp/firebird/fb_lock_0408000000000000f21fc00000000000
lrwx------ 1 firebird firebird 64 May 13 22:36 60 -> /tmp/fb_table_pjMj9T (deleted)

И так можно обвводиться до посинения: файлы остаются открытыми, в т.ч. и файл базы.

При этом потоки внутри процесса ФБ:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

$ ps -FLC -p 1468
UID        PID  PPID   LWP  C NLWP    SZ   RSS PSR STIME TTY      STAT   TIME CMD
firebird  1468 32756  1468  0    6 3728290 696784 11 22:36 ?      Sl     0:03 /opt/fb30trnk/bin/firebird
firebird  1468 32756  1469  0    6 3728290 696784 10 22:36 ?      Sl     0:00 /opt/fb30trnk/bin/firebird
firebird  1468 32756  1470  0    6 3728290 696784 7 22:36 ?       Sl     0:00 /opt/fb30trnk/bin/firebird
firebird  1468 32756  1471  0    6 3728290 696784 4 22:36 ?       Sl     0:00 /opt/fb30trnk/bin/firebird
firebird  1468 32756  1482  0    6 3728290 696784 9 22:36 ?       Sl     0:00 /opt/fb30trnk/bin/firebird
firebird  1468 32756  1526  0    6 3728290 696784 3 22:36 ?       Sl     0:00 /opt/fb30trnk/bin/firebird

Три бактрассы процесса 1468 (снимал с интервалом 10 сек) - в аттаче.

PS. Драма в трекере с перепутанным номером порта - согласен, лишняя. Всё с одним портом получилось :-)

...

Рейтинг:

0 / 0

13.05.2014, 23:12

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640394

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

ТаблоидФБ валится (примерно полминуты-минуту),
Используй отладочный билд. Моя интуиция подсказыват, что ты получишь ДВА ассерта. Вот
второй и будет причиной незакрытия коннектов.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

13.05.2014, 23:42

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640449

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Dimitry SibiryakovИспользуй отладочный билд. Моя интуиция подсказыват, что ты получишь ДВА ассерта. Вот
второй и будет причиной незакрытия коннектов.Использовал. Стошнило его от моих изысканий: после 50-го коннекта (а всего их должно было случиться 60) на консоли сервера вылезло:

Код: plaintext

1.
2.

$ /root/downloads/fb30snap/gen/Debug/firebird/bin/firebird -p 3333
Server started successfully
Segmentation fault (core dumped)

- и в /tmp появился:

Код: plaintext

$ ls -l /tmp/core.firebird.4809
-rw------- 1 root root 11895427072 May 14 01:30 /tmp/core.firebird.4809

Трасса с него - в аттаче.

...

Рейтинг:

0 / 0

14.05.2014, 01:39

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640450

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

ТаблоидСтошнило его от моих изысканийт.е. я хочу сказать, что придется грузить дебаговый билд слегка потише... сейчас попробую еще разок... :-)

...

Рейтинг:

0 / 0

14.05.2014, 01:41

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640453

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

ТаблоидТаблоидСтошнило его от моих изысканийт.е. я хочу сказать, что придется грузить дебаговый билд слегка потише... сейчас попробую еще разок... :-)В общем, нету никаких ассертов на консоли. Загрузил успешно 35 аттачей-молотилок, дал им поработать около 3 минут (уж не знаю, работали они на самом деле или нет! ибо ну ооочень медленно-тягомотно с дебуговым билдом всё).
Далее запустил отдельный сеанс, в котором запустил скрипт, заваливающий ФБ.
На консоли сервера при этом получилось всё то же самое: "Aborted (core dumped)".

Создался коредамп:
$ ls -l /tmp/core.firebird.5237
-rw------- 1 root root 12384956416 May 14 01:48 /tmp/core.firebird.5237

Бактрасса с него - в аттаче.
HTH.

...

Рейтинг:

0 / 0

14.05.2014, 01:53

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640483

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

на краш не обращай внимания, это прямое следствие багчека. Там сильно спорный кусок кода, его будем пересматривать.

...

Рейтинг:

0 / 0

14.05.2014, 07:33

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640484

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

лингер у тебя точно не включен?

...

Рейтинг:

0 / 0

14.05.2014, 07:38

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640522

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrлингер у тебя точно не включен?Если я правильно понимаю Алекса:core-4263Certainly this is not default. Linger is configured using ALTER DATABASE statement, i.e.

ALTER DATABASE SET LINGER TO 30; -- seconds
ALTER DATABASE DROP LINGER;
- то НЕТ, лингер я не включал.

...

Рейтинг:

0 / 0

14.05.2014, 08:58

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640546

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Таблоид,

не надо понимать, просто посмотри в rdb$database

...

Рейтинг:

0 / 0

14.05.2014, 09:26

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38640814

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrпосмотри в rdb$database

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

Database:  192.168.0.220/3333:oltp30
SQL> set list on;
SQL> select * from rdb$database;

RDB$DESCRIPTION                 <null>
RDB$RELATION_ID                 404
RDB$SECURITY_CLASS              <null>
RDB$CHARACTER_SET_NAME          NONE

RDB$LINGER                      <null>

...

Рейтинг:

0 / 0

14.05.2014, 12:39

| Ответить | Цитировать | Написать

Должен ли ФБ оставлять открытым файл базы при неуспешном аттаче по TCP ("resource busy") ?

#38641543

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Таблоидвроде бы прояснилось <...> речь идёт об OLTP-тестеТут еще вылезло, уже на тесте idx_under_load, который был запущен в виде 450 аттачей.
Этот тест также реагирует на стоп-файл с ЭТИМ ЖЕ именем ('stoptest.txt'), как и OLTP-emul.
Создал я этот стоп-файлик, все молотилки дружно "самозакрылись" в 21:10, выбросив всё то же user-исключение 'ex_test_cancellation'.

Через 15 минут делаю "анкетирование".

Q1. Кто держит открытым файл базы ?
A1. А всё тот же, кто и раньше:

Код: plaintext

1.
2.

$ lsof idx_under_load_ds.fdb
COMMAND    PID     USER   FD   TYPE DEVICE   SIZE/OFF    NODE NAME
firebird 18191 firebird    8uW  REG    8,4 1345355776 6553631 idx_under_load_ds.fdb

Q2. Что еще открыл этот процесс ?
A2. Да всё, как обычно:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

]$ ls -l /proc/18191/fd
total 0
lrwx------ 1 firebird firebird 64 May 14 20:30 0 -> socket:[5449053]
lrwx------ 1 firebird firebird 64 May 14 20:30 2 -> /tmp/firebird/fb_init
lrwx------ 1 firebird firebird 64 May 14 20:30 3 -> /tmp/firebird/fb12_trace
lrwx------ 1 firebird firebird 64 May 14 20:30 4 -> /tmp/firebird/fb_trace_gRpfTK
lrwx------ 1 firebird firebird 64 May 14 20:30 5 -> /opt/fb30/security3.fdb
lrwx------ 1 firebird firebird 64 May 14 20:30 6 -> /tmp/firebird/fb_lock_04080000000000007c20c00000000000
lrwx------ 1 firebird firebird 64 May 14 20:30 7 -> /tmp/firebird/fb_user_mapping
lrwx------ 1 firebird firebird 64 May 14 20:30 8 -> /var/db/fb30/idx_under_load_ds.fdb
lrwx------ 1 firebird firebird 64 May 14 20:30 9 -> /tmp/firebird/fb_lock_04080000000000001f00640000000000

Q3. А что там с заголовком лок-таблицы ?
A3. А вот что:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

$ /opt/fb30/bin/fb_lock_print -d /var/db/fb30/idx_under_load_ds.fdb
LOCK_HEADER BLOCK
        Version: 146, Creation timestamp: 2014-05-14 20:27:44
        Active owner:      0, Length: 4194304, Used: 3468624
        Enqs: 122909617, Converts:  18310, Rejects: 5683342, Blocks:      0
        Deadlock scans:      0, Deadlocks:      0, Scan interval:  10
        Acquires: 240431945, Acquire blocks: 15193059, Spin count:   0
        Mutex wait: 6.3%
        Hash slots: 8191, Hash lengths (min/avg/max):    0/   0/   5
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners (4):     forward:  78376, backward:  78568
        Free owners (447):      forward: 170376, backward: 2581416
        Free locks (1697):      forward:  80080, backward: 1710880
        Free requests (44312):  forward: 2602320, backward: 2633256

Q4. А что показывает ps для потоков процесса 18191 ?
A4. Да есть еще какие-то, помимо "стандартно-минимального" набора из трёх штук:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

$ ps -FLC -p 18191
UID        PID  PPID   LWP  C NLWP    SZ   RSS PSR STIME TTY      STAT   TIME CMD
firebird 18191 18190 18191 19    6 4397773 2056452 7 20:16 ?      Sl    15:20 /opt/fb30/bin/firebird
firebird 18191 18190 18193  0    6 4397773 2056452 10 20:16 ?     Sl     0:00 /opt/fb30/bin/firebird
firebird 18191 18190 18194  0    6 4397773 2056452 11 20:16 ?     Sl     0:00 /opt/fb30/bin/firebird
firebird 18191 18190 18398  0    6 4397773 2056452 11 20:27 ?     Sl     0:00 /opt/fb30/bin/firebird
firebird 18191 18190 18399  0    6 4397773 2056452 7 20:27 ?      Sl     0:00 /opt/fb30/bin/firebird
firebird 18191 18190 18402  3    6 4397773 2056452 4 20:27 ?      Sl     2:03 /opt/fb30/bin/firebird

Q5. А что там в firebird.log ?
A5. А ничего, пусто там. *Совсем* пусто, ошибок не было.

Q6. А что там с бактрассами процесса 18191 ?
A6. А это в аттаче, их там три штуки, созданы были с интервалом = 10 сек.

Итого: получается, что ФБ при каких-то загадочных обстоятельствах может держать базу открытой даже в случае, когда не было никакого краха. Все окна позакрывались САМИ, увидев стоп-файл и выбросив эксепшены.
След-но, валидацию базы хрен проведёшь без рестарта ФБ :(

Any comments ?

...

Рейтинг:

0 / 0

14.05.2014, 21:41

| Ответить | Цитировать | Написать

18 сообщений из 18, страница 1 из 1

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=40&fpage=96&tid=1563602]:	0ms
get settings:	5ms
get forum list:	13ms
check forum access:	2ms
check topic access:	2ms
track hit:	56ms
get topic data:	9ms
get forum data:	2ms
get page messages:	48ms
get tp. blocked users:	1ms
others:	197ms

total:	335ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы