Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Добрый день, уважаемые форумчане!

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

Подскажите, есть у кого-нибудь практика по сжатию топ-нагруженных таблиц? Реально помогает или это просто миф?
14 апр 17, 17:15    [20403018]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37077
Есть такая практика - сначала выяснить, что является узким местом, а потом лечить. Это реально помогает.
14 апр 17, 17:28    [20403062]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
надо не гадать, а оценивать, будет ли вообще эффект от сжатия:
sp_estimate_data_compression_savings (Transact-SQL)
откуда всему форуму знать, какие у вас данные и типы данных.
LOBы, например, не сжимаются
14 апр 17, 17:31    [20403071]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Гавриленко Сергей Алексеевич,

по идее в пик грузится диск с базой, база находится на ssd 6gb/s, при этом разнесена на 2 диска - лог и сама база.
14 апр 17, 17:31    [20403073]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Traygod
по идее в пик грузится диск с базой, база находится на ssd 6gb/s, при этом разнесена на 2 диска - лог и сама база.

так по идее или у вас это в waits?
хотя вот aleks2 знает, что "тормо3ят запросы", а диски вообще никогда ни при чем
14 апр 17, 17:33    [20403078]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37077
Traygod
Гавриленко Сергей Алексеевич,

по идее в пик грузится диск с базой, база находится на ssd 6gb/s, при этом разнесена на 2 диска - лог и сама база.
Ну так посмотрите ожидания сервера в пик, ожидания долгоиграющих запросов и т.п.

Сообщение было отредактировано: 14 апр 17, 17:35
14 апр 17, 17:33    [20403079]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
o-o,

Делал вот такой запрос, на топ 10 хулиганов.


SELECT TOP 10
wait_type ,
max_wait_time_ms wait_time_ms ,
signal_wait_time_ms ,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
AS percent_total_waits ,
100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
AS percent_total_signal_waits ,
100.0 * ( wait_time_ms - signal_wait_time_ms )
/ SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0 -- уберем нулевые задержки
AND wait_type NOT IN -- эти нем не интересны
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC


Пишут что эти надо игнорить, ибо SLEEP. В остальном я так понял всё гуд(Картинка).

QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
SP_SERVER_DIAGNOSTICS_SLEEP
QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP


Топ нагрузки на диски я вижу в perfmon, аплет - % нагрузки на физ. диск.

К сообщению приложен файл. Размер - 22Kb
14 апр 17, 17:42    [20403102]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Нафига эта статистика с момента рестарта?
Что ждут интересующие вас сессии в то пиковый момент ?
sys.dm_os_waiting_tasks
14 апр 17, 17:50    [20403120]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
o-o,

Во время пика примерно тоже самое. Но хорошо я соберу статистику и в пик, но perfmon явно показывает что нагрузка идет на диск, а глюки не из-за парллелизма или какого-нить райтлога...
14 апр 17, 17:55    [20403131]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Кстати, на картинке вообще никаких намеков на io нет?
14 апр 17, 18:00    [20403147]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37077
o-o
Кстати, на картинке вообще никаких намеков на io нет?
На картинке нет намеков на какую-либо работу сервера вообще.
14 апр 17, 18:02    [20403151]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Какое приращение выставлено файлам данных и лога, какая recovery model?
У вс куча ожиданий os, поди файлы расширяет
14 апр 17, 18:07    [20403157]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
o-o
Какое приращение выставлено файлам данных и лога, какая recovery model?
У вс куча ожиданий os, поди файлы расширяет


шаг на 100 мегабайт база и лог.
14 апр 17, 18:12    [20403162]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Гавриленко Сергей Алексеевич
o-o
Кстати, на картинке вообще никаких намеков на io нет?
На картинке нет намеков на какую-либо работу сервера вообще.

Так он перегрузил сервер 5 минут назад, 5 *60 * 1000,вот и 300000
Но говорит же, что в пик ожидания те же.
Про sch-m не поверю, что ж они, таблицы дропают или индексы в час пик вешают?
14 апр 17, 18:16    [20403166]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Traygod
o-o
Какое приращение выставлено файлам данных и лога, какая recovery model?
У вс куча ожиданий os, поди файлы расширяет


шаг на 100 мегабайт база и лог.

А это точно те же ожидания, что и в пик?
А то при рестарте он лог темпдб зануляет, это наверное оно
Телефон зло, в экран или не лезет, или мелко, я на список смотрю, а Гавриленко на цифры, и он прав: бездейтвующий сервер, только что рестартанутый, скорее всего.
Это ж ms, в секунды переведите, смешно станет
14 апр 17, 18:23    [20403172]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37077
o-o
Так он перегрузил сервер 5 минут назад, 5 *60 * 1000,вот и 300000
Там подстава. Вместо wait_time скрипт зачем-то выводит max_wait_time.
14 апр 17, 18:26    [20403181]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
o-o
Guest
Гавриленко Сергей Алексеевич
o-o
Так он перегрузил сервер 5 минут назад, 5 *60 * 1000,вот и 300000
Там подстава. Вместо wait_time скрипт зачем-то выводит max_wait_time.

Это он зпт потерял
Вот и поговорили ни о чем
Все, товарищи, поезд тронулся, всем пока
14 апр 17, 18:36    [20403194]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31488
Traygod
в пик грузится диск с базой, база находится на ssd 6gb/s, при этом разнесена на 2 диска - лог и сама база.
Вы просто в ресурс мониторе посмотрите очереди к дискам, и нагрузку на файле.
Это простое пятисекундное действие покажет, нужно заморачиваться дисковой нагрузкой, или нет.

А то, ладно, LOBы не сжимаются, так bulk операции вообще деградируют, на любом даже суперсервере, с сотнями дисков, будет стабильные 3 МБ/сек.
14 апр 17, 22:38    [20403708]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31488
Traygod
но perfmon явно показывает что нагрузка идет на диск, а глюки не из-за парллелизма или какого-нить райтлога...
Вы случайно базу не шринкуете по расписанию, для "оптимизации"? :-)
14 апр 17, 22:39    [20403713]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
alexeyvg
Traygod
но perfmon явно показывает что нагрузка идет на диск, а глюки не из-за парллелизма или какого-нить райтлога...
Вы случайно базу не шринкуете по расписанию, для "оптимизации"? :-)


Вы имеете ввиду лог или базу? Лог регулярно отрезается, т.к. модель симпл.
15 апр 17, 11:44    [20404243]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
aleks2
Guest
Traygod
Лог регулярно отрезается, т.к. модель симпл.


Что делает кот, когда делать нечего?

ЗЫ. Лучше вышивайте крестиком.
15 апр 17, 12:56    [20404343]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
человек_ниоткуда
Guest
Обслуживание статистик сделайте. Ежедневно, ежечасно... 1С очень это любит.

Самый тупой способ определить какие статистики обслуживать:
* перед началом дня сделайте"DBCC FREEPROCCACHE", "DBCC DROPCLEANBUFFERS"
Это может ненадолго снизить производительность.
* в конце дня снимите TOP из sys.dm_exec_query_stats
Смотрите какие запросы в топе по CPU и Reads/Writes , и те таблицы в них, что часто INSERT/UPDATE имеют обновляйте статистики ежечасно и ночью с fullscan.
15 апр 17, 14:28    [20404456]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31488
Traygod
alexeyvg
пропущено...
Вы случайно базу не шринкуете по расписанию, для "оптимизации"? :-)


Вы имеете ввиду лог или базу? Лог регулярно отрезается, т.к. модель симпл.
И то и другое.
Зачем делать шринк файла лога? Если он в симпл модели, то он достигнет некоего оптимального размера, и дальше расти не будет.

Повторю - посмотрите ресурс монитором для начала, что происходит.
16 апр 17, 02:39    [20405200]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Итак запустил в пик, топом оказался RESOURCE_SEMAPHORE, есть мысли как лечить? Максимальная степень параллелизма стоит 1.
17 апр 17, 12:50    [20407316]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7969
Traygod,

сколько ядер? 1c создает значительную нагрузку на tempdb.

https://msdn.microsoft.com/ru-ru/library/ms175527(v=sql.105).aspx

Кроме того, 100 мб прирост - это для домашней базы ещё пригодно, но не для предприятия. Для журнала это просто губительно - получите тысячи VLF и производительность стремительно деградирует.
17 апр 17, 13:08    [20407394]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Владислав Колосов
Traygod,

сколько ядер? 1c создает значительную нагрузку на tempdb.

https://msdn.microsoft.com/ru-ru/library/ms175527(v=sql.105).aspx

Кроме того, 100 мб прирост - это для домашней базы ещё пригодно, но не для предприятия. Для журнала это просто губительно - получите тысячи VLF и производительность стремительно деградирует.


База после сжатия таблиц по PAGE стала весить 50 гигов, вместо 90. Сколько сделать шаг на рост?
17 апр 17, 13:12    [20407409]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Владислав Колосов
Traygod,

сколько ядер? 1c создает значительную нагрузку на tempdb.

https://msdn.microsoft.com/ru-ru/library/ms175527(v=sql.105).aspx

Кроме того, 100 мб прирост - это для домашней базы ещё пригодно, но не для предприятия. Для журнала это просто губительно - получите тысячи VLF и производительность стремительно деградирует.



4 ядра, tempdb на системном диске, в perfmon нагрузка в пик на него 50-60%.
17 апр 17, 13:14    [20407418]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
invm
Member

Откуда: Москва
Сообщений: 9438
Traygod
как лечить?
Либо увеличить объем памяти на сервере.
Либо избавляться от сортировок, хеш-соединений и хеш-группировок в запросах.
17 апр 17, 13:17    [20407433]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7969
Traygod,

Если Вам известен годовой прирос базы, то я бы советовал сделать от текущего запас на 5-10 лет и зафиксировать этот размер сразу.

Например, 90 Гб сотрудники наработали за 5 лет. Установите фиксированный размер базы в 300 гб и размер журнала 10% от размеры базы. При этом желательно произвести дефрагментацию диска (или создавать на чистом диске), разместить на нём базу(ы) и выделить для нее (них) место сразу с запасом.
При этом логически база будет занимать непрерывное пространство и исчезнут накладные расходы на сжатие, расширение, дисковую фрагментацию. Чтение непрерывных кусков выгодно даже для SSD.
17 апр 17, 13:20    [20407461]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7969
Traygod,

посмотрите рекомендации по ссылке на оптимизацию tempdb.
17 апр 17, 13:21    [20407472]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Владислав Колосов
Traygod,

посмотрите рекомендации по ссылке на оптимизацию tempdb.


Да, спасибо большое. Сделано всё было изначально примерно так же. Сегодня зафиксировал интересный момент, когда заходит и начинает проводить один из людей(Оператор передает задания в цех), то все начинают вешаться, при этом ни память, ни нагрузка на проц и жесткие - особо не отличается, разве что процентов на 10 вырастает, но ощущение что sql рвет со всеми коннекты, т.е. у меня завис даже sql монитор, а рядом с часиками появилось сообщение что "mssql ждет завершение операции, если будет постоянно, то обратитесь в microsoft". Скуль 2014, 1с 8.3.8_1784. Даже предполагал что может что-то агент делает и выключил его сегодня с утра, но днем всё повторилось - помог только перезапуск службы скуля. Ребят, выручайте - что-то неведомое ))
17 апр 17, 14:57    [20407881]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31488
Traygod
Даже предполагал что может что-то агент делает и выключил его сегодня с утра, но днем всё повторилось - помог только перезапуск службы скуля. Ребят, выручайте - что-то неведомое ))
Так что происходит то?
Кроме эмоциональных оценок что есть?
Какие были блокировки, какие очереди к дискам, как они распределены по типам файлов, какая нагрузка на CPU, как она распределена по ядрам, какие появились ожидания у коннектов, которые "зависли"?
17 апр 17, 15:06    [20407919]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
человек_ниоткуда
Guest
Traygod
Итак запустил в пик, топом оказался RESOURCE_SEMAPHORE, есть мысли как лечить?

RESOURCE_SEMAPHORE - это оперативка.
Лечить - тупо добавить оперативки на сервер. +25% >>> +50% >>> +100% -- пока не поможет.
А версию скуля ты говорил уже? У тебя там надеюсь не x86?
PRINT @@VERSION

^^^ что выдаёт?

Просто для интереса:
EXEC sys.sp_configure 'show advanced options', '1'; RECONFIGURE;
GO

EXEC sys.sp_configure 'max server memory (MB)';
EXEC sys.sp_configure 'min server memory (MB)';

^^^ что выдаёт?

Попробуй обновлять статистики, тогда планы запросов будут оптимальнее и есть шанс что память будут меньше юзать. Ночью запусти:
+

/*	@Mode :
*	 - RPT : Генерирует и выводит на экран скрипт обновления статистк.
*	 - EXE : Выполняет обновление статистик. 
*/
DECLARE @Mode CHAR(4) = 'EXE';
/*	@DoFullScan :
*	 - 1 : Выполняет обновление статистик с атрибутом FULLSCAN.
*	 - 0 : Иначе.
*/
DECLARE @DoFullScan BIT = 0;

------------------
SET NOCOUNT ON;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

WHILE 1=1
BEGIN
	IF @Mode = 'RPT'
	BEGIN
		PRINT 'USE ' + QUOTENAME(DB_NAME()) + ';';
		BREAK;
	END;
	
	IF @Mode = 'EXE'
	BEGIN
		PRINT 'Database name: ' + DB_NAME();
		BREAK;
	END;

	RAISERROR ('Invalid @Mode option.', 11, 1);
END;

DECLARE 
	@TblObjId INT = (SELECT MIN([object_id]) FROM sys.tables)
,	@SQL NVARCHAR(4000);

WHILE	@TblObjId IS NOT NULL
BEGIN
	SET @SQL =
	(	SELECT
			REPLACE(REPLACE(
				CASE @DoFullScan 
					WHEN CAST(1 AS BIT) THEN N'UPDATE STATISTICS ?(sc_name).?(tb_name) WITH FULLSCAN;'
					WHEN CAST(0 AS BIT) THEN N'UPDATE STATISTICS ?(sc_name).?(tb_name);'
				END
			,	'?tb_name?', QUOTENAME(tb.name))
			,	'?sc_name?', QUOTENAME(sc.name))
		FROM
			sys.tables tb
		INNER JOIN
			sys.schemas sc
		ON	sc.[schema_id] = tb.[schema_id]
		WHERE
			@TblObjId = tb.[object_id]
	);
	
	IF @Mode = 'RPT'
	BEGIN
		PRINT 'GO';	
		PRINT @SQL;		
	END;
	
	IF @Mode = 'EXE'
		EXEC (@SQL);
	
	SET @TblObjId = (SELECT MIN([object_id]) FROM sys.tables WHERE [object_id] > @TblObjId);
END


И скажи как на следующий день всё будет работать?

Traygod
Максимальная степень параллелизма стоит 1.

Норм. Можешь затюнить по крутому.
Сделай:
EXEC sys.sp_configure 'show advanced options', '1'; RECONFIGURE;
GO
EXEC sys.sp_configure 'cost threshold for parallelism', '2048'; RECONFIGURE;
EXEC sys.sp_configure 'max degree of parallelism', '2'; RECONFIGURE;

Вечером следующего дня отсюда запусти скрипт https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/ посмотри какие значения в StatementSubTreeCost и много-ли значений приходит.
17 апр 17, 15:48    [20408034]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 34100
Блог
сколько Page Life Expectancy?
18 апр 17, 15:32    [20411106]     Ответить | Цитировать Сообщить модератору
 Re: И опять об 1с SQL и повышения производительности.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7969
автор
Сегодня зафиксировал интересный момент

Возможно, что он забрал себе все 4 ядра.
18 апр 17, 18:39    [20412066]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Microsoft SQL Server Ответить