По сабжу - в инете много инфы.
В большинстве случаев (по 1с77) всё сводится к 2м вещам:
- оптимизация индексов и статистики
- управление блокировками
Но у всех этих методов есть существуенный недостаток:
- сложно поддерживать для случая когда выполнена реорганизация (реструктуризауия) БД средставми 1с-ки...
Предлагаю посмотреть собственно на средства сервера SQL
и оптимизировать скорость только там, не вмешиваясь в технологии от 1С.
Имеем
8шт 1С77 баз +
3 штуки 1С8, одна из которых УПП
Все разного размера и интенсивности.
Как угодить всем?
Вот к чему я пришел:
железо (минимум, для моего объема)* 2xCPU, 48Gb RAM, RAID-10 SAS 8x300Gb
* сеть: 1Гбит
* сервер = виртуализация (proxmox), на котором
- MS Терминал (4-8 ядер, RAM из расчета 128-512Мб на юзверя)
- MS SQL 2008r2 (16 ядер, 24Гб RAM)
- остальные VM: в этом топике - не важно
По настройкам SQL:1) для винды читаем здесь:
www.sql.ru/blogs/gladchenko/3322) настройки сиквеля (у меня такие - методом проб и экспериментов, для этого железа):
backup compression default 1
default trace enabled 0
lightweight pooling 0
priority boost 1
max worker threads 8192
network packet size (B) 8192
max degree of parallelism 64 (заставляем принудительно SQL использовать все ядра, что имеются)
cost threshold for parallelism 1 (если запрос долше 1сек - параллелим его)
locks 50000 (не будем считать проблемой количество блокировок вплоть до этого значения)
max server memory (MB) 22528 (22 = 24Гб - 2Гб под ОС)
min memory per query (KB) 1024
min server memory (MB) 0
query wait (s) 2147483647 (ждем пока любой пришедший запрос не будет отработан - до конца)
recovery interval (min) 60 (уменьшаем количество чекпоинтов = 1 раз/час)
remote query timeout (s) 600
3) выносим tempdb - на RAM-диск (я пользуюсь imDisk-ом, не подводил, GPL)
4) все базы
* simple
* autocreate stat / autoupdate stat = off
* асинхронное обновление статистики = да (на всякий случай)
* page verify = torn page detection (надежность вряд ли пострадает, скорость выше)
* если более 1 (физического) массива дисков - разностим MDF/LDF (иначе не обращаем внимания)
* путь к файлам MDF/LDF - должен быть без длинных путей
(т.е. переностим все MDF/LDF файлы в корень диска/ков)
* еже-ночные: (а) _1sp_dbreindex (б) full backup
В СЛУЧАЕ МОНОПОЛЬНОГО ПЕРЕПОВЕДЕНИЯ БАЗЫ 1С77:
делаем финт ушами:
- средставим тогоже imDisk создаем RAM диск размером 20Гб
- переносим туда БД (backup/restore в новое место)
- выставляем: autocreate stat / autoupdate stat = ON
- запускаем _1sp_DbReindex + sp_updatestats
- проводим базу
- выставляем: autocreate stat / autoupdate stat = OFF
- опять backup и restore на диск, на старое место...
Все остальные извращения (индексы и прочее)- именно в случае вмешательсва в стандартные структуры и процедуры от 1С-ки
- дают выигрыш в производительности максимум 10-15%
- при этом затрат на обслуживание (времени) уходит просто тьма.
А с учетом того что память и диски сегодня стоят ....
Проше наростить мощь сервера и выносить (когда нужно) базу в память...Я пошел экстенсивным путем.
Топик: к обсуждению