Имя: Пароль:
1C
1С v8
Степени параллелизма в MS SQL Server
0 BigShmax
 
19.11.13
12:02
подскажите  как отреагирует SQL
=0  это полное распараллеливание как я понимаю. =1 - наоборот выключено распараллеливание.

а как отдать например половину  или  четверть  из 32 ядер ?
если я укажу =16  будет два ядра на один запрос или наоборот половина?

Задача.  есть расчёт себестоимости при = 0 считается 4-7 часов  но из низ около 3 часво никто работать не может.  при =1  вот уже 13 часво считает  запросами занято одно ядро и конца края нет.  хочу выставить показатель так  чтобы половина  распараллеливание шло на половину ядер.
1 ДенисЧ
 
19.11.13
12:03
ну так выставляй и экспериментируй
2 Maxus43
 
19.11.13
12:07
http://technet.microsoft.com/ru-ru/library/ms188611(v=sql.105).aspx

думаешь это что-то решит?
>>при = 0
это дефолт, сервер сам определяет паралелить и на сколько или нет
3 BigShmax
 
19.11.13
12:08
я проверю.  в будущем  просто запросы сменяюмся медленно. :-)   текущий длится уже час.  и если  когда он таки просчитается  и следующий  займёт половину ядер будет супер.  займёт два ядра будет плохо :-)
4 BigShmax
 
19.11.13
12:09
(2)  = 0  это супер  но   три часа перерыва в работе БД это много. я готов его держать в нуле и только на расчёт 1-3 раза в месяц выставлять ручками в другое значение мне сейчас нудно понять  какое  4 или 16 например
5 Maxus43
 
19.11.13
12:09
(3) почитай сначала внимательней что значит этот параметр. Это нифига не то что он записывает данные в 2 или больше потокой или читает. Только некоторые операции можно распаралелить
6 BigShmax
 
19.11.13
12:10
а за ссылка спасибо ушёл читать.
7 BigShmax
 
19.11.13
12:14
(5) ну у меня  есть яркий пример.  при  = 0   расчёт себестоимости занимает все 32 ядра на SQL сервере на 3-4 часа.   на какие то попытки  что нить с ним сделать отзывается еле еле  соотвественно. потому что процессорная мощность ниже планки 100% не падает часами.   при  = 1  только одно ядро занято на 100% остальные отдыхают. и расчёт  идёт себе параллельно никому не мешает но боюсь  что времени уйдёт на него чуть ли не в 32 раза больше.  т.е. имея  опыт наблюдений  с  значениями выставленными в ноль или единицу  параметр ведёт себя именно как распараллеливание.
8 Sorm
 
19.11.13
12:15
(0)http://technet.microsoft.com/ru-ru/library/ms181007(v=sql.105).aspx

Ставь 0, дашь нагрузку на оптимизатор, зато сервер сам определит, сколько ему нужно процессоров. В чем может быть беда (иногда) - в том, что издержки на построение плана запроса при параллелизме могут быть больше, чем построение плана запроса без него.
9 Sorm
 
19.11.13
12:16
(7) Что-то мне подозрительна такая нагрузка... Размеры базы каковы? С индексами, со статистикой все в порядке?
10 BigShmax
 
19.11.13
12:17
(8)  как мне ещё обяснить что при занчении выставленном в ноль  я полностью блокирую работу в БД других пользователей.  и в нормальной работе  этот показатель у меня в нуле  НО при себестоимость мне параметр надо менять.   чтобы около 50 %  ушло на себестоимость а остальное пользователям.
11 Maxus43
 
19.11.13
12:19
(7)(10) этот параметр не является истиной, оказыванет влияние на блокировки и производительность только косвенно, в зависимости от конкретного случая, проблемы с производительностью решаются комплексно обычно, а не тим параметром
12 Maxus43
 
19.11.13
12:22
>>чтобы около 50 %  ушло на себестоимость а остальное пользователям.
параметр к этоу не имеет отношения
13 BigShmax
 
19.11.13
12:24
(11)(12)  спасибо.
14 Sorm
 
19.11.13
12:25
(10) http://technet.microsoft.com/ru-ru/library/ms189094(v=sql.105).aspx Чеж непонятного?... Но не жди прямой корреляции, не жди.
15 Sorm
 
19.11.13
12:28
(0) На небольших базах 1С (<20ГБ) всегда ставлю серваку 1. Проверено неоднократными опытами. Затраты на параллелизм там всегда больше, чем на работу без него.
16 BigShmax
 
19.11.13
12:29
(14)   прямая корреляция это фантастика  не жду. :-)   главное  что я понимаю  что с моим  кол-м ядер нуждно указать  примерно их половину.   кстати ссыла  из (14)  не прямо но опровергает (11)(12)  :-)  Хоть   авторитет  автора для меня заоблачен.
17 Sorm
 
19.11.13
12:33
(16) Ты их выделишь для параллелизма, а вот будут ли они параллелить...:) Читай внимательно ссылку из (2)...
18 BigShmax
 
19.11.13
12:33
(15)  БД под 300 гиг всего . но если убрать огромные регистры себестоимости и хранилище  то около 200.
19 BigShmax
 
19.11.13
12:34
(17) судя как они параллелились при значении 0  до и  при значении 16 будут - куда им деваться
20 capitanjack1
 
19.11.13
12:38
Долго проводится не из за SQL сервера, причина невозможности скорее всего в блокировках. Чтобы быстрей работало проведение нужно смотреть настройки сервера 1С рабочие процессы, может быть увеличивать процессорную мощность самого сервера.
21 Sorm
 
19.11.13
12:39
(20) Если копать в эту сторону, то возникает вопрос - а tempDB где находится?
22 Maxus43
 
19.11.13
12:44
да хоть на 20 потоков "распаралель" - если возникнет блокировка то пользователи всё равно не смогут работать, а если мы говорим о РСВ - там задействоаны почти все объекты важные конфы, естетсвенно блокировки. РСВ - регламентная операция, мы на ночь ставили просто частенько
23 BigShmax
 
19.11.13
12:48
(20)(21)  занято именно процессорное время на sql сервере.  сервер 1с при расчёте отдыхает.  SQL  с дисков почти ничего не пишет и не читатет.   tempDB  на SSD ? но повторюсь - занято процессорное время.  себестоиомсть самопал.
24 BigShmax
 
19.11.13
12:48
(22) блокировок нет.   время рассчёта не зависит от монопольного или разделённого режима
25 ansh15
 
19.11.13
12:49
(18) Сам сервер есть возможность более подробно описать?
Я так понимаю это он v8: конфигурируем новый SQL сервер ?
26 BigShmax
 
19.11.13
12:51
(25) в общем да.  система на рейд 1.  дата на рейд 0 6 штук SAS 15000   ldf на рейд0  и  tempdb на SSD .   но  я   еще  разок повторюсь  занят процессор  и более никто
27 ansh15
 
19.11.13
12:55
(26) А процессоры с памятью что из себя представляют? Гипертрединг включен/выключен, турбобуст как себя ведет?
28 senior
 
19.11.13
12:56
(7) "параллельно, никому не мешая"? А с блокировками проблем нет? (и скока размер базы? РАУЗ?)
29 Sorm
 
19.11.13
12:57
(26) Реиндексация, update stat - нормально все с этим?
30 Reaper_1c
 
19.11.13
13:00
(0) В течении этих 3-х часов видимо происходит запись в регистры учета затрат. На работу пользователей загрузка процессоров не должна влиять так, чтобы они совсем остановились - скорее здесь идет столкновение на блокировках. Разумнее будет датами запрета редактирования заблокировать всем пользователям работу в периоде, за который ты выполняешь расчет и запустить его вне транзакции. А перед запуском - отключи итоги на регистрах затрат, включишь после успешного расчета. Таким образом ты риск столкновения на блокировках значительно уменьшишь.
31 BigShmax
 
19.11.13
13:02
не блокрирвоки  .  скорость расчёта в монопольном не уменьшается не рауз.  время расчёта не проблема  оно изначально было таким. разрабочики не смогли сократить время удовлетворив  всех потребностей руководства.  проблема не в скорости расчёта  а как заставить SQL отдавать много процессорного времени но не всё.
32 BigShmax
 
19.11.13
13:02
регламенты с базами выполняются конечно же.
33 Reaper_1c
 
19.11.13
13:04
(31) Если это не блокировки - расшифруй фразу "никто работать не может"?
34 BigShmax
 
19.11.13
13:06
про HyperThreading не скажу :-(   где посмотреть?  и  в каком положении он должен быть?
35 BigShmax
 
19.11.13
13:07
(33) как Вы думаете   как  весело кому то работать если занятость ядер ВСЕХ не падает ниже 100% на протяжении часов? т.е. они заняты. у меня  проводник минуту открывается потому что тупо  процы заняты.
36 ansh15
 
19.11.13
13:50
(34) Модель процессора и сколько их установлено в сервер скажите. И сколько памяти(если не секрет).
В BIOS материнской платы сервера.
37 Maxus43
 
19.11.13
13:58
никогда не видел чтоб узкое место было - процессоры. расходы на чтение-запись данных, очереди сети на порядки превышают обычно процессорное время
38 Sorm
 
19.11.13
14:00
(37) Крайне большое количество мелких запросов при максимальном параллелизме - может быть... Обрати внимание на (23) "себестоиомсть самопал."
39 Reaper_1c
 
19.11.13
14:01
(35) Так у тебя, что терминальный сервер совмещен с СУБД?
40 Maxus43
 
19.11.13
14:02
(38) тогда скорее всего справедливо будет "90% тормозов находися в коде"...
41 Sorm
 
19.11.13
14:18
(40) Согласен.
42 BigShmax
 
19.11.13
15:12
(39)  процессоры  ссервера  СУБД заняты на 100%  им не до ваших запросв  и именно поэтому невозможно работать.
43 andr_andrey
 
19.11.13
16:29
(42) У вас NUMA архитектура с 4 процессорами по 8 ядер в каждом? Тогда следуйте рекомендациям http://support.microsoft.com/kb/2806535