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

victor3000 · Сообщение **victor3000** » 17 апр 2007, 18:55

. а такой вопрос не по теме конечно. хочу сделать связь с машинами, но читал в соседних топиках что на больших пингах будут проблемы и что в 2.1 вроде должны в принципе решить эту проблему. ВЫ не в курсе какие-то шаги сделаны в этом направлении в новой версии? и еще если кто из разработчиков готов подправить код firebirda, вынеся мою проблему на первый план (я так понимаю там очередь на исправления багов), я готов оплатить разумную сумму. предложения в личку.
p.s. можно конечно ждать, но год с начала открытия топика это много

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

dimitr · Сообщение **dimitr** » 17 апр 2007, 22:32

2.1 лучше себя ведет на больших пингах (уже сейчас), но я бы не стал кричать про принципиальное решение проблемы. Люди отмечают двухкратное ускорение при работе через интернет, это уже неплохо.

насчет года - дык только недавно удалось получить нормальную диагностику и понять причину. Есть старые баги, к которым просто нет подходов. Увы.

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

victor3000 · Сообщение **victor3000** » 18 апр 2007, 11:16

спасибо. понятно.

victor3000 · Сообщение **victor3000** » 19 июн 2007, 14:14

может есть новости? давно не заглядывал.

dimitr · Сообщение **dimitr** » 26 июн 2007, 14:07

занимаемся проблемой, на этой неделе скорее всего будет доступна тестовая версия с фиксом для тестирования

dimitr · Сообщение **dimitr** » 29 июн 2007, 12:27

Просьба автору ветки протестировать данную сборку и доложить результаты:
http://www.firebirdsql.org/download/rab ... 686.tar.gz

victor3000 · Сообщение **victor3000** » 29 июн 2007, 13:21

ок, спасибо ща поставлю, но есть нюанс. у меня сейчас на смене одновременно максимум 6 человек. при 6 редко виснет, может и не висеть вовсе. надо как минимум человек 10. а сейчас период отпусков, лето сами понимаете. но в любом случае ставлю и буду смотреть.

victor3000 · Сообщение **victor3000** » 29 июн 2007, 16:30

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

victor3000 · Сообщение **victor3000** » 29 июн 2007, 16:45

опять зависло, так часто давно не было. или совпадение или боюсь стало хуже.

victor3000 · Сообщение **victor3000** » 29 июн 2007, 22:38

еще блок. резюме, стало намного хуже, откатываться назад?

dimitr · Сообщение **dimitr** » 30 июн 2007, 00:03

там же лежит debug info, подложи его и поймай-ка снова дамп в момент блока. Может, что изменилось...

ЗЫ. после этого откатывайся, конечно же

victor3000 · Сообщение **victor3000** » 30 июн 2007, 02:41

Докладываю. При попытке перейти на дебаг версию, для начала решил сделать бекап-ресторе. при бекапе ругаеться что база повреждена. Фиксил gfix -mend, опосля прошло. Вывод если раньше раньше прибивание подвисшего процесса базу не убивало, то теперь такой фокус беследно не проходит. Второе наблюдение( за 9 часов было 6 блоков), заметил интересную разницу, раньше в одном процессе было максимум до 3-4 блоков иногда, а так в основном 1. Теперь же 5-6 блоков в одном процессе стабильно. Вообщем русские не здаются, поставил дебаг жду блок

.

victor3000 · Сообщение **victor3000** » 30 июн 2007, 03:44

дебаг, два процесса в блоках fb_lock_print:

OWNER BLOCK 11508
Owner id: 4999, type: 3, flags: 0x10, pending: 204940, semid: 8
Process id: 4999, UID: 0x54 Alive
Flags: 0x10
Requests (663): forward: 104184, backward: 204940
Blocks (3): forward: 1047252, backward: 1324376

OWNER BLOCK 894344
Owner id: 5000, type: 3, flags: 0x10, pending: 1042988, semid: 9
Process id: 5000, UID: 0x54 Alive
Flags: 0x10
Requests (608): forward: 487528, backward: 1042988
Blocks (2): forward: 398600, backward: 1166556

BT 4999:

(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7af70eb in semop () from /lib/libc.so.6
#2 0xb7cbb651 in semaphore_wait_isc_sync (count=-1076410896, semid=-4, semnums=0x8001) at ../src/jrd/isc_sync.cpp:4230
#3 0xb7cba33d in ISC_event_wait (count=1, events=0xbfd7494c, values=0xbfd74948, micro_seconds=10000000, timeout_handler=0xb7e3d1c0 <lock_alarm_handler>,
handler_arg=0xb76f0d34) at ../src/jrd/isc_sync.cpp:938
#4 0xb7e3ecc6 in wait_for_request (request=0xb7e3d1c0, lck_wait=1, status_vector=0xfffffffc) at ../src/lock/lock.cpp:4864
#5 0xb7e3d007 in grant_or_que (request=0xb759b08c, lock=0xb75718b8, lck_wait=1) at ../src/lock/lock.cpp:2883
#6 0xb7e3a42c in LOCK_enq (prior_request=0, parent_request=104184, series=3, value=0xad670030 "\024)", length=4, type=3 '\003', ast_routine=0xfffffffc,
ast_argument=0xfffffffc, data=0, lck_wait=1, status_vector=0xbfd762d0, owner_offset=11508) at ../src/lock/lock.cpp:555
#7 0xb7d9d2fb in LCK_lock (tdbb=0x3, lock=0xad66ffdc, level=3, wait=1) at ../src/jrd/lck.cpp:1021
#8 0xb7d9d49d in LCK_lock_opt (tdbb=0x1, lock=0xad66ffdc, level=3, wait=1) at ../src/jrd/lck.cpp:772
#9 0xb7d36247 in lock_buffer (tdbb=0xbfd75a80, bdb=0xad670048, wait=1, page_type=5 '\005') at ../src/jrd/cch.cpp:5161
#10 0xb7d32c43 in CCH_fetch_lock (tdbb=0x5, window=0xbfd74da0, lock_type=3, wait=1, latch_wait=1, page_type=5 '\005') at ../src/jrd/cch.cpp:862
#11 0xb7d338c7 in CCH_handoff (tdbb=0xbfd75a80, window=0xbfd74da0, page=10516, lock=3, page_type=5 '\005', latch_wait=1, release_tail=0)
at ../src/jrd/cch_proto.h:90
#12 0xb7cce70b in DPM_cardinality (tdbb=0xbfd75a80, relation=0xad641884, format=0x0) at ../src/jrd/cch_proto.h:120
#13 0xb7db0883 in OPT_getRelationCardinality (tdbb=0xfffffffc, relation=0xad641884, format=0xfffffffc) at ../src/jrd/Optimizer.cpp:594
#14 0xb7da1be6 in OPT_compile (tdbb=0xbfd75a80, csb=0xad41dd74, rse=0xad36c020, parent_stack=0x0) at ../src/common/classes/array.h:111
#15 0xb7d42e9d in post_rse (tdbb=0xfffffffc, csb=0xad41dd74, rse=0xad36c020) at ../src/jrd/cmp.cpp:5467
#16 0xb7d409b1 in pass2 (tdbb=0xbfd75a80, csb=0xad41dd74, parent=0xacf8b268) at ../src/jrd/cmp.cpp:5033
#17 0xb7d411e2 in pass2 (tdbb=0xbfd75a80, csb=0xad41dd74, parent=0xad4a2590) at ../src/jrd/cmp.cpp:4709
#18 0xb7d3d8ae in CMP_make_request (tdbb=0xbfd75a80, csb=0xad41dd74) at ../src/jrd/cmp.cpp:1991
#19 0xb7d3b81d in CMP_compile2 (tdbb=0xbfd75a80, blr=0xfffffffc <Address 0xfffffffc out of bounds>, internal_flag=0) at ../src/jrd/cmp.cpp:561
#20 0xb7d91ade in jrd8_compile_request (user_status=0xbfd762d0, db_handle=0xfffffffc, req_handle=0xbfd75b2c, blr_length=270,
blr=0xfffffffc <Address 0xfffffffc out of bounds>) at ../src/jrd/jrd.cpp:1691
#21 0xb7cc2c98 in isc_compile_request (user_status=0xace8dc44, db_handle=0xfffffffc, req_handle=0xace8dc3c, blr_length=270,
blr=0x1 <Address 0x1 out of bounds>) at ../src/jrd/why.cpp:1220
#22 0xb7e13176 in prepare (request=0xace8dbe4, string_length=270,
string=0xb774edf4 "Select ID,DT_Message,from_User,to_user,mess,sys,kakdolgo,(select fio from users b where b.id=a.From_user) fromuser,(select fio from users c where c.id=a.to_user) touser from chat a where id>=2879720\r\n"..., client_dialect=3, parser_version=2) at ../src/common/classes/array.h:132
#23 0xb7e10e22 in GDS_DSQL_PREPARE_CPP (user_status=0xbfd762d0, trans_handle=0xfffffffc, req_handle=0xb7818694, length=200,
string=0xb774edf4 "Select ID,DT_Message,from_User,to_user,mess,sys,kakdolgo,(select fio from users b where b.id=a.From_user) fromuser,(select fio from users c where c.id=a.to_user) touser from chat a where id>=2879720\r\n"..., dialect=3, item_length=12, items=0xfffffffc <Address 0xfffffffc out of bounds>,
buffer_length=32, buffer=0xfffffffc <Address 0xfffffffc out of bounds>) at ../src/dsql/dsql.cpp:1395
#24 0xb7cc7598 in isc_dsql_prepare_m (user_status=0xbfd762d0, tra_handle=0xbfd75ecc, stmt_handle=0xfffffffc, length=200,
string=0xb774edf4 "Select ID,DT_Message,from_User,to_user,mess,sys,kakdolgo,(select fio from users b where b.id=a.From_user) fromuser,(select fio from users c where c.id=a.to_user) touser from chat a where id>=2879720\r\n"..., dialect=32, item_length=12,
items=0xb7819a04 "\004\a\t\v\f\r\016\020\021\022\023\b", buffer_length=32, buffer=0xbfd75ed0 "АcЧї\003") at ../src/jrd/why.cpp:3357
#25 0xb7e64f58 in rem_port::prepare_statement (this=0xb781be84, prepareL=0xbfd76614, sendL=0xbfd76690) at ../src/remote/server.cpp:3079
#26 0xb7e6566b in process_packet (port=0xb781be84, sendL=0xbfd76690, receive=0xbfd76410, result=0x0) at ../src/remote/server.cpp:3359
#27 0xb7e61d6b in SRVR_main (main_port=0xb781be84, flags=0) at ../src/remote/server.cpp:267
#28 0xb7e6194d in server_main (argc=-4, argv=0xbfd76b58) at ../src/remote/inet_server.cpp:429
#29 0x08048569 in main (argc=-4, argv=0xfffffffc) at ../src/remote/server_stub.cpp:12

BT 5000:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7adf0eb in semop () from /lib/libc.so.6
#2 0xb7ca3651 in semaphore_wait_isc_sync (count=-1080623184, semid=-4, semnums=0x8001) at ../src/jrd/isc_sync.cpp:4230
#3 0xb7ca233d in ISC_event_wait (count=1, events=0xbf97030c, values=0xbf970308, micro_seconds=10000000, timeout_handler=0xb7e251c0 <lock_alarm_handler>,
handler_arg=0xb76d85c8) at ../src/jrd/isc_sync.cpp:938
#4 0xb7e26cc6 in wait_for_request (request=0xb7e251c0, lck_wait=1, status_vector=0xfffffffc) at ../src/lock/lock.cpp:4864
#5 0xb7e25007 in grant_or_que (request=0xb764fa2c, lock=0xb756d484, lck_wait=1) at ../src/lock/lock.cpp:2883
#6 0xb7e2242c in LOCK_enq (prior_request=972972, parent_request=487528, series=3, value=0xad662820 "МI", length=4, type=6 '\006', ast_routine=0xfffffffc,
ast_argument=0xfffffffc, data=0, lck_wait=1, status_vector=0xbf970ec0, owner_offset=894344) at ../src/lock/lock.cpp:555
#7 0xb7d852fb in LCK_lock (tdbb=0x6, lock=0xad6627cc, level=6, wait=1) at ../src/jrd/lck.cpp:1021
#8 0xb7d1e466 in lock_buffer (tdbb=0xbf970b80, bdb=0xad662838, wait=1, page_type=5 '\005') at ../src/jrd/cch.cpp:5228
#9 0xb7d1ac43 in CCH_fetch_lock (tdbb=0x5, window=0xad0c62a0, lock_type=6, wait=1, latch_wait=1, page_type=5 '\005') at ../src/jrd/cch.cpp:862
#10 0xb7d1b8c7 in CCH_handoff (tdbb=0xbf970b80, window=0xad0c62a0, page=18892, lock=6, page_type=5 '\005', latch_wait=1, release_tail=0)
at ../src/jrd/cch_proto.h:90
#11 0xb7cb82b9 in DPM_get (tdbb=0xbf970b80, rpb=0xad0c6258, lock_type=6) at ../src/jrd/cch_proto.h:120
#12 0xb7dd16c2 in purge (tdbb=0xbf970b80, rpb=0xad0c6258) at ../src/jrd/vio.cpp:4607
#13 0xb7dca513 in VIO_chase_record_version (tdbb=0xbf970b80, rpb=0xad0c6258, rsb=0xad0c1a78, transaction=0xad039bb4, pool=0xad039c90, writelock=false)
at ../src/jrd/vio.cpp:933
#14 0xb7dcc419 in VIO_get (tdbb=0xbf970b80, rpb=0xad0c6258, rsb=0xfffffffc, transaction=0xfffffffc, pool=0xad039c90) at ../src/jrd/vio.cpp:1736
#15 0xb7dae1a2 in get_record (tdbb=0xbf970b80, rsb=0xad0c1a78, parent_rsb=0xad032334, mode=RSE_get_forward) at ../src/jrd/rse.cpp:1892
#16 0xb7daded3 in get_record (tdbb=0xbf970b80, rsb=0xad032334, parent_rsb=0x0, mode=RSE_get_forward) at ../src/jrd/rse.cpp:2141
#17 0xb7dad255 in RSE_get_record (tdbb=0xbf970b80, rsb=0xad032334, mode=RSE_get_forward) at ../src/jrd/rse.cpp:266
#18 0xb7d4af43 in looper (tdbb=0xbf970b80, request=0xad0c60e8, in_node=0xad0c60e8) at ../src/jrd/exe.cpp:1723
#19 0xb7d4a758 in execute_looper (tdbb=0xbf970b80, request=0xad0c60e8, transaction=0xad039bb4, next_state=4294967292) at ../src/jrd/exe.cpp:1251
#20 0xb7d49e3e in EXE_receive (tdbb=0xbf970b80, request=0xad0c60e8, msg=1, length=18, buffer=0xacf9e5a0 "") at ../src/jrd/exe.cpp:599
#21 0xb7d7dc4a in jrd8_receive (user_status=0xbf970ec0, req_handle=0xfffffffc, msg_type=1, msg_length=18,
msg=0xfffffffc <Address 0xfffffffc out of bounds>, level=0) at ../src/jrd/jrd.cpp:3122
#22 0xb7cb0dac in isc_receive (user_status=0xbf970ec0, req_handle=0xfffffffc, msg_type=1, msg_length=18, msg=0x1 <Address 0x1 out of bounds>, level=0)
at ../src/jrd/why.cpp:3995
#23 0xb7df85e1 in GDS_DSQL_FETCH_CPP (user_status=0xfffffffc, req_handle=0xfffffffc, blr_length=12, blr=0xb773699c "\005\002\004", msg_type=0,
msg_length=4, dsql_msg_buf=0xb7801bb8 "") at ../src/dsql/dsql.cpp:1109
#24 0xb7caea51 in isc_dsql_fetch_m (user_status=0xbf970ec0, stmt_handle=0xfffffffc, blr_length=12, blr=0xb773699c "\005\002\004", msg_type=0, msg_length=4,
msg=0xb7801bb8 "") at ../src/jrd/why.cpp:2994
#25 0xb7e4bb43 in rem_port::fetch (this=0xb7803e84, sqldata=0xbf971238, sendL=0xbf971280) at ../src/remote/server.cpp:2177
#26 0xb7e4d625 in process_packet (port=0xb7803e84, sendL=0xbf971280, receive=0xbf971000, result=0x0) at ../src/remote/server.cpp:3347
#27 0xb7e49d6b in SRVR_main (main_port=0xb7803e84, flags=0) at ../src/remote/server.cpp:267
#28 0xb7e4994d in server_main (argc=-4, argv=0xbf971748) at ../src/remote/inet_server.cpp:429
#29 0x08048569 in main (argc=-4, argv=0xfffffffc) at ../src/remote/server_stub.cpp:12

p.s.Все откатился на 2.0.1(12855)

victor3000 · Сообщение **victor3000** » 12 июл 2007, 19:37

Вышла бета есть смысл пробывать?

hvlad · Сообщение **hvlad** » 12 июл 2007, 20:54

Нет

dimitr · Сообщение **dimitr** » 16 авг 2007, 15:44

новая сборка для тестирования:
http://www.firebirdsql.org/download/rab ... 686.tar.gz

там же рядом debug info

victor3000 · Сообщение **victor3000** » 20 авг 2007, 22:41

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

freemanzav · Сообщение **freemanzav** » 18 окт 2007, 08:45

victor3000 писал(а): о результатах отпишусь.

Ну и как?

victor3000 · Сообщение **victor3000** » 18 окт 2007, 12:55

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

freemanzav · Сообщение **freemanzav** » 19 окт 2007, 08:32

victor3000 писал(а):я переписуюсь приватно с разработчиком. поэтому сюда и не пишу. на данном этапе проблема не исправлена , жду новую сборку для теста.

У меня примерно такая же проблема. Решилась переходом с ядра 2.6 на 2.4. На ядре 2.4 не пробовал?