powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / MTEX.C методы борьбы кроме саппорта
25 сообщений из 29, страница 1 из 2
MTEX.C методы борьбы кроме саппорта
    #35657820
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переехал с 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" по среди дня сейчас дополнительная головная боль.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35658110
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть неск. вопросов:
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?
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35658584
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за ответ.

0. Железо гонялось почти год. Это одно из 14 однотипных лезвий с общими дисковым массивом. Перед запуском в продакшен лезвие месяц вертелось под нагрузкой на порядок превышающей стандартную. Одно плохо, операции начала-конца дня тестировались не так плотно :(.
1. После избиения системщика выяснилось, что таки пара параметров подгуляла. Хотелось бы надеятся, что виноваты именно они.
2. Да.
3.
а)С BUFFERPOOL-ом я играюсь в данный момент. У второй группы был другой размер страницы. Приведение к одному BUFFERPOOL-у на падение сервера не повлияло. На счет много, не сказал бы. Вся активная часть БД в кеше.
б). Хватает, архивация данных идет в цикле небольшими порциями.
в). Принято, почитаю на досуге доку, ибо лет 7 в руки точно ее не брал.
г) Эксперимент на основании Гугла из-за проблем В machine_notes SHMBASE 0x44000000L.
Сегодня верну взад.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35658677
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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. За что именно отвечает этот параметр - времени почитать уже нет, убегаю, но звучит вдохновляюще :)
Я бы попробывал тоже увеличить...
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35658738
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нетипичных тасков на системе в рабочее время нет (за них сразу расстрел на месте). Нормальное количество активных юзеров в системе - 5. Из них 2 бота, так что для моего случая 200Мб резерв по-моему очень даже ничего.

А вот судя по STACKSIZE это бинго! Спасибо, думаю поможет.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659024
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Присоединяюсь по поводу увеличения STACKSIZE
Помню еще старые какие то рекомендации по его увеличению при больших рекурсиях.
Да и 64 обычно стоит по умолчанию уже давненько (?), а тут всего 32.

RA_PAGES и RA_THRESHOLD ты не устанавливаешь из религиозных соображений - я помню :)

SHMVIRTSIZE 768000 - а зачем такой огромный размер на 5 сессий ? Мне кажется, лучше буферный пул увеличить. если активная база небольшая.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659092
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
То что Вы переехали на IDS 10-ку это нормально.
Хуже всего то, что на IDS 10.0.xC6 ... уж лучше на IDS 10.0.xC8.W4 - поверь мне.

С уважением,
Вадим.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659114
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GVF112GVFТо что Вы переехали на IDS 10-ку это нормально.
Хуже всего то, что на IDS 10.0.xC6 ... уж лучше на IDS 10.0.xC8.W4 - поверь мне.

С уважением,
Вадим.

Или на IDS 10.0.xC9W1 ... :)
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659121
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня Informix за 11 лет мигрировал в факультатив. Если в остальных системах при увеличении нагрузки, юзеров стало на 2 порядка больше, в информиксной как было пятеро так и осталось.
До RA_* параметров вопрос даже не добрался, производительность мне почти по барабану, ибо у меня запас производительности на порядок. Основная тема при переходе:
А. под поддерживаемую производителем платформу.
Б. под ОС, под которую у меня есть админы.
В. на железо, которому меньше 7 лет.

На железе имеется 4Гб ОЗУ (меньше нет ни на одном из 14 лезвий). Поэтому пытаюсь приткнуть память куда-нибудью. Кроме как на Информикс девать память ее негде. Поэтому я ее распихал во все дыры. Проблемы только при закрытии дня, который с 5-й итерации закатывается, а кроме меня этих итераций никто не видит.

Для основной работы RA_* в принципе не интересен, поскольку система выродилась в OLTP. С текущими BUFFERS все в кеше. 99% DSS ушло в другие системы.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659126
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GVF112GVF,

пока у меня не проплачен апгрейд, саппорт и т.д. пользуюсь тем, что есть. По большому счету системе более чем достаточно было 7.2 купленного в 97-м :).
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35659201
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Увеличил stacksize до 128. Полет нормальный. Надеюсь вопрос закрылся.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35660241
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DaugavaGVF112GVF,

пока у меня не проплачен апгрейд, саппорт и т.д. пользуюсь тем, что есть. По большому счету системе более чем достаточно было 7.2 купленного в 97-м :)." ... а потом что было, то и полюбила..." (С). Я бы прислушался к мнению держащего руку на пульсе коллеги.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35660424
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я прислушался и взял на заметку. Деньги в бюджет на обновление Informix-а на 2009-й год заложены. В 2008-м я их достать не могу.
Кстати, провел эксперимент. В течение нескольких часов каждые 10 секунд update statistics "дневных" таблиц и процедур. Негативных эффектов нет. Раньше это была практически документированнная возможность для укладки сервера.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35660617
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И, как обычно :), при множестве внесенных изменений так и непонятно, что все таки помогло ?
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35660767
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я таки думаю, что STACKSIZE. Впрочем тестовый сервер уже добилдил RAID, к вечеру подниму Informix, backup и посмотрим кто был виноват.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35662039
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дао, если постучишься в аську 255930914 или на zaiets@gmail.com
могу дать все настройки информикса, который работает уже более года под твоей системой.

Правда я и есть наверное тот виновник, из-за которого на RHL 5 работает.
Кстати RHL 6 мы отбраковали - медленно дисковые операции, возможно какое-то ядро было не то.
Но это было давно уже.

По поводу обновления версий - не верь никому.
на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через
саппорт все поправилось на этой версии.

Пробовали 10.00UC8 - не пошло, не советую.
UC7 и UC8 какие-то багавитые получились - куча запросов просто едет.
Да и нафиг оно нужно перед НГ.

На 10.00UC9 байда с бтрисканером, никак не соберусь написать в саппорт - не могу изменить приоритет на лав. Правда уже вышел фикс, но его еще не смотрел.

По поводу темповых пространств - запей на 3 пространства - с одним работает как по мне лучше и без ошибок.

По поводу статистики. Если используешь statist.sh разработчика - то там фигня - он делает статистику токо отдельно по отдельным полям индекса, а этого мало.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35662326
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разработчик UC6 и рекомендует. В принципе, несмотря на кризис мы сейчас ищем информикс-админа, как найдем и оплатим саппорт, вот ему и будет раздолье для экспериментов. Тем более тестовых-резервных серверов под SuSe у меня скоро будет 3 штуки .
Сейчас система отдана в лапы дежурной смены и мне ею заниматься недосуг. За прошедшие сутки сбоев не отмечено.

На счет одного темпдбспейса в общем случае ты не прав, у меня на прошлом серваке болталось без дела 4 винта просто на SCSI без всяких рейдов, я на каждом из них поставил по темп.спейсу. Прирост производительности был весьма заметен, ибо через темп идут практически все операции с базой. На данный момент таки да, возможно один темп или несколько разницы особой не будет, поскольку все равно это один и тот же дисковый массив.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35664282
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
По поводу обновления версий - не верь никому.
на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через
саппорт все поправилось на этой версии.


Вот этому - действительно верить нельзя . Версия 10.00.UC6 - одна из самых не стаблиных.
Это подтверждает сам Support IBM !!! Позвоните им Вам ответят ... :)

На 10.00UC9 байда с бтрисканером, никак не соберусь написать в саппорт - не могу изменить приоритет на лав. Правда уже вышел фикс, но его еще не смотрел.


Читайте документацию - начиная с 10.00.XC7 - LOW - ОТМЕНИЛИ !!!

По поводу темповых пространств - запей на 3 пространства - с одним работает как по мне лучше и без ошибок.


Без ошибок может .. а вот лучше - не всегда и не для всех запросов ... и не для всех систем ..
... и т.д.
Многое зависит от архитектуры и схемы базы данных.
Как правило, разработчики которые не работали с объемами данных > 300 GB, могут и не иметь
опыта проектирования больших баз данных .... какую стратегию фрагментации выбирать и почему.
Как следствие - не зрелые советы, рекомендации ... и отсутствие реального опыта.

С уважением,
Вадим.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35664293
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Разработчик UC6 и рекомендует. В принципе, несмотря на кризис мы сейчас ищем информикс-админа, как найдем и оплатим саппорт, вот ему и будет раздолье для экспериментов. Тем более тестовых-резервных серверов под SuSe у меня скоро будет 3 штуки .


Для начала "Memory Leak" - defect 132429, все отсальное можно будет узнать только
по результатам функционального и нагрзузочного тестирования.
Возможно, что Ваши SQL-запросы и не затронут те грабли на которые наступали многие разработчики.

Желаю удачи!

С уважением,
Вадим.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35664400
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GVF112GVF По поводу обновления версий - не верь никому.
на 10.00UC6 данная система работает стабильно, правда была пару раз фигня, но через
саппорт все поправилось на этой версии.


Вот этому - действительно верить нельзя . Версия 10.00.UC6 - одна из самых не стаблиных.
Это подтверждает сам Support IBM !!! Позвоните им Вам ответят ... :)



Читайте документацию - начиная с 10.00.XC7 - LOW - ОТМЕНИЛИ !!!


Без ошибок может .. а вот лучше - не всегда и не для всех запросов ... и не для всех систем ..
... и т.д.
Многое зависит от архитектуры и схемы базы данных.
Как правило, разработчики которые не работали с объемами данных > 300 GB, могут и не иметь
опыта проектирования больших баз данных .... какую стратегию фрагментации выбирать и почему.
Как следствие - не зрелые советы, рекомендации ... и отсутствие реального опыта.
.


Н-да, как оказывается только релиз ноутс читать мало, в документейшн ноутс нужно заглядывать.

Понятие стабильности весьма относительно. И не совсем обязательно что проблемы других
будут проявляться у меня.

В данном случе имелось в виду что именно эта версия ИДС с используемым прикладным софтом
работает стабильно и удовлетворяет требования бизнеса.
На старших версиях - начинаются проблемы производительности для указанной прикладной системы. И насколько я знаю, выше хС6 никто ее не тестировал.

По поводу временных пространств.
Если указано несколько пространств, то вроде бы как временные объекты создаются в
нескольких пространствах одновременно. Для боьшинства случаев этого не нужно. А для случаев
когда нужно, ничто не мешает на стороне клиента определить временные пространства.

Кстати, на 9.21 на указанной системе часто при указанных нескольких временных пространствах
сыпались аефки с 200 какой-то ошибкой(212?). Точно уже и не помню номер ошибки - года 4 назад вроде как это было. После установки в одно пространство - значительно реже стали возникать данные ошибки.

Ясно конечно, что универсального случая нет и прикладные системы отличаются.
Высказывая свое мнение я отталкивался именно от конкретной прикладной задачи.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35664612
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zaiets Кстати, на 9.21 на указанной системе часто при указанных нескольких временных пространствах
Игорь, у меня 4 темпа на 9.21UC2 жили в течение 6 с гаком лет. База правда даже в эпоху своего расцвета еле перевалила за 100 гиг да и дневные нагрузки до 80тык документов. Единственный реально задалбывавший момент - это падения сервака в момент апдейта стата.
Ну и еще весьма медленный level-0 примерно раз в месяц, на который уходили все выходные. Темп пространства в обоих случаях не причем.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35668393
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
У меня когда то при переезде на новую версию сервак при вызове любой ХП валился с этой ошибкой.
Вылечилось командой
update statistics for procedure;
попробуйте вдруг поможет.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35668465
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял.
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35668802
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
DaugavaУ меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял.

афигеть
в кроне?
...
Рейтинг: 0 / 0
MTEX.C методы борьбы кроме саппорта
    #35668819
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cprDaugavaУ меня "update statistics for procedure;" выполняется ежечасно :). Полет кстати по прежнему нормальный (тьфу-тьфу). Тестовый сервак правда я до конца не поднял.
афигеть
в кроне?
off-topic
Ну разве можно доверить бездушному автомату такую ответственную и творческую работу ?
Да еще и в финансовой системе. Только админ, причем главный.
И только ручками, бережно, каждый раз с опаской, подглядывая в потертую, но бесценную инструкцию :)
...
Рейтинг: 0 / 0
25 сообщений из 29, страница 1 из 2
Форумы / Informix [игнор отключен] [закрыт для гостей] / MTEX.C методы борьбы кроме саппорта
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]