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

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

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

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

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

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

Откуда: Moscow
Сообщений: 31446
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
Сообщений: 31446
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

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

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

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

Кроме того, 100 мб прирост - это для домашней базы ещё пригодно, но не для предприятия. Для журнала это просто губительно - получите тысячи VLF и производительность стремительно деградирует.
17 апр 17, 13:08    [20407394]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить