Есть бухня последняя редакция 3.
Размер 10 гиг.
Перенесена была на SQL (сервак тотже служба 64 битная).

Начала медленней работать с раза 3 (наоперациях типа проведение реализации товаров и услуг).
Если сравнивать с файловой то при проведении процесс SQL сервера (sqlservr.exe) нереально сжирает проц, причем сразу по всем ядрам (на некоторых опирациях даже упирается в потолок типа "закрытие месяца", а иногда в потолок уходит только одно виртуальное ядро).

Делал тестирование, операции на SQL (Построение индекса, статистика и остальное стандартное), но ничего не поменялось.

У кого какие мысли есть?

(0) ты 100500 , кто открыл это - поздравляем

а кто сказал,что скуль дает скорость?

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

(2) Да я вкурсе что быстрее будет SQL при одновремеено работающих 10-15 пользователей и более.

Тут я через ТекущаяУниверсальнаяДатаВМилисекундах посмотрел, там разница даж поболее чем в 4 раза

(4) неа не будет

(3) Да админ не вкурсах, по инструкции наверно SQL поставил, с параметрами поумолчанию и все.
Пробывал 2 разных платформы (обе 8.3.5).

А какие замеры ты имеешь ввиду конкретно?

(5) Ты уверез? тоесть берем один и тотже сервак и сравниваем SQL и файловую на 25 пользователях?

(6) http://v8.1c.ru/overview/Term_000000607.htm
ТЖ
SQL Profiler
(7)скуль именно для работы большего кол-ва пользователей,а не для скорости

(7) 25 юзеров одновременно на файловой?

https://www.google.ru/search?as_sitesearch=forum.mista.ru&q=%F2%EE%F0%EC%EE%E7%E8%F2+%E1%EF&gws_rd=ssl

(9) Это я к примеру

(8) сравни для ДВУХ пользователей скорость 1с:документооборот с включённым и настроенным RLS, скуль уделает файловую в пух и прах....

(0) для начала настрой регламент скуля (обновление статистики, реиндексацию и т.д.)

(13) сделанно, яж писал

(14) я не увидел... обновление статистики сколько раз в день делается?

(0) Пять копеек добавлю - начиная с 2005 скуля есть очень приятная фишка  в плане связывания  работы железа и скуля . Можно настроить   счетчики производительности железа  с  сохранением в XML и это дело  наложить на трассу профайлера скуля   . Как то так . На выходе показывает  динамику работы железа в процессе выполнения инструкций сервера СУБД .

(14) Для оптимизации запросов статистика должна накопиться, нужно делать ее как можно чаще, + продувку кэша.

+(16) Собственно
https://msdn.microsoft.com/ru-ru/library/ms191152.aspx

(17) Ну настроен план, в нем и индекс и статистика и продувка кэша, делается раз в день, но сегодня ручками 2 раза ещё дополнительно делал

(19) Параллелизм как настроен?

(20) + Виртуалка? Памяти сколько в процентах скулу?

тогда http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

(21) у тебя-то как? лучше?

(21) Не не виртуалка, памяти ему указал до 20 гигов позволено (всего 32).

(20) Поподробней

(20) По скулу слушай vde69

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

(25) Параллелизм как раз раздает нагрузку ядрам, по советам надо ставить в ноль.

(28) Это в настройка инстанса?

(28) Там вроде в 0 установленно "Максимальная степень паралелизма"

(29) Завтра если надо отпишусь точно, под рукой нет скула, а так выставление этого параметра - основа. Можно загуглить.

(30) А, ну тогда (22) потом подскажут что не так.

(32) + только при нагрузке (работающих пользователях).

(30) 0 - это говорит о том, что скул сам распределяет по ядрам, попробуй 1, только отпишись как это повлияло.

(33) Блин я уже запустил после 18, нет там никого, выполняется уже более 50 минут. Что отменить?

(34) Ок ща попробую

(35) Я тоже на это поймался ). 300 минут это будет длиться.

(37) Не переживай, в оконцовке получишь данные, опытные люди тебе подскажут.

(33) + на это обрати внимание, вечером вряд ли много пользователей.

(34) Жесть проводка документа стала в 15 раз дольше (потолок то у одного ядра то у другого)

(40) Давай соберем данные по (32) , потом спросим совета. А пока, верни все назад ), хотя многие советуют в 1 ставить.

(41) Да уже вернул, а то пипец, по 34 секунды ждать пока проведеться реализация))) (так хоть около 3 секунд)

Ладно запрос тогда я вырублю завтра включу в часиков 11 тогда, там потом что с результатом делать, тебе показать?

(42) Есть тут спецы, не переживай -помогут, у меня тоже проблемы с этим, см. ветку Конфликт блокировок при выполнении транзакции.

(43) vde69

(42) Кстати 3 сек - это ниче, норм.

(17)(19) продувка кэша? о_0.. компрессором чтоли от пыли продуваете?

(46) Да 3 сек эт если один и тотже док проводить несколько раз на раз третий (а если первый раз то до 5 доходит)

(47) Неа - "Рот в рот"

Скрипты запустил?

(50) не пока, хотел в 11, чтоб наверняка, а то сутра наверно поя чаи пьют бездельничают

(50) Есть результат

(52) Выложи, кто знает подскажет, я сам просил помощи с результатом ))

http://dropmefiles.com/fxabC весь файл.

ниже верхушка до 0.0 значений

ТИП             Время           Проценты  
***total***    237431661.0    100.0
CXPACKET    19694386.0    8.3
CHECKPOINT_QUEUE    18471698.0    7.8
HADR_FILESTREAM_IOMGR_IOCOMPLETI    17950654.0    7.6
DIRTY_PAGE_POLL    17949840.0    7.6
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    17937080.0    7.6
LAZYWRITER_SLEEP    17948820.0    7.6
LOGMGR_QUEUE    17949804.0    7.6
REQUEST_FOR_DEADLOCK_SEARCH    17949088.0    7.6
XE_TIMER_EVENT    17949812.0    7.6
XE_DISPATCHER_WAIT    18001112.0    7.6
FT_IFTS_SCHEDULER_IDLE_WAIT    17823228.0    7.5
SP_SERVER_DIAGNOSTICS_SLEEP    17700750.0    7.5
SLEEP_TASK    8983109.0    3.8
BROKER_TO_FLUSH    8974967.0    3.8
LATCH_EX    1843205.0    0.8
BROKER_TASK_STOP    180230.0    0.1
SNI_TASK_COMPLETION    0.0    0.0
SNI_LISTENER_ACCESS    0.0    0.0

Так удобней смотреть

Проценты    Врем    Тип
100.0    237431661.0    ***total***
8.3    19694386.0    CXPACKET
7.8    18471698.0    CHECKPOINT_QUEUE
7.6    17950654.0    HADR_FILESTREAM_IOMGR_IOCOMPLETI
7.6    17949840.0    DIRTY_PAGE_POLL
7.6    17937080.0    SQLTRACE_INCREMENTAL_FLUSH_SLEEP
7.6    17948820.0    LAZYWRITER_SLEEP
7.6    17949804.0    LOGMGR_QUEUE
7.6    17949088.0    REQUEST_FOR_DEADLOCK_SEARCH
7.6    17949812.0    XE_TIMER_EVENT
7.6    18001112.0    XE_DISPATCHER_WAIT
7.5    17823228.0    FT_IFTS_SCHEDULER_IDLE_WAIT
7.5    17700750.0    SP_SERVER_DIAGNOSTICS_SLEEP
3.8    8983109.0    SLEEP_TASK
3.8    8974967.0    BROKER_TO_FLUSH
0.8    1843205.0    LATCH_EX
0.1    180230.0    BROKER_TASK_STOP
0.0    0.0    SNI_TASK_COMPLETION

(55) Удобней, но лучше скрин на первые позиции ))

http://prntscr.com/6kse2w

(57) Наверное не знают, думают.

--------------------------------------
первые две позиции показывают на плохой план запроса, тут три варианта

1. самое простое - статистика кривая, все рекомендации уже были.

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

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

--------------------------------------

можно не учитывать
DIRTY_PAGE_POLL
HADR_FILESTREAM_IOMGR_IOCOMPLETION
PREEMPTIVE_OS_PIPEOPS
LAZYWRITER_SLEEP

остальные надо смотреть...

(0) из-за (59) начинай с простого  обновление статистики почаще.

(60) Да хрен его знает, вчера делал так 3 раза почти подряд, эфекта 0

Ты (0) подожди шашкой рубить. Ты запусти на сервере монитор ресурсов и посмотри что за процесс ест эти ресурсы. С вероятностью 99% это будет НЕ SQL. Я уверен, что ресурсы жрет Сервер1С предприятия и менеджер серверов 1сПредприятия.
  В файловом режиме программа работает без этих поделок от 1с. И поэтому не сильно тормозит. С переходом на SQL вы вынуждены использовать эти программы с их развитой системой кеширования, на которую и тратятся все системные ресурсы.
  Вариант ускорения - использование SSD дисков (что снимает проблему кеширования), отключение гипертрейдинга на сервере (это снимает проблему однопоточности приложения сервер1сПредприятия), разнесение сервер1сПредприятия и RDP server на разные компы.
   После этого готовьте вазилин и насладжайтесь.

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

(62) Да наблюдал я в диспетчере задач, подскакивает именно SQL, особенно заметно было что именно он когда с многопоточностью игрался

(63) Когда я игрался с УТ11 с номенклатурой порядка 40 тыс. То постоянная картина, которую я видел в мониторе ресурсов - это загрузка процессора 25%. Когда был включен гипертрейдинг то загрузка была 12.5%. При этом 25% съедал либо сервер 1С предприятия либо Сервер1 1с предприятия на пару с менеджером кластера.
  Примерно через трое суток работы Сервер1С и менеджер кластера начинали жрать свои законные 25% процессорной мощности вообще без ЛЮБОЙ НАГРУЗКИ. Т.е. соединений с Сервером1С нет, фоновых заданий нет, а нагрузка ЕСТЬ. Только ручная остановка и запуск Сервер 1С останавливали пожирание мощностей.
  Из этих наблюдений я сделал вывод о больших проблемах с многопоточностью и с работоспособностью х64  версий 1С.
  К SQL вопросов вообще не было. SQL работает вполне адекватно и жрет что положено

(0) Руки программистов.
Руки разработчиков платформы.
Руки Администраторов.
Жадность владельца на нормальное железо.

...И как бы причем тут SQL?...

(66) Я хочу понять почему он так себя ведет, я больше чем уверен что SQL вещь гораздо продуманей чем 1С.