gifts2017

Тестирование SQL проблем

Опубликовал Дмитрий Воробьев (vde69) в раздел Программирование - Инструментарий

Предназначена для выявления статистики ожидания блокировок и транзакций.
Вещь крайне полезная!

НЕ МОЯ!!! Думаю, можно плюсовать, а то теряется она на просторах, а ведь реально - стоящая вещь
(а еще лучше писать сюда, насколько удалось улучшить систему)

Скрипт выполнить в Мастерс, потом вызвать созданную ХП

Спасибо Schtass за ссылку для расшифровки результатов
http://www.sqldev.net/misc/waittypes.htm

Спасибо artbear за расшифровку результатов на русском и в более полном варианте
http://msdn.microsoft.com/ru-ru/library/ms179984.aspx

Скачать файлы

Наименование Файл Версия Размер
- 1160
.1225980665 3,10Kb
22.08.14
1160
.1225980665 3,10Kb Бесплатно

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Василий Демидов (Душелов) 06.11.08 21:24
2. Дмитрий Воробьев (vde69) 06.11.08 21:34
to 1, эта для конкретной базы, а в САБЖ-е для сервера в целом (пофигу сколько и каких баз).

кроме того в САБЖЕ анализ шире, по сколько анализируеться на сами блокировки и не запросы а системные счетчики
3. Василий Демидов (Душелов) 06.11.08 21:41
Скрипт толком не рассматривал. Тут же дело в том, что 1С-ка не использует SQL, как положено... А так... В качестве хранилища данных... Но посмотреть стоит...
4. Дмитрий Воробьев (vde69) 06.11.08 21:47
to 3
так в этом и весь прикол, этой ХП пофиг как работаешь, она показывает статистику, и на основании статистики можно оптимизировать не только саму 1с, но, что самое главное всю систему под РЕАЛЬНОЙ нагрузкой, учитывая и скорость работы клиентов и дисков и т.д.
Эта ХП позволяет найти слабые стороны САМОГО SQL СЕРВЕРА
5. Schtass (sCHTASS) 07.11.08 09:37
А не могли бы сказать неискушенному в серверах, где бы можно посмотреть расшифровку полученного результата? Желательно на руссоком языке.
6. Дмитрий Воробьев (vde69) 07.11.08 09:49
в гугл вбиваешь и читаешь,
ну если на английском, но у мелкомягких
7. Никита Сасов (n) 07.11.08 11:18
Чесно говоря несколько не ясна поль за от такой статистики:

***total*** 3194903351.0 100.0
OLEDB 3175652096.0 99.4

Ну вижу я что OLEDB занимает 99% а дальше чего?

8. Дмитрий Воробьев (vde69) 07.11.08 11:38
to 7
не то смотришь, или активности нету...

бывает всякая фигня, типа "PAGEIOLATCH_SH" и т.д.

запускать надо на рабочем сервере в рабочее время на длительноое время (я рекомендую 4-6 часов)
9. Василий Демидов (Душелов) 07.11.08 11:45
Решение оформлено не правильно. Надо обработочкой для 7.7 и 8.х с 1 кнопкой - исправить ;)
10. Дмитрий Воробьев (vde69) 07.11.08 11:52
to 9
я не претендую на полное решения, я написал, что не мое и просил не плюсовать.
решение преднозначено для оптимизации SQL сервера, а не конкретных баз, по этому я считаю, что все нормально.

а про 1 кнопку - это только вред, интересно, что будет делать тупой пользователь с результатами? да и права SA нужны
Noy; Душелов; +2 Ответить
11. Schtass (sCHTASS) 07.11.08 12:36
12. Дмитрий Воробьев (vde69) 07.11.08 12:50
to 11

спасибо, то, что нужно
13. Никита Сасов (n) 07.11.08 14:05
to 8 вообще то сервер самый что ни на есть рабочий и пользователей штук 50 на нем есть и замеры 5 часов делались.
14. Дмитрий Воробьев (vde69) 07.11.08 14:12
(13) по ссылке в (11)

Сервер SQL ждет ответа клиента, чтобы послать данные

короче долгий отклик приложений, то есть он типа все сделал и ждет когда клиент заберет данные.
думаю все очень понятно!
15. Никита Сасов (n) 07.11.08 14:23
to 14, ага спасибо уже почитал
16. Дмитрий Воробьев (vde69) 07.11.08 14:25
to 15
вот так и понимаешь, что в тормозах сам скуль не виноват :)
напрягай админов, пусть это показатель сокращают до 10-20%
17. Альтаир (Altair777) 07.11.08 14:41
(0) НЕ МОЯ!!! просьба НЕ плюсовать
За такую фразу так и хочется плюсик влупить :-)
18. Дмитрий Воробьев (vde69) 25.11.08 10:17
я передумал, можете плюсовать :)
причина простая, теряеться она среди прочих пустых вещей, а ведь нужная вещь
19. Артур Аюханов (artbear) 25.11.08 13:07
Расшифровка результатов на русском и в более полном варианте
http://msdn.microsoft.com/ru-ru/library/ms179984.aspx
20. Дмитрий Воробьев (vde69) 26.11.08 16:21
добавил картинку (что-бы народ понимал, что за фиговина такая)
21. gilv (Gilev.Vyacheslav) 10.12.08 01:38
(2) функциональнось полностью перекрывается обработкой из (1)
если думаешь, что не так, то смотри код обработки :)
22. Дмитрий Воробьев (vde69) 10.12.08 09:43
(21) обработка в (1) хороша инужна, но по моему это разные вещи

1. если у огранизации совсем нету 8.1 ????
2. если административные установки не позволяют пользоваться SWbemLocator
------------следующие пункты ИХМО (могу заблуждаться)---------------
3. реализованы далеко не все виды счетчиков
4. как я понял в (1) результаты счетчиков выводяться для конкретной базы ("SELECT * FROM "+БазаДанных+".dbo.View_Lock_W") а в САБЖе для сервера в целом
23. gilv (Gilev.Vyacheslav) 10.12.08 13:52
(22) рекомендую другие закладки посмотреть, прежде продолжим обсуждение
24. gilv (Gilev.Vyacheslav) 10.12.08 13:53
в настоящее время обработка развивается "в закрытом" режиме, например умеет находить и строить отсутствующие индексы в субд
25. Barmolei (Barmolei) 15.12.08 15:06
А под IBM DB2 будет работать?
26. gilv (Gilev.Vyacheslav) 16.12.08 06:35
(25) пока на практике таких заказчиков не было, но если появяться, то почему нет
27. Дмитрий Елисеев (w-divin) 29.06.09 17:01
вот чего-то не допонял...
из QA: CXPACKET 949831.0 53.2

"CXPACKET
Имеет место при попытке синхронизации итератора обмена обработчика запросов. Можно попытаться снизить степень параллелизма, если конфликты такого типа становятся проблемой."
это шо за ?

а этого: NETWORKIO 96863.0 5.4
вообще в табле не нашел (((
28. Дмитрий Воробьев (vde69) 29.06.09 17:04
CXPACKET
Имеет место при попытке синхронизации итератора обмена обработчика запросов. Можно попытаться снизить степень параллелизма, если конфликты такого типа становятся проблемой."
это шо за ?

в настройках SQL в свойствах параллелизма ставь 1 (а у тебя скорее всего там 0)


NETWORKIO - ожидание клиента
29. Дмитрий Елисеев (w-divin) 29.06.09 17:13
(28) нашел:
"CXPACKET
Parallel process waits. Possible skew of data possible lock of a range for this CPU, meaning that one parallel process is behind, etc.
Check for parallelism using sp_configure 'max degree of parallelism'.
If max degree of parallelism = 0, you may want to do one of the following:
· Turn off parallelism by setting max degree of parallelism to 1
· Limit parallelism by setting max degree of parallelism to less than the total number of CPUs. For example, if you have 8 procedures, set max degree of parallelism to 4 or less."
стоял действительно 0 )))
поставил на 4 пока - потестю )))
спасип )))
30. Дмитрий Елисеев (w-divin) 29.06.09 17:14
ЗЫ поставил на 4 потому как CPUs 2*4core )))
31. Дмитрий Воробьев (vde69) 29.06.09 17:16
(30) включи поддержку 4х ядер, но параллелизм ставь 1
32. Дмитрий Елисеев (w-divin) 29.06.09 17:37
вот теперь таки выползло:
NETWORKIO 9577.0 85.8
из SQLDEV.NET:
"NETWORKIO
Waiting on network I/O completion. Waiting to read or write to a client on the network.
This can occur if a client is in the middle of sending packets to SQL Server, or when SQL writes data to a client and is waiting for an ACK.
Check bandwidth of your network interface card. 100 mbits is preferable to 10 mbs."
а откуда оно если и 1С и скуль на 1 машине в терминале?
33. Дмитрий Елисеев (w-divin) 29.06.09 17:42
(1)
а она фунциклирует если нет сервера предприятия 8???
к скуль-серверу подключается, а при попытке "подготовить к мониторингу"
Форма.Форма(388)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near '('.
RecSet.Open(Query,SQLServer,3,1,1);
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near '('.
34. Дмитрий Воробьев (vde69) 29.06.09 17:53
(32) вот теперь вы видишь, что или сама сеть или клиенты тормозят. Админов напряги пусть уменьшают до 5%
35. Дмитрий Воробьев (vde69) 29.06.09 18:01
(32) у тебя SQL и терминал на ОДНОЙ???
какие настройки сервера ? на службы или на приложения?

вообще на 1 машине их НЕЛЬЗЯ ставить
36. Дмитрий Елисеев (w-divin) 29.06.09 18:02
(34) концовку пропустил:
"а откуда оно если и 1С и скуль на 1 машине в терминале?"
37. Дмитрий Елисеев (w-divin) 29.06.09 18:04
(35) угу - на 1й ((((((((((((( на вторую денех не дають )))
по поводу "нельзя ставить": если очень нужно, то можно )))) выхода то нету )))
настройки и проц и память на приложения...
38. Дмитрий Воробьев (vde69) 29.06.09 18:10
у тебя вероятно на терминал памяти не хватает, ограничивай скуль, и в сесиях смотри кто сколько жрет... патч от ромикса поставь на 100% загрузку, дальше будет видно.

запусти виндовые счетчики... короче нужно
1. уменьшить по максимуму все в сесиях, почту/аськи/офис/интернет - все в топку
2. пытаться сбалансировать распределение ресурсов
39. victor smolin (croco) 31.08.09 21:00
кто-нибудь знает какое желаемое распределение процентов по задержкам должно быть (ведь уменьшая простои по одному типу будут расти простои по другим типам) ?
40. Дмитрий Воробьев (vde69) 31.08.09 22:23
(39) во первых уменьшая одно у тебя должно уменьшаться Total

во вторых все должно упираться в дисковые операции и они должны быть более менее симетричными (например write-25% writeLog-30%, остальное частями не более 10%),
это конечно мое личное мнение, кто-то считает по другому, но я считаю раз HDD самая медленая деталь в компе, то упираться должно в нее...

можно конечно пытаться упереться в загрузку CP, но при современных многоядерных серверах это не реально :)
41. victor smolin (croco) 01.09.09 12:57
(40) Выполнил тестирование на продуктовых серверах.
Вот результаты:

Сервер 1 - Одна 10G база под сайт (1Gbit канал с веб-сервером, трафик не более 800 kBit/s)
***total*** 1653620.0 100.0
OLEDB 546265.0 33.0
LAZYWRITER_SLEEP 540000.0 32.7
SQLTRACE_BUFFER_FLUSH 540000.0 32.7
SLEEP_TASK 14640.0 .9
CXPACKET 5484.0 .3
LCK_M_IS 2781.0 .2
SOS_SCHEDULER_YIELD 1000.0 .1
MSSEARCH 1250.0 .1
MSQL_DQ 859.0 .1

Сервер 2 - 10 сателитных баз (от 1G до 10G)
***total*** 2760902.0 100.0
CXPACKET 974218.0 35.3
PAGELATCH_EX 593562.0 21.5
LAZYWRITER_SLEEP 541000.0 19.6
SQLTRACE_BUFFER_FLUSH 540000.0 19.6
EXECSYNC 82468.0 3.0
LCK_M_IX 28531.0 1.0

Верны ли следующие выводы:
1) производительность сервера 1 притормаживается web-сервером.
2) оптимизировать запросы на втором сервере:
- искать запросы с параллельнымми планами выполнения
42. Дмитрий Воробьев (vde69) 01.09.09 13:26
по 1 серверу:
LAZYWRITER_SLEEP, SQLTRACE_BUFFER_FLUSH - это трассировки и прочие средства отладки, на рабочей базе их надо отключать на время когда они не нужны

OLEDB - это уже от веб сервера, на нем нужно сократить транкзации, как я не знаю (надо смотреть всю систему в целом).

по 2 серверу
CXPACKET - поставить параллелизм в 1
PAGELATCH_EX - это от кода зависит, вероятно какието ручные блокировки
ну и отладку SQL отключить

43. victor smolin (croco) 01.09.09 13:40
(42) спасибо. будем пробовать
44. Ярослав Юнка (y22-k) 07.09.09 16:07
Подскажи пожалуйста в ссылках ничего толкового не нашел

Сервер 3 базы 2 по 8 ГБ 1по 1 ГБ
Оперативки 8 ГБ
4 процессора по 2ГГрца
но 1ска УТ все равно тормозит и ругается на транзакции
статистика обновляется раз в 4 часа и реидексация стоит еженощно

MISCELLANEOUS; 17950296.0; 30.9
LAZYWRITER_SLEEP; 17948828.0; 30.9
SQLTRACE_BUFFER_FLUSH; 17912500.0; 30.8
LCK_M_IS; 1553453.0; 2.7
LCK_M_IX; 711812.0; 1.2
SLEEP_BPOOL_FLUSH; 425031.0; 0.7
45. Ярослав Юнка (y22-k) 08.09.09 12:28
конкретно что такое MISCELLANEOUS; 17950296.0; 30.9
46. Дмитрий Воробьев (vde69) 08.09.09 13:34
(45) я не знаю, у тебя какой сервер? (ведь не 2000!) ищи в MSDM на сайте мелкомягких.

Могу только предположить, что это какие-то теневые операции скуля (тригеры, репликации с другой базой и т.д.)
47. Ярослав Юнка (y22-k) 08.09.09 15:13
48. Павел (pavel_tr) 16.09.09 15:33
Имеем 1С-базу 30 Гб, 25-30 активных пользователей, связку терминального и SQL-сервера по гигабитной сети. Конфа SQL-сервера: PentiumD 3,4 GHz, 4 GB RAM, массив RAID5 на контроллере Adaptec 2130S из 5 дисков SCSI 10 000RPM Fujitsu. Используем SQL 2005 WorkGroup Edition. Всё это добро в последнее воемя тормозит, блокировки журнала очень часто (по 5-10 секунд).
Делал замер производительности по счётчикам винды: загрузка проца средняя 60%, в пиковые моменты - 100. Средняя длина очереди диска - 200 (максимальная больше 1000), в основном очередь на запись, счётчик очереди по чтению поменьше. SQL использует 3 гига памяти

Делал замеры, помогите интерпретировать результаты:

wait type; wait time; percentage;

LAZYWRITER_SLEEP; 3545453.0; 63.1;
CXPACKET; 947578.0; 16.9;
IO_COMPLETION; 286500.0; 5.1;
PAGEIOLATCH_SH; 267906.0; 4.8;
SLEEP_TASK; 193000.0; 3.4;
WRITELOG; 130750.0; 2.3;
LCK_M_X; 77234.0; 1.4;
SOS_SCHEDULER_YIELD; 64703.0; 1.2;
PAGEIOLATCH_EX; 59687.0; 1.1;
49. Дмитрий Воробьев (vde69) 16.09.09 16:02
LAZYWRITER_SLEEP -
Имеет место при приостановке задач средства отложенной записи. Представляет собой показатель времени, затраченного ожидающими фоновыми задачами. Не следует учитывать это состояние при исследовании пользовательских простоев.

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

обычно это бывает из-за бешеного количества "мелких" запросов, например вычисляемая колонка в справочнике



50. Дмитрий Воробьев (vde69) 16.09.09 16:04
кстати, то, что у тебя загрузка ЦП доходит до 100 - то же не гуд, скуль не должен жрать больше 70-80% в пиках
51. Павел (pavel_tr) 16.09.09 16:57
У нас SQL WorkGroup - он больше 3 гиг кушать не умеет =/
Может какие-то скульные счётчики посмотреть чтоб с кэшем удостовериться? Пока грешу на RAID5, т.к. очередь на запись скачет, а он по записи тормозной. Ну и проц бы поменять, думаю.
52. Дмитрий Воробьев (vde69) 16.09.09 17:31
(51) скульных счетчиков нету для этого, копай виндовые для обмена память<->своп

думаю можно посмотреть профайлером в момент пиковой загрузки (просто количество запросов в 1 сек) если их много - то см. (49)
53. Алексей Плутенко (Noy) 21.09.09 18:12
Уважаемый гуру, подскажи!
по тестам из (0) большего всего занимает WRITELOG (от 32 до 45%), на втором месте LCK_M_X (до 30%) - дальше все по мелочам...
Как оптимизировать? Куда смотреть?
База 7.7 25 релиз, SQL 2000 sp4. На сервере 8гб памяти (PAE + AWE), рейд 10 на Sata2 (на нем и база и лог). База <20Гб в режиме Simple.
54. Дмитрий Воробьев (vde69) 21.09.09 19:20
WRITELOG - перенеси лог файл на другой ФИЗИЧЕСКИЙ диск, или райд более быстрый собирай, можно вообще лог отключить, потеряешь возможность востановление в течения дня, зато работать будет быстрее
55. Алексей Плутенко (Noy) 22.09.09 11:34
(54) Я так понимаю первый вариант предпочтительней, но на данный момент для меня не достижимый.
Буду отключать лог (тем более я понятия не имею как с помощью лога что-либо восстанавливать да и бекап ежедневно делаю).
Большое спасибо за совет.
56. Maksim Nabiullin (bluestorm) 07.10.09 09:23
зедсь уже писали что возникла такая ошибка :

к скуль-серверу подключается, а при попытке "подготовить к мониторингу"
Форма.Форма(388)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near '('.
RecSet.Open(Query,SQLServer,3,1,1);
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near '('.

такая же беда... В чем может быть дело ?
57. Владимир Долгушин (Вотс) 16.12.09 10:09
PAGEIOLATCH_EX
Имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося в состоянии запроса ввода-вывода. Запрос на кратковременную блокировку производится в режиме общего доступа. Длительное время ожидания может указывать на проблемы с дисковой подсистемой.
,189171.0,.8 - это много?
58. Максим Шуйский (maxpiter) 26.10.10 12:45
59. idw idw (idw) 11.05.11 18:53
А как этим скриптом пользоваться?
60. Сергей Мурзинов (Sergey_Murzinov) 28.09.11 18:01
Попробовал собрал статиску, интересно. Но тормоза сервера были по другой причине
61. san k (Zdec1) 30.09.11 11:05
База 1с около 130 гб, скл, конфигурации серверов сейчас не могу сказать. за 2,5 часа получил вот такую статистику. Кто что может сказать по этому поводу?

***total*** 18538808.0 100.0
LCK_M_X 5368370.0 29.0
PAGEIOLATCH_SH 4199847.0 22.7
LCK_M_IS 3980967.0 21.5
LCK_M_U 3611659.0 19.5
WRITELOG 385871.0 2.1
CXPACKET 355302.0 1.9
PAGEIOLATCH_EX 336477.0 1.8
LCK_M_S 205544.0 1.1
62. Zoomby Zoomby (Zoomby) 30.09.11 12:20
63. Дмитрий Воробьев (vde69) 30.09.11 19:57
(61) Zdec1,

в целом не так плохо

PAGEIOLATCH_SH - конечно великовата, копай в сторону размеров файловых буферов и их оптимизации

LCK_M_X, LCK_M_IS - весьма характерные блокировки для 7.7 и по моим наблюдения они зависят скорее не от SQL а от скорости каталога с MD и темпов, для SQL версии вообще разумно сделать для этого рам диск.

ИХМО
в конечном итоге самое слабое место SQL - скорость записи лога, WRITELOG должно быть от 10 до 30%
64. san k (Zdec1) 03.10.11 08:59
(63) спасибо, будем копать в эту сторону
65. Igor Александрович (igor_1c) 29.10.11 16:57
Отличная штука, будем пробовать
66. eremin (mybracho) 13.04.12 16:25
(42)
"по 1 серверу:
LAZYWRITER_SLEEP, SQLTRACE_BUFFER_FLUSH - это трассировки и прочие средства отладки, на рабочей базе их надо отключать на время когда они не нужны"


А как отключить это дело ?
67. eremin (mybracho) 17.04.12 18:26
Вот результаты теста, куда смотреть ? где узкие места ? Подскажите, пожалуйста.
Прикрепленные файлы:
Тестирование SQL.txt
68. eremin (mybracho) 27.04.12 17:17
69. Андрей Горенский (gorenski) 14.05.12 08:04
Не забывам комментарии удалять в скрипте, а то ругается:

Msg 102, Level 15, State 1, Line 1
Incorrect syntax near '/'.
Msg 102, Level 15, State 1, Line 4
Incorrect syntax near '/'.
Msg 111, Level 15, State 1, Line 14
'CREATE/ALTER PROCEDURE' must be the first statement in a query batch.
Cannot add rows to sys.sql_dependencies for the stored procedure because it depends on the missing table 'get_waitstats'. The stored procedure will still be created; however, it cannot be successfully executed until the table exists.
70. Алексей Каменец (leshik) 12.07.13 09:07
Что-то не могу скачать скрипт. Премиум доступ оплатил.
71. Вячеслав Гилёв (Gilev.Vyacheslav) 29.11.13 13:14
Более полноценную картину бесплатно можно получить с помощью http://www.gilev.ru/sqlsize/
72. Константин Щербинин (scherbinin) 24.07.16 13:52
Подскажите куда копать:

1С 7.70.027 для SQL

***total*** 213255969 100
XE_DISPATCHER_WAIT 57630092 27
CHECKPOINT_QUEUE 28606900 13,4
SQLTRACE_BUFFER_FLUSH 17944972 8,4
LAZYWRITER_SLEEP 17945744 8,4
LOGMGR_QUEUE 17885276 8,4
REQUEST_FOR_DEADLOCK_SEARCH 17945304 8,4
XE_TIMER_EVENT 17940060 8,4
FT_IFTS_SCHEDULER_IDLE_WAIT 17760364 8,3
SLEEP_TASK 8985282 4,2
BROKER_TO_FLUSH 8973495 4,2
LCK_M_IS 661023 0,3
CXPACKET 443392 0,2
SLEEP_BPOOL_FLUSH 152757 0,1
IO_COMPLETION 137195 0,1


сервер покупался в январе 2012г:
Windows Server 2008R2 Hyper-V
MB Intel S5500BCR
CPU 2 x Intel Xeon E5607 (8 ядер)
RAM 8 x 2Gb = 16Gb
RAID controller = Intel SRCSASLS4I
RAID1 = 2 x Seagate 300Gb ST3300657SS 15000rpm SAS


сервер 1С: виртуальная машина №3
Windows Server 2008R2
CPU 4 ядра
RAM 8Gb
MS SQL 2008
база SQL: 8,1Гб

на данный момент железо наращивать не планируется.
Переход на 1С8 тоже не планируется как минимум год.

Проблема: при переключении окон часто появляется белый экран и висит несколько минут.


виртуальная машина №2 - сервер управления антивирусом - загружен минимально
CPU 2 ядра
RAM 2Gb

виртуальная машина №1 - шлюз в интернет на Linux - загружен мало
CPU 2 ядра
RAM 1.5Gb
73. Дмитрий Воробьев (vde69) 24.07.16 17:57
проблема с долгим откликом окон клиента скорее всего не связана с SQL напрямую, скорее тут дело в чем-то хитром, типа временного кеша, или разрывом сесий.
Симптомы похожи на то, что 1с ожидает ответ от SQL но не получает его, и тут главный вопрос - какие такие запросы 1с шлет в SQL при переключении окон, возможно там что-то левое тормозит ...

высокий XE_DISPATCHER_WAIT можно попробовать побороть переводом SQL в режим однопоточности и одновременным включением ежедневного регламента обновления статистики. При этом и поиск дедлоков должен исчезнуть.


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

74. Константин Щербинин (scherbinin) 25.07.16 00:10
vde69, спасибо за быстрый ответ. Пока попробовал довести размер оперативки для 1С-виртуалки 8Gb -> 12Gb, с утра повторно запущу тест и затем выложу.
75. Константин Щербинин (scherbinin) 25.07.16 14:53
После добавления оперативки картина поменялась:

***total*** 143770908 100
XE_TIMER_EVENT 17970036 12,5
LOGMGR_QUEUE 17944784 12,5
REQUEST_FOR_DEADLOCK_SEARCH 17945260 12,5
CHECKPOINT_QUEUE 17908664 12,5
SQLTRACE_BUFFER_FLUSH 17941024 12,5
LAZYWRITER_SLEEP 17945052 12,5
FT_IFTS_SCHEDULER_IDLE_WAIT 17760338 12,4
SLEEP_TASK 8975681 6,2
BROKER_TO_FLUSH 8972515 6,2
CXPACKET 86349 0,1
PAGEIOLATCH_SH 136859 0,1

После завершения теста занято оперативной памяти всего 6Гб.
76. Дмитрий Воробьев (vde69) 25.07.16 19:33
еще раз спрошу

1. какими средствами дружили 1с и скуль ?
2.. на скуле включен параллелизм=1 ???
77. Константин Щербинин (scherbinin) 26.07.16 12:30
1. Не владею навыками настройки, SQL 2008 ставился по умолчанию на ту же машину с RDP. Перенос базы делал программист 1С.

2.

"Максимальная степень параллелизма" попробовать поставить единичку и повторить тесты?
78. Дмитрий Воробьев (vde69) 26.07.16 13:22
(77) scherbinin,

ставь 1,

настрой обновление статистики в SQL раз в 4 часа, (ОБЯЗАТЕЛЬНО)

дай поработать сутки,

потом уже повторяй тест
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа