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

Утром все повторяется.
Это вообще нормальное поведение для СКЛ и 1С - или надо чето делать?

Сервер: Вин2к3 стандарт 64х. 2хXeon E5540 2,53 GHz, 18 Gb RAM
SQL 2005 sp3 32 bit
1C 8.3.4.437 32 bit
Пользователи работают на отдельном сервере терминалов.

(0) нет, это не нормально и вопиет о криво настроенном как сиквеле, так и сервере приложений

ну и конечно работать под 32 bit безумие

(1)  по поводу кривизны СКЛ и 1С - куда копать то?


По поводу 32 бит - не спорю - но маемо, шо маемо - "мопед не мой".
А с другой стороны и однозначности в этом вопросе тоже нет - тут мелькали темки в которых народ экспериментировал с разными комбинациями битности - и учитывая наличие в этой связке 1С - результаты как то не особо однозначны были.
Да и по-большому счету битность однозначно влияет на общую скорость, но связь битности с замедлением работы для меня не очевидна.

(0) "отжирания оперативки СКЛ" и много ест?

(3)  Ну с утра после рестарта - с учетом всех процессов занято где то 5-6 Гб.
Сейчас конец дня - занято 16 гб.
Непосредственно СКЛ сожрал где то около 10 гб.

Кстати а где глянуть битность СКЛ?
А то я чето написал 32 а теперь усомнился - ибо в диспетчере задач - на 32 битных процессах есть в наименовании *32. А на СКЛ -нету.
А в "Опрограмме" студии версию пишет, а битность че то не вижу.

http://infostart.ru/public/65955/

(4) выполнить select @@version

(4) В студии. Свойства сервера.

(0) У тебя все в своп уходит со временем. Установить в SQL Server максимально допустимый размер отжираемой памяти. Размер определить с учетом памяти потребляемой сервером 1С и службами Windows. Телепатирую, что 12Gb должно подойти.

18 гигов на сервер 1с+скуль по любому мало....

а вообще
http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

Насколько я помню, в 8.2 была такая бага - время запуска фонового задания нелинейно зависело от количества рабочих процессах. Чем их больше - тем медленнее. Поскольку в типовых многие вещи реализованы через фоновые задания - то это сильно замедляет работу.
А с учетом того, что 8.3 сама запускает рабочие процессы - можно сделать вывод, что баг с медленной инициализацией фоновых заданий при нескольких процессах остался, но теперь он стал проявляться лишь после того, как платформа насоздает процессы по своим потребностям..

(9) А почему 18 гигов мало?
Это зависит от размера базы. Если база 100 гигов то конечно мало, а для 500 мегабайтной базы этого выше крыши.

(9) ни о чем

(11) С учетом "только что перешли с файловой" это ВООБЩЕ неактуально. Хватит на SQL батон крошить.. дело не в нём однозначно, а в 1с!

(5)  Спс попробовую - завтра посмотрю на результат
(8) Ну по рекомендациям из (5) где то так и получается
(11)  База кстати весит пока всего 4 гига.

Ну СКЛ в общем более менее ясно - буду пробовать

А тюнинг сосбственно 1С сервера предприятия - какой нибудь есть?

Таки я ошибся - СКЛ 2005 - 64 бит

Впрочем не думаю, что это радикально меняет картину.

Хотя возможно и стоит озадачится 64 битным сервером 1С Предприятия - но это в любом случае не раньше выходных.

(16) Попробуй в виде эксперимента сделать так, чтобы сервер 1с не запускал более 1 рабочего процесса. Количество соединений на процесс и количество ИБ на процесс задай побольше. И перезапусти.

(0) так вроде еще не предлагали: в настройках СКЛ сказать ему не брать больше 8 Гб. не фиг.

(0)
>>Но затем по мере работы пользователей и отжирания оперативки СКЛ

Ну так поставь ограничение на оперативку не более 80% точнее сколько советуют в статье по ссылке (5)

(16)[Впрочем не думаю, что это радикально меняет картину. ]
меняет

(17) он разве не сам в 8.3 регулирует этот процесс?

(10) Это не баг, а особенность. Если много процессов, то большая вероятность, что фоновое задание стартанет на процессе, отличном от родительского, а это накладные расходы на передачу "данных" между процессами.

(22) "фоновое задание стартанет на процессе, отличном от родительского"

Это - как?

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

(10) больше 4-х не видел

сейчас на 55 соединений 2 процесса

(23) Все, понял. Попутал фоновое и регламентное.

Вот кстати я поднимал тему как-то
v8: Почему фоновые задачи так тормозят?

(20) На порядок? На базе в 4Гб?
А почему?

апну
ибо тюнинг СКЛ как бы если и помог - то незаметно на глаз.

Пальцем в небо:

Cоединения с подзапросами
Рекомендации
При написании запросов не следует использовать соединения с подзапросами. Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с подзапросами, то его следует переписать с использованием временных таблиц.

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

вроде не было вопроса: типовая?

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

(32) как будто типовые, на УФ летают прям. Прям таки образец скорости работы

(32)  Ну изначально бухия 3.0. Если это имеет значение.
Модуль ПКО - строго говоря немножко допилен (добавлен учет в разрезе касс)
Я бы конечно посыпал бы голову пепелом и признал бы наличие г...кода - но симптомы не слишком похожи.

Если бы он тормозил всегда - вопросом бы не было.
Но после перезапуска служб в течение часа-полутора - он летает.

Я бы успокоился если бы речь шла о тупо повышении нагрузки засчет входа пользователей - но если службы перезапустить часов в 11-12 - все равно час другой они быстро проводятся - а потом снова начинают тупить

(34) Ну пока была файловая - летала только в путь

(36) Фиксировать один рабочий процесс на сервере пробовал?

Блин я теперь вообще понимать все перестал.

Сегодня днем попробовал - перезапустить сервер 1С, не трогая сервер  СКЛ - реакции 0.
Перезапускаю СКЛ - оперативка освобождается и все более менее работать начинает.

То есть походу СКЛ все таки свопиться - но блин вся база весит 4 гб - зачем он свпоиться - не понимаю

Ну попробуй ограничить sql-серверу память..

(38) Не путай размер быза и размер оперативки, которая отжирается для работы с этой базой - это совершенно разные вещи.

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

(40) * размер быза = размер базы

(40) + Я так и не увидел сколько активных пользователей сидят в 1С + что они делают?

(38) [зачем он свпоиться - не понимаю]
в гугл не смотри
счётчики не поднимай

(39)  Ограничил - 12 гб - еще на прошлой неделе
(40)  Да это то понятно, что отожрать СКЛ может и больше чем сама база. Не понятно почему он вместо того, что бы освобождать оперативку - начинает походу свопиться.
Битность сервера и СКЛ сервера - 64.
Пользователей 20-25.
10 активно бьют документы.
Остальные 10-15 формируют отчеты

(43) Не понял

(44) И кстати, если юзаете "бухия 3.0", то в каком режиме работаете (Толстый клиент, тонкий, веб)?

(45)  - тонкий.

(45) разницы не заметил, но для порядку юзаем тонкий в терминале

(47) Тонкий лучше без терминала

(47) Ну вроде как эти новые конфу лучше работают под тонким...и без терминала.

(49) Не вижу принципиальной разницы.
Да и проблема то по сути концентрируется на сервере БД.

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

А терминал с Сервером БД через Гигабит все таки общаются

(38) Сколько съедают все процессы в системе? Проверь еще раз ограничение по памяти в SQL Server. Могут застревать плохие планы запросов, попробуй обновлять статистику раз в день.

(50)
Ну а разницу между 15*i3 vs 2*Xeon видишь ?

Точнее реально
1*Xeon vs 25*i3

(52) разницу вижу. Аналогии не вижу.

Если бы речь шла о просто тормозах - тогда понятно.
Но проблема в _замедлении_ работы.

Ну и кроме того и СКЛ и Винда все таки 64 битные

(53)  Это про клиентов. Не сообразил сразу.
Ну если бы там i3  стояли. а то там все больше селероны и пентиумы 2003-2005 г.в.

и сравнение 2 Хеон 5660  2.8 Ггц  ( учетом многоядерности и НТ) получается 24 физических и логических ядра с 25 станциями 10 летней давности - не факт, что в пользу последних. и это не учитывая еще ЛВС. которая тоже в массе своей отнюдь не гигабитная

(55) плюс опять же я когда вчера проверял сервер 1С - выгнал всех и кассир вообще одна на сервере работала - даже 1 пока работала - тормозило. И заработала только после того как службу скл рестартанул.

(56) Что-то у вас странное. В настройках mssql грязными руками не ковырялись? По умолчанию он работает вполне прилично. Надеюсь, автошринк у вас не включен?

+(57) Должно быть включено автоматическое обновление статистики для вашей базы и для TEMPDB, но отключено асинхронное обновление статистики.

(57)  только план обслуживания по 1С рекомендациям
и память ограничил по (5)
(58)  так и стоит

параллелизм на скуле = 0 ? счетчики по очередям и прочее когда смотреть начнешь?