Еще раз, по-новому: производительность 1С: 7.7/1С: 8 + SQL
Еще один подход к увеличению производительности 1C+SQL = использование RAM-дисков
- Описание
- Подробнее
Описание
По оптимизации 1С+SQL = в инете много информации.
В большинстве случаев (1с77/1с8х) всё рекомендации, методики и алгоритмы сводятся к двум вещам:
— оптимизация индексов и статистики
— управление блокировками
При этом предполагается «вмешательство» в стандартные структуры и процедуры БД от 1С…..
Вот к чему я пришел:
У всех этих методов есть существенный недостаток:
— если вмешиваться в штатные механизмы от 1С: тогда сложно поддерживать восстановление своих «хотелок» после реструктуризации БД — …
Предлагаю собственно иной взгляд и подход: посмотрим на родные средства сервера SQL+Win и попробуем оптимизировать скорость только «там», не изменяя «коробочные» технологии от 1С.
* В БОЛЬШИНСТВЕ СЛУЧАЕВ СТАНДАРТНЫЕ МЕХАНИЗМЫ 1С «ИЗ КОРОБКИ» ОПТИМАЛЬНЫ (в 90%)
* НЕ ОПТИМАЛЬНЫ (как правило) НАШИ ДОПОЛНИТЕЛЬНЫЕ «навески» НА ТИПОВЫЕ РЕШЕНИЯ
— либо потому что мы чего-то не знаем
— либо потому что этот «узкоспециализированный костыль» по другому не работает
В результате мы начинаем оптимизировать «всё» и «вся» , жадно вычитывая решения из интернет……
Я же предлагаю (исходя из соображения стоимости сопровождения) по-иному взглянуть на проблему:
1) свои ошибки (внутри 1С) исправлять (однозначно)
2) бросить затею «оптимизировать 1С» — вместо этого посмотрим на САМ сервер WIN+SQL
В моем случае (на одной площадке, сервере) имеем 8шт 1С7.7 баз + 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+Win:
| 1) настроки Win для SQL читаем здесь: www.sql.ru/blogs/gladchenko/332 | ||||||||||||||||||||||||||||||||||||
2) настройки собственно самого SQL (у меня такие — методом проб и экспериментов, для этого железа): | ||||||||||||||||||||||||||||||||||||
|
| 3) выносим tempdb — на RAM-диск в 2Гб (я пользуюсь imDisk Toolkit-ом, ни разу не подводил, GPL) |
| 4) для всех баз устанавливаем такие параметры (много раз писалось, приведу еще раз для общей картины): |
| recovery model | simple | обсуждалось много раз |
| autocreate stat | off | |
| autoupdate stat | off | |
| асинхронное обновление статистики | on | на всякий случай |
| page verify | torn page detection | или вообще NONE: надежность вряд ли пострадает, скорость выше |
| files | * если более 1 (физического) массива дисков — разностим MDF/LDF (иначе не обращаем внимания) * путь к файлам MDF/LDF — должен быть без длинных путей (т.е. переностим все MDF/LDF файлы в корень диска/ков) * но не на диске С:\ (естественно) * помним про autogrow и прочее…(думаем) | |
| регламенты | еже-ночные: 1) _1sp_dbreindex 2) full backup |
5) В СЛУЧАЕ МОНОПОЛЬНОГО ПЕРЕПОВЕДЕНИЯ БАЗЫ (1С77) :
делаем «финт ушами»:
— средставим тогоже imDisk создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)
— переносим туда БД (backup/restore в новое место)
— выставляем: autocreate stat / autoupdate stat = ON
— запускаем _1sp_DbReindex + sp_updatestats
— проводим базу
— выставляем: autocreate stat / autoupdate stat = OFF
— опять backup и restore на диск, на старое место…
6) если RAM совсем много: переносим «туда» нашу БД «на всегда» :
при этом:
— каждые 10 минут FULL BACKUP
— при старте SQL — агентом вызываем скрипт для restore
— при стопе SQL — агентом вызываем скрипт для full backup
Все остальные способы (индексы и прочее)
— именно в случае вмешательсва в стандартные структуры и процедуры от 1С-ки
— дают выигрыш в производительности максимум 10-15%
— при этом затрат на обслуживание (времени) уходит просто уйма.
А с учетом того что память и диски сегодня стоят ….
Проще наростить мощность сервера и вынести (когда нужно) базу в память…
Я пошел экстенсивным путем.
Всё это — к обсуждению 
Критика приветсвуется.
