Fatal error
Igor Zavgorodny
> 18:20:13 Assert Failed: No Exception Handler
> 18:20:13 Informix Dynamic Server 2000 Version 9.21.UC3
> 18:20:13 Who: Session(2159834, statist@dbinter1, 18539, 688637964)
> Thread(2790282, xchg_1.0, 2908f238, 3)
> File: mtex.c Line: 405
Меня этот mtex.c достал хуже горькой редьки. Впрочем, в последние 9
месяцев очередного апгрейда прикладного софта падения сервера
прекратились (тьфу-тьфу), теперь 2-3 раза в неделю застреливается
сессия, в которой приключился Exception, правда номер строки в этом
случае другой " File: mtex.c Line: 356 ".
Четкого мнения о причинах я так и не сформировал. Единственным
отмеченным фактом, который влиял на повышение вероятности падения
сервера - это затянувшееся по времени выполнение архива нулевого уровня
(в результате фичи "old pages backup") и наслоившийся на него update
statistics for procedure.
В целом по onconfig-у ряд замечаний:
1. MAX_PDQPRIORITY 45
Насколько я понял из "onstat -g mgm" приложения под PDQ не заточенны,
поэтому лучше его выключить: MAX_PDQPRIORITY 0.
2. LRUS 128
Насколько видно из "onstat -F", запись у тебя идет во время чекпоинта,
т.е. LRUS не используется. Если хотелось добиться снижения времени
чекпоинта, то для того, чтобы заставить LRUS работать, надо снизить
значения параметров: LRU_MAX_DIRTY, LRU_MIN_DIRTY.
3. TBLSPACE_STATS 1
Установить в 0, никто не тестировал, но все утверждают, что крадется
10-15% производительности :-).
4. TAPEBLK,LTAPEBLK 16
Диски, на которые идет бекап, в RAID-e? Можно увеличить хотя бы до
размера страйпа. Впрочем, даже если не RAID и вообще не диск, а лента,
то все равно можно увеличивать. 16kb буфер - дань весьма устаревшим
системам.
5. OFF_RECVRY_THREADS 10
Некоторые собаководы рекомендуют ставить "1". Дескать восстановление
медленне, но надежнее.
6. Также многие собаководы для повышения вероятности целостности данных
настоятельно рекомендуют:
NOFUZZYCKPT 1 # Turn off Fuzzy Checkpoint (0 by default)
Впрочем, я у себя этого не делал.
Regards, Igor.
Vasyl Shulzhenko
"Igor Zavgorodny" <dau...@ukr.net> wrote in message
news:4073b5bd$1...@proxy.kreditprombank.com...
> Rodion wrote:
> > 18:20:13 Assert Failed: No Exception Handler
> > 18:20:13 Informix Dynamic Server 2000 Version 9.21.UC3
> > 18:20:13 Who: Session(2159834, statist@dbinter1, 18539, 688637964)
> > Thread(2790282, xchg_1.0, 2908f238, 3)
> > File: mtex.c Line: 405
> В целом по onconfig-у ряд замечаний:
> 1. MAX_PDQPRIORITY 45
> Насколько я понял из "onstat -g mgm" приложения под PDQ не заточенны,
> поэтому лучше его выключить: MAX_PDQPRIORITY 0.
Почему же ? Именно аварийная сессия использовала PDQ. Возможно, именно поэтому и
упала.
Кстати, значение DS_MAX_SCANS 1048576 явно "отфонарное", хоть и приходит от IBM
:)
Желательно установить в что то более осмысленное, если PDQ все же используется.
> 2. LRUS 128
> Насколько видно из "onstat -F", запись у тебя идет во время чекпоинта,
> т.е. LRUS не используется. Если хотелось добиться снижения времени
> чекпоинта, то для того, чтобы заставить LRUS работать, надо снизить
> значения параметров: LRU_MAX_DIRTY, LRU_MIN_DIRTY.
Это значение установлено исходя из большого размера буферного пула
BUFFERS 192000
И для данного случая, мне кажется, правильное, т.е. максимальное =128
> 3. TBLSPACE_STATS 1
> Установить в 0, никто не тестировал, но все утверждают, что крадется
> 10-15% производительности :-).
Кроме тебя, больше никто о таких цифрах не говорил, но я тебе, почему то, верю
:))
> 4. TAPEBLK,LTAPEBLK 16
> Диски, на которые идет бекап, в RAID-e? Можно увеличить хотя бы до
> размера страйпа. Впрочем, даже если не RAID и вообще не диск, а лента,
> то все равно можно увеличивать. 16kb буфер - дань весьма устаревшим
> системам.
Кстати, а существут максимальный размер ?
Или он зависит только от ленточного устройства ?
А если писать на диск ?
> 6. Также многие собаководы для повышения вероятности целостности данных
> настоятельно рекомендуют:
> NOFUZZYCKPT 1 # Turn off Fuzzy Checkpoint (0 by default)
> Впрочем, я у себя этого не делал.
А я теперь рекомендую выключать, если проблемы с дительностью КТ не очень
волнуют.
И еще, по статистике видно, что превыщаюется кол-во доступных блокировок, т.е.
LOCKS 20000 нужно увеличить, например до 40000. Много дополн.ресурсов это не
сьест.
Igor Zavgorodny
>>В целом по onconfig-у ряд замечаний:
>>1. MAX_PDQPRIORITY 45
>>Насколько я понял из "onstat -g mgm" приложения под PDQ не заточенны,
>>поэтому лучше его выключить: MAX_PDQPRIORITY 0.
>
> Почему же ? Именно аварийная сессия использовала PDQ. Возможно, именно поэтому и
> упала.
Я смотрел af. вчера, а отвечать начал сегодня. Мысль про первоочередную
виноватость PDQ была, но за ночь выветрилась :-).
>
>>2. LRUS 128
>>Насколько видно из "onstat -F", запись у тебя идет во время чекпоинта,
>>т.е. LRUS не используется. Если хотелось добиться снижения времени
>>чекпоинта, то для того, чтобы заставить LRUS работать, надо снизить
>>значения параметров: LRU_MAX_DIRTY, LRU_MIN_DIRTY.
>
>
> Это значение установлено исходя из большого размера буферного пула
> BUFFERS 192000
> И для данного случая, мне кажется, правильное, т.е. максимальное =128
Это понятно, но при таком большом буфферном пуле при значениях
LRU_MAX_DIRTY=60,LRU_MIN_DIRTY=50,CKPTINTVL=300 LRU работать не будет,
по крайней мере в onstat этого не видно.
>>3. TBLSPACE_STATS 1
>>Установить в 0, никто не тестировал, но все утверждают, что крадется
>>10-15% производительности :-).
> Кроме тебя, больше никто о таких цифрах не говорил, но я тебе, почему то, верю
> :))
Кто-то говорил, откуда-то ж я их взял :-). Впрочем, не исключенно что
там говорилось о совокупнусти TBLSPACE_STATS,QSTATS,WSTATS. В целом
резюме собаководов (включая Арта) по этому вопросу: выключать на рабочей
системе.
>
>>4. TAPEBLK,LTAPEBLK 16
>>Диски, на которые идет бекап, в RAID-e? Можно увеличить хотя бы до
>>размера страйпа. Впрочем, даже если не RAID и вообще не диск, а лента,
>>то все равно можно увеличивать. 16kb буфер - дань весьма устаревшим
>>системам.
> Кстати, а существут максимальный размер ?
> Или он зависит только от ленточного устройства ?
Поставил у себя вместо 64к 256к, скорость бекапа незначительно
возрасла. Впрочем, утверждать это со 100% гарантией не могу. Флюктуации
времени бекапa из-за "very old pages" у меня чересчур велики.
> А если писать на диск ?
Думаю, что тут все будет зависеть от кешей системы, raid, винтов,
страйпнусти RAID-а и т.д. и т.п.
Вообщем, в каждом конкретном случае необходимо производить отдельный
эксперимент.
>
>>6. Также многие собаководы для повышения вероятности целостности данных
>>настоятельно рекомендуют:
>>NOFUZZYCKPT 1 # Turn off Fuzzy Checkpoint (0 by default)
>>Впрочем, я у себя этого не делал.
> А я теперь рекомендую выключать, если проблемы с дительностью КТ не очень
> волнуют.
Меня волнует. Если бекап нуля затягивался до начала работы юзеров, то
время чекпоинта уходило в 2-3 минуты, при том, что у меня чекпоинт
интервал 5 минут. Впрочем, проблему заборол с помощью LRU. Чекпоинт упал
до 5-6 секунд, что моми юзерам не смертельно. Отключать фуззи боюсь,
учитывая, что "серьезный" проблем с нулевым бекапом весьма редок,
хочется убедиться, что проблема полечилась.
Regards, Igor.
Rodion
поэтому и
> упала
Откуда это видать-то?
Торможу я что-то...
"Vasyl Shulzhenko" <nospam_...@mail.ru> wrote in message
news:c50om9$i9d$1...@news.lucky.net...
Vasyl Shulzhenko
"Rodion" <m_ro...@mail.ru> wrote in message news:c5178q$7gs$1...@news.lucky.net...
> > Почему же ? Именно аварийная сессия использовала PDQ. Возможно, именно
> поэтому и
> > упала
>
> Откуда это видать-то?
> Торможу я что-то...
> > > > 18:20:13 Who: Session(2159834, statist@dbinter1, 18539, 688637964)
> > > > Thread(2790282, xchg_1.0, 2908f238, 3)
Вот три потока одной сессии, два из них exchange (сливают считанные и
отсортированные данные (?)
2908f238 -------*2159834 statist - 0 0 0 0 0
29093978 Y------*2159834 statist - 2a8d8750 0 0 3 0
29095728 Y--P---*2159834 statist - 2ac321a8 0 0 391 588
/usr/informix/bin/onstat -g ses 2159834:
session #RSAM total used
id user tty pid hostname threads memory memory
2159834 statist - 18539 dbinter1 3 1523712 1470688
tid name rstcb flags curstk status
2790248 sqlexec 29095728 Y--P--- 7188 29095728 cond wait(opened_up)
2790282 xchg_1.0 2908f238 ------- 3112 2908f238 running
2790283 xchg_2.0 29093978 Y------ 348 29093978 cond wait(ok_to_close)
Memory pools count 2
name class addr totalsize freesize #allocfrag #freefrag
2159834 V 298c7020 1425408 40904 2297 43
2159834_SOR V 2b72c020 98304 12120 11 4
name free used name free used
overhead 0 3296 mtmisc 0 984
scb 0 96 opentable 0 187704
filetable 0 12584 ru 0 224
misc 0 2208 log 0 6456
temprec 0 26256 keys 0 208
ralloc 0 995056 gentcb 0 2504
ostcb 0 2632 sort 0 17328
sqscb 0 46776 sql 0 40
srtmembuf 0 67528 rdahead 0 832
xchg_desc 0 608 xchg_port 0 368
xchg_packet 0 152 xchg_group 0 256
xchg_priv 0 192 scan_desc 0 1128
sort_desc 0 1184 btmrg_desc 0 192
hashfiletab 0 840 osenv 0 1152
buft_buffer 0 25640 sqtcb 0 13280
fragman 0 47200 shmblklist 0 136
sapi 0 104 udr 0 5480
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers
2159834 SELECT inter4 DR Wait 15 0 0 9.03
Last parsed SQL statement :
execute procedure get_mgr_prm ( ? , ? , ? , ? , ? )
==========------------- - - - - - -
/usr/informix/bin/onstat -g sql 2159834:
Informix Dynamic Server 2000 Version 9.21.UC3 -- On-Line -- Up 89 days
03:24:38 -- 537036 Kbytes
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers
2159834 SELECT inter4 DR Wait 15 0 0 9.03
Last parsed SQL statement :
execute procedure get_mgr_prm ( ? , ? , ? , ? , ? )
Rodion
> месяцев очередного апгрейда прикладного софта падения сервера
> прекратились (тьфу-тьфу), теперь 2-3 раза в неделю застреливается
> сессия, в которой приключился Exception, правда номер строки в этом
> случае другой " File: mtex.c Line: 356 ".
Привет еще раз !
А можно подробнее узнать, какая ОС, Informix, libc, релизы, какой прикладной
софт и тд.
"Igor Zavgorodny" <dau...@ukr.net> wrote in message
news:4073b5bd$1...@proxy.kreditprombank.com...
Igor Zavgorodny
>>Меня этот mtex.c достал хуже горькой редьки. Впрочем, в последние 9
>>месяцев очередного апгрейда прикладного софта падения сервера
>>прекратились (тьфу-тьфу), теперь 2-3 раза в неделю застреливается
>>сессия, в которой приключился Exception, правда номер строки в этом
>>случае другой " File: mtex.c Line: 356 ".
>
>
> Привет еще раз !
> А можно подробнее узнать, какая ОС, Informix, libc, релизы, какой прикладной
> софт и тд.
>
большая вложенность вызовов процедур из процедур. Падения в основном
вызываются ESQL-C приложением.
Первый раз падение с "MT_EX_OS" я получил после апгрейда на 7.31.UC5 на
SCO 5.0.2, разделения данных на несколько dbspace-ов и настройек
параметров RA_. Номер строки в те время был "mtex.c 446". До этого, тот
же софт на том же SCO и 7.22.UC2 работал без проблем. Определить
закономерность падений не удалось. Согласно "Tech Info" подобная
проблема описывался для IDS под Solaris, при этом батон крошился на баги
в солярном компилере. К концу жизни на этой версии IDS у меня падал
практически каждую пятницу утром, хотя в плане регламентных работ и
нагрузки пятница ни чем не отличается от других рабочих дней. Согласно
рассказам моего (не информикс) саппорта "mtex.c 446" наблюдался у
некоторых клиентов при отсутствии пользователей в системе и выполнении
архива 0-го.
Именно для устранения данной проблемы я проагрейдился до 9.21.UC2 под
Solaris 2.8 (X86). Падения сервера стали значительно реже, номер строки
"mtex.c 405". Удалось четко обозначить причину - "update statistics for
procedure" без разгона пользователей. При этом, если сбор статистики
пересекался с level-0, незакончившимся из-за "very old pages backup"
вероятность падения была практически 100%.
После разнесения юзеров (к счастью супер активный юзер у меня один и я
могу управлять им в автоматическом режиме) и сбора статистики, а также
нормализации времени бекапа "mtex.c 405" произошел ровно один раз,
правда как следствие проблемы в "mtex.c 356", которая происходит
достаточно часто, но не приводит к падению сервера. На мой взгляд, в
этом "mtex.c 356" виновата чрезмерная сложность и вложенность
используемых у меня процедур.
Regards, Igor.
Paul Tatarenko
Friday, April 9, 2004, 10:38:23 AM, you wrote:
[...покусано голодными мышами...]
IZ> Прикладной софт ESQL-C и DELPHI (BDE). Большое количество SPL-процедур,
IZ> большая вложенность вызовов процедур из процедур. Падения в основном
IZ> вызываются ESQL-C приложением.
IZ> Первый раз падение с "MT_EX_OS" я получил после апгрейда на 7.31.UC5 на
IZ> SCO 5.0.2, разделения данных на несколько dbspace-ов и настройек
IZ> параметров RA_. Номер строки в те время был "mtex.c 446". До этого, тот
IZ> же софт на том же SCO и 7.22.UC2 работал без проблем. Определить
[...покусано голодными мышами...]
IZ> этом "mtex.c 356" виновата чрезмерная сложность и вложенность
IZ> используемых у меня процедур.
Позволю себе небольшое дополнение, пока еще не всё забыл - больше двух
лет прошло. ;)
Я получил то же самое на 7.31.UC5 под SCO 5.0.5. Причем из четырёх
серверов только один начал падать по средам примерно в одно и тоже время
с упоминанием сессии одного и того же компа. Какой именно SQL-оператор
был, я уже не вспомню (может Гугль ещё помнит). Хранимых процедур там
почти не было (несколько штук, вызываемые один раз в месяц), запросы
сравнительно несложные и приложение, написанное на M$ Visual FoxPro 5.0,
подключалось через ODBC. Примерно через месяц в падениях сервера
перестали винить "ту" машину и пользователя - система нарушилась. Но что
стало дальше уже не знаю - сменил работу. :)
--
Best regards,
Paul Tatarenko http://attend.to/paul
[ winamp пошел за пивом и до сих пор не вернулся ]
Rodion
что это : "very old pages backup" ?
"Igor Zavgorodny" <dau...@ukr.net> wrote in message
news:40765347$1...@proxy.kreditprombank.com...
Igor Zavgorodny
> Можно я снова вернусь к проблеме и задам такой вопросик:
> что это : "very old pages backup" ?
>
Bug 101062 ARCHIVE PERFORMANCE DEGRADATION WHEN MANY CALLS TO
ARC_VERY_OLD_PAGE()
http://groups.google.com/groups?hl=uk&lr=&ie=UTF-8&oe=UTF-8&th=dca5ee5ea3ebf034&rnum=1
Regards, Igor.