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

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

Сильно тормозит 1с, даже посте полного ТИ средствами 1с, затем выгрузкой и загрузкой dt-шника и ребилдом индексов средствами sql(Именно в это порядке - 1) ТИ 2)backup/restore 3) index rebuild). Хватает поработать от силы полчаса-час и начинаются тормоза.

Всего пользователей 10 все работаю по сети, база 16 гигов, сервак xeon 2.4, оперативы 32 гига - чисто под sql выделил по 1,5 на rphost - всего rphost 4 шт. (Т.е. 4 рабочих процесса сервера 1с) - добавлял больше или делал меньше - толку нет, оставил рекомендуемые. База находится на raid 1 - индикатор контроллера изредка помыргивает, т.е. нагрузки на диски особо нет, процессор крайне изредка превышает 30%-ю нагрузку, оперативы больше половины всегда свободна.

Порекомендовали сделать запрос:

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


Но разобраться в результатах не могу, так как не sql-щик. Чувствую проблемав жестких и постоянных затянутых блокировках внутри базы. Помогите с результатом, может кто-то знает как победить подобную проблему с 1с? Результат команды в прикрепленном файле.

К сообщению приложен файл. Размер - 17Kb
3 сен 13, 18:49    [14791111]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Traygod
оперативы 32 гига - чисто под sql выделил по 1,5 на rphost - всего rphost 4 шт. (Т.е. 4 рабочих процесса сервера 1с) - добавлял больше или делал меньше - толку нет, оставил рекомендуемые

Из этого пассажа я так и не понял, сколько памяти выделено "чисто под sql"? (т.е. для инстанса MSSQL, работающего с БД 1С)

Traygod
Порекомендовали сделать запрос:

SELECT TOP 10
        ...
        max_wait_time_ms wait_time_ms ,
        ...
FROM    sys.dm_os_wait_stats 
WHERE   ...
ORDER BY wait_time_ms DESC

То есть порекомендовали посмотреть на 10 "чемпионов" по максимальному времени ожидания? Может, лучше всё-таки отсортировать по общему времени ожидания?
WITH [Waits] AS
    (SELECT
        [wait_type],
        [wait_time_ms] / 1000.0 AS [WaitS],
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
        [signal_wait_time_ms] / 1000.0 AS [SignalS],
        [waiting_tasks_count] AS [WaitCount],
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
    FROM sys.dm_os_wait_stats
    WHERE [wait_type] NOT IN (
        N'CLR_SEMAPHORE',    N'LAZYWRITER_SLEEP',
        N'RESOURCE_QUEUE',   N'SQLTRACE_BUFFER_FLUSH',
        N'SLEEP_TASK',       N'SLEEP_SYSTEMTASK',
        N'WAITFOR',          N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'XE_TIMER_EVENT',   N'XE_DISPATCHER_JOIN',
        N'LOGMGR_QUEUE',     N'FT_IFTS_SCHEDULER_IDLE_WAIT',
        N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
        N'CLR_AUTO_EVENT',   N'DISPATCHER_QUEUE_SEMAPHORE',
        N'TRACEWRITE',       N'XE_DISPATCHER_WAIT',
        N'BROKER_TO_FLUSH',  N'BROKER_EVENTHANDLER',
        N'FT_IFTSHC_MUTEX',  N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'DIRTY_PAGE_POLL',  N'SP_SERVER_DIAGNOSTICS_SLEEP')
    )
SELECT
    [W1].[wait_type] AS [WaitType],
    CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
    CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
    CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
    [W1].[WaitCount] AS [WaitCount],
    CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
    ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold

Скрипт взят из блога Paul Randal'а: http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
4 сен 13, 09:05    [14792423]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Гость333, чисто под mssql 2005 памяти используется 1,5*4 процесса = 6144 + 2 048 ~ 8 гигабайт.

Вот что показал ваш запрос, что посоветуете? )

К сообщению приложен файл. Размер - 13Kb
4 сен 13, 09:34    [14792537]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Traygod
Вот что показал ваш запрос, что посоветуете? )

CXPACKET - это параллелизм
cost threshold for parallelism сколько установлен ?
4 сен 13, 09:49    [14792596]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Traygod
Гость333, чисто под mssql 2005 памяти используется 1,5*4 процесса = 6144 + 2 048 ~ 8 гигабайт.

rphost не является процессом, относящимся к SQL Server. Поэтому ваши расчёты непонятны (2048 — это что? откуда?).
Покажите лучше результат выполнения запроса:
select name, value, value_in_use from sys.configurations where name like '%server memory%'

там будет видно, сколько памяти выделено для SQL Server.
4 сен 13, 09:50    [14792606]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Glory
Traygod
Вот что показал ваш запрос, что посоветуете? )

CXPACKET - это параллелизм
cost threshold for parallelism сколько установлен ?


Значение равно 5
4 сен 13, 09:51    [14792611]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Гость333
Traygod
Гость333, чисто под mssql 2005 памяти используется 1,5*4 процесса = 6144 + 2 048 ~ 8 гигабайт.

rphost не является процессом, относящимся к SQL Server. Поэтому ваши расчёты непонятны (2048 — это что? откуда?).
Покажите лучше результат выполнения запроса:
select name, value, value_in_use from sys.configurations where name like '%server memory%'

там будет видно, сколько памяти выделено для SQL Server.


Действовал по рекомендации - указать значение памяти в 1,5 гигабайта на процесс rphost.exe(Процесс сервера 1с), процесса всего 4 - отсюда получается 6144 мб. + 2048 мб под регламенты и т.д. Итого установил значение в параметрах 8192.

Вот вывод строки

select name, value, value_in_use from sys.configurations where name like '%server memory%'

К сообщению приложен файл. Размер - 2Kb
4 сен 13, 09:57    [14792642]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Traygod
Итого установил значение в параметрах 8192.

А ваша редакция сервера позволяет использовать столько памяти ?
И сколько она использует фактически ?

Traygod
Значение равно 5

Сделайте 15 - наблюдайте за CXPACKET
4 сен 13, 10:24    [14792743]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Glory
Traygod
Итого установил значение в параметрах 8192.

А ваша редакция сервера позволяет использовать столько памяти ?
И сколько она использует фактически ?

Traygod
Значение равно 5

Сделайте 15 - наблюдайте за CXPACKET


Да, sql 64 бита - видно как кушает при пиковых нагрузках(Например ТИ в 1с съедает всю память сколько не выделяй, но при текущем параметре тестирование занимает столько же времени, так что выделять больше не вижу смысла). В среднем использует 6-7 гигабайт.

Установил в 15, понаблюдаю 2-3 часа, отпишусь.
4 сен 13, 10:28    [14792755]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
HoBTID
Member

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

Для работы с 1С у MS SQL Server параллелизм лучше вообще отключить.
Делается это так:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
4 сен 13, 11:36    [14793148]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
OYM
Member

Откуда:
Сообщений: 236
Traygod
Здравствуйте, уважаемые формучане!

Сильно тормозит 1с, даже посте полного ТИ средствами 1с, затем выгрузкой и загрузкой dt-шника и ребилдом индексов средствами sql(Именно в это порядке - 1) ТИ 2)backup/restore 3) index rebuild). Хватает поработать от силы полчаса-час и начинаются тормоза.

Всего пользователей 10 все работаю по сети, база 16 гигов, сервак xeon 2.4, оперативы 32 гига - чисто под sql выделил по 1,5 на rphost - всего rphost 4 шт. (Т.е. 4 рабочих процесса сервера 1с) - добавлял больше или делал меньше - толку нет, оставил рекомендуемые. База находится на raid 1 - индикатор контроллера изредка помыргивает, т.е. нагрузки на диски особо нет, процессор крайне изредка превышает 30%-ю нагрузку, оперативы больше половины всегда свободна.

Порекомендовали сделать запрос:

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


Но разобраться в результатах не могу, так как не sql-щик. Чувствую проблемав жестких и постоянных затянутых блокировках внутри базы. Помогите с результатом, может кто-то знает как победить подобную проблему с 1с? Результат команды в прикрепленном файле.


Память-дура! Диск-молодец.
Замените диски SATA на SAS.
Разнесите данные, лог и темпдб на разные массивы, пускай все будет зеркалами.
4 сен 13, 11:48    [14793237]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
[/quot]

Память-дура! Диск-молодец.
Замените диски SATA на SAS.
Разнесите данные, лог и темпдб на разные массивы, пускай все будет зеркалами.[/quot]

Я ведь написал, что диск почти не напрягается даже в пиковые нагрузки, скорости вращения шпинделей более чем хватает, тут явно что-то другое, сас если и поможет, то совсем незначительно.
4 сен 13, 12:02    [14793355]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
HoBTID
Member

Откуда:
Сообщений: 929
Traygod, а отключение параллелизма не пробовали?
Это совет из практического опыта, если что.
4 сен 13, 12:04    [14793383]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35398
Блог
Traygod
Я ведь написал, что диск почти не напрягается даже в пиковые нагрузки, скорости вращения шпинделей более чем хватает, тут явно что-то другое, сас если и поможет, то совсем незначительно.


так у вас же на картинке показано наибольшее ожидание по операциям,
почитайте о них
4 сен 13, 12:05    [14793389]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
Traygod
Glory
пропущено...

А ваша редакция сервера позволяет использовать столько памяти ?
И сколько она использует фактически ?

пропущено...

Сделайте 15 - наблюдайте за CXPACKET


Да, sql 64 бита - видно как кушает при пиковых нагрузках(Например ТИ в 1с съедает всю память сколько не выделяй, но при текущем параметре тестирование занимает столько же времени, так что выделять больше не вижу смысла). В среднем использует 6-7 гигабайт.

Установил в 15, понаблюдаю 2-3 часа, отпишусь.


Сменил значение, но скуль не перезапустил(Подскажите, надо ли?), результат пока примерно тот же.

К сообщению приложен файл. Размер - 13Kb
4 сен 13, 12:07    [14793407]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

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

Для работы с 1С у MS SQL Server параллелизм лучше вообще отключить.
Делается это так:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO


Спасибо больше, обязательно попробую, но можете подсказать, что дает конкретное значение? Кол-во одновременных пользователей? Потоков на подключение? Или что обозначает? На сайте msdn очень размыто об этом написано.
4 сен 13, 12:11    [14793453]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
HoBTID
Member

Откуда:
Сообщений: 929
Traygod, конкретное значение в строке:
sp_configure 'max degree of parallelism', 1;

задает количество потоков, на которые MS SQL может разделить выполнение ОДНОГО ЗАПРОСА.

Значение 1 - один поток, никакого параллельного выполнения.
Значение 0 (по умолчанию) - неограниченное количество потоков.

Например, вы послали серверу запрос
SELECT * FROM _Reference31

И он его решил разделить на 5 потоков, чтобы читать одновременно разные части таблицы.
На таком простом запросе, скорее всего будет выигрыш, если таблица большая.
Но на типичных запросах 1С, которые довольно большие, со многими соединениями и подзапросами,
как показывает практика, получается проигрыш. Причем оптимизатор MS SQL думает, что экономит время,
а на самом деле, его теряет.

Кроме того, иногда бывает ситуация, когда параллельно выполняющиеся части одного запроса блокируют друг друга.
Это вообще смешно выглядит: запрос сам себя заблокировал и был убит в связи с deadlock.

Поэтому распараллеливание запросов лучше отключить.
4 сен 13, 12:31    [14793619]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
HoBTID
Traygod, конкретное значение в строке:
sp_configure 'max degree of parallelism', 1;

задает количество потоков, на которые MS SQL может разделить выполнение ОДНОГО ЗАПРОСА.

Значение 1 - один поток, никакого параллельного выполнения.
Значение 0 (по умолчанию) - неограниченное количество потоков.

Например, вы послали серверу запрос
SELECT * FROM _Reference31

И он его решил разделить на 5 потоков, чтобы читать одновременно разные части таблицы.
На таком простом запросе, скорее всего будет выигрыш, если таблица большая.
Но на типичных запросах 1С, которые довольно большие, со многими соединениями и подзапросами,
как показывает практика, получается проигрыш. Причем оптимизатор MS SQL думает, что экономит время,
а на самом деле, его теряет.

Кроме того, иногда бывает ситуация, когда параллельно выполняющиеся части одного запроса блокируют друг друга.
Это вообще смешно выглядит: запрос сам себя заблокировал и был убит в связи с deadlock.

Поэтому распараллеливание запросов лучше отключить.



Хороший совет, спасибо больше, сейчас буду всё проделывать, что описано выше, завтра денёк погоняю и отпишусь что да как.

Кстати, а можете подсказать по двум моментам в отчете, что означают пункты

PAGEIOLATCH_SH и PAGEIOLATCH_EX ?
4 сен 13, 15:25    [14794741]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Traygod
что означают пункты

PAGEIOLATCH_SH и PAGEIOLATCH_EX ?

Это ожидания загрузки страниц данных с диска в буферный пул.
Возникают, когда идёт обращение к данным, которых нет в кэше SQL Server.
4 сен 13, 15:34    [14794802]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
HoBTID
Member

Откуда:
Сообщений: 929
Traygod
Хороший совет, спасибо больше, сейчас буду всё проделывать, что описано выше, завтра денёк погоняю и отпишусь что да как.

Кстати, а можете подсказать по двум моментам в отчете, что означают пункты

PAGEIOLATCH_SH и PAGEIOLATCH_EX ?

Как уже сказали, это ожидание чтения с диска.
Если их останется много, после того, как исчезнет CXPACKET,
надо с этим тоже что-то делать, например можно увеличить объем оперативной памяти для SQL Server.

Ну и конечно же можно оптимизировать запросы, только это долгое дело.
4 сен 13, 16:41    [14795348]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
HoBTID
Traygod
Хороший совет, спасибо больше, сейчас буду всё проделывать, что описано выше, завтра денёк погоняю и отпишусь что да как.

Кстати, а можете подсказать по двум моментам в отчете, что означают пункты

PAGEIOLATCH_SH и PAGEIOLATCH_EX ?

Как уже сказали, это ожидание чтения с диска.
Если их останется много, после того, как исчезнет CXPACKET,
надо с этим тоже что-то делать, например можно увеличить объем оперативной памяти для SQL Server.

Ну и конечно же можно оптимизировать запросы, только это долгое дело.



Это невероятно, отключение параллелизма показывает отличные результаты по скорости - тормоза пропали раз и навсегда кажись, cxpacket ушел далеко и надолго, нагрузка на чтение и запись значительно упали - пользователи просто апплодируют. Это лучший из простых совет, который мне давали за всю мою практику администрирования. Большое спасибо всем за помощь, через неделю выдам окончательные результаты. Ниже результаты текущих тестов.

К сообщению приложен файл. Размер - 10Kb
5 сен 13, 11:38    [14798278]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35398
Блог
Traygod,

Все равно у вас возможны проблемы с дисковой подсистемой, судя по картинке.
И, прежде чем радоваться, попробуйте запустить сложные отчеты )
5 сен 13, 11:47    [14798375]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

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

Все равно у вас возможны проблемы с дисковой подсистемой, судя по картинке.
И, прежде чем радоваться, попробуйте запустить сложные отчеты )


Диски - это следующий шаг - тут всё проще - посадим на сас, но отключенный cxpacket дал дури для 1с так, что тесты показывают повышение скорости в 10 раз! Думаю, это более чем убедительно.
5 сен 13, 11:50    [14798403]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
HoBTID
Member

Откуда:
Сообщений: 929
Traygod,
Рад, что у вас все быстро заработало :-)))
5 сен 13, 12:26    [14798730]     Ответить | Цитировать Сообщить модератору
 Re: И опять о тормозах 1с. Помогите разобраться со статистикой и блокировками.  [new]
Traygod
Member

Откуда:
Сообщений: 82
HoBTID
Traygod,
Рад, что у вас все быстро заработало :-)))


Подскажите, а проблем с потерей данных или получения неполных данных не будет? Я так понимаю, что отключены параллельные запросы и данные просто читаются теперь одни запросом, проще говоря убраны "навороченные запросы и теперь используются только просты? - я всё правильно понял? )
5 сен 13, 13:34    [14799444]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить