Вход | Регистрация
    1  2
1С:Предприятие :: 1С:Предприятие 8 общая

Подсобите с выбором сервера для УТ

Подсобите с выбором сервера для УТ
Я
   lenkavovka
 
23.11.21 - 14:44
Всем привет!
Наверное 100500-я тема такая, но у нас ситуация, когда ИТ-отдел устал от жалоб юзеров на тормоза 1С и просит нас (программистов) озвучить конфигурацию сервера, которая наконец-то будет достойна нашей титульной базы УТ 11.4
Вводные такие: УТ Проф, доработанная нашими предшественниками и дооснащённая купленными решениями в плане учёта финансовой статистики, аналитики продаж, прогноза спроса, > 100 юзеров на тонких клиентах, много обменов, много постоянно выполняющихся несколькими отделами аналитических отчётов.
Сервер сейчас: 12 ядер, 384Гб ОЗУ, диски современные быстрые. SQL и 1С на одном сервере. Ещё там есть Бухгалтерия и прочее, но много ресурсов не потребляет.
В спокойном режиме rphost потребляет 5 гигов оперативы, SQL и того меньше. Клиенты работают шустро.
Но как только юзерам хочется одновременно запустить что-то большое, 1С через некоторое время встаёт колом (замедляется в n-цать раз). Причём потребление памяти процессом rphost может даже не дойти до максимально ему доступных 100 Гб, а скажем до 30ти, процессор расходует не больше 20% своих ресурсов, SQL потребляет всего 1,5 Гб ОЗУ из выделенной сотни, очереди записи на диск нет.
Раньше в другом месте сталкивались, когда 1С вроде бы не выбирал всю серверную память, только 50%, и ощутимо подвисал при этом, а после увеличения ОЗУ ожил и проблемы прошли. Но тот ли здесь случай - фиг знает.
Стоит ли апгрейдить ресурсы сервера дальше?
Скажите, кто какие конфигурации серверов нынче использует, в плане ОЗУ, ПЗУ, ЦП? Или, может, нам пора разделять 1С и SQL на разные сервера? Или вообще о кластере думать?

Да, с точки зрения кода/запросов заметных недостатков нет ни в местных, ни в покупных доработках. Запросы максимально оптимальные, в цикле их никто не запускает)). Просто большая задача: под сотню тысяч позиций номенклатуры, под 200 магазинов, 7 лет истории продаж, дополнительные регистры для финансового учёта и аналитики, сложные вычисления по всему перечисленному.
   Kassern
 
101 - 24.11.21 - 13:58
(98) вся проблема в том, что как определить тех. эксперт это, или вася, который недавно узнал о существовании тех. журнала. Он может с умным видом походить по серверной, запустить какую-нить аиду64 на серваке, прогнать пару тестов дефолтных. Далее взять базу, для якобы тестов, на недельку. А позже выкатить один из шаблонных ответов, где будет написано, нужно обновить железо. При этом никакой гарантии, что после апгрейда все залетает как вы и планировали...
Как заказчику обезопасится от таких спецов?
   mistеr
 
102 - 24.11.21 - 14:01
(101) Сертификат и/или репутация, другого пока не придумали. С этим уже и Миста может помочь.
   Добрыня Никитич
 
103 - 24.11.21 - 14:02
(100) там куча одминов и 1с-ников на зп сидят, поэтому нужно бесплатно
   Kassern
 
104 - 24.11.21 - 14:07
(102) с репутацией сейчас тоже проблема, отзывы, в большинстве случаев, покупные, а негативные удаляются. Сертификат тоже мало что скажет, он может быть у одного сотрудника конторы, а остальные джуны которые делают всю черную работу.
   Dmitrii
 
105 - 24.11.21 - 14:12
(101) >> Как заказчику обезопасится от таких спецов?

Во-первых. Как и в любом другом вопросе в сфере ИТ. И не только ИТ.
Наличие успешного опыта и положительных проверяемых отзывов от заказчиков, с которыми можно пообщаться. Хорошее портфолио и репутация, которую уже упоминали.

Во-вторых, при заключении договора можно обсудить какие-то критерии, определяющие успешность проведения работ. Как пример - оценка по методике APDEX, которая уже встроена в типовые 1С.
Но в любом случае придётся самим попотеть для того чтобы определить и чётко для себя и для исполнителя сформулировать критерии - что значит "1С колом стоит", "работает с приемлемой скоростью", "летает".

В-третьих, ждать, что прилетит волшебник в голубом вертолёте и разом решит все проблемы только лишь деньги поступят к нему на р/счет, не стоит. Придётся и самим поработать.
   Dmitrii
 
106 - 24.11.21 - 14:17
(104) >> Сертификат ... может быть у одного сотрудника конторы, а остальные джуны которые делают всю черную работу.

Какая разница - кто делает работу, если она делается и её контролирует и отвечает за неё сертифицированный специалист?

>> с репутацией сейчас тоже проблема.

А репутация должна быть проверяемой. Если у исполнителя в портфолио есть успешные проекты и с понятными результатами, то должна быть возможность связаться с заказчиками для обсуждения таких проектов - что было сделано исполнителем, достигнут ли был ожидаемый результат, какие были сложности.
Это ж не покупка наушников в интернет-магазине на основе отзывов покупателей.
   lenkavovka
 
107 - 24.11.21 - 16:02
(81) несколько часов
(86) загрузка процессора в пределах 20% всегда, 1С тормозит даже если запустить тяжёлые отчёты практически при полном отсутствии юзеров
(90) базы действительно в разных платформах. Спасибо за идеи и развёрнутые советы!

(98) (99) (100) с оплатой тех. эксперта проблем нет, руководство адекватное, всегда готово. Дело не в том, что "на форуме бесплатно", а, как сказали выше, и как я уже писал -  в оценке компетентности эксперта. Поэтому и создал тему на форуме, описав наши чаяния, чтобы получить советы от более опытных в борьбе с тормозами коллег, и быть в теме. А то действительно пальцем в сервер потыкают, скажут менять железо, а потом, если не взлетит - "а, ну так у вас код кривой". И виноватыми окажутся программисты.
   Ёпрст
 
108 - 24.11.21 - 16:07
(107) конечно кривой. Кто-то у вас зоть раз профайлер открывал?.. ну или зотя бы стату по запросам к саулю смотрел?..
   pechkin
 
109 - 24.11.21 - 16:07
(107) загрузка ядра или процессора в целом?
   pechkin
 
110 - 24.11.21 - 16:08
(107) берите Гилева если нужно имя
   Dmitrii
 
111 - 24.11.21 - 16:31
(107) Полистайте эти статьи на ИТС. Они хоть и старые, но может что-то найдёте для себя полезного и интересного.

https://its.1c.ru/db/metod8dev#browse:13:-1:1989:2599 Технологические вопросы крупных внедрений.
https://its.1c.ru/db/metod8dev#content:5808:hdoc Оценка производительности и оптимизация многопользовательской системы. Общий подход.
https://its.1c.ru/db/metod8dev/content/4052/hdoc Анализ производительности и оптимизация работающей многопользовательской системы.
https://its.1c.ru/db/metod8dev/content/5838/hdoc Анализ загруженности оборудования для Windows.

Про сайт Гилева уже многие упоминали.

>> Дело не в том, что "на форуме бесплатно", а ... в оценке компетентности эксперта.

Выбирайте из списка Партнёры «Центр компетенции 1С:КОРП».
https://consulting.1c.ru/partners/?base=corp&industry=0&country=0&city=0&area=0&search=
У этих партнёров требуйте портфолио с отзывами  по завершенным проектам с подробным описанием (как было, что делали, как стало) и возможностью пообщаться с из заказчиками.
   Dmitrii
 
112 - 24.11.21 - 16:43
(108) >> Кто-то у вас хоть раз профайлер открывал?.. ну или хотя бы статус по запросам к скулю смотрел?

Чтобы это делать надо хотя бы знать - в какой момент это делать и куда именно смотреть.
А судя по "1С через некоторое время встаёт колом (замедляется в n-цать раз)" ясного понимания у авторов нет.
Не исключено, что у них всё настроено идеально, а для описанной ситуации - "когда юзерам хочется одновременно запустить что-то большое" - такое поведение системы вполне даже норма. И в таком случае апгрейд железа только смягчит проблему и на какое-то время отложит её, но не решит кардинально. А единственное решение - разделение пользователей по разным базам (оперативка и "для отчетов"), от которого автор старательно открещивается.
   lenkavovka
 
113 - 24.11.21 - 19:13
(108) (112) Профайлер конечно открывали, всё что можно было, в первую очередь тяжёлые запросы - оптимизировали. И даже знаем на самом деле, что именно (какие именно запросы и в каких условиях) тормозит.
Наша сложность - установленные сторонние "серийные" разработки, анализирующие движения за большие периоды. В организации политика невмешательства в код таких решений, тем более, что часть из них обновляется. Отсюда и происходит моё опасение, что переписать эти решения для разделения на разные сервера, сохранив комфорт работы пользователей, или даже просто значительно их переделать - невозможно в наших условиях. Делать самим - означает взять на себя ответственность за функционал, и придётся увеличивать штат, кода там немало. Заказывать у разработчиков - означает заплатить за индивидуальную версию, которая скорее всего будет в разы сложнее и дороже оригинала. Если упростить и немного притянуть за уши: у вас Word на компе тормозит, будете комп апгрейдить/винду оптимизировать, или у Майкрософта облегчённую версию Ворда заказывать? В общем, стремимся к комплексному подходу в анализе проблемы.
Вот если бы была возможность ограничивать память, выделяемую одному сеансу 1С, у нас 90% проблем решилось бы моментально. Но что-то я подозреваю, что даже КОРП не поможет. Или не прав?
(109) процессора в целом
(111) (110) Спасибо за советы!
   lenkavovka
 
114 - 24.11.21 - 19:23
(55) предложил админам I9, а они смеются, что он только 128 гигов памяти поддерживает (
   ansh15
 
115 - 24.11.21 - 20:16
(114) Предложите этим людям на выбор Gold 6244, 6250, 6256, только цену не показывайте сразу, иначе они дольше смеяться будут.
Раз уж "политика невмешательства в код таких решений".
   Garykom
 
116 - 24.11.21 - 20:28
(114) У нас всего 64 памяти для сервер 1С и PostgreSQL для более 100 юзеров
И за глаза хватает

Оперативка не сильно нужна когда сам проц шустрый в однопотоке и дисковая подсистема тоже шустрая
   mistеr
 
117 - 24.11.21 - 20:38
(113) > сторонние "серийные" разработки, анализирующие движения за большие периоды

"Серийные" в смысле тиражные? Можете конкретные назвать?
   mistеr
 
118 - 24.11.21 - 20:41
(113) > если бы была возможность ограничивать память, выделяемую одному сеансу 1С, у нас 90% проблем решилось бы

Каким образом? Разве алгоритм, которому нужно много памяти, не вывалится с ошибкой?
   mistеr
 
119 - 24.11.21 - 20:44
(118) Но если узким местом действительно является ОЗУ, то это решается горизонтальным масштабированием. Рассматривали?
   pavig
 
120 - 24.11.21 - 21:08
(114)
ВРЕМЕННО разнесите 1С и СУБД по разным серверам.
Протестируйте, погоняйте недельку. Узнаете, где же вы проседаете.
Сам rphost на i9 будет летать с 128 Гб памяти на борту как истребитель. Возможно, что слегка просядете на времени взаимодействия 1С и СУБД. Но это терпимо и не точно.
Но ваши админы на это не пойдут.
   АНДР
 
121 - 24.11.21 - 21:21
Загрузка 20% проца (максимум 3 ядра на 100% из 16, но скорее 1 на 100 и остальные чуть-чуть), отключили фиксацию страниц в памяти...

А Max degree of parallelism в 1 админы случайно не выставили на SQL?
   H A D G E H O G s
 
122 - 24.11.21 - 22:02
(113) КОРП может в "Безопасный расход памяти за один вызов", установив который, по крикам пользователей, вы вычлените хада.
   H A D G E H O G s
 
123 - 24.11.21 - 22:02
(121) У них скорее всего mdop=0, вот и тормозит
   H A D G E H O G s
 
124 - 24.11.21 - 22:04
Более-менее хорошая идея в (120), прокинуть rphost на i9, just for lulz, формочки быстро открываться будут, чебынет?
   H A D G E H O G s
 
125 - 24.11.21 - 22:05
Ну а вообще, its читайте, там все написано.
В книге - сила!
https://youtu.be/QUZs_E6dRf8
   Bigbro
 
126 - 25.11.21 - 04:40
(113) анализировать движения за большие периоды раз за разом - моветон.
перепишите эти решения, выбирайте данные один раз, делайте все необходимые расчеты и сохраняйте промежуточные результаты в другой регистр/документ не важно.
откуда уже сможете дернуть все что нужно за долю секунды, потому что все посчитано.
мне пришлось примерно таким путем пойти когда анализ выручки для маркетологов делал, чтобы не лопатить всю базу за 2-3 месяца а то и за год с движениями.
регламентом раз в месяц после закрытия формируем нужную аналитику по месяцу результаты сохраняем.
затем при формировании отчета дергаем данные оттуда. и только текущий период выбираем из оперативных движений с расчетом.
   lenkavovka
 
127 - 25.11.21 - 06:49
(117) Да, тиражные. Не могу написать названия, но давайте опишу как средний пример систему обеспечения спроса, установленную отдельным расширением: производится расчёт ABC, XYZ, количество продаж по периодам, сезонность продаж. Средний период анализа - 3-4 года. Расчёт по каждой товарной позиции (их десятки тысяч, но обычно берут не больше десяти тысяч), и помножено это на 200 магазинов. Расчёты не сохраняются, каждый раз пересчитываются. Продукт руководство более чем устраивает. Разработчик с нами общается, но в корне менять продукт для нас одних, хоть и очень крупных, не будет, разве что за сумму, на которую можно будет купить пяток быстрых серверов. Ограничивать пользователей в расчётах нельзя: всё-таки наша задача обеспечить эффективную работу компании. Мы тоже мечтаем об идеальных условиях, но нужно исходить из реальных.
(121) (123) MDOP = 1, админы опирались на найденные рекомендации от 1С и статью на Инфостарте "Тестирование параллелизма SQL в среде 1С Предприятие" и комменты к ней.
(126) рады бы, но по факту сохраняем результаты длительных расчётов только в своих разработках, а тормозят преимущественно запросы в покупных.
   Bigbro
 
128 - 25.11.21 - 07:02
(127) а что там, код закрыт, в покупных?
выходите на поставщика тогда требуйте оптимизировать решение или предоставить доступ к модификации.
помню с рарусом была история когда они наотрез отказались исправлять свои косяки в автотранспорте
пришлось на их закрытый модуль вешать свою обвязку - которая меняла данные до закрытого модуля и правила то что вернулось уже приводя к корректному виду.
но такая работа с кривым черным ящиком недолго продлилась - менее чем через год отказались от них, естественно предложение перейти на их же управление автотрансопртом после предыдущего взаимодействия было послано в даль.
   lenkavovka
 
129 - 25.11.21 - 07:06
(128) часть кода закрыта. Так что у единственный выход, кроме оптимизации/модернизации сервера - написать свой альтернативный продукт. Но инициатива, как известно, наказуема, а ещё у нас нет существенных дополнительных ресурсов на разработку того, что уже работает((
   Смотрящий
 
130 - 25.11.21 - 07:37
(129) Тогда только терпеть, сжимать зубы, плакать
 
 
   АНДР
 
131 - 25.11.21 - 08:14
(127) Задайте mdop = 8, и да +(123) mdop = 0 ставить на связке sql+1с не надо.
Что б админы не сомневались, табличка в конце https://its.1c.ru/db/metod8dev/content/5945/hdoc
И закрепление страниц верните.

PS С вашими текущими настройками на i9 будет лучше.
   Мультук
 
132 - 25.11.21 - 08:53
(131)

>>Задайте mdop = 8, и да +(123) mdop = 0 ставить на связке sql+1с не надо.
>>Что б админы не сомневались, табличка в конце https://its.1c.ru/db/metod8dev/content/5945/hdoc

Вся статья о реструктуризации базы. Ни слова о штатной работе. Есть пруф, что mdop=8  нужно ставить при штатной работе?

Там же в статье сказано:

После завершения реструктуризации мы рекомендуем в общем случае ВЕРНУТЬ значение в ИСХОДНОЕ СОСТОЯНИЕ.
Конечно же, в процессе ее выполнения стоит выполнять мониторинг ожиданий СУБД, о котором сказано выше, а также производительности дисковой подсистемы при помощи, например, Performance Monitor.
   АНДР
 
133 - 25.11.21 - 09:46
(132) см. последнюю строку в указанной таблице.
   Garykom
 
134 - 25.11.21 - 09:54
(127) Тогда у вас выход только РИБ
Ну и RLS отключите
   Kassern
 
135 - 25.11.21 - 09:58
Отпишитесь потом, какое решение нашли.
   mistеr
 
136 - 25.11.21 - 10:15
(127) Еще раз обращу ваше внимание на горизонтальное масшатбирование. В частности рассмотрите эти механизмы: https://its.1c.ru/db/metod8dev/content/5951/hdoc
   Добрыня Никитич
 
137 - 25.11.21 - 10:35
(136) Акселератор вроде только на чтение работает
   Добрыня Никитич
 
138 - 25.11.21 - 10:36
(127) >>а тормозят преимущественно запросы в покупных.

Т.е. вы нашли причину? Быстро, однако
   mistеr
 
139 - 25.11.21 - 10:41
(137) Вроде им это и нужно: "Расчёты не сохраняются, каждый раз пересчитываются".

Даже без акселератора копия базы может помочь.
   Bigbro
 
140 - 25.11.21 - 10:56
(136) блин, сколько классных штук оказывается есть в 1с, о которых еще не знаю (
это же на уровне платформы реализованный механизм кеширования фактически.
который десятилетиями люди сами костылями приделывали.
и до сих пор многие приделывают
   lenkavovka
 
141 - 25.11.21 - 11:02
(134) RLS отключено. Про РИБ думаем.
(135) обязательно отпишусь
(136) (139) Акселератор, увы, к нам не применим. На ИТСе говорят, что не будет работать с запросами, где есть менеджер временных таблиц, а у нас в покупных решениях он везде.
С копией думаем, какой механизм использовать. Пока у нас только один сервер. Думаем про варианты выноса rphost на отдельный купленный сервер с I9, либо покупку более мощного сервера для использования механизмов типа РИБ, или кластеризация SQL, или предложенный Вами "Механизм копий баз данных" (по описанию очень интересная штука). Ну и перевод лицензий на КОРП, начнём с него.
(138) мы причину понимаем изначально: в-основном это тяжёлые запросы, которые мы не можем переписать. в третьем абзаце (0) я говорю про аналитические отчёты.
   XMMS
 
142 - 25.11.21 - 11:19
Я пропустил или нигде не было данных по используемым процессорам?
   Добрыня Никитич
 
143 - 25.11.21 - 11:44
(141) вы это прям точно по трассе установили или понимаете примерно?
   H A D G E H O G s
 
144 - 25.11.21 - 11:48
(142) 8 ядерная Silver-ная шлабуда.
   Garykom
 
145 - 25.11.21 - 11:58
(141) РИБ в нативном виде скорее всего не пойдет
Имхо нечто вроде шины/кролика и в отдельную базу для отчетности выносить копию данных
А рабочую оперативную базу лишить всего ненужного, все эти сторонние расширения выкинуть
   Garykom
 
146 - 25.11.21 - 12:00
(145)+ Например имел отрицательный опыт с БИТ.ФИНАНС
Тормоза по закрытию месяца возрастали с один-два часа до суток
   Добрыня Никитич
 
147 - 25.11.21 - 12:11
(145) В РИБе?
   Garykom
 
148 - 25.11.21 - 12:30
(147) Поясни
   lenkavovka
 
149 - 25.11.21 - 15:03
(143) многократно отлавливали замером производительности + в консоли 1С сеанс/соединение с момента начала выполнения запроса (или отчёта, если на СКД) жрёт текущую память до небес, один раз даже 150 гигов видели. Пока спасаемся запретом на запуск отчётов с большими периодами или без отбора по товару, ведём переговоры с разработчиком самого прожорливого решения. Локальные разработки, как уже писал, практически привели в порядок: тестили сравнением планов запросов и замерами времени на небольших объёмах данных. Если интересно, то практически везде помогает отказ от вложенных запросов, переход к конкретным типам от определяемых, в сложных случаях отказ от обращений через вторую и т.д. точки, то есть приведение трудов прошлых поколений кодеров (и наших тоже) к рекомендациям с ИТС.
   Добрыня Никитич
 
150 - 25.11.21 - 15:50
(149) а с определяемыми типами что не так?
   Garykom
 
151 - 25.11.21 - 15:57
(150) примерно тоже самое что и с составными
погугли как в базе sql хранятся
  1  2

Список тем форума
 
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.