Добрый день. Имеется 1с платформа 8.3.10.2252 на отдельном сервер стоит сервер 1с жёсткие ссд память на нем 32 гб. На втором сервере стоит windows server 2008 r2 скуль 2008 проц ксеон 4 ядра оперативки 80 гб (dell) два жёстких сас по 300 гб, на одном система и темповые базы, на втором две базы данных одна 65 гб вторая 92гб. Суть проблемы - очень тормозит проведение документов и всего прочего, притом замечено, какая из баз была запущена первая та хоть более и менее будет работать, вторая жестко тупить. Монитор ресурсов загрузку жёсткого показывает минимальную, проц как обычно один процесс запущенный в 1с грузит один процессор, памяти выжигается все 78 гигов которые разрешили использовать скулю, с учётом оси полная загрузка памяти 79.5 гигов. Куда можно попробовать рыть. В голове вариант попробовать поставить новую скуль и поменять энские на ссд, но при загрузке текущей жести ну думается что будет результат. Второй - покупать новый сервер баз данных с оперой от 200 гб. Есть мысли? Писал с тела, автозамену кто не отменял.

P.s. Програмист говорит что все ок. Мол база разработчиком спроектирована коряво и используется пару регистров в них почти все данные записываются и в месяц в них лям строк добавляется, вот мол и проблема.

(1) какая хоть конфа 1С?

ССД это, конечно, хорошо, но в вашей ситуации скорей всего погоды не сделает. Со стороны скуля какие-то действия пробовали предпринимать?

Решение 2 в (0) - половинчатое, закладывайте сразу от 1 Тб оперативы, что б наверняка, с запасом (шутка).

...ксеон 4 ядра...
думаю это узкое место

Узкое место это сервер 1С и sql сервер на разных железках.
Ну и само железо убогое.

Или менять железо на один приличный "настоящий сервер" или переписывать конфу 1С.

Между серверами гигабит. Загрузка сети в пик это 50% на пару сек, а так 0.2%. Конфигурация вдгб (нынешний рарус) учёт в управляющих компаниях ТСЖ и ЖСК 2.0!! На тройку переход не предлагать. Свои заморочки. Процессор грузится исключительно скулам одно задание одно ядро загружается скулем, с базой на запись работают 3 человека, как правило не проводят одновременно, загрузка максимум 75 процентов (3 ядра)

Переписывать конфу дело мертвое и не решаемое.

(2) скуль - если память не изменяет включена постоянное сжатие базы, каких либо дополнительных решений не делалось. Тупняки начались только после возрастания баз от 50 гигов. Три года назад когда базы весили по 10 и 15 гигов, были переведены на данное решение с отдельным сервером скуля.

(5) Да пофиг на загрузку сети, проблема в таймингах.

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

(7) Значит пора порезать базу и делать это постоянно каждый год свертку данных.

Да. Файер стоит, керио, скажу чтобы отрубили и постестим денёк, сразу будет видно, отпишусь.

А какой проц на сервере 1с?

(9) конфа расчета квартплаты. Свертка означает лишение оперативного ответа на заданные вопросы в перелах 5 лет. Начальник отдела свертку базы отвергла.

(11) Интел i7 4*** дальше не помню. Рп хост создаётся для каждого клинта ( как то так вроде звучит). Загрузка проца максимум 40% но это очень редко, так как правило если большая обработка то ядро сожрала каждая 1с и сервер 1с соответственно

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

Возможно при проведении выполняются запросы к РН и документам

Строк в документах по разному - бывает и 600 бывает и 20, логично что чем больше строк тем больше проводится. Непонятное для себя план обслуживания баз спрошу в пн у админа. P.s. Я руководитель, админ и прогер по 1с говорят одно что это нормально для такого объема инфы (Дэн) если сидишь тут Дак отписывайся.

(0)SQL 2008?

(0)Блин.. сорри.. рили 2008..

Снимай его и ставь 2012 хотя бы.. он с памятью получше дружит.. У меня опыта в этом деле не много, но вот исходя из него, это первое, что я бы сделал.

(10) файер между сервером SQL и 1С?! если нет, то неважно это.
судя по (5) надо смотреть планы обслуживания и логику 1с.

Вы прикалываетесь штоле?
У автора мильены строк в регистре.
Достаточно одного внеиндексного запроса - и ничего не поможет.

Процессор не озвучен, полагаю, там что-то уровня 12-летнего пентиума 4 по частоте.
Сервер СУБД живет на железке с механическими винтами (при наличии в организации ССД).
Загрузка сети в пик 50% (полагаю, адаптеров два, следовательно в пик как раз в сеть и упирается). Сервера хоть напрямую соеденены, или через дир-300 какой-нибудь?
Есть штатный программист, значит решение со сверткой вполне можно найти - разбить реестры по годам, например.

(19) только этот сеанс подвиснет

Автор, у тебя ведь настроены планы обслуживания, правильная схема электропитания (а может и бурст мода?), max_paralelizm=1 ?

А почему нет отдельного диска под журналы?

в самом топике не отвечено главное:

в момент появления тормоз что именно "заваливается" - сервер 1С или сервер СУБД ? Вангую, что трабла именно в сервере 1С. И надо каким-то образом в агенте или где-то еще указать, чтоб рпхосты сервер 1С создавал РАЗНЫЕ на разные две базы.

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

Это не скуль, не субд

и кстати, размер оперативы памяти именно на СУБД не будет настолько критичен как например 32 ГБ на Сервере 1С и 80 ГБ на Сервере СУБД - вот их нужно поменять местами. для сервера СУБД и всего двух баз 80 на фоне 32 избыточно

и еще перечитал - в топике не сказано сколько сеансов в принципе предполагается запускать одновременно и как эти сеансы делятся по количеству между двумя базами

и еще вспомнил - какая разрядность сервера 1С в топике тоже не указано. Не операционки на железяке, а конкретно сервер-приложений 1С, у которого есть исполнение в 32 бита и 64 бита. Какой разрядности установлена СУБД на отдельном железе или на том же самом не указано тоже

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

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

(25) извини, но ты в этом посте херню написал.

(30) для кого?!

Если для тебя, то может и херню, но я сильно сомневаюсь, что у тебя в наличии будет такой вот комплект железа и такие вот проблемы, как у ТС

(31) ты понимаешь чем сервер СУБД отличается от сервера приложений и какую функцию каждый из них выполняет?

(32) ок. Давай посоветуем ТС еще больше оперативы запхать в сервер СУБД - решит это его проблему?

(33) поздно - см. (2)

(0) Конечно извиняюсь, но кажется базы делят общий кэш в СУБД. Вот одна другой палки в колеса и суёт. Можно два экземпляра СУБД поднять, ну или как-то настроить разделение кэша между базами.

(27) для справки - сервер приложений - intel core i7 4790, 32гб, ssd sata, windows server r2 2008 x64, платформа сервера 8.3.10.2252, файер kerio, антивирус каспер (8.0.0.559). Сервер базы данных - dell PowerEdge T320, xeon e5-2407 (1 проц, 4 ядра) память 80 гб (5*16) hdd sas 300 гб 2 штуки, ось windows server r2 2008 x64, также каспер и файер керио. База данных база и лог на одном жестком диске, база темпов на диске с виндой.

(35) логику понял. Попробуем. Спасибо.

(33) проблема... ddr3 растровая не продается 32 гб нигде уже, есть ddr3L купили ее 32 гб сервер ее не кушает. Вот уже и закинулись на сборку нового сервера, ценник озвучили лям почти. (в параметрах было - 160 гб оперы, с возможностью расширения до 240, жесткие ssd pci по 400 гб) это то что закидывали как основные параметры сервера.

(25) на сервере приложении опера более 18 гигов не кушается(всего 32).

(38) (39) Надеюсь, есть понимание, что это вам не поможет?

(40) Дак да. Поэтому и создался топик. Пару вариантов оптимизации высказанные здесь, пустим в работу, будет видно уже в течении след рабочей недели.

(41) например, можно было спросить у яндекса... я вот спросил и получил ссылку

https://blog-admina.ru/мониторинг-памяти-в-ms-sql/

Смотрели? Реально, что там на нем с использованием захваченной скл сервером памятью?

(36) какой нахрен антивирус! Какой в отстой файервол!!!
Сноси их с серверов и ставь на клиентов и только так!!!

(39) сколько ИБ и сколько сеансов на 1 меня (РП)?

(39) Сеансов на 1 одного тебя - 7 постоянно + вэб сервис иногда появляется, ИБ 5, но это разные сервера БД (2 на отдельном и остальное на другом)

(42) память в зависимости от запроса начинает отдавать или забирать, сейчас 60% большая база есть 40% маленькая. Бывает ситуация обратная, но зависит от проводки.

Для понимания объема базы - вдруг чего даст, регламентное задание пересчет регистров накопления начинается в 3:00 закончилось в 4:11 это большая база.

Меньшая 3:00 - 3:44

Короче, у ТС проблемы во всех аспектах. Немного там, немного тут, в результате эта тема на мисте!

(36) Как я и думал, у вас очень слабый сервер БД. Надо рассмотреть вопрос о замене. Ну и конечно антивирусы и сторонние фаерволы с серверов долой. Вы б еще туда контроллер домена установили.

(50) и видеонаблюдение. обязательно )))

(46) таким образом, можно предположить, что хоть сервер СУБД слабоват (как утверждают тут многие), но нагрузка на нем распределена примерно одинаково на ОБЕ базы.

Это подтверждает предположение о том, что перекос в использовании ресурсов происходит не на СУБД, а на сервере приложений, т.е. Сервер 1С нужно отстроить на предмет разделения доступа клиентов РАЗНЫХ баз, ХОТЯ БЫ, в РАЗНЫЕ процессы сервера 1С

предположение довольно очевидно, но я говорю о том, что у ТС забыли посмотреть на вот эти параметры
---
ПАРАМЕТРЫ РАБОЧЕГО СЕРВЕРА

Параметры рабочего сервера 1С

Максимальный объем памяти рабочих процессов — это объем памяти, который могут использовать рабочие процессы вместе. Нужно быть очень внимательными при установке параметра, измеряется в байтах. Если установить неверное значение (недостаточное для нормальной работы пользователей) пользователям будет выдана ошибка "Недостаточно свободной памяти на сервере 1С". Так же эту ошибку можно получить, когда на сервере 1С закончилась квота по памяти.

Безопасный расход памяти за один вызов —  позволяет контролировать расход памяти при серверном вызове, измеряется в байтах. Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe). Соответственно "неудачник", который выполнил вызов сервера, утратит сеанс с базой 1С без влияния на работу других пользователей.

Объем памяти рабочих процессов, до которого сервер считается производительным — при превышении этого параметра сервер в кластере 1С перестанет принимать новые соединения.

Количество ИБ на процесс — позволяет изолировать информационные базы по рабочим процессам. По умолчанию у текущего кластера 1С было установлено значение — "8", но на протяжении нескольких часов работы сервер себя очень нестабильно, сеансы пользователей зависали. После изоляции каждой информационной базы (значение — "1") проблемы пропали.

Количество соединений на процесс — по умолчанию значение "128". Так как у текущей базы очень большая нагрузка фоновыми заданиями (расчет логистики, анализ прайсов, анализ конкурентов и прочее) было принято решение уменьшить количество до "25".
---

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

(47) Если проведение ваших документов или пересчет допускают многопоточную(при помощи фоновых заданий) обработку, то быстрый 10-ти или 12-ти процессор  последнего модельного ряда Xeon Scalable Processors может существенно сократить время выполнения.
(38)>>в параметрах было - 160 гб оперы
Учитывая, что базы "резать" нельзя, а они довольно быстро растут, 160 ГБ мало. Смотрите в сторону 384-512 ГБ, чтобы через 3-4 года не пришлось опять искать устаревшую уже, к тому времени, память.
Я это к тому, что у автора темы и его организации уже есть понимание, что на старой повозке, пусть и запряженной осликом, далеко не уедешь. 12 тонн груза не ней не перевезешь, фура нужна...

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

(56) значит вы не тот показатель смотрели. очередь к диску должна была быть большой

(0) Начни с perfmon и очереди дисков в нем.

1с и sql на разных серверах это нормально, лично у меня 1с + 2 sql отлично работают.

(0) Еще в монитор производительности sql неплохо бы заглянуть (это в SSMC).

(36) А нафига у вас на серверах всякие керио и антивирусы?)

Там пользователи бродят чтоль?)

(50) И терминал!)

(0) Учитывая (36), вангую очереди, как за ойфонами в день релиза)

(0)куда рыть... ну сам же пишешь вся оперативка на скуле выжрана. Видимо которая первая база запускается вся в памяти и шевелится. я бы начал с замера производительности при проведении документа.