|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Переехал с 9.21 на 10.00.UC6 Linux SLES 10.1. Вылеты в mtex.c сталм регулярны :(. Причем если раньше он был достаточно стабилен при выполненнии процедур с одновременным update statistics for procedure, то теперь вылазит в самом критичном месте - закрытие дня, когда два киллограмма процедур переворачивают всю базу вверх дном, т.е. данные из дневных таблиц сливаются в архивные, дневные таблицы пересоздаются и в них добавляют информацию, которая нужна на следующий день. Саппорт Информикса пока что недоступен (срок оплаты давно истек, бюджет на будующий год не раньше января). Саппорт аппликейшена меня пошлет (и будет прав) - аппликейшен тестирован только под RedHat. Но у меня под SLES куча других серверов, ради Informix заводить пингвинов другой масти очень не хочется. Причина лично для меня ясна - большая вложенность вызовов процедур. Повлиять на нее практически невозможно. Заниматься реинженирингом 5Мб SQL кода никто не будет. Дело усугубляется тем, что тестовый-резервный сервер пока что на 9.21 под Солярой и там такой проблемы нет. Надеюсь завтра подниму тест на SLES. ZIP с AF-ами (кстати в десятке формируется только стек, данных onstat-а в af-е нет) и onconfig-ом прилагаю. Преполагаю по onconfig-у: "IFX_EXTEND_ROLE" - поставлю в 0. Врядли оно, но когда что-то не работат все контроли лучше отключать. "TBLSPACE_STATS" - 0 по той же причине. DIRECTIVES 0 OPTCOMPIND 0 - производительности сервера для 99% запросов хватает с головой. "UPDATE STATISTICS" по среди дня сейчас дополнительная головная боль. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 13:48 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Есть неск. вопросов: 0) железо тестировалось перед установкой софта ? 1) при установке ТОЧНО выполнены требования из machine_notes к настройкам ядра/конфига? 2) ядро ОС с поддержкой ACPI ? 3) в конфиге: а) две строки для одного параметра, некрасиво как-то... BUFFERPOOL default,buffers=1000,lrus=8,lru_min_dirty=50,lru_max_dirty=60 BUFFERPOOL size=2k,buffers=500000,lrus=8,lru_min_dirty=50,lru_max_dirty=60 к тому же цифра buffers=500000 мне кажется рискованно большой на 32bit архитектуре... я бы попробовал уменьшить до 300000 ради эксперимента. б) PHYSFILE 20000 мониторится ли, насколько хватает этого объема в период нагрузки? в) может кошернее определять настройки VP через опцию VPCLASS, а не через устаревшие NUMCPUVPS SINGLE_CPU_VP NOAGE ... ? г) из каких соображений менялось: #SHMBASE 0x44000000L # Shared memory base address SHMBASE 0x10000000L ... что по этому поводу рекомендует тот же machine_notes? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 15:08 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Спасибо за ответ. 0. Железо гонялось почти год. Это одно из 14 однотипных лезвий с общими дисковым массивом. Перед запуском в продакшен лезвие месяц вертелось под нагрузкой на порядок превышающей стандартную. Одно плохо, операции начала-конца дня тестировались не так плотно :(. 1. После избиения системщика выяснилось, что таки пара параметров подгуляла. Хотелось бы надеятся, что виноваты именно они. 2. Да. 3. а)С BUFFERPOOL-ом я играюсь в данный момент. У второй группы был другой размер страницы. Приведение к одному BUFFERPOOL-у на падение сервера не повлияло. На счет много, не сказал бы. Вся активная часть БД в кеше. б). Хватает, архивация данных идет в цикле небольшими порциями. в). Принято, почитаю на досуге доку, ибо лет 7 в руки точно ее не брал. г) Эксперимент на основании Гугла из-за проблем В machine_notes SHMBASE 0x44000000L. Сегодня верну взад. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 17:38 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Daugava 3. а)С BUFFERPOOL-ом я играюсь в данный момент. У второй группы был другой размер страницы. Приведение к одному BUFFERPOOL-у на падение сервера не повлияло. На счет много, не сказал бы. Вся активная часть БД в кеше. под "много" я имел ввиду не количество BUFFERS в связи с потребностью приложения, а в связи с ограничениями архитектуры... Могу соврать (где-то в ФАКе уже написано), но общий объем памяти, что максимально может заграбастать для себя oninit на 32-хразрядной ОС - порядка 2.7 (2.6?)Гб. Судя по вашему конфигу: SHMVIRTSIZE 768000 ... buffers=500000 имеем суммарно ~2.5Гб. Т.е. близко к максимуму. Можно нафантазировать(!), что если IDS захочет заиметь, к примеру, еще некоторое кол-во памяти под SHM_ADD или дополнительные LOCKS, то может "упереться" в невозможность их выделения. Отсюдова и вылеты... Впрочем, за неимением "onstat -a" на момент вылета, - это только фантазия. Второе, с учетом подозрений на большую вложенность вызовов процедур. В предоставленном конфиге есть параметр STACKSIZE 32 На IDS версии 11.5, к примеру, в machine_notes явным образом рекомендуется установить его значение в 128. За что именно отвечает этот параметр - времени почитать уже нет, убегаю, но звучит вдохновляюще :) Я бы попробывал тоже увеличить... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 18:11 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Нетипичных тасков на системе в рабочее время нет (за них сразу расстрел на месте). Нормальное количество активных юзеров в системе - 5. Из них 2 бота, так что для моего случая 200Мб резерв по-моему очень даже ничего. А вот судя по STACKSIZE это бинго! Спасибо, думаю поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 18:34 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Присоединяюсь по поводу увеличения STACKSIZE Помню еще старые какие то рекомендации по его увеличению при больших рекурсиях. Да и 64 обычно стоит по умолчанию уже давненько (?), а тут всего 32. RA_PAGES и RA_THRESHOLD ты не устанавливаешь из религиозных соображений - я помню :) SHMVIRTSIZE 768000 - а зачем такой огромный размер на 5 сессий ? Мне кажется, лучше буферный пул увеличить. если активная база небольшая. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 21:18 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
То что Вы переехали на IDS 10-ку это нормально. Хуже всего то, что на IDS 10.0.xC6 ... уж лучше на IDS 10.0.xC8.W4 - поверь мне. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 22:18 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
GVF112GVFТо что Вы переехали на IDS 10-ку это нормально. Хуже всего то, что на IDS 10.0.xC6 ... уж лучше на IDS 10.0.xC8.W4 - поверь мне. С уважением, Вадим. Или на IDS 10.0.xC9W1 ... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 22:35 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
У меня Informix за 11 лет мигрировал в факультатив. Если в остальных системах при увеличении нагрузки, юзеров стало на 2 порядка больше, в информиксной как было пятеро так и осталось. До RA_* параметров вопрос даже не добрался, производительность мне почти по барабану, ибо у меня запас производительности на порядок. Основная тема при переходе: А. под поддерживаемую производителем платформу. Б. под ОС, под которую у меня есть админы. В. на железо, которому меньше 7 лет. На железе имеется 4Гб ОЗУ (меньше нет ни на одном из 14 лезвий). Поэтому пытаюсь приткнуть память куда-нибудью. Кроме как на Информикс девать память ее негде. Поэтому я ее распихал во все дыры. Проблемы только при закрытии дня, который с 5-й итерации закатывается, а кроме меня этих итераций никто не видит. Для основной работы RA_* в принципе не интересен, поскольку система выродилась в OLTP. С текущими BUFFERS все в кеше. 99% DSS ушло в другие системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 22:41 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
GVF112GVF, пока у меня не проплачен апгрейд, саппорт и т.д. пользуюсь тем, что есть. По большому счету системе более чем достаточно было 7.2 купленного в 97-м :). ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 22:43 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Увеличил stacksize до 128. Полет нормальный. Надеюсь вопрос закрылся. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2008, 23:53 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
DaugavaGVF112GVF, пока у меня не проплачен апгрейд, саппорт и т.д. пользуюсь тем, что есть. По большому счету системе более чем достаточно было 7.2 купленного в 97-м :)." ... а потом что было, то и полюбила..." (С). Я бы прислушался к мнению держащего руку на пульсе коллеги. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2008, 13:09 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Я прислушался и взял на заметку. Деньги в бюджет на обновление Informix-а на 2009-й год заложены. В 2008-м я их достать не могу. Кстати, провел эксперимент. В течение нескольких часов каждые 10 секунд update statistics "дневных" таблиц и процедур. Негативных эффектов нет. Раньше это была практически документированнная возможность для укладки сервера. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2008, 13:50 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
И, как обычно :), при множестве внесенных изменений так и непонятно, что все таки помогло ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2008, 14:33 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Я таки думаю, что STACKSIZE. Впрочем тестовый сервер уже добилдил RAID, к вечеру подниму Informix, backup и посмотрим кто был виноват. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2008, 15:21 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Дао, если постучишься в аську 255930914 или на zaiets@gmail.com могу дать все настройки информикса, который работает уже более года под твоей системой. Правда я и есть наверное тот виновник, из-за которого на RHL 5 работает. Кстати RHL 6 мы отбраковали - медленно дисковые операции, возможно какое-то ядро было не то. Но это было давно уже. По поводу обновления версий - не верь никому. на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через саппорт все поправилось на этой версии. Пробовали 10.00UC8 - не пошло, не советую. UC7 и UC8 какие-то багавитые получились - куча запросов просто едет. Да и нафиг оно нужно перед НГ. На 10.00UC9 байда с бтрисканером, никак не соберусь написать в саппорт - не могу изменить приоритет на лав. Правда уже вышел фикс, но его еще не смотрел. По поводу темповых пространств - запей на 3 пространства - с одним работает как по мне лучше и без ошибок. По поводу статистики. Если используешь statist.sh разработчика - то там фигня - он делает статистику токо отдельно по отдельным полям индекса, а этого мало. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2008, 01:23 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Разработчик UC6 и рекомендует. В принципе, несмотря на кризис мы сейчас ищем информикс-админа, как найдем и оплатим саппорт, вот ему и будет раздолье для экспериментов. Тем более тестовых-резервных серверов под SuSe у меня скоро будет 3 штуки . Сейчас система отдана в лапы дежурной смены и мне ею заниматься недосуг. За прошедшие сутки сбоев не отмечено. На счет одного темпдбспейса в общем случае ты не прав, у меня на прошлом серваке болталось без дела 4 винта просто на SCSI без всяких рейдов, я на каждом из них поставил по темп.спейсу. Прирост производительности был весьма заметен, ибо через темп идут практически все операции с базой. На данный момент таки да, возможно один темп или несколько разницы особой не будет, поскольку все равно это один и тот же дисковый массив. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2008, 09:37 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
По поводу обновления версий - не верь никому. на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через саппорт все поправилось на этой версии. Вот этому - действительно верить нельзя . Версия 10.00.UC6 - одна из самых не стаблиных. Это подтверждает сам Support IBM !!! Позвоните им Вам ответят ... :) На 10.00UC9 байда с бтрисканером, никак не соберусь написать в саппорт - не могу изменить приоритет на лав. Правда уже вышел фикс, но его еще не смотрел. Читайте документацию - начиная с 10.00.XC7 - LOW - ОТМЕНИЛИ !!! По поводу темповых пространств - запей на 3 пространства - с одним работает как по мне лучше и без ошибок. Без ошибок может .. а вот лучше - не всегда и не для всех запросов ... и не для всех систем .. ... и т.д. Многое зависит от архитектуры и схемы базы данных. Как правило, разработчики которые не работали с объемами данных > 300 GB, могут и не иметь опыта проектирования больших баз данных .... какую стратегию фрагментации выбирать и почему. Как следствие - не зрелые советы, рекомендации ... и отсутствие реального опыта. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2008, 21:53 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
Разработчик UC6 и рекомендует. В принципе, несмотря на кризис мы сейчас ищем информикс-админа, как найдем и оплатим саппорт, вот ему и будет раздолье для экспериментов. Тем более тестовых-резервных серверов под SuSe у меня скоро будет 3 штуки . Для начала "Memory Leak" - defect 132429, все отсальное можно будет узнать только по результатам функционального и нагрзузочного тестирования. Возможно, что Ваши SQL-запросы и не затронут те грабли на которые наступали многие разработчики. Желаю удачи! С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2008, 22:04 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
GVF112GVF По поводу обновления версий - не верь никому. на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через саппорт все поправилось на этой версии. Вот этому - действительно верить нельзя . Версия 10.00.UC6 - одна из самых не стаблиных. Это подтверждает сам Support IBM !!! Позвоните им Вам ответят ... :) Читайте документацию - начиная с 10.00.XC7 - LOW - ОТМЕНИЛИ !!! Без ошибок может .. а вот лучше - не всегда и не для всех запросов ... и не для всех систем .. ... и т.д. Многое зависит от архитектуры и схемы базы данных. Как правило, разработчики которые не работали с объемами данных > 300 GB, могут и не иметь опыта проектирования больших баз данных .... какую стратегию фрагментации выбирать и почему. Как следствие - не зрелые советы, рекомендации ... и отсутствие реального опыта. . Н-да, как оказывается только релиз ноутс читать мало, в документейшн ноутс нужно заглядывать. Понятие стабильности весьма относительно. И не совсем обязательно что проблемы других будут проявляться у меня. В данном случе имелось в виду что именно эта версия ИДС с используемым прикладным софтом работает стабильно и удовлетворяет требования бизнеса. На старших версиях - начинаются проблемы производительности для указанной прикладной системы. И насколько я знаю, выше хС6 никто ее не тестировал. По поводу временных пространств. Если указано несколько пространств, то вроде бы как временные объекты создаются в нескольких пространствах одновременно. Для боьшинства случаев этого не нужно. А для случаев когда нужно, ничто не мешает на стороне клиента определить временные пространства. Кстати, на 9.21 на указанной системе часто при указанных нескольких временных пространствах сыпались аефки с 200 какой-то ошибкой(212?). Точно уже и не помню номер ошибки - года 4 назад вроде как это было. После установки в одно пространство - значительно реже стали возникать данные ошибки. Ясно конечно, что универсального случая нет и прикладные системы отличаются. Высказывая свое мнение я отталкивался именно от конкретной прикладной задачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2008, 00:08 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
zaiets Кстати, на 9.21 на указанной системе часто при указанных нескольких временных пространствах Игорь, у меня 4 темпа на 9.21UC2 жили в течение 6 с гаком лет. База правда даже в эпоху своего расцвета еле перевалила за 100 гиг да и дневные нагрузки до 80тык документов. Единственный реально задалбывавший момент - это падения сервака в момент апдейта стата. Ну и еще весьма медленный level-0 примерно раз в месяц, на который уходили все выходные. Темп пространства в обоих случаях не причем. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2008, 09:02 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
У меня когда то при переезде на новую версию сервак при вызове любой ХП валился с этой ошибкой. Вылечилось командой update statistics for procedure; попробуйте вдруг поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2008, 15:12 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
У меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2008, 15:27 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
DaugavaУ меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял. афигеть в кроне? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2008, 17:12 |
|
MTEX.C методы борьбы кроме саппорта
|
|||
---|---|---|---|
#18+
cprDaugavaУ меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял. афигеть в кроне? off-topic Ну разве можно доверить бездушному автомату такую ответственную и творческую работу ? Да еще и в финансовой системе. Только админ, причем главный. И только ручками, бережно, каждый раз с опаской, подглядывая в потертую, но бесценную инструкцию :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2008, 17:22 |
|
|
start [/forum/topic.php?fid=44&msg=35660767&tid=1607872]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 169ms |
0 / 0 |