Имя: Пароль:
1C
Админ
Тормоза 1С 8.2 на новом сервере
0 TrankAdmin
 
06.11.13
22:52
Здравствуйте!
Поделитесь мыслями, что может быть за беда.

Сервер новый: 2 процессора Xeon E5-2680 , ОЗУ: 64 Гб , RAID 10, под управлением Win Server 2008 R2 x64. Работает в связке с MSSQL 2012

Платформа 1С 8.2.18

На сервере одна база УНФ + внушительная часть самописного кода. Сама база занимает 28 Гб, хотя бэкапится в 3 Гб. Проверяю клиентом прямо на сервере, сразу после перезагрузки, соответственно никаких аномалий загрузки не замечено, загрузка процессоров 1-2% , rphost 300 MB, никаких page fault, read/write на диске в норме, база почти пустая, но проведение любого документа занимает 2-5 секунд. Если прикинуть какие нагрузки будут при работе с 40-50 пользователями, то явно это время увеличится.

Подскажите, в какую сторону копать?
Возможны ли тормоза из-за платформы?

Интересны любые мнения. Спасибо!
1 Reaper_1c
 
06.11.13
23:08
1. Режим электропитания
2. Куча самописного кода - тестировать демо-базу типовой, смотреть разнцу
3. Где замер производительности БЛЕАТЬ???
2 Euguln
 
06.11.13
23:09
+ SQL настроить правильно не лишним будет
3 Лефмихалыч
 
06.11.13
23:16
(0) Я бы сначала доказал, что мегатонны самописек не причастны к этим 2-5 секунд


>бэкапится в 3 Гб
перестаньте бэкапить через выгрузку в dt - потеряете нафиг базу в случаего, т.к. dt не предназначен для резервного копирования.
4 Fragster
 
модератор
06.11.13
23:29
WITH Waits AS ( SELECT wait_type , wait_time_ms / 1000. AS wait_time_s , 100. * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS pct ,
ROW_NUMBER() OVER ( ORDER BY wait_time_ms DESC ) AS rn FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( 'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK', 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN' ) ) SELECT W1.wait_type , CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s , CAST(W1.pct AS DECIMAL(12, 2)) AS pct , CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.rn <= W1.rn GROUP BY W1.rn , W1.wait_type , W1.wait_time_s , W1.pct HAVING SUM(W2.pct) - W1.pct < 95 ; -- percentage threshold
5 Лефмихалыч
 
06.11.13
23:31
(4) эмм... ты это... рукой покажи штоле...
6 йети
 
06.11.13
23:36
(0) померяй сервер попугаями Гилева
7 Gepard
 
06.11.13
23:52
(0) не факт,  что увеличится
8 Gepard
 
06.11.13
23:53
(0) можно еще проверить код,  в частности подписки на события
9 Gepard
 
06.11.13
23:54
(8) +может там что-то перебором шпарит
10 etc
 
06.11.13
23:57
(4) вот это я понимаю "проверка на вшивость" :)
11 etc
 
06.11.13
23:58
(0) я бы на таком сервере только SQL оставил. А 1С-ку рядом на другом сервере раза в два-три попроще.
12 etc
 
06.11.13
23:59
И да, самое важное в 3-ем пункте у (1)! Где?
Основная теорема систематики: Новые системы плодят новые проблемы.