Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

sql server грузит проц на 100%

sql server грузит проц на 100%
Я
   jawakharlal
 
04.01.19 - 21:18
Ситуация следуюющая:
был сервер с win 2012r2 32гб оперативки, sql 2008 - переустановили ось на win srv 2016, добавили еще 32 гига оперативы, установили sql server 2016.
При установке sql server были изменены параметры по-умолчанию, которые в дальнейшем сыграли злую шутку - при работе пользователей в 1с - база встали - начались дедлоки, пользователей сбрасывало..
пробовал удалить sql server и заново установить, присоединив базы (без резервного копирования и восстановления) - но лучше не стало..
Кто может ткнуть, куда копать, всех местных "экспертов" уже привлекали - никто не смог помочь.
мои знания в sql сервере минимальны :(
 
 
   Смотрящий
 
1 - 04.01.19 - 21:22
(0) раз знания минимальны, и работает кривой - ставь постгри
   Seriy_Volk
 
2 - 04.01.19 - 21:32
(0) если у вас сервер с количеством ядер более 4 и загружены все ядра именно процессом sql сервера, значит есть код, который отрабатывает долго, зато замечательно параллелится. Для проверки этой теории можно попробовать поменять параметр "степень параллелизма", который по умолчанию 0, т.е. один запрос может использовать все доступные ядра. Для того, чтобы найти источник проблемы нужно прикрутить, например performance dashboard.
   kofeinik
 
3 - 04.01.19 - 21:36
(0) А грузит проц именно sql?
   ДенисЧ
 
4 - 04.01.19 - 21:42
"При установке sql server были изменены параметры по-умолчанию, которые в дальнейшем сыграли злую шутку"

Вернуть параметры по умолчанию взад - не предлагать?
   jawakharlal
 
5 - 04.01.19 - 21:49
(4) "пробовал удалить sql server и заново установить, присоединив базы (без резервного копирования и восстановления) - но лучше не стало.. "
собственно при переустановке заново - параметры по-дефолту не меняли
   jawakharlal
 
6 - 04.01.19 - 21:50
(2) дело не в коде - до переустановки все работало нормально. просто озушки не хватало на пользователей.
   jawakharlal
 
7 - 04.01.19 - 21:52
(3) да, грузит именно sql.
   ДенисЧ
 
8 - 04.01.19 - 21:53
попробуй maxdop=1 выставить.
Да и код кривой поискать. Долгие запросы...
   jawakharlal
 
9 - 04.01.19 - 22:21
(8) с кодом сделать ничего не могу - я вообще сисадмин, просто 1с программист ушел ))
   H A D G E H O G s
 
10 - 04.01.19 - 22:28
(9) С ним ... все хорошо? Жив, здоров?
 
 Рекламное место пустует
   palsergeich
 
11 - 04.01.19 - 22:39
(9) Денежки он свои получил?)
   vcv
 
12 - 04.01.19 - 22:40
(9) Ну, а если сисадмин, то и карты в руки.
Какие роли на сервере? Не навесили ли на сервер кроме SQL ещё и терминал, домен и прочей шняги.
Что показывает монитор ресурсов? Что показывает системный монитор? Смотрим не только на три сводных параметра "процент загрузки процессора, диска, сети", а подробно. На подозрительные места настраиваем сбор данных, что бы потом изучить дневные графики.
Счётчики в системном мониторе смотрим, не только по винде, но и SQL.
В самом SQL посмотреть запланированные задания, может чего лишнего. Посмотреть статистику по состояниям ожидания.

-- начали мониторинг, обнулили представление sys.dm_os_wait_stats*/
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)
-- ждем три часа, или сколько мы там хотим
SELECT * FROM sys.dm_os_wait_stats order by wait_time_ms desc

После всего этого, с большим пониманием места затыка гуглить и вопрошать в форумах.
   vde69
 
13 - 04.01.19 - 22:41
(9) давно без программиста?

период полураспада баз 1с без программиста = 1 год (с)мое
   palsergeich
 
14 - 04.01.19 - 22:45
is read commited snapshot on - включи.
Так же параллеризм выстави в 1.
Есть конечно подозрения - возможно сервер SQL был тюнингован.
Попробуйте отключить эскалацию на блокировках - смотри флаги 1211 и 1224 MSSQL
   vcv
 
15 - 04.01.19 - 22:46
По SQL заняться дефрагментацией индексов, обновлением статистики.
При переустановке сервера дисковую подсистему не переделывали? Она точно живая? Может рэйд сыпаться начал? Может кто-то талантливый базу куда-нибудь на iSCSI разместил?
   palsergeich
 
16 - 04.01.19 - 22:48
но для бысстрого анализа - включить тех журнал и воспользоваться утилитой из Инструментов Разработчика http://devtool1c.ucoz.ru/ по анализу ТЖ.
(15) Кстати да, когда рейд сыпется действительно симптомы схожие
   vcv
 
17 - 04.01.19 - 22:54
(6) >> просто озушки не хватало на пользователей.
Вангую, что терминал на одном сервере с SQL. Надеюсь хотя бы железном, а не виртуальном. Плохой признак.
Сервер приложений где? Он как себя ведёт?
   jawakharlal
 
18 - 04.01.19 - 23:59
(17) 1с и бд на одном серваке.. работало 5 лет, и дальше планировали работать.
   jawakharlal
 
19 - 05.01.19 - 00:04
(12) да, на серваке поднят remoteapp, сервер 1с и прочая бадяга (но коллега который все это разворачивал, уверяет что на другой работе данная конфигурация летает)
   Fram
 
20 - 05.01.19 - 00:37
(19) ну, раз уж ты админ может подробности железа и архитектуру системы выложишь?
   _Дайвер_
 
21 - 05.01.19 - 00:38
   jawakharlal
 
22 - 05.01.19 - 01:26
(20) hp proliant dl380p xeon e5-2620v2 2.1ggz
64 гига озу
raid5 из hp sas 300gb
   youalex
 
23 - 05.01.19 - 01:33
(9) чисто случайно, ушедшего программиста зовут не Вася?
   ikea
 
24 - 05.01.19 - 01:41
(23) Этот вопрос не мог не быть задан!))))))) Если программиста зовут Вася, беги - тебя не спасет ничего)))))))))))
   jawakharlal
 
25 - 05.01.19 - 01:47
(23) нет )) не вася
   Fram
 
26 - 05.01.19 - 02:06
(22) ну вот и ответ - raid5 из hdd дисков. я б тоже тормозил на месте сервера.
сколько дисков? 3 небось?
и при этом и темпдб и лог баз на этом же рейде?
   Fram
 
27 - 05.01.19 - 02:13
(26)+ и все файлы пользователей, темп файлы 1с сервера, журнал 1с сервера. то есть все, что хорошо нагружает дисковую подсистему записями/чтениями мелкими блоками работает на raid5 из hdd дисков.
   jawakharlal
 
28 - 05.01.19 - 02:51
(27) дисков 5, sas 10k
логи/данные разнесены по логическим дискам

но факт остается фактом - до переустановки все работало
   девопсер
 
30 - 05.01.19 - 06:47
(0) По дефолту на скуле размер ОЗУ не ограничен, у вас как с этим параметром?
   девопсер
 
31 - 05.01.19 - 06:52
>да, на серваке поднят remoteapp, сервер 1с и прочая бадяга 

да, с таким подходом сисадмины должны страдать
   Aleksey
 
32 - 05.01.19 - 07:54
   mexanik_96
 
33 - 05.01.19 - 08:47
(0)"...всех местных "экспертов" уже привлекали"" привлеките не местных.
сиквел может так себя вести не только потому что проблема в нем, например
1. долгое поднятие страниц с диска(железо, код 1с, индексы)
2. транзакции на апдейт
3. нет параллелизма

2,3 смотреть в студии(ожидание на блокировках, ожидание выполнения запросов)

железо смотреть в сис мониторе
код 1с смотреть в профайлере, можно в студии если стор квери есть
если в студии ничего не выполняется, смотреть ось(доп нагрузку), сеть

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

ну итд
 
 
   AkeHayc
 
34 - 05.01.19 - 09:27
А сколько попугаев набирает тест Гилева?
   ptiz
 
35 - 05.01.19 - 10:00
(19) "уверяет что на другой работе данная конфигурация летает" - вот пусть он и объясняется перед начальством.
   vcv
 
36 - 05.01.19 - 10:15
(28) >> логи/данные разнесены по логическим дискам
Это еще хуже, чем сложить на один логический диск. Своим разделением по *логическим* дискам вы только увеличиваете расходы на прозвольное чтение. Делить надо по физическим дискам.

>> но факт остается фактом - до переустановки все работало

Даже если не брать во внимание возможное совпадение железных проблем с переустановкой, слёт каких-то настроек при переустановке (может быть было включено кеширование на запись), у вас на один сервер навешано множество ролей. При этом легко получить ситуацию конфликта ресурсов, когда какая-то роль/служба/программа пожирает немного больше, а общее быстродействие падает в разы.
Может вы перенесли на этот сервер дополнительно какую-нибудь роль, которая раньше жила на дохлой железяке, но ему хватило? Поведение в фактически однозадачной среде (один сервер - одна роль) отличается от многозадачной.
   vcv
 
37 - 05.01.19 - 10:17
Копайтесь в системном мониторе, смотрите много разных счетчиков. Если процесс sql-сервера пожирает проц, это не означает, что проблема в sql и процессоре.
   lodger
 
38 - 05.01.19 - 10:21
(28) так они ж логические. матчасть то учите. а лучше подкиньте в систему SSD.
   vde69
 
39 - 05.01.19 - 14:34
   Провинциальный 1сник
 
40 - 05.01.19 - 15:14
(6) "просто озушки не хватало на пользователей."
У вас терабайтная база и тысячи пользователей что ли?
   Turku
 
41 - 05.01.19 - 15:34
(0) был сервер с win 2012r2 32гб оперативки, sql 2008 - переустановили ось на win srv 2016, добавили еще 32 гига оперативы, установили sql server 2016.

А зачем переустанавливать-то было? 2012 Standard не ограничен 32 гигами в отличие от 2008. Накатите обратно 2012. А можно и 2008R2. Думаете, чем новее версия, тем быстрее работает? А оно ведь наоборот...
(22) Железо хлам. Купите хоть 1 SATA SSD. А лучше 2: под систему и базы. Да хоть Samsung 860Evo, если денег в обрез.
Проц 2.1ГГц...1С нужно 4ГГц, чтоб нормально работать. Для этой платформы можно на Алике по дешману камни получше купить.

Держать сервер терминалов и (1С-сервер+СУБД) на одном хосте - плохая идея.
   dmpl
 
42 - 05.01.19 - 17:37
(40) Один пользователь в ERP легко может 100 Гб ОЗУ выжрать... на 20 Гб базе... ну просто кто-то дату куда-нибудь в будущее запулил - в хитрый алгоритм там по дням остатки выбирает до этой даты...
   jawakharlal
 
43 - 05.01.19 - 18:17
(41) думаете я не знаю что нужен ssd? раньше февраля нам никто просто не был готов поставить диски, т.е. ни у кого нет в наличии того что мы хотим
   jawakharlal
 
44 - 05.01.19 - 19:09
(40) да нет, базы по 30-40гб, бухгалтерия под 100.
но выделенные 17 гб не позворяли пользователем нормально работать на сервере
   ice777
 
45 - 05.01.19 - 19:18
>переустановили ось на win srv 2016
на кой ляд, если знаний пшик? уже одно это могло нагрузить сервак настройками по умолчанию.

>добавили еще 32 гига оперативы
смешно для серверов
   jawakharlal
 
46 - 05.01.19 - 19:40
(45) пшик не пшик, да надо было.
вы специально приходите в темы лишь бы повыеживаться над ТС, показав остроту ума.
ежеле нечем толковым помочь, хоть флуд не разводите


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует