Всем привет!
Наверное 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 лет истории продаж, дополнительные регистры для финансового учёта и аналитики, сложные вычисления по всему перечисленному.

начните с прочтения правил форума

раздел рекомендации

(0)

>>>Да, с точки зрения кода/запросов заметных недостатков нет ни в местных, ни в покупных доработках. Запросы максимально оптимальные, в цикле их никто не запускает)).

На глаз или чем-то мерили?
Проводили аудит/рефакторинг кода?

>>Но как только юзерам хочется одновременно запустить что-то большое
Майнинг? Перепроведение всех документов от рождества христова? Все реализации оформлены на "Физ.лицо" с одним договором.

>>Что показывает тест Гилева на вашем сервера?

(0) MS SQL или PostgreSQL ?
Пробовали больше оперативки скулю дать?

(0) вот будет забавно, когда вы купите новый супер сервак, а проблема как была, так и осталась...
Чтобы это минимизировать, нужно найти причину тормозов, а уже потом придумывать, как это решить, либо железо апгрейдить, либо логику (код) править. Может у вас вообще с сетью проблемы, а может закрытие месяца бухи запускают. Может регламент какой-нить корявый через внешнюю обработку воткнут. В общем, если есть возможность проанализировать все узкие места и есть компетенции для этого, то вперед. Если же всего этого нет, а проблему решать надо, то ищите контору, которая в этом шарит, может по договору будут хоть какие-то гарантии)

(0) лицензия у вас какая? КОРП я надеюсь?

>> SQL потребляет всего 1,5 Гб ОЗУ из выделенной сотни

SQL сервер обычно потребляет столько, сколько дадут. Либо плохо смотрите потребляемую память, либо плохо SQLю

(0) ребилд, реорганизация индексов с обновлением статистики у вас выполняется в скуле по регламенту?

(3) Аудит кода проводили. Делали замеры.
Виснет всё на больших SQL-запросах, с минимальными отборами или без них. Причём часть из них отрабатывает в сторонних докупленных расширениях, общались с разработчиками, оптимизировать там условно некуда.
Тест Гилёва админы запускали, считают, что результаты были более чем хорошими. К сожалению, скриншотов не оставили. Как пользователи разойдутся по домам - попробуем сами пустить.
Да, а большинство продаж действительно на одно физлицо...
(4)  MS SQL. Давали ему 240, ситуация та же была.
(5) Узкие места в коде мы видим. Но в настройках сервера опыт необширный. Нет ли на примете контор именно по серверам? Думали о внешнем аудите железа и настроек сервера, но без рекомендаций боимся нарваться на контору, которая берётся за всё, не имея реального опыта.
(6) Увы, недавно из-за проблемы с документами лишились Корп, сейчас снова покупаем.
(7) В диспетчере задач он резервирует все выделенные 100 Гб, но если посмотреть реально потребляемую память - то 1,5 Гб.

(8) задам вопрос админам.

выделенный сервер под сложные задачи

(8) ну они же скажут, что у нас загрузка сервера 30%, смотрите 1с

а процы небось по 2ггц?

(0) Неправильно память меряете.
Неправильно конфу сервера указываете.

Поди и все остальное неправильное.

а кстати жр какого формата?

вставание колом - это один из глюков жр на скл-лайт

(11) и копию базы туда заливать? в принципе вариант
все только чтение вынести на другой сервер или хотя бы другую sql базу

(0)  >>SQL потребляет всего 1,5 Гб ОЗУ из выделенной сотни

Как определили?

(9) "Увы, недавно из-за проблемы с документами лишились Корп, сейчас снова покупаем" С Корпом у вас появится возможность нормально настроить кластер под нужды 1с

и еще, раз у вас кластер и скуль на одной машинке, то проверьте shared memory включено ли.

Аналитики случаем не с начала времен отчеты крутят? можно их на отдельный сервер убрать

(11) (21) На отдельный сервер - очень сложно получится. Там комплексные решения, создающие документы на основании отчётов. Учитывая размер базы, выгружать на отдельный сервер регистры по продажам/заказам/перемещениям, а обратно созданные документы: будет неоперативно, как раз от похожего решения недавно ушли, правда от облачного.

(22) речь про поднятие копии базы средствами скуля

(23)+ и выкидывание на эту копию с задержкой всех економистов и оналитеков
которые только читают но не пишут в базу

(22) Поднимите РИБ, обмен раз в ролчаса. Перестройте отчёты - текущие данные в этом месяце с боевой брать, прошлые периоды с рИб

(25) нахрен нужен РИБ если во второй базе только отчеты?

(13) (15) (16) Журнал регистрации - SQLite, попробуем эту версию обдумать. Проц посмотрел - Intel Xeon Silver 4215R 3.2ГГц. Судя по характеристикам в инете в нём 8 ядер/16 потоков, видимо я исказил, когда сказал, что 12 ядер.

(19) (20) Спасибо, покупку Корп постараемся ускорить, shared memory проверим.

(28) Корп в данном случае не поможет

(23) (24) (25) (26) Увы, разделение пользователей на две базы у нас не одобрят точно. Нет пользователей, которые только читают, и ничего не пишут. Или которые могут работать только с небольшим периодом, или без оперативных данных. Надо другое решение придумывать.

(30) Так что с памятью (18), Ленка-Вовка?

Созрел попутный вопрос. Если покупать новый сервер, как работать предпочтительнее: оставить на старом Бухгалтерию (20 бухгалтеров с проводками) + мелочь, а на новый выселить УТ, или разделить 1С и SQL на 2 сервера?

(31) Пытаемся понять, как правильно смотреть.

(27) это первый кандидат на тормоза. А так, память закончилась и все колом, это, к бабке не ходи

Сколько вы памяти скулю то хоть отдали из 384 ?

(34) Хранить в текстовом виде, или крутить настройки вокруг SQLite?

(36) а ты там кем работаешь?

(35) Пробовали диапазоны 100-240, по ощущениям - изменений не замечено. Причём сначала было 240.

(36) в тексте период день, или отключить, за ненадобностью, ну или иегить тока ошибки

(37) Разраб.

(35) какая разница сколько отдали, если по его словам используется всего 1,5 Гб?

(41) в 1.5 гига при 100 пользователей не верю

Как говорит Ежов, у (0) ничего не получится.

tempdb хоть на каком хоть диске валяется? Настройкой самого скуля кто там у вас занимается?

(41) (42) увы, админы уже отдыхают, не можем сходу догадаться, как правильное значение потребляемой памяти в SQL посмотреть:(
Гуглим.

(44) если правильно смотрим, то два SSD, и над ними контроллер avago smc3108. Весь сервер настраивают админы, включая SQL.

(30) Не разделение пользователей
Создание распределенной базы, с периодом выгрузки минимальным и переточки отчетов так, чтобы с начала текущего месяца отчеты брались с боевой базы а за предыдущие месяца с базы РИБ
Делается бесшовно даже на границу месяца, юзера ничего не почувствуют, вам тоде не придется зависеть от отминов и трахаться с нехарактерными для 1Снника щаниями о процах, количестве потоков и прочей шлоебени

(45) Монитор ресурсов или DBCC MEMORYSTATUS

(48) > DBCC MEMORYSTATUS
Available Physical Memory    213151866880
Available Virtual Memory    140489880350720
Available Paging File    251929268224
Working Set    161062051840
Percent of Committed Memory in WS    100

И монитор ресурсов: https://skr.sh/sBA7ReYrihp

(47) Спасибо за пояснение, покурим идею.

(27) хочу сказать что проц говно
для 100 юзеров хрень полнейшая и тормоза вполне логичны

(52) Сможете посоветовать модельку проца для нового сервера?

https://en.wikichip.org/wiki/intel/xeon_silver/4215r (цветная табличка)
Да...

(52) Хозяйка дрянь, пирог - овно, иппал я ваши именины ... (с)
(53) I9 какой нить для рабочих станций, с максимальной тактовой частотой под сервер 1с - он однопоточный

(49) 160 Гиг юзает

(56) точнее, 150..

(0) "диски современные быстрые"
-А что, отец, невесты у вас в городе есть? -Кому и кобыла невеста. (с)

какие быстрые то?

(0) зашел спросить чисто про ник. Вы долго думали?
Даже боюсь представить, например Гения с ником ТатьянаСерега или ЕленаСережа)))

(59) там весь текст во множественном числе, а тебя только ник смущает ))))

(59) > ТатьянаСерега или ЕленаСережа
ПашаПаша =)

(0) на виртуалке крутится?

(60) тут выбор в русском языке ограничен, или "мы, Николай вторых", или "я, майя Плисецкая".

(0) Анализ ожиданий на блокировках, например, делали?

(63) а как же беременная женщина?

(65) ник или псевдоним оно насовсем.

(56) (57) Спасибо, выходит, не туда смотрели.

(59) мы с супругой вместе работаем, на одинаковых ставках. Очень удобно, кстати. Ну и акки часто общие))

(62) реальная железка
(64) не делали, спасибо, попробуем

(58) Под srv-info и sql-temp Intel Optane 900P, под SQL стоят SATA SSD D3-S4510: 8шт в 10 рейде

конкретная спецификация дисков: 1,92 ТБ, 2,5 дюйма, SATA, 6 Гбит/с, 3D2, TLC

(41) (42) наш админ так считает про 1,5 гига на SQL:
SQL старается всю память забирать , до этого жил в 2 гигах, почему-то все остальное не пользовал
выключил блокировки , хотя 1С их рекомендует включать..
https://its.1c.ru/db/metod8dev#content:5904:hdoc:_top:lock%20page%20in%20memory
теперь SQL пытается загрузить в память все, что пользует
понятно, что целиком все наши базе не лезут ..
теперь. какой потолок на серверу назначу, столько он и будет всегда занимать

(72) Блокировки страниц в памяти имеет смысл включать когда сиквел и 1с на разных серверах (и то вопрос спорный). Он и раньше использовал всю выделенную память, просто в диспетчере задач процесс показывал маленький объем.

(72) у тебя железо норм, в первую очередь переведи ЖР в старый формат

Что вы прикопались к нику? Какая разница какой ник?
Лишь бы человек был адекватный.

Полтора гига скулю под УГ11?
У меня на домашнем компе хром в три раза больше занимает...

(76) в (49) написано что 150 гигов жрет.
может это еще и без нагрузки
при ограничении в 100

(0)

Говорят в Древней Греции заболевший человек шел на рынок и спрашивал советы окружающих.
Я х.з. о результативности такого лечения, вероятно в это время эффективно работал дарвиновский отбор.

О "встает колом" и традиционный вопрос "что делать?".

Сервисы Гилева для оценки запросов юзали?
А его же сервисы по оценке блокировок?
Сам сайт прочитан от и до?

Почему на простой вопрос о shared memory следует ответ "нужно посмотреть" ?

Мне искренне жал ваш SQL-сервер, который живет в тюрьме из 2 Гб



P.S.
Вы же понимаете, что новое оборудование будет недешевым и аргумент ген.директору "мне ребята на мисте подсказали" будет несколько "слабым".

P.P.S.
Наймите уже http://www.gilev.ru/
или любую другую команду

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

(77) а в (72) написано немного другое ))

Разберитесь сначала вот с этой чушью "наш админ так считает про 1,5 гига на SQL", процессор в диспетчере загружен?, очередь к дискам какая? Что у вас тормозит посмотрите уже, это по железу. А по софту  ставьте Корп разделяйте базы по процессам, ставьте нормальную версию ms sql, дайте ему не ограничено памяти и посмотрите, что после этого будет по железу тормозить, тогда ясно станет, что нужно сделать.

150 гиг 1с сервер ест - это аномально, за сколько он нажирается, после перезапуска службы?

Или его уже пол года не перезапускали?

У вас все наоборот - скл должен 100 есть , а 1с детятки гиг.

(68) казалось, к 40 годам в жизни все повидал...ан нет...
У вас и телефон один на двоих?

+(84) Приходишь такой в магазин, "А дайте нам булку хлеба, а вокруг тебя то нет никого,..."

По загрузке процессора в процессе "вставания колом" в мониторе ресурсов что показывает?
Какие именно процессы долго и интенсивно используют несчастный процессор начального уровня, который не подписывался на такую тяжелую работу?
Только одни тяжелые аналитические отчеты запускались, без 100 пользователей, обменов, регзаданий? Так же тормозит или быстрее получается?

(80) >>А по софту  ставьте Корп разделяйте базы по процессам

ты в отделе продаж корп-платформы штоли работаешь?

(82) вполне вероятно кстати.
"чистые" админы, далекие от 1с, не считают обычно регулярные утечки памяти от 1с нормой.

(0) Если сервер на MS SQL, то еженочно делать репликацию базы на другой сервер. На другой сервер запускать аналитиков, пусть там и только там запускают свои мухобойные отчеты.

(50) >> Монитор ресурсов.

А почему два процесса rmngr? У вас там два кластера поднято на одном физическом сервере?
1С такую установку рекомендует исключительно в опытно-тестовых сценариях, но никак не в продуктиве.

А так из очевидного.
Проверка и настройка регламентов СУБД (если они вдруг не настроены или настроены криво).
Перевод ЖР на текстовый формат с периодичностью день.
Вынести вот это вот всё "Бухгалтерия и прочее" на отдельный сервер. Оставить только УТ.

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

Совершенно не факт, что от этих действий будут хоть какие-то результаты (хотя бы даже незаметные для глаза).
Любые остальные рекомендации - тыканье пальцем в небо.
Есть рекомендации по поиску узких мест. Задача эта в большинстве случаев сложная и весьма нетривиальная.
А главное - серебряной пули не существует. Нет такой волшебной галочки, которую вы включите или выключите и всё сразу залетает.

Пригласите специалистов. Дорого. Но в конечном счёте это выйдет дешевле, чем вложения в апгрейд сервера по рекомендациям с форума.
"Программист 1С" - по определению это специалист, не обладающий достаточными компетенциями для решения задачи в (0).
Запрос админов к вам на озвучивания конфигурации железа - это провокация и/или попытка переложить ответственность на вашу сторону. Скорее всего, и то, и другое.
Такие задачи должны решаться либо специально обученным человеком - DBA 1С, либо (если такого нет) совместно - админами, DBA и разработчиками 1С.
И начинается всё с поиска узких мест. А выбор железа - самый последний шаг.
И "1С встаёт колом, когда пользователи запускают что-то большое" - это не узкое место. Это даже не формулировка проблемы. Это какая-то эмоция.

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

(90) > 1С такую установку рекомендует исключительно в опытно-тестовых сценариях, но никак не в продуктиве
Серьезно?

(91) >> Серьезно?

Ссылок прям щас не найду. Но наталкивался на такие рекомендации на ИТС.
Формально - возможность такая есть (несколько служб 1С одной версии и различных версий на одном сервере). И в документации подробно описана со всеми инструкциями. Но по факту 1С не рекомендует этими возможностями злоупотреблять.

(92) Ну да. Нвпример, по факту, вот тут - https://its.1c.ru/db/v8320doc#bookmark:cs:TI000000124 явно написано:

    Ситуация, когда на одном компьютере функционируют параллельно два и более
    агента серверов, каждый из которых управляет своим набором кластеров, является
    вполне нормальной, но достаточно редкой и специфичной. Например, необходимость
    в этом может возникнуть тогда, когда на одном компьютере нужно использовать
    различные версии сервера «1С:Предприятия».

(93) Более того. Я где-то встречал прямое указание на то, что подобная конфигурация именно что не рекомендуется на продуктивных серверах. Только в случае крайней необходимости или для каких-либо целей тестирования в отдельной от продуктива среде.

(94) Ну понятно. Это у 1С как запросы в цикле писать.

(94) и еще крипту на продовых серверах лучше не майнить

(96) А вот видео пережимать можно.

(0) Вам бы тех. эксперта нанять, прежде чем сервер апгрейдить. Может и дешевле выйдет.

(98) зачем? тут несколько тех. экспертов забесплатно в телепатов игруают от скуки

(99) Чтоб не бесплатно, а отвечал за результат.

(98) вся проблема в том, что как определить тех. эксперт это, или вася, который недавно узнал о существовании тех. журнала. Он может с умным видом походить по серверной, запустить какую-нить аиду64 на серваке, прогнать пару тестов дефолтных. Далее взять базу, для якобы тестов, на недельку. А позже выкатить один из шаблонных ответов, где будет написано, нужно обновить железо. При этом никакой гарантии, что после апгрейда все залетает как вы и планировали...
Как заказчику обезопасится от таких спецов?

(101) Сертификат и/или репутация, другого пока не придумали. С этим уже и Миста может помочь.

(100) там куча одминов и 1с-ников на зп сидят, поэтому нужно бесплатно

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

(101) >> Как заказчику обезопасится от таких спецов?

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

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

В-третьих, ждать, что прилетит волшебник в голубом вертолёте и разом решит все проблемы только лишь деньги поступят к нему на р/счет, не стоит. Придётся и самим поработать.

(104) >> Сертификат ... может быть у одного сотрудника конторы, а остальные джуны которые делают всю черную работу.

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

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

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

(81) несколько часов
(86) загрузка процессора в пределах 20% всегда, 1С тормозит даже если запустить тяжёлые отчёты практически при полном отсутствии юзеров
(90) базы действительно в разных платформах. Спасибо за идеи и развёрнутые советы!

(98) (99) (100) с оплатой тех. эксперта проблем нет, руководство адекватное, всегда готово. Дело не в том, что "на форуме бесплатно", а, как сказали выше, и как я уже писал -  в оценке компетентности эксперта. Поэтому и создал тему на форуме, описав наши чаяния, чтобы получить советы от более опытных в борьбе с тормозами коллег, и быть в теме. А то действительно пальцем в сервер потыкают, скажут менять железо, а потом, если не взлетит - "а, ну так у вас код кривой". И виноватыми окажутся программисты.

(107) конечно кривой. Кто-то у вас зоть раз профайлер открывал?.. ну или зотя бы стату по запросам к саулю смотрел?..

(107) загрузка ядра или процессора в целом?

(107) берите Гилева если нужно имя

(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=
У этих партнёров требуйте портфолио с отзывами  по завершенным проектам с подробным описанием (как было, что делали, как стало) и возможностью пообщаться с из заказчиками.

(108) >> Кто-то у вас хоть раз профайлер открывал?.. ну или хотя бы статус по запросам к скулю смотрел?

Чтобы это делать надо хотя бы знать - в какой момент это делать и куда именно смотреть.
А судя по "1С через некоторое время встаёт колом (замедляется в n-цать раз)" ясного понимания у авторов нет.
Не исключено, что у них всё настроено идеально, а для описанной ситуации - "когда юзерам хочется одновременно запустить что-то большое" - такое поведение системы вполне даже норма. И в таком случае апгрейд железа только смягчит проблему и на какое-то время отложит её, но не решит кардинально. А единственное решение - разделение пользователей по разным базам (оперативка и "для отчетов"), от которого автор старательно открещивается.

(108) (112) Профайлер конечно открывали, всё что можно было, в первую очередь тяжёлые запросы - оптимизировали. И даже знаем на самом деле, что именно (какие именно запросы и в каких условиях) тормозит.
Наша сложность - установленные сторонние "серийные" разработки, анализирующие движения за большие периоды. В организации политика невмешательства в код таких решений, тем более, что часть из них обновляется. Отсюда и происходит моё опасение, что переписать эти решения для разделения на разные сервера, сохранив комфорт работы пользователей, или даже просто значительно их переделать - невозможно в наших условиях. Делать самим - означает взять на себя ответственность за функционал, и придётся увеличивать штат, кода там немало. Заказывать у разработчиков - означает заплатить за индивидуальную версию, которая скорее всего будет в разы сложнее и дороже оригинала. Если упростить и немного притянуть за уши: у вас Word на компе тормозит, будете комп апгрейдить/винду оптимизировать, или у Майкрософта облегчённую версию Ворда заказывать? В общем, стремимся к комплексному подходу в анализе проблемы.
Вот если бы была возможность ограничивать память, выделяемую одному сеансу 1С, у нас 90% проблем решилось бы моментально. Но что-то я подозреваю, что даже КОРП не поможет. Или не прав?
(109) процессора в целом
(111) (110) Спасибо за советы!

(55) предложил админам I9, а они смеются, что он только 128 гигов памяти поддерживает (

(114) Предложите этим людям на выбор Gold 6244, 6250, 6256, только цену не показывайте сразу, иначе они дольше смеяться будут.
Раз уж "политика невмешательства в код таких решений".

(114) У нас всего 64 памяти для сервер 1С и PostgreSQL для более 100 юзеров
И за глаза хватает

Оперативка не сильно нужна когда сам проц шустрый в однопотоке и дисковая подсистема тоже шустрая

(113) > сторонние "серийные" разработки, анализирующие движения за большие периоды

"Серийные" в смысле тиражные? Можете конкретные назвать?

(113) > если бы была возможность ограничивать память, выделяемую одному сеансу 1С, у нас 90% проблем решилось бы

Каким образом? Разве алгоритм, которому нужно много памяти, не вывалится с ошибкой?

(118) Но если узким местом действительно является ОЗУ, то это решается горизонтальным масштабированием. Рассматривали?

(114)
ВРЕМЕННО разнесите 1С и СУБД по разным серверам.
Протестируйте, погоняйте недельку. Узнаете, где же вы проседаете.
Сам rphost на i9 будет летать с 128 Гб памяти на борту как истребитель. Возможно, что слегка просядете на времени взаимодействия 1С и СУБД. Но это терпимо и не точно.
Но ваши админы на это не пойдут.

Загрузка 20% проца (максимум 3 ядра на 100% из 16, но скорее 1 на 100 и остальные чуть-чуть), отключили фиксацию страниц в памяти...

А Max degree of parallelism в 1 админы случайно не выставили на SQL?

(113) КОРП может в "Безопасный расход памяти за один вызов", установив который, по крикам пользователей, вы вычлените хада.

(121) У них скорее всего mdop=0, вот и тормозит

Более-менее хорошая идея в (120), прокинуть rphost на i9, just for lulz, формочки быстро открываться будут, чебынет?

Ну а вообще, its читайте, там все написано.
В книге - сила!
https://youtu.be/QUZs_E6dRf8

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

(117) Да, тиражные. Не могу написать названия, но давайте опишу как средний пример систему обеспечения спроса, установленную отдельным расширением: производится расчёт ABC, XYZ, количество продаж по периодам, сезонность продаж. Средний период анализа - 3-4 года. Расчёт по каждой товарной позиции (их десятки тысяч, но обычно берут не больше десяти тысяч), и помножено это на 200 магазинов. Расчёты не сохраняются, каждый раз пересчитываются. Продукт руководство более чем устраивает. Разработчик с нами общается, но в корне менять продукт для нас одних, хоть и очень крупных, не будет, разве что за сумму, на которую можно будет купить пяток быстрых серверов. Ограничивать пользователей в расчётах нельзя: всё-таки наша задача обеспечить эффективную работу компании. Мы тоже мечтаем об идеальных условиях, но нужно исходить из реальных.
(121) (123) MDOP = 1, админы опирались на найденные рекомендации от 1С и статью на Инфостарте "Тестирование параллелизма SQL в среде 1С Предприятие" и комменты к ней.
(126) рады бы, но по факту сохраняем результаты длительных расчётов только в своих разработках, а тормозят преимущественно запросы в покупных.

(127) а что там, код закрыт, в покупных?
выходите на поставщика тогда требуйте оптимизировать решение или предоставить доступ к модификации.
помню с рарусом была история когда они наотрез отказались исправлять свои косяки в автотранспорте
пришлось на их закрытый модуль вешать свою обвязку - которая меняла данные до закрытого модуля и правила то что вернулось уже приводя к корректному виду.
но такая работа с кривым черным ящиком недолго продлилась - менее чем через год отказались от них, естественно предложение перейти на их же управление автотрансопртом после предыдущего взаимодействия было послано в даль.

(128) часть кода закрыта. Так что у единственный выход, кроме оптимизации/модернизации сервера - написать свой альтернативный продукт. Но инициатива, как известно, наказуема, а ещё у нас нет существенных дополнительных ресурсов на разработку того, что уже работает((

(129) Тогда только терпеть, сжимать зубы, плакать

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

PS С вашими текущими настройками на i9 будет лучше.

(131)

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

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

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

После завершения реструктуризации мы рекомендуем в общем случае ВЕРНУТЬ значение в ИСХОДНОЕ СОСТОЯНИЕ.
Конечно же, в процессе ее выполнения стоит выполнять мониторинг ожиданий СУБД, о котором сказано выше, а также производительности дисковой подсистемы при помощи, например, Performance Monitor.

(132) см. последнюю строку в указанной таблице.

(127) Тогда у вас выход только РИБ
Ну и RLS отключите

Отпишитесь потом, какое решение нашли.

(127) Еще раз обращу ваше внимание на горизонтальное масшатбирование. В частности рассмотрите эти механизмы: https://its.1c.ru/db/metod8dev/content/5951/hdoc

(136) Акселератор вроде только на чтение работает

(127) >>а тормозят преимущественно запросы в покупных.

Т.е. вы нашли причину? Быстро, однако

(137) Вроде им это и нужно: "Расчёты не сохраняются, каждый раз пересчитываются".

Даже без акселератора копия базы может помочь.

(136) блин, сколько классных штук оказывается есть в 1с, о которых еще не знаю (
это же на уровне платформы реализованный механизм кеширования фактически.
который десятилетиями люди сами костылями приделывали.
и до сих пор многие приделывают

(134) RLS отключено. Про РИБ думаем.
(135) обязательно отпишусь
(136) (139) Акселератор, увы, к нам не применим. На ИТСе говорят, что не будет работать с запросами, где есть менеджер временных таблиц, а у нас в покупных решениях он везде.
С копией думаем, какой механизм использовать. Пока у нас только один сервер. Думаем про варианты выноса rphost на отдельный купленный сервер с I9, либо покупку более мощного сервера для использования механизмов типа РИБ, или кластеризация SQL, или предложенный Вами "Механизм копий баз данных" (по описанию очень интересная штука). Ну и перевод лицензий на КОРП, начнём с него.
(138) мы причину понимаем изначально: в-основном это тяжёлые запросы, которые мы не можем переписать. в третьем абзаце (0) я говорю про аналитические отчёты.

Я пропустил или нигде не было данных по используемым процессорам?

(141) вы это прям точно по трассе установили или понимаете примерно?

(142) 8 ядерная Silver-ная шлабуда.

(141) РИБ в нативном виде скорее всего не пойдет
Имхо нечто вроде шины/кролика и в отдельную базу для отчетности выносить копию данных
А рабочую оперативную базу лишить всего ненужного, все эти сторонние расширения выкинуть

(145)+ Например имел отрицательный опыт с БИТ.ФИНАНС
Тормоза по закрытию месяца возрастали с один-два часа до суток

(145) В РИБе?

(147) Поясни

(143) многократно отлавливали замером производительности + в консоли 1С сеанс/соединение с момента начала выполнения запроса (или отчёта, если на СКД) жрёт текущую память до небес, один раз даже 150 гигов видели. Пока спасаемся запретом на запуск отчётов с большими периодами или без отбора по товару, ведём переговоры с разработчиком самого прожорливого решения. Локальные разработки, как уже писал, практически привели в порядок: тестили сравнением планов запросов и замерами времени на небольших объёмах данных. Если интересно, то практически везде помогает отказ от вложенных запросов, переход к конкретным типам от определяемых, в сложных случаях отказ от обращений через вторую и т.д. точки, то есть приведение трудов прошлых поколений кодеров (и наших тоже) к рекомендациям с ИТС.

(149) а с определяемыми типами что не так?

(150) примерно тоже самое что и с составными
погугли как в базе sql хранятся