AOS!!! количество пользователей, настройки, устойчивость

[SHiSHok]

Исходные данные:
Ax3.0sp2 + MSSQL2000sp3. Users - 48, Axapta Object Servers -1
AOS стоит на CPU:2x Intel Xeon3066MHz, RAM: 2048Mb
работают эти пользователи ну где то как 100 ASU (если не больше).

Проблема:
переодически падает AOS (наиболее частые проявления: либо выкидывает пользователей; либо перестает пускать, а новым пишет "Internal revision mismatch in AOCP ...")
замечено что у процесса AOS со временем плодятся :
threads : <Non-existent Process>(3388): 328
files : C:\Temp\$tmp001a0001.$$$

Вопросы:
1) какое рекомендуемое/эмпирически выгодное количество пользователей на 1 AOS (может пора уже второй заводить??)
2) есть ли рекомендации по тюнингу настроек AOS-а?
3) может обновление какое поможет?

[Antant]

как я понимаю версии АОС и клиента не соответствуют друг другу. Может было использование клиента с более высоким или более низким сервис паком по сравнению с АОС.

[SHiSHok]

Цитата:

Сообщение от Antant

как я понимаю версии АОС и клиента не соответствуют друг другу. Может было использование клиента с более высоким или более низким сервис паком по сравнению с АОС.

В том то и дело что клиенты и сервер SP2, и подобный отказ и есть сбой.

[SHiSHok]

Неужели нечего посоветовать???
может хоть по пользователям на 1 АОС чего кто подскажет?

[mazzy]

Цитата:

Сообщение от SHiSHok

Вопросы:
1) какое рекомендуемое/эмпирически выгодное количество пользователей на 1 AOS (может пора уже второй заводить??)

Нет.
Рекомендуемое ASU на один AOS - около 100-150.
Но один AOS может потянуть и значительно больше до 350-400 ASU.
Если есть возможность, то лучше держаться рекомендованной величины.

Цитата:

Сообщение от SHiSHok

2) есть ли рекомендации по тюнингу настроек AOS-а?

Нет.

Цитата:

Сообщение от SHiSHok

3) может обновление какое поможет?

Установите везде одинаковую версию.
Где-то у вас стоит другая версия.

См. также http://forum.mazzy.ru/index.php?showtopic=584

[SHiSHok]

Цитата:

Сообщение от mazzy

Нет.
Рекомендуемое ASU на один AOS - около 100-150.
Но один AOS может потянуть и значительно больше до 350-400 ASU.
Если есть возможность, то лучше держаться рекомендованной величины.

значит есть смысл жить на одном.

Цитата:

Сообщение от mazzy

Установите везде одинаковую версию.
Где-то у вас стоит другая версия.

да. я себе для тестирования поставил SP3 и вобщемто клиентом SP3 работаю с AOS SP2 (у всех стоят клиенты SP2). Не думаю что это может как то отразиться на работе. То есть протокол он и на Украине протокол : TCP/IP же не отличается от Винды к Винде или к Юниксу или еще чему... для эксперимента поставлю себе SP2, и потанцую с бубном

Цитата:

Сообщение от mazzy

См. также http://forum.mazzy.ru/index.php?showtopic=584

Рекомендации правильные, у нас как бы соблюдаются . интерес вызывает пункт: "Периодически обновляйте exe-шники Аксапты"

[mazzy]

Цитата:

Сообщение от SHiSHok

Не думаю что это может как то отразиться на работе.

Однако ж, отражается.
Текущая версия записывается в таблицу SysConfig.

Цитата:

Сообщение от SHiSHok

То есть протокол он и на Украине протокол : TCP/IP же не отличается от Винды к Винде или к Юниксу или еще чему...

А вот AOCP - вполне.
На то он и закрытый, и проприетарный.

[SHiSHok]

Цитата:

Сообщение от mazzy

А вот AOCP - вполне.
На то он и закрытый, и проприетарный.

сенкс. соблюду версионность, посмотрим что выйдет.
хотя возникло впечатление что AOS по достижении ГИГа ОЗУ начинает подглюкивать (игрался настройками АОС - буферы увеличивал, количество курсоров, отфетчиных записей...)

[axaLearner]

SHiSHok
К вопросу о производительности АОС можете глянуть ссылку и рассчитать для своей конфигурации.
http://www.fujitsu-siemens.ru/soluti...ta_sizing.html

[sia]

Если у вас SQL Server, то в настройках АОСа настройте соединение через DSN, а не напрямую. Тогда будет использоваться другой драйвер (при соединение напрямую используется DBNETLIB, который при работе с Аксаптой подглючивает). Если у вас ко всему прочему Windows Serever 2003, то можно попробовать откатить MDAC до версии 2.6 SP2. Тоже помогает.

[SHiSHok]

Цитата:

Сообщение от sia

Если у вас SQL Server, то в настройках АОСа настройте соединение через DSN, а не напрямую. Тогда будет использоваться другой драйвер (при соединение напрямую используется DBNETLIB, который при работе с Аксаптой подглючивает).

в чем заключается глюкавость? мусор в процессе аксапты? я при работе с сиквелом не замечал глюков.

Цитата:

Сообщение от sia

Если у вас ко всему прочему Windows Serever 2003, то можно попробовать откатить MDAC до версии 2.6 SP2. Тоже помогает.

про MDAC тоже интересно в чем его глюкавость выражается?
как корректно откатить?? ручками подменить нужные файлы из 2.6sp2?

[SHiSHok]

Цитата:

Сообщение от axaLearner

К вопросу о производительности АОС можете глянуть ссылку и рассчитать для своей конфигурации.
http://www.fujitsu-siemens.ru/soluti...ta_sizing.html

честно говоря, все эти расчетные движки привязаны к стандартному функционалу, а у нас приложение серъёзно переделано. Попробовать конечно можно, но когда мы расчитывали конфигурацию серверов на коком-то из axapta-ориентированных сайтов получались смешные конфигурации (наверное раза в 2 слабее нашего железа). Так что все подобные расчеты - дело чисто индивидуальное.

[sia]

Цитата:

Сообщение от SHiSHok

в чем заключается глюкавость? мусор в процессе аксапты? я при работе с сиквелом не замечал глюков.

Глюкавость заключается в переодическом отказе АОС-ов

Цитата:

Сообщение от SHiSHok

про MDAC тоже интересно в чем его глюкавость выражается?
как корректно откатить?? ручками подменить нужные файлы из 2.6sp2?

Да, менять руками. Иначе не получится. Меняли и на АОСе и на SQL Server-e. Проблема была в огромном кол-ве NETWORKIO waits. После отката решилась.

[SHiSHok]

Цитата:

Сообщение от sia

Если у вас SQL Server, то в настройках АОСа настройте соединение через DSN, а не напрямую

можете написать какие параметры соединения в настройках DSN желательно указать для корректной работы axapta (работает нормально как с установленной птицой "perform translation for character data" так и без)?

[somebody]

ВСЕ галки на последней странице настройки ODBC-соединения желательно убрать (в том числе и perform translation)...
вообще-то почитайте руководства для админов...
есть кое-что любопытное, в том числе про русификацию...

[KiselevSA]

А на SQL стоит SP3 или SP3a? Очень похоже на утечку памяти при длительных запросах

[SHiSHok]

Цитата:

Сообщение от KiselevSA

А на SQL стоит SP3 или SP3a? Очень похоже на утечку памяти при длительных запросах

SQL2kSP3a, AWE mode.

[SHiSHok]

Цитата:

Сообщение от somebody

ВСЕ галки на последней странице настройки ODBC-соединения желательно убрать (в том числе и perform translation)...
вообще-то почитайте руководства для админов...
есть кое-что любопытное, в том числе про русификацию...

с руссификацией проблем как то не возникало.
про настройки ODBC соединения в документации сказано исключительно немного. Единственное что есть, это указание на "perform translation for character data", но мои тесты подключения через ODBC показали что тестовая база работала корректно как с включенной опцией "perform translation for character data" так и без (я так понимаю что с этой опцией как то неправильно должна была отображаться кодировочка)

[SHiSHok]

новые факты:
произвел некоторую коррекцию параметров АОС и результат: АОС работает без ошибок и слетов около недели. это наверное рекорд за последние полгода.
Общий смысл настройки параметров АОС - уменьшить количество используемой памяти. Как следствие процесс максимально захватывал 820Mb, при этом у процесса присутствуют мертвые хендлы thead <Non-existent Process>(1024): 2500, висящие хендлы file C:\Temp\$tmp00130001.$$$. Всетаки есть подозрение что АОС axpta3.0sp2 некорректно работает при приближении к 1Gb ОЗУ.
Посему интересно было бы узнать у участников (интересно для разных сервиспаков):
1) параместы настройки АОС : Database
2) какой пик захвата памяти вашего АОСа?
3) присутствуют ли вышеописанные мертвые хендлы?
3) как стабильно работает АОС (среднее время работы в днях до слета/глюка)?

Я настроил следующим образом:
Settings:
max open cursors:320
retry:3
max cache sync time:6
buffer size:86
array fetch ahead:64
Connection:
Number of retries:3
Retry delay:2000
Timeout connection after being idle for: 7200

[Shur]

Тебе скоко говорил - не гиг ОЗУ, а превышение 2 гиг виртуалки.
Поставь в boot.ini сервера ключ /3GB и еще чуть поработает...