|
JulianНа количество сегментов мы думали, но вроде сообщение об ошибке должно быть другим. Попробуем увеличить начальный размер.
/opt/informix/bin/onstat -g seg:
Informix Dynamic Server 2000 Version 9.21.UC3 -- On-Line -- Up 14:44:53 -- 345272 Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
4816896 1381386241 10000000 278257664 223264 R 67906 28
5111817 1381386250 2095e000 8192000 856 V 2000 0
5144586 1381386251 2112e000 663552 624 M 132 30
5177355 1381386252 211d0000 8388608 856 V 2047 1
5210124 1381386253 219d0000 8388608 856 V 2027 21
5242893 1381386254 221d0000 8388608 856 V 2043 5
5275662 1381386255 229d0000 8388608 856 V 2024 24
5308431 1381386256 231d0000 8388608 856 V 1933 115
5341200 1381386257 239d0000 8388608 856 V 1804 244
5373969 1381386258 241d0000 8388608 856 V 1801 247
5406738 1381386259 249d0000 8388608 856 V 207 1841
Total: - - 354222080 - - 83924 2556
(* segment locked in memory)
Всего памяти 1G.
Linux Red Hat с ядром 2.4 (абсолютно точно следующие цифры после точки
пока не могу сказать, т.к. сижу удаленно и и сейчас нет доступа к серверу).
Все dbspace и так на raw device (настоящие и ненастоящие - это как?).
На всякий случай повторяю прицеп в zip, но при этом не укладываюсь
в отведенный максимум 70K, из-за чего - две части (вторая, возможно, и
лишняя, просто для полноты).
Количество сегментов тут ни при чем. Сервер упал через минуту после выделения последнего сегмента.
Чем занята упавшая нить ? выполнением процедуры Price_Injunction
Last parsed SQL statement :
execute PROCEDURE Price_Injunction ( ? , ? )
User-created Temp tables :
partnum tabname rowsize
300007 inj_price_tmp 94
300007 inj_price_tmp 94
30000e print_appl_tmp 74
300007 inj_price_tmp 94
30000f print_appl_tmp 74
30000b weight_tmp 173
30000a print_protocol_tmp 34
30000f print_model_tmp 44
300007 inj_price_tmp 94
30000b weight_tmp 173
30000a print_protocol_tmp 34
300009 print_registr_tmp 51
Где именно в теле процедуры ? Где-то после создания таблиц print_appl_tmp, print_model_tmp . Что именно не нравится ? Выражение с преобразованием типов (кастингом), потому что стек выглядит
0x084f404f (oninit)afsig_handler(0xb, 0x2262a350, 0x2262a3d0, 0x24408440, 0x818f508, 0x2262a700)
0x4003da35 (*nosymtab*)0x4003da35(0xb, 0x2262a350, 0x2262a3d0, 0xb, 0x0, 0x1)
0x400cc840 (*nosymtab*)0x400cc840(0x2262a780, 0x0, 0x21c9a150, 0x2262a75c, 0x2262a780, 0x2262a704)
0x08150a2d (oninit)find_celist(0x21c9a150, 0x2262a780, 0x818f508, 0x2262a700, 0x247bdef0, 0x2262a760)
0x08150b39 (oninit)retrieve_rrcache(0x4, 0x2262a780, 0x2262a75c, 0x0, 0x818f298, 0x0)
0x0818f7ce (oninit)getcastinfo(0x2262a8e4, 0x2262a8f8, 0x2262a8b8, 0x2262a8f8, 0x2262a8e4, 0x2262a8b8)
0x0818b8be (oninit)getcast2(0x2262a8e4, 0x2262a8f8, 0x2262a8b8, 0x2262a850, 0x0, 0x0)
0x0818b52f (oninit)getcast (0x2262a8e4, 0x2262a8f8, 0x2262a8b8, 0x23ae1410, 0x23be8270, 0x0)
0x0812a0c1 (oninit)mkcastexpr(0x23be8270, 0x23be82b0, 0x49, 0x2262aa54, 0x23492710, 0x18)
0x08140660 (oninit)ip_doimplicit(0x23be8270, 0x23ae1410, 0x18, 0x0, 0x0, 0x244e9a18)
0x08140ac5 (oninit)ip_exprparse(0x244f5650, 0x23ae1410, 0x0, 0x23ae1410, 0x0, 0x244e9a18)
0x0813f9a9 (oninit)ip_evalexpr(0x23ae1410, 0x244f5650, 0x60220, 0x23ae10a0, 0x2, 0x21c9a0a0)
0x0813eb37 (oninit)runproc (0x2262ad08, 0x2262ad0c, 0x21c9a0a0, 0x23ae10a0, 0x23ae1238, 0x2262ad58
runproc - запустить процедуру,
...
ip_doimplicit - выполнить неявное преобразование типов,
getcast, getcast2, getcastinfo - входы в процедуры кастинга, потом сервер зачем-то лезет в (специализированный ) кэш ( retrieve_rrcache ), затем ищет какой-то список (find_celist) - и здесь грохается. afsig_handler - это уже обработка assert failure.
Так что, если вам сильно интересно, то трахайте процедуру Price_Injunction - ищите место где в ней падает и пытайтесь найти workaround. Ну или проапдейтесь до более свежей версии, 9.21.UC3 исполнилось сто лет в обед.
|
