Быстрый PDM

[bdv1983 0]

Здравствуйте.

 

Пользователи жалуются на долгое выполнение практически всех операций в SWE-PDM. Особенно регистрацию и разрегистрацию файлов. В пустом хранилище все действия выполняются быстро. Что можно сделать для ускорения работы PDM?

[Maze 16]

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

[streamdown 1 565]

Судя по 

практически всех операций

затык в скорости сетки.

У нас сейчас некоторые файлы просто лежат на серваке (свои библиотеки компонентов) да и то подгружаются ооочень медленно.

[NGM 267]

А судя по

В пустом хранилище все действия выполняются быстро

Косяк в СУБД.
Проверьте параметр максимального количество сессий в инстансе и сопоставьте с фактической ситуацией. 

[bdv1983 0]

 

А судя по

 

 

В пустом хранилище все действия выполняются быстро

Косяк в СУБД.

Проверьте параметр максимального количество сессий в инстансе и сопоставьте с фактической ситуацией. 

 

Вот и я так думаю. А где смотреть этот параметр - максимальное количество сессий?

[NGM 267]

В Оракле это делается элементарным запросом (если вам нужно вывалить перечень всех сессий, уберите count):

select count(*) from v$session

Если у Вас база крутится на MS SQL - с ходу ответить не смогу. Нужно покопаться.

UPD. Упс, сорри, плавит мозг в понедельник. Запрос выше показывает количество открытых сессий в данный момент времени. Значение максимального количества сессий смотрим запросом:

select name, value from v$parameter where name in ('sessions')

[bdv1983 0]

В документации SWE-PDM черным по белому написано, что в качестве СУБД должен использоваться SQL сервер. Соответственно и в моей организации MS SQL 2008.

[NGM 267]

В документации SWE-PDM черным по белому написано, что в качестве СУБД должен использоваться SQL сервер.

Простите, документации по SWE-PDM нет, поэтому прочитать, что в ней написано черным по белому, не могу   

Единственное отвлеченное замечание - PDM, которая функционирует на одной-единственной СУБД - зло (исключительно с точки зрения администратора).

Теперь давайте попробуем решить Вашу проблему.

Попробуем посмотреть на то, как изменится работа в системе после изменения параметра user connections. Вообще-то, если его не менять при развертывании экземпляра БД, то его значение равно 32 тысячам с каким-то хвостиком. Лично я всегда с большой опаской отношусь к тем параметрам, которые советуют "оставить по умолчанию" - скорее все, они выстрелят именно в тот момент, когда нагрузка на сервер превысит определенный предел. Хотя в MS SQL 2012 этот параметр авторасширяемый, таким должен быть и в 2008...

 

Начните с самого простого - запустите Management Studio, выберите нужную Вам базу данных, перейдите в свойства и найдите параметр "Максимальное количество соединений" (может называться по-другому, сервера MS SQL под рукой нет). Попробуйте немного увеличить параметр и проследите за ситуацией. Опять же - могу утверждать на все 100%, но вроде бы MS SQL выделяет память на каждое соединение, вне зависимости - используется оно или нет.

 

Если не поможет - дайте время на подумать, будем действовать более решительно 

UPD. Коллега подсказал, что значение параметра "Максимальное количество соединений" в MS SQL 2008 по умолчанию устанавливается в ноль - т.е. их количество "неограниченно" (как раз те самые 32 тысячи с хвостиком). Хорошо это или плохо - с кондачка сказать не могу. Чисто интуитивно - плохо, ибо если не ограничивать память, выделяемую под экземпляр БД, то "будит бида". Кстати, на сервере в диспетчере задач не смотрели на загрузку процессора и памяти в момент возникновения проблем?

 

Короче,

1) Узнаем количество подключений,

select count(*) from master..sysprocesses

2) Мысленно накидываем 10-15%, получившуюся цифру загоняем в параметры соединения.

3) Крестимся. Перезапускаем базу. А лучше сервер целиком. Смотрим на результат.

[_DS 45]

В документации SWE-PDM черным по белому написано, что в качестве СУБД должен использоваться SQL сервер. Соответственно и в моей организации MS SQL 2008.

Если у Вас лицензия, то может стоит с supportом поработать, не насилуя систему по подсказкам наугад)

[NGM 267]

Если у Вас лицензия, то может стоит с supportом поработать, не насилуя систему по подсказкам наугад)

Мысль здравая, но как показывает практика работы с десятком вендоров - качественный ответ на данный вопрос может быть получен лишь в том случае, если на стороне вендора есть квалифицированный DBA или программист со знаниями в прикладной области. В противном случае все сведется к тем же подсказкам и изнасилованиям системы 

 

Если у SWR такой спец есть, это просто здорово.

А вообще для таких случаев неплохо держать на предприятии админа, который умеет работать с СУБД хотя бы на базовом уровне.

[bdv1983 0]

 

В документации SWE-PDM черным по белому написано, что в качестве СУБД должен использоваться SQL сервер. Соответственно и в моей организации MS SQL 2008.

Если у Вас лицензия, то может стоит с supportом поработать, не насилуя систему по подсказкам наугад)

 

В CRM задал вопрос еще в пятницу. До сих пор молчат.

[bdv1983 0]

Ответили в CRM:

 

 

Добрый день.

Наиболее вероятная причина возникающих проблем недостаточная: производительность базы данных хранилища.
Уточните, пожалуйста:
1. Архивный сервер SWE-PDM и MS SQL Server расположены на одном сервере?
2. Какая конфигурация сервера (процессоры, оперативная память, массивы дисков, сеть) на котором расположен MS SQL Server?

Пришлите, пожалуйста:
1. Данные для поддержки с одного из клиентов, на котором наиболее часто возникают проблемы. В модуле Администрация SolidWorks Enterprise PDM подключитесь к хранилищу и выберите в контекстном меню Сбор данных о поддержке.
2. Проведите обновление статистики и пересчет индексов в базе данных по инструкции из вложения. Процедура перестроение индексов должна увеличить производительность базы данных. 

Попробую сперва их способ.

[NGM 267]

Наиболее вероятная причина возникающих проблем недостаточная: производительность базы данных хранилища.

 

 

Капитан Очевидность таки нашел себе работу, можно теперь за него не беспокоиться

 

Вполне стандартные и логичные ответы для техподдержки.

 

А вот последний пункт пугает. Вообще-то перестраивать индексы (тем более во ВСЕЙ базе) рекомендуется в исключительных случаях, например когда откровенно криво работают отдельные запросы. И как это может повлиять на скорость работы бек-энда, мне тоже категорически неясно. Это, фактически та же припарка мертвому, как и сжатие базы в Access.

 

В любом случае, пожалуйста, отпишитесь по результатам - очень хочется знать, чем все же закончилось.

[bdv1983 0]

   Настроили обновление статистики и пересчет индексов согласно инструкции из вложения CRM. Сегодня ночью первый раз действия должны были выполниться, но при работе в PDM никаких изменений незаметно.

   На данный момент ситуация следующая. При регистрации в основном хранилище виртуального документа размером 1 Кб выскакивает окно Регистрация файла. Регистрация длится около 40-60 секунд. Иногда окно один раз пропадает. В тестовой же базе сохранение и регистрация файлов происходят за доли секунд, даже не успеть засечь время.

 

UPD. Коллега подсказал, что значение параметра "Максимальное количество соединений" в MS SQL 2008 по умолчанию устанавливается в ноль - т.е. их количество "неограниченно" (как раз те самые 32 тысячи с хвостиком). Хорошо это или плохо - с кондачка сказать не могу. Чисто интуитивно - плохо, ибо если не ограничивать память, выделяемую под экземпляр БД, то "будит бида". Кстати, на сервере в диспетчере задач не смотрели на загрузку процессора и памяти в момент возникновения проблем?

 

Короче,

1) Узнаем количество подключений,

select count(*) from master..sysprocesses

2) Мысленно накидываем 10-15%, получившуюся цифру загоняем в параметры соединения.

3) Крестимся. Перезапускаем базу. А лучше сервер целиком. Смотрим на результат.

 

 

Максимальное количество соединений на сервере сейчас установлено в 0. Среднее количество подключений к БД = 250. Иногда подскакивает до 300.

[bdv1983 0]

Пересчет индексов завершается ошибкой. Разбираюсь.

[bdv1983 0]

Для задачи перестроения индексов сбросил флаг "Сохранять индекс в режиме "в сети" в процессе переиндексирования" и задание успешно выполнилось. Однако, PDM по прежнему работает медленно.

[bdv1983 0]

Проблема по прежнему остается. Зато сегодня был строго отчитан представителем SolidWorks (через третье лицо, конечно) за перепечатку сообщений из CRM. Это они про единственное сообщение приведенное здесь.

Хочу обратиться по этому поводу к уважаемым из данной компании и милой Юле в частности. Займитесь наконец делом, а не болтайтесь по чужим форумам. Я завел здесь тему через двое суток после создания заявки в CRM. Если бы мне там ответили немного быстрее, а не через четыре дня, сюда бы и заходить не пришлось. Три недели как проблема сформулирована, а воз и ныне там. Учитесь работать. И исправьте ошибки в PDM, их слишком много, для такой солидной фирмы это позор. Начните с орфографических: "в течение", а не "в течении".

[bdv1983 0]

   Удалось добиться значительного улучшения быстродействия. Среднее время регистрации файла - 2 секунды, так же как и в создаваемом новом хранилище. Правда время от времени происходят зависания системы, но это уже другой вопрос.
   Сделал это специалист занимавшийся внедрением PDM до меня. По его словам, были "перестроены системные индексы согласно плана". Непонятно, конечно, что именно он сделал. Ведь обновление статистики и пересчет индексов в базе данных по инструкции из CRM были настроены мной еще в сентябре и согласно журналу исправно выполнялись.

   В общем, подводя итог проведенной работы, можно сделать вывод, что на улучшение быстродействия больше всего повлияли организация индексации БД и исключение встроенных приложений - DocId, например. Назначение DocId мне, кстати, в CRM так и не смогли объяснить. Хотя это программа компании SolidWorks Russia.
   Всем счастливого Нового года!