Как улучшить производительность 1С?

Стоит ли переходить на диски SSD в рэйде? И даст ли это эффект?

Основная база 1С 8.2, обычное приложение, УТ 10.3 много переписанное.
40 гигов, 75 пользователей.

(0) даст

начни с определения что именно тебя не устраивает...

например
документ ПКО проводится 8 сек а должен 2 сек


составь список, потом будет видно лучше. по тому что например запись и чтение по разному оптимизируются....

а вообще http://infostart.ru/public/16681/

(3) и там сразу будет видно :)

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

(5) Переписать что-то на Управляемые блокировки. Купите ЦУП.

(3) спасибо, это запускать на 300 минут, а ничего что там юзвери сидят?

(6) зачем ЦУП? перейдите на семерку и всё

(7) запускать нужно именно при юзверях...

кстати софтпоинт тут кричал, что свой продуктик дает в триал... можно им поюзать...

(9) то есть результат я увижу через 5 часов?
еще раз спасибо, потом буду спрашивать про расшифровку результата

(10) если работа у пользователей равномерная в течении суток, то можно и на 1 час запустить.

5 часов это типа на целый день, что бы уж наверняка...

Счетчик очереди к дискам что показывает?

Не угадал автора. Думал, Борис Георгиевич к нам заглянул

:)

(12) учитывая "так же часты взаимоблокировки" очередь к дискам сильно вторична.

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

я бы пошел так
0. проверить регламенты скуля, реиндексация и статистика
1. разделить проблеммы 1с, железа, сети для этого скриптик мой подходит.
2. убрать сетевые проблеммы
3. однозначно нужно боротся с дедлоками переписывая 1с
4. повторить тест и уже на основании его смотреть железо сервера

5 часовой скрипт, результат:

***total***    112101958.0    100.0
CXPACKET    47435156.0    42.3
PAGEIOLATCH_SH    24376578.0    21.7
LAZYWRITER_SLEEP    17939532.0    16.0
SQLTRACE_BUFFER_FLUSH    17940078.0    16.0
PAGEIOLATCH_EX    1709203.0    1.5
ASYNC_NETWORK_IO    1076468.0    1.0
LATCH_EX    481765.0    0.4
LCK_M_IX    284656.0    0.3
LCK_M_IS    198203.0    0.2
SLEEP_TASK    173171.0    0.2
SOS_SCHEDULER_YIELD    58078.0    0.1
LCK_M_S    94265.0    0.1
SLEEP_BPOOL_FLUSH    59375.0    0.1
CHKPT    0.0    0.0
IO_COMPLETION    46187.0    0.0
ASYNC_IO_COMPLETION    0.0    0.0
SQLTRACE_SHUTDOWN    0.0    0.0
MSQL_SYNC_PIPE    0.0    0.0
QUERY_TRACEOUT    0.0    0.0
DTC_STATE    0.0    0.0
FCB_REPLICA_WRITE    0.0    0.0
FCB_REPLICA_READ    0.0    0.0
WRITELOG    13015.0    0.0
HTTP_ENDPOINT_COLLCREATE    0.0    0.0
EXCHANGE    0.0    0.0
DBTABLE    0.0    0.0
EC    0.0    0.0
TEMPOBJ    0.0    0.0
XACTLOCKINFO    0.0    0.0
LOGMGR    0.0    0.0
CMEMTHREAD    343.0    0.0
LCK_M_U    0.0    0.0
LCK_M_X    54656.0    0.0
MISCELLANEOUS    0.0    0.0
LCK_M_SCH_S    0.0    0.0
LCK_M_SCH_M    8750.0    0.0
LCK_M_IU    0.0    0.0
PAGEIOLATCH_UP    5406.0    0.0
LATCH_DT    0.0    0.0
PAGELATCH_NL    0.0    0.0
PAGELATCH_KP    0.0    0.0
PAGELATCH_SH    2421.0    0.0
PAGELATCH_UP    12296.0    0.0
PAGELATCH_EX    11250.0    0.0
PAGELATCH_DT    0.0    0.0
PAGEIOLATCH_NL    0.0    0.0
PAGEIOLATCH_KP    0.0    0.0
LCK_M_SIU    0.0    0.0
LCK_M_SIX    0.0    0.0
LCK_M_UIX    0.0    0.0
LCK_M_BU    0.0    0.0
LCK_M_RS_S    26968.0    0.0
LCK_M_RS_U    5062.0    0.0
LCK_M_RIn_NL    31843.0    0.0
LCK_M_RIn_S    0.0    0.0
LCK_M_RIn_U    0.0    0.0
LCK_M_RIn_X    0.0    0.0
LCK_M_RX_S    0.0    0.0
LCK_M_RX_U    0.0    0.0
LCK_M_RX_X    1984.0    0.0
LATCH_NL    0.0    0.0
LATCH_KP    0.0    0.0
LATCH_SH    1953.0    0.0
LATCH_UP    0.0    0.0
SOS_VIRTUALMEMORY_LOW    0.0    0.0
SOS_RESERVEDMEMBLOCKLIST    0.0    0.0
SOS_LOCALALLOCATORLIST    0.0    0.0
SOS_CALLBACK_REMOVAL    0.0    0.0
LOWFAIL_MEMMGR_QUEUE    0.0    0.0
BACKUP    0.0    0.0
BACKUPBUFFER    0.0    0.0
BACKUPIO    0.0    0.0
BACKUPTHREAD    0.0    0.0
DBMIRROR_DBM_MUTEX    0.0    0.0
DBMIRROR_DBM_EVENT    0.0    0.0
DBMIRROR_SEND    0.0    0.0
CURSOR_ASYNC    0.0    0.0
HTTP_ENUMERATION    0.0    0.0
SOAP_READ    0.0    0.0
SOAP_WRITE    0.0    0.0
DUMP_LOG_COORDINATOR    0.0    0.0
DISKIO_SUSPEND    0.0    0.0
IMPPROV_IOWAIT    0.0    0.0
QNMANAGER_ACQUIRE    0.0    0.0
DEADLOCK_TASK_SEARCH    0.0    0.0
REPL_SCHEMA_ACCESS    0.0    0.0
REPL_CACHE_ACCESS    0.0    0.0
SQLSORT_SORTMUTEX    0.0    0.0
SQLSORT_NORMMUTEX    0.0    0.0
SQLTRACE_WAIT_ENTRIES    0.0    0.0
SQLTRACE_LOCK    0.0    0.0
SLEEP_SYSTEMTASK    0.0    0.0
RESOURCE_SEMAPHORE    1687.0    0.0
DTC    0.0    0.0
OLEDB    0.0    0.0
FAILPOINT    0.0    0.0
ASYNC_DISKPOOL_LOCK    0.0    0.0
THREADPOOL    0.0    0.0
DEBUG    0.0    0.0
REPLICA_WRITES    0.0    0.0
BROKER_RECEIVE_WAITFOR    0.0    0.0
DBMIRRORING_CMD    0.0    0.0
WAIT_FOR_RESULTS    0.0    0.0
PAGEIOLATCH_DT    0.0    0.0
TRAN_MARKLATCH_NL    0.0    0.0
TRAN_MARKLATCH_KP    0.0    0.0
TRAN_MARKLATCH_SH    0.0    0.0
TRAN_MARKLATCH_UP    0.0    0.0
TRAN_MARKLATCH_EX    0.0    0.0
TRAN_MARKLATCH_DT    0.0    0.0
CURSOR    0.0    0.0
EXECSYNC    19812.0    0.0
SOSHOST_INTERNAL    0.0    0.0
SOSHOST_SLEEP    0.0    0.0
SOSHOST_WAITFORDONE    0.0    0.0
SOSHOST_MUTEX    0.0    0.0
SOSHOST_EVENT    0.0    0.0
SOSHOST_SEMAPHORE    0.0    0.0
SOSHOST_RWLOCK    0.0    0.0
SOSHOST_TRACELOCK    0.0    0.0
MSQL_XP    0.0    0.0
MSQL_DQ    0.0    0.0
LOGBUFFER    250.0    0.0
TRANSACTION_MUTEX    0.0    0.0
MSSEARCH    0.0    0.0
XACTWORKSPACE_MUTEX    0.0    0.0
CLR_JOIN    0.0    0.0
CLR_CRST    0.0    0.0
CLR_SEMAPHORE    0.0    0.0
CLR_MANUAL_EVENT    0.0    0.0
CLR_AUTO_EVENT    0.0    0.0
CLR_MONITOR    0.0    0.0
CLR_RWLOCK_READER    0.0    0.0
CLR_RWLOCK_WRITER    0.0    0.0
SQLCLR_QUANTUM_PUNISHMENT    0.0    0.0
SQLCLR_APPDOMAIN    0.0    0.0
SQLCLR_ASSEMBLY    0.0    0.0
KTM_ENLISTMENT    0.0    0.0
KTM_RECOVERY_RESOLUTION    0.0    0.0
KTM_RECOVERY_MANAGER    0.0    0.0
SQLCLR_DEADLOCK_DETECTION    0.0    0.0
QPJOB_WAITFOR_ABORT    0.0    0.0
QPJOB_KILL    0.0    0.0
BAD_PAGE_PROCESS    0.0    0.0
BACKUP_OPERATOR    0.0    0.0
PRINT_ROLLBACK_PROGRESS    0.0    0.0
ENABLE_VERSIONING    0.0    0.0
DISABLE_VERSIONING    0.0    0.0
REQUEST_DISPENSER_PAUSE    0.0    0.0
DROPTEMP    0.0    0.0
FT_RESTART_CRAWL    0.0    0.0
FT_RESUME_CRAWL    0.0    0.0
LOGMGR_RESERVE_APPEND    26000.0    0.0
LOGMGR_FLUSH    0.0    0.0
XACT_OWN_TRANSACTION    0.0    0.0
XACT_RECLAIM_SESSION    0.0    0.0
DTC_WAITFOR_OUTCOME    0.0    0.0
DTC_RESOLVE    0.0    0.0
SEC_DROP_TEMP_KEY    0.0    0.0
SRVPROC_SHUTDOWN    0.0    0.0
NET_WAITFOR_PACKET    0.0    0.0
DTC_ABORT_REQUEST    0.0    0.0
DTC_TMDOWN_REQUEST    0.0    0.0
RECOVER_CHANGEDB    0.0    0.0
WORKTBL_DROP    0.0    0.0
MIRROR_SEND_MESSAGE    0.0    0.0
SNI_HTTP_ACCEPT    0.0    0.0
SNI_HTTP_WAITFOR_0_DISCON    0.0    0.0
UTIL_PAGE_ALLOC    0.0    0.0
SERVER_IDLE_CHECK    0.0    0.0
BACKUP_CLIENTLOCK    0.0    0.0
DEADLOCK_ENUM_MUTEX    0.0    0.0
INDEX_USAGE_STATS_MUTEX    0.0    0.0
VIEW_DEFINITION_MUTEX    0.0    0.0
QUERY_NOTIFICATION_MGR_MUTEX    0.0    0.0
QUERY_NOTIFICATION_TABLE_MGR_MUT    0.0    0.0
QUERY_NOTIFICATION_SUBSCRIPTION_    0.0    0.0
QUERY_NOTIFICATION_UNITTEST_MUTE    0.0    0.0
IMP_IMPORT_MUTEX    0.0    0.0
RESOURCE_SEMAPHORE_MUTEX    0.0    0.0
IO_AUDIT_MUTEX    0.0    0.0
BUILTIN_HASHKEY_MUTEX    0.0    0.0
SOS_PROCESS_AFFINITY_MUTEX    0.0    0.0
MSQL_XACT_MGR_MUTEX    0.0    0.0
MSQL_XACT_MUTEX    0.0    0.0
QRY_MEM_GRANT_INFO_MUTEX    0.0    0.0
SOS_STACKSTORE_INIT_MUTEX    0.0    0.0
SOS_SYNC_TASK_ENQUEUE_EVENT    0.0    0.0
SOS_OBJECT_STORE_DESTROY_MUTEX    0.0    0.0
EE_PMOLOCK    0.0    0.0
RESOURCE_SEMAPHORE_QUERY_COMPILE    5546.0    0.0
RESOURCE_SEMAPHORE_SMALL_QUERY    0.0    0.0

PAGEIOLATCH_SH + SQLTRACE_BUFFER_FLUSH = скорее всего у тебя проблеммы с диском системы, там где темп дб и обычные темпы скуля лежат, смотри статистику диска C: особено очередь ожидания, если более 1 сек - то менять диски на более быстрые. Кстати если это виртуалка - возможно это проблеммы настроек.


CXPACKET - это излишний параллелизм, или слишком длинные блокировки. переходи на управляемые (тупо галочки везде поставь, в коде не нужно ничего менять)

(17)+
CXPACKET может такой быть если на скуле нет обнавления статистики

(17)+ с диском где лежат базы у тебя все нормально :)

(0)
Начни с того что запусти счетчики на сервере.
Включи просмотр очереди к диску. Если меньше дисков в рейде постоянно - покупка SSD бесполезна
http://ko.com.ua/monitoring_i_optimizaciya_diskovoj_podsistemy_servera_66663

Если очередь к дискам меньше кол дисков в рейде

(17) а как посмотреть статистику?

(18) как узнать?
да, вопросов много, не админ

(22) http://langslab.com/ebooks/techdocs/using-mssql

>> переходи на управляемые (тупо галочки везде поставь, в коде не нужно ничего менять)
Это ничем не чревато?

(23) как это работает
1. скуль строит план запроса, при этом каждую операцию оценивает на основании собраной статистики
2. делит план запроса на паралельные подзапросы и начинает их выполнять
3. если статистика давно не одновлялась, то возникает перекос один из подзапросов выполняется сильно дольше остальных (по тому что поделили не правильно) и остальные его ждут....

иногда обновление статистики дает прирост скорости в ДЕСЯТКИ раз....

(25)в теории чревато, на практике не встречал проблемм...

(26) это я понимаю, как узнать как часто обновляется статистика или когда последний раз это было?

(28)
Returns the date of the most recent update for statistics on a table or indexed view.

For more information about updating statistics, see Using Statistics to Improve Query Performance.

Transact-SQL Syntax Conventions

Syntax

STATS_DATE ( object_id , stats_id )


Arguments
object_id
ID of the table or indexed view with the statistics.

stats_id

(28) ссылка в (24) там все написано и с картинками даже...

на самом деле там все просто....

советую
обновлять статистику не реже 1 раз в час
индексирование - ночью 1 раз в день

не надо обновлять статистику раз в час. достаточно обновлять раз в день и после каждой массовой операции - пересчет итогов, загрузка больших объемов данных.

У меня обновление статистики - раз в день, дефрагментация индексов раз в день, реиндексация раз в неделю. По мануалу с инфостарта настраивал. База 22Гб и 70 юзеров. Все ок, вроде

(31) обновление статистики - фоновая операция практически не влияющая на пользовательские процессы.

Конечно дело вкуса, например на прошлой работе обновляли раз в 15 мин, и настраивали реальные дба админы :) правда там диасофт крутился :)

спасибо, вчитываюсь

(33)вот блин, зашел в ветку, теперь тоже хочу все на управляемые блокировки перевести.. аж руки чешутся :) Гилев за это много денег берет, а ты говоришь, можно просто галки поставить... Я прям теряюсь в нерешительности :) А обновление статистик поставлю, пусть чаще делаются, спасибо

А кстати никто не знает про дедлоки в управляемом режиме ?
Что то куча статей - но только про автоматический, типа в управляемом не должно быть. Но есть

(36) а новые типовые уже все на упр. блокировках?

(35) Подергай себя за гениталии чтоб руки не чесались. Если в голове нет четкого понимания, какие механизмы платформы работают только в режиме автоматических блокировок, а какие только в режиме управляемых - не трогай эти настройки.
(37) Да, автоматические даже на экзамене вне закона.

(27) как-то ссыкатно

(35) поставьте просто галку, будут проблемы, тогда обращайтесь :)

эксперименты откладываем на понедельник, а то пятница...

(33) это полный пересчёт или только изменившейся статистики? Полный может несколько часов занимать.

А если в управляемом режиме блокировок в транзакции проведения  идет чтение набора по регистратору то блокировка READ COMMITTED на таблицу итогов будет по измерениям набора ?

max degree of parallelism = 1 надо поставить, а то напокупали, панимаишь, 100500ядреные сервера...

а следующее - диски

Галка управляемые переводит запросы в обработках проведения из режима блокирование до конца транзакции в режим блокирования на время запроса.
Т.е. ДЛЯ ИЗМЕНЕНИЯ в запросах перестает работать.

Списывать в  минуса могут.

(46) поэтому и шустрее работать начинает, поэтому и обязательны управляемые блокировки на экзаменах.

(46) еще как будут минусы, поэтому у нас и работы не бесплатные

(47) но быстрее по этой причине не будет, отсутствие контроля разве что снизить вероятность взаимной блокировки да и то не факт
управляемые блокировки повышают параллельность за счет не накладывания блокировок, а за счет "оптимистичных" блокировок, наложенных вручную, в то время как автоматические блокировки накладывают "пессимистичные" блокировки

(0) авторы http://www.thg.ru/storage/obzor_24_ssd_dc_s3700_test/obzor_24_ssd_dc_s3700_test-01.html утверждают, что даже в програмнном рейде SSD дадут эффект

вот здесь http://forum.infostart.ru/forum16/topic98672/message1023427/?result=reply#message1023427 коллективно пришли к выводу :) что  наращивать мощность железо надо )

закладка

(44) а где это выставить?

(53) запросом

эх. взяли на тестирование IBM FlashSystem 810. сказка. загрузка данных из клюшек в УПП раза в 3-5 быстрее. проведение тоже...
но денег, похоже, на нее не дадут...

(25) Думаю черевато

если мы переводим документ в режим управляемых блокировок, то блокировки нужно прописывать вручную и составить хорошую структуру блокировок не так то просто для сложных документов.

(53) Бездумно выставлять случайные настройки без понимания для чего они нужны? Ну, ну. Продолжайте "ускорять 1С".

Что про мой результат сказать можете?
LAZYWRITER_SLEEP    35669440.0    21.8
XE_TIMER_EVENT    17948456.0    11.0
REQUEST_FOR_DEADLOCK_SEARCH    17946624.0    11.0
CHECKPOINT_QUEUE    17848156.0    10.9
LOGMGR_QUEUE    17944508.0    10.9
FT_IFTS_SCHEDULER_IDLE_WAIT    17823590.0    10.9
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    17908256.0    10.9
SLEEP_TASK    8991212.0    5.5
BROKER_TO_FLUSH    8975061.0    5.5
CXPACKET    2393097.0    1.5
LATCH_EX    99052.0    0.1
SLEEP_BPOOL_FLUSH    150569.0    0.1

(58) повелись на посты vde69 )))
все уже изобретено, ставьте http://www.gilev.ru/querytj/ , находите долгие запросы и оптимизируйте их

(59) Спасибо за ссылку. попробую на днях