Зависание процессов classic на linux

Access Violation, некорректное выполнение запросов или вызовов API, ошибки утилит командной строки, в общем все, что вам мешает работать

Модераторы: kdv, dimitr

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Зависание процессов classic на linux

Сообщение victor3000 » 03 май 2006, 17:54

Есть линукс сервер классик 2. Работает с ним к примеру 5 пользователей, в определенный момент клиентские приложения зависают. Попытка открыть приложение по новой не к чему не приводит. Вияснилось что нужно прибивать один из процессов firebirda на сервере потом у всех приложения продолжают работать , даже не требуются их перезапуск.
Кто подскажет что блокирует работу firebirda?

Ivan_Pisarevsky
Заслуженный разработчик
Сообщения: 644
Зарегистрирован: 15 фев 2005, 11:34

Сообщение Ivan_Pisarevsky » 04 май 2006, 08:33

Манера писать приложения и блокирует. :)
Для меня штатная ситуация это если запущено пяток приложений, только с моей машины, не считая моих операторов.

Почитай еще статейку про кипалив, здесь же на сайте.

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

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 04 май 2006, 14:38

у меня есть ошибки в логах 104. вот сдесь есть http://www.ibase.ru/devinfo/errors.htm ссылка и рекомендация отследить их с помощью http://www.ibase.ru/download/ibconsvc.zip но она только под винду. как поступить в ситации с linux.

Ivan_Pisarevsky
Заслуженный разработчик
Сообщения: 644
Зарегистрирован: 15 фев 2005, 11:34

Сообщение Ivan_Pisarevsky » 04 май 2006, 16:55

Про кипалив таки почитай, 104 ошибка это помницца мне как раз и есть отвал клиента из-за проблем на клиенте или в сети по пути к нему.

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 05 май 2006, 07:51

и все таки я прошу помощи.
keepaliv настроен как рекомендовали сдесь с 2 часов стандартных до 1 минуты. в работоспособности настройки убеждался способом резета клиентской машины. через 1,5 минуты из "top" исчезал процесс и из netstat так же уходил конект с этой машиной. все остальные клиенты при этом спокойно работали.
при зависании обычно убивал по одному процессу все убивать не приходилось на одном из них работоспособность востанавливалась у части клиентов и они могли продолжать работать.
сегодня обратил внимание что при очередном вислове в команде
fb_lock_print
увидел следующее:
LOCK_HEADER BLOCK
Version: 16, Active owner: 0, Length: 360448, Used: 351856
Lock manager pid: 3722
Semmask: 0x2CE8, Flags: 0x0001
Enqs: 418646, Converts: 6446, Rejects: 7422, Blocks: 38192
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 721559, Acquire blocks: 16139, Spin count: 0
Mutex wait: 2.2%
Hash slots: 101, Hash lengths (min/avg/max): 6/ 11/ 17
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (12): forward: 11844, backward: 11508
Free owners: *empty*
Free locks (22): forward: 12428, backward: 245808
Free requests (243): forward: 176272, backward: 19112
Lock Ordering: Enabled

OWNER BLOCK 11844
Owner id: 3722, type: 1, flags: 0x04, pending: 0, semid: 2
Process id: 3722, UID: 0x0 Alive
Flags: 0x44 hung
Requests: *empty*
Blocks: *empty*

OWNER BLOCK 25288
Owner id: 3723, type: 3, flags: 0x00, pending: 0, semid: 4 (available)
Process id: 3723, UID: 0x0 Alive
Flags: 0x40 hung
Requests (474): forward: 25176, backward: 89788
Blocks: *empty*

OWNER BLOCK 216952
Owner id: 3805, type: 3, flags: 0x10, pending: 0, semid: 11 (available)
Process id: 3805, UID: 0x0 Alive
Flags: 0x50 hung
Requests (510): forward: 201800, backward: 19000
Blocks (1): forward: 19000, backward: 19000

OWNER BLOCK 156872
Owner id: 3899, type: 3, flags: 0x20, pending: 0, semid: 8 (available)
Process id: 3899, UID: 0x0 Alive
Flags: 0x20 wake
Requests (516): forward: 237924, backward: 343664
Blocks: *empty*

OWNER BLOCK 197612
Owner id: 4098, type: 3, flags: 0x20, pending: 0, semid: 12 (available)
Process id: 4098, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (409): forward: 201436, backward: 108408
Blocks: *empty*

OWNER BLOCK 128672
Owner id: 4099, type: 3, flags: 0x20, pending: 0, semid: 1 (available)
Process id: 4099, UID: 0x0 Alive
Flags: 0x20 wake
Requests (544): forward: 85100, backward: 349100
Blocks: *empty*

OWNER BLOCK 11712
Owner id: 4100, type: 3, flags: 0x00, pending: 0, semid: 9 (available)
Process id: 4100, UID: 0x0 Alive
Flags: 0x40 hung
Requests (109): forward: 30592, backward: 89996
Blocks: *empty*

OWNER BLOCK 139176
Owner id: 4101, type: 3, flags: 0x20, pending: 0, semid: 5 (available)
Process id: 4101, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (532): forward: 140876, backward: 269840
Blocks: *empty*

OWNER BLOCK 245920
Owner id: 4102, type: 3, flags: 0x20, pending: 0, semid: 10 (available)
Process id: 4102, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (108): forward: 152672, backward: 183160
Blocks: *empty*

OWNER BLOCK 155008
Owner id: 4108, type: 3, flags: 0x20, pending: 0, semid: 7 (available)
Process id: 4108, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (759): forward: 214924, backward: 203620
Blocks: *empty*

OWNER BLOCK 71296
Owner id: 7239, type: 3, flags: 0x00, pending: 0, semid: 3 (available)
Process id: 7239, UID: 0x0 Alive
Flags: 0x40 hung
Requests (507): forward: 342444, backward: 214560
Blocks: *empty*

OWNER BLOCK 11508
Owner id: 7240, type: 3, flags: 0x00, pending: 343716, semid: 6
Process id: 7240, UID: 0x0 Alive
Flags: 0x40 hung
Requests (439): forward: 346372, backward: 343716
Blocks: *empty*

Event log:
DEL_OWNER: owner = 156872, lock = 156872, request = 0
DEL_OWNER: owner = 245920, lock = 245920, request = 0
DEL_OWNER: owner = 245920, lock = 245920, request = 0
DEL_OWNER: owner = 197612, lock = 197612, request = 0
DEL_OWNER: owner = 156872, lock = 156872, request = 0
DEL_OWNER: owner = 156872, lock = 156872, request = 0
DEL_OWNER: owner = 11508, lock = 11508, request = 0
DEL_OWNER: owner = 156872, lock = 156872, request = 0
DEL_OWNER: owner = 197612, lock = 197612, request = 0
DEL_OWNER: owner = 197612, lock = 197612, request = 0
DEL_OWNER: owner = 197612, lock = 197612, request = 0
DEL_OWNER: owner = 128672, lock = 128672, request = 0
DEL_OWNER: owner = 197612, lock = 197612, request = 0
DEL_OWNER: owner = 128672, lock = 128672, request = 0
DEL_OWNER: owner = 11712, lock = 11712, request = 0
DEL_OWNER: owner = 139176, lock = 139176, request = 0
DEL_OWNER: owner = 245920, lock = 245920, request = 0
DEL_OWNER: owner = 71296, lock = 71296, request = 0
DEL_OWNER: owner = 155008, lock = 155008, request = 0
DEL_OWNER: owner = 71296, lock = 71296, request = 0
DEL_OWNER: owner = 11508, lock = 11508, request = 0
обратил внимание на этот блок
OWNER BLOCK 216952
Owner id: 3805, type: 3, flags: 0x10, pending: 0, semid: 11 (available)
Process id: 3805, UID: 0x0 Alive
Flags: 0x50 hung
Requests (510): forward: 201800, backward: 19000
Blocks (1): forward: 19000, backward: 19000

сдесь указан блок и id процесса. прибив конкретно этот процесс все остальные разблокировались. то есть необходимость прибивания методом тыка отпала. но проблема в корне все равно не решена.

вот еще фрагмент с другой ситуации
Owner id: 7381, type: 3, flags: 0x30, pending: 0, semid: 1 (available)
Process id: 7381, UID: 0x0 Alive
Flags: 0x70 hung wake
Requests (522): forward: 275160, backward: 264152
Blocks (1): forward: 264152, backward: 264152

еще интересное наблюдение. подвисшие клиенты со своей стороны
закрыли приложения к примеру через снятие диспетчером задач. при этом netstat на сервере через минуту показывает что конекты закрылись (keepaliv отработал)., в tope же все процессы висят(keepalive не работает хотя как писал выше и сетевые шнурки выдергивал и сбрасывал и все отрабатывало верно). больше инфы нет, зацепок нет, зависает когда хочет(зависит от звезд) закономерности нет, на винде на этой же машине и с этим же клиенским приложением все работало. ХЕЕЕЕЛП.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 05 май 2006, 10:35

victor3000 писал(а):LOCK_HEADER BLOCK
Version: 16, Active owner: 0, Length: 360448, Used: 351856
Lock manager pid: 3722
Semmask: 0x2CE8, Flags: 0x0001
Enqs: 418646, Converts: 6446, Rejects: 7422, Blocks: 38192
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 721559, Acquire blocks: 16139, Spin count: 0
Mutex wait: 2.2%
Hash slots: 101, Hash lengths (min/avg/max): 6/ 11/ 17
Не скажу сходу за зависания, но
1) увеличь LockMemSize, скажем в 2-4 раза, например 524288
2) увеличь LockHashSlots раз в 10, например до 1021 (выбери простое число)

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 09 май 2006, 06:09

ну подскажите хоть что нибудь. блокируется рандомно, НИКАКОЙ системы что больше всего бесит. за что цепляться??? как анализировать информацию с fb_lock_print или она ни о чем конкретно не говорит. в логах пусто, зависших конектов нет что делать???
OWNER BLOCK 216952
Owner id: 3805, type: 3, flags: 0x10, pending: 0, semid: 11 (available)
Process id: 3805, UID: 0x0 Alive
Flags: 0x50 hung
Requests (510): forward: 201800, backward: 19000
Blocks (1): forward: 19000, backward: 19000 что говорит вот эта строка, в не заблокированых сдесь пусто, может можно увязать с приложением, с базой, с чертом, но за что-то зацепиться?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 09 май 2006, 15:32

victor3000 писал(а):ну подскажите хоть что нибудь
Подсказали. Ты это сделал ?

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 09 май 2006, 15:55

[root@server bin]# ./fb_lock_print
LOCK_HEADER BLOCK
Version: 16, Active owner: 0, Length: 2097152, Used: 597052
Lock manager pid: 4150
Semmask: 0x49A8, Flags: 0x0001
Enqs: 1030265, Converts: 17683, Rejects: 22606, Blocks: 108818
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 1734855, Acquire blocks: 44743, Spin count: 0
Mutex wait: 2.6%
Hash slots: 1021, Hash lengths (min/avg/max): 2/ 2/ 7
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (11): forward: 18868, backward: 469448
Free owners (2): forward: 353540, backward: 400884
Free locks (24): forward: 19656, backward: 338688
Free requests (567): forward: 577964, backward: 388708
Lock Ordering: Enabled

OWNER BLOCK 18868
Owner id: 4148, type: 3, flags: 0x00, pending: 0, semid: 3 ( available)
Process id: 4148, UID: 0x0 Alive
Flags: 0x40 hung
Requests (2639): forward: 18948, backward: 588316
Blocks: *empty*

OWNER BLOCK 19072
Owner id: 4150, type: 1, flags: 0x04, pending: 0, semid: 1
Process id: 4150, UID: 0x0 Alive
Flags: 0x44 hung
Requests: *empty*
Blocks: *empty*

OWNER BLOCK 505896
Owner id: 4160, type: 3, flags: 0x30, pending: 0, semid: 11 ( available)
Process id: 4160, UID: 0x0 Alive
Flags: 0x70 hung wake
Requests (473): forward: 462708, backward: 551436
Blocks (1): forward: 587900, backward: 587900

OWNER BLOCK 27616
Owner id: 4165, type: 3, flags: 0x20, pending: 0, semid: 4 ( available)
Process id: 4165, UID: 0x0 Alive
Flags: 0x20 wake
Requests (680): forward: 383288, backward: 581384
Blocks: *empty*

OWNER BLOCK 459224
Owner id: 4176, type: 3, flags: 0x20, pending: 348600, semid: 2
Process id: 4176, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (716): forward: 242676, backward: 348600
Blocks: *empty*

OWNER BLOCK 428652
Owner id: 4185, type: 3, flags: 0x30, pending: 0, semid: 5 ( available)
Process id: 4185, UID: 0x0 Alive
Flags: 0x70 hung wake
Requests (622): forward: 561216, backward: 433384
Blocks (1): forward: 328684, backward: 328684

OWNER BLOCK 565976
Owner id: 4186, type: 3, flags: 0x20, pending: 0, semid: 6 ( available)
Process id: 4186, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (111): forward: 407324, backward: 564608
Blocks: *empty*

OWNER BLOCK 434216
Owner id: 4187, type: 3, flags: 0x20, pending: 0, semid: 7 ( available)
Process id: 4187, UID: 0x0 Alive
Flags: 0x20 wake
Requests (572): forward: 459060, backward: 382560
Blocks: *empty*

OWNER BLOCK 542516
Owner id: 4188, type: 3, flags: 0x20, pending: 0, semid: 10 ( available)
Process id: 4188, UID: 0x0 Alive
Flags: 0x60 hung wake
Requests (113): forward: 358560, backward: 498696
Blocks: *empty*

OWNER BLOCK 373476
Owner id: 4189, type: 3, flags: 0x30, pending: 0, semid: 8 ( available)
Process id: 4189, UID: 0x0 Alive
Flags: 0x70 hung wake
Requests (545): forward: 447224, backward: 588576
Blocks: *empty*

OWNER BLOCK 469448
Owner id: 4190, type: 3, flags: 0x30, pending: 0, semid: 9 ( available)
Process id: 4190, UID: 0x0 Alive
Flags: 0x70 hung wake
Requests (605): forward: 417588, backward: 414540
Blocks (1): forward: 393612, backward: 393612

Event log:
DEL_OWNER: owner = 353540, lock = 353540, request = 0
DEL_OWNER: owner = 373476, lock = 373476, request = 0
DEL_OWNER: owner = 565976, lock = 565976, request = 0
DEL_OWNER: owner = 27616, lock = 27616, request = 0
DEL_OWNER: owner = 542516, lock = 542516, request = 0
DEL_OWNER: owner = 353540, lock = 353540, request = 0
DEL_OWNER: owner = 373476, lock = 373476, request = 0
DEL_OWNER: owner = 434216, lock = 434216, request = 0
DEL_OWNER: owner = 400884, lock = 400884, request = 0
DEL_OWNER: owner = 469448, lock = 469448, request = 0
DEL_OWNER: owner = 459224, lock = 459224, request = 0
DEL_OWNER: owner = 428652, lock = 428652, request = 0
DEL_OWNER: owner = 565976, lock = 565976, request = 0
DEL_OWNER: owner = 434216, lock = 434216, request = 0
DEL_OWNER: owner = 542516, lock = 542516, request = 0
DEL_OWNER: owner = 373476, lock = 373476, request = 0
DEL_OWNER: owner = 469448, lock = 469448, request = 0
DEL_OWNER: owner = 353540, lock = 353540, request = 0
DEL_OWNER: owner = 400884, lock = 400884, request = 0

сделал все Ваши рекомендации видно вверху.
а вот тоже интересная ситуация, все повисло но никто ничего не делал в итоге спустя 2 часа при не работающих фактически клиентах наблюдается ТРИ блока у разных клиентов.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 09 май 2006, 21:34

Какой линукс и какой Fb2 ?

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 09 май 2006, 22:16

fedora core 3
Firebird 2.0 Release Candidate 1.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 10 май 2006, 08:06

в момент, когда висит процесс сервера, top какую загрузку проца показывает? Если блокирующий процесс загружен, то ничего ты не сделаешь - надо искать затык в кривых запросах/планах.

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 10 май 2006, 17:00

загрузка 0 и на всех клиентах и на сервере в целом.

victor3000
Сообщения: 98
Зарегистрирован: 27 апр 2006, 09:32

Сообщение victor3000 » 11 май 2006, 18:04

господа а давайте что-нибудь подскажем? ну например мануал почитай или прочее :). по сути как увеличить память (которая в случае надобности увеличивается сама :) ) никто толком ничего и не сказал.

adima
Сообщения: 12
Зарегистрирован: 06 сен 2005, 16:16

Сообщение adima » 11 май 2006, 22:56

у нас тоже такая проблема . Классик 1.5.2 под Suse Linux 9.0. Периодически, достаточно редко сервер внезапно останавливается, загрузка нулевая, пользователи жалуются на то, что все "висит". Помогает только "отстрел" всех коннектов. Причины не очень понятны

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 май 2006, 23:12

victor3000 писал(а):господа а давайте что-нибудь подскажем? ну например мануал почитай или прочее :).
Пробуй текущий снапшот. Если повторится, то пиши в fb-devel
Ещё можно не на федоре попробовать, ругались на неё

PS gfix -v -f что говорит ?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 май 2006, 23:13

adima писал(а):у нас тоже такая проблема . Классик 1.5.2 под Suse Linux 9.0. Периодически, достаточно редко сервер внезапно останавливается, загрузка нулевая, пользователи жалуются на то, что все "висит". Помогает только "отстрел" всех коннектов. Причины не очень понятны
Зуб дашь, что такая ?
sweep_interval чему равен ?
gstat -h в момент зависания делал ?

adima
Сообщения: 12
Зарегистрирован: 06 сен 2005, 16:16

Сообщение adima » 12 май 2006, 08:50

hvlad писал(а):Зуб дашь, что такая ?
Все очень похоже, только пользователей побольше, около 180 коннектов.
hvlad писал(а):sweep_interval чему равен ?

Код: Выделить всё

Database header page information:
...
    Variable header data:
        Sweep interval:         0
        *END*
hvlad писал(а):gstat -h в момент зависания делал ?
нет, а что он должен показать? я так понял, что этот ключ нужен для
установки sweep interval. Я думал, что в классике
используется кооперативная сборка мусора.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 12 май 2006, 12:02

adima писал(а):
hvlad писал(а):Зуб дашь, что такая ?
Все очень похоже, только пользователей побольше, около 180 коннектов.
Что очень похоже ??? Ты fb_lock_print делал и анализировал ?
adima писал(а):
hvlad писал(а):gstat -h в момент зависания делал ?
нет, а что он должен показать? я так понял, что этот ключ нужен для
установки sweep interval. Я думал, что в классике
используется кооперативная сборка мусора.
А давай ты таки сам прочитаешь (на этом же сайте) и про свип, и про статистику, и про то кто и как задаёт свип-интервал ?
Ибо жевать пережёванное N-ый раз мне, сам понимаешь, невкусно.

Я фигею с этих людей - не знать элементарных вещей и пускать 180 юзеров в БД :shock:
А потом жаловаться на неадекватное поведение системы...

adima
Сообщения: 12
Зарегистрирован: 06 сен 2005, 16:16

Сообщение adima » 12 май 2006, 13:05

:oops: В общем стормозил я, искал ключ -h у gfix.
про статистику и свип читал, действительно есть застрявшая транзакция, размер Hash Slots был выставлен по умолчанию в 101, сейчас увеличен.
буду разбираться дальше.

Ответить