Конфигурация сервера под ERP, у кого что? #810093

Здравствуйте! Господа, у кого ERP внедрено, расскажите, на каком железе ей комфортно работать? На нашей конфигурации (виртуалка 2 Xeon E5-2650, 90 ГБ ОЗУ, SAS HDD) есть проблемы с производительностью (Конфликт блокировок). Как у вас с этим вопросом?

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

Для пары пользоватенлей и десятка реализаций за месяц и ваш сервер сойдет...

Конфликт блокировок может и на ультамощном железе остаться. это логическая ошибка.

У меня под 5 пользователей мощнее

мало вводных данных, база файловая или клиент-серверная? Если клиент-сервер, то какой SQL пользуете?

Так по умолчанию в конфигурации ERP включены управляемые блокировки   Забыл указать, клиент-сервер, MSSQL 2012 Пользователей около 50, документов несколько тысяч в день А в чем ваш мощнее? Процессор?

Да и проблема не только в конфликте блокировок...Открытие документа "Производство без заказа" с 2 тыс строками в ТЧ открывается 15-20 минут. Просто открыть...

Процессор Intel® Xeon® E5-2650 Базовая тактовая частота процессора 2,00 GHz Максимальная тактовая частота с технологией Turbo Boost 2,80 GHz ERP + такой процессор + без SSD - дальше разговаривать бессмысленно

SQL сервер на виртуалку ставить как-бы вообще строго не рекомендуется. У меня SQL и сам кластер по отдельности по 200 гиг съедают в легкую. Не хватает оперативы походу, 2 тысячи строк это сколько оперативы сжирается.

+ в виртуалке он турбо буст не включает. Почему-то.

Убрать виртуалки. Поставить SSD.

да хз... нагрузка у них явно не большая... можно решать другими методами... Снэпшоты в скуле включить например. ерп типовая, что говорит замер производительности при открытии? Насколько отжираются ресурсы сервера при этом, цпу как? загрузка по ядрам какая? Какая очередь к записи на диск на сервере субд? Может у вас затык в коде, а не в сервере... поидее, за исключением дисковой подсистемы нормальный сервер для 50 пользователей

Рекомендации то они одни, прикиньте сколько у вас таблицы основные весят... вся таблица по хорошему должна вмещаться в оперативку на сервере субд. это для максимальной производительности...

У нас с этим все хорошо, хоть и не ЕРП, а УТ11. РТУ в 1124 строки открылась за 4 секунды.

Медленно конечно, но у нас 2 ТЧ "Товары" :-)

Черный и белый контур?

у пользователей шаблон не рвется от двух ТЧ товары?

я подозреваю, что из 15 минут 14м 55 секунд уходят на ожидания на блокировках и на перекидывание с сервера на клиент кучи лишних данных. в качестве оптимизации можно сделать подгрузку номенклатуры постранично... и с отборами. Тогда передача с сервера на клиент будет быстрее... А 2 тысячи строк в режиме онлайн все равно никто не будет просматривать...

До и после ВМС.

Смешно и одновременно грустно читать, как люди работают на УФ :( На ОФ документы с любым числом строк открываются практически мгновенно.

На 7.7 еще быстрее, но желающих пересесть что с УФ на ОФ, что с УФ на 7.7 - исчезающе мало.

а зачем открывать документ с 20000 строк? кто будет его читать? кто будет просматривать 20000 строк огромным полотенцем? это бесполезная трата трафика, ресурсов и прочего. То о чем программисты 1с зачастую вообще не думают. Мне надо вывести одну строку... ну ок отберу все записи регистра, потом наложу отбор... отрабатывает же "Почти мнгновенно" Вот это то с чем я регулярно сталкиваюсь... Кстати у тех кто пишет под уф таких косяков на порядок меньше.

даже если документ (например - заказ) прилетает в электронном виде - как минимум оператор должен проверить все реквизиты шапки (контрагент, договор, тип цен, склад, адрес доставки) и провести документ. как это сделать, не открывая его?

Нарисовать отдельную морду для такой проверки, нехай открывать документы с тыщами строк. Ну или изменить форму объекта до ее передачи на клиент - если строк в ТЧ куча, то не отображать ТЧ, подгружать по отдельной кнопке-команде :)

Зачем ему это проверять?

я не говорил не открывать, я говорил задумываться о ресурсах. Например постраничный вывод информации в ТЧ. т.е. выводится не 20000 а 100-200, а остальное можно подгружать такими же порциями. К этому пришли все в веб дизайне уже давно. При этом способе и остается возможность найти те позиции которые нужны, и возможность посмотреть все порциями по 200-300, и проверить шапку и тд. И не говорите, что кому-то нужно вот прям сразу в ТЧ 20000 строк, я не поверю.

Ксеоны оставь под контроллер домена, для 1с соберите мощный комп на обычном проце, лучше не многоядерном. Удивитесь, но работает в разы быстрее.

Любителям ИБД.

в типовой ERP это предусмотрено?

"лучше НЕ многоядерном" или "лучше НА многоядерном"?

Конечно, расширение в помощь

Именно НЕ многоядерном. Но с как можно более высокой частотой.

4 ядра самое оно, просто 1с часто первое ядро сильнее грузит

,, омг =)) диванные эксперты. сервер 1с действительно не умеет в паралеллизм, потому одна конкретная операция выполняется на одном конкретном ядре процессора. т.е. открытие документа или же закрытие месяца в каждом конкретном случае будут отрабатывать быстрее. Но при параллельной работе 2 или более пользователей ядро процессора будет перегружено. Потому для нормальной полноценной работы 1с надо, чтоб количество рабочих процессов примерно совпадало(а лучше было чуть чуть меньше) с количеством ядер процессора. Таким образом тактовая частота процессора важна для выполнения одной операции в один поток, но для совместной работы 50 пользователей необходимо несколько ядер.

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

Практик. :-) А вот я с тобой соглашусь, как ни странно. Но проблема современных процессоров еще и в том, что с увеличением числа ядер снижается их тактовая частота. А 1С крайне чувствительна к оной, особенно на УФ. Ну а дальше надо играться с количеством баз на РП и числом пользователей, которых этот РП обслуживает.

Это не так, или очень сложно настраивается. 4-ядерный i5 в нескольких организациях уже заменил по моей рекомендации 2 процессорные 12-ядерные ксеоны и работает в разы быстрее, даже там где 200 пользователей онлайн.

Управляемые блокировки уже

+ почти нигде не остались. Даже на УПП бородатых годов они управляемые

Сервер 1С вполне себе параллелится по ядрам. 1 пользователь- 1 ядро. 4 пользователя - 4 ядра.

Берите i7-8700k и будет вам щастье.

Можно будет писать код большой степени быдлокодости.

эт конечно же не правда. сессии в пределах одного рпхоста юзают только одно ядро.

А что делать тем, у кого под 400 юзеров? :(

про параллелизм - понятно, но если уж у человека документы по 2000 строк - я предположил, что у них серверный вариант - тогда Скулю тоже нужны ядра.

Возможно, в момент открытия формы в ТЧ заполняются сопутствующие данные, которые нах никому не нужны после того, как дождался открытия документа :) Сам с таким сталкивался - для ТЧ добавлены неосновные реквизиты, которые при чтении данных объекта заполняются какой то связанной инфой