Оптимизация работы TC

[lexx174 373]

Кто-нибудь пробовал как-то влиять на производительность TC?С ростом объектов в БД,размера товов этот вопрос может стать актуальным(особенно при работе с большими сборками и не малом числе активных пользователей).

Здесь несколько факторов - как мощности серверов так и непосредственно конфигурация субд(в данном случае oracle) и pdm.

Например фирма разработчик предлагает определенные рекомендации и требования по организации табличных пространств oracle,вплоть до размещения отдельных таблиц на отдельных разделах диска.

Так же интересует вопрос о разнесении томов на разные дисковые пространства или даже сервера - улучшает ли такой подход производительность?

[trion 0]

Кто-нибудь пробовал как-то влиять на производительность TC?С ростом объектов в БД,размера товов этот вопрос может стать актуальным(особенно при работе с большими сборками и не малом числе активных пользователей).

Здесь несколько факторов - как мощности серверов так и непосредственно конфигурация субд(в данном случае oracle) и pdm.

Например фирма разработчик предлагает определенные рекомендации и требования по организации табличных пространств oracle,вплоть до размещения отдельных таблиц на отдельных разделах диска.

Так же интересует вопрос о разнесении томов на разные дисковые пространства или даже сервера - улучшает ли такой подход производительность?

Вы забыли самое главное - пропускную способность локальной сети.

[lexx174 373]

Вы забыли самое главное - пропускную способность локальной сети.

сеть конечно также важный фактор.пропускная способность у нас достаточная.Тормоза стали проявляться после увеличения в разы объектов в базе.

При создании айтемов материалов,СТИ,ПКИ и последующей их классификации, ощутимые тормоза появились и в классификаторе.Проще говоря работать в нем нормально пользователю довольно проблематично.

Если тормоза при работе с большими сборками в NX еще можно как-то пофиксить за счет настроек непосредственно ОС, то тут уже тормоза другого рода

Изменено 26 июня 2010 пользователем lexx174

[labslo 0]

Вопрос производительности даже поднимали на конференции Siemens которая была в марте.

Например, мне рассказывали следующее: имеем изделие на 2 млн. дет., из него вычленяем отсек на 30 тыс. дет. на этот отсек необходимо сделать ревизию, для того чтобы ее сделать Teamcenter работает от 22-30 часов непрерывно.

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

примерно как они искали:

1. Была проверена производительность сети на всех участках.

2. Профилирование работы сервера БД (oracle). Далее была консультация по производительности со специалистами.

3. Профилирование работы сервера томов. По рассказам серверов томов несколько, причем все разнесено.

4. Пофилирование работы сервера приложений BEA. Вот тут было очень много проблем. Специально учили человека на BEA и приглашали для консультаций специалиста по BEA.

В результате этих действий производительность увеличилась на 20-30 %.

Однако резко улучшить описанную вначале ситуацию не удалось. Если ранее процедура ревизии проходила с полудня субботы до вечера воскресенья или до утра понедельника. То теперь как раз уменьшилась до приведенных цифр.

В чем причина так до конца и не выяснено:(

[lexx174 373]

Вопрос производительности даже поднимали на конференции Siemens которая была в марте.

Например, мне рассказывали следующее: имеем изделие на 2 млн. дет., из него вычленяем отсек на 30 тыс. дет. на этот отсек необходимо сделать ревизию, для того чтобы ее сделать Teamcenter работает от 22-30 часов непрерывно.

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

примерно как они искали:

1. Была проверена производительность сети на всех участках.

2. Профилирование работы сервера БД (oracle). Далее была консультация по производительности со специалистами.

3. Профилирование работы сервера томов. По рассказам серверов томов несколько, причем все разнесено.

4. Пофилирование работы сервера приложений BEA. Вот тут было очень много проблем. Специально учили человека на BEA и приглашали для консультаций специалиста по BEA.

В результате этих действий производительность увеличилась на 20-30 %.

Однако резко улучшить описанную вначале ситуацию не удалось. Если ранее процедура ревизии проходила с полудня субботы до вечера воскресенья или до утра понедельника. То теперь как раз уменьшилась до приведенных цифр.

В чем причина так до конца и не выяснено:(

у нас например TC ставить на процесс немаленькую сборку может до часа.Причем до миллионов деталей там далеко.Для наших объемов это очень долго.Посчитайте потери рабочего времени конструктора когда открытие/сохранение большой сборки занимает не менее 40мин,плюс добавьте сюда постановку на процесс - те же 40 мин. - итого 2 часа рабочего дня уходят ни на что.

Если "по рассказам" как я понял - разнесено практически все и при этом на производительности это не сказывается то стоит задуматься...

Как простой вариант конечно - использовать на каждый проект отельный сервер и соответственно базу,но это дорогое удовольствие,такое реализовано на одном предприятии,но оно может себе такое позволить.Обычно если проектов не много для них используется одна база.

Вот самые простые рекомендации которые предлагает siemens(рекомендую ознакомиться):

requirements.doc

Так же видим что предлагается разносить все.На ветках по NX можно встретить рекомендации по настройке клиентской машины,которые также предлагают манипуляции с разнесением ОС,TEMP_DIR и своп файла на разные диски(физические!,не логические).

Еще меня настораживает такая вещь как FSC и FCC(кэш клиента и кэш сервера).какие рекомендации по настройкам FSC и FCC дает siemens?