Имя: Пароль:
1C
Админ
v8: Поиск узкого места (1c82, MSSQL, ESXi)
0 nosovk
 
29.01.13
14:43
Добрый день!
Столкнулся пару недель с проблемой медленоой работы 1с на сервере, и никак не могу побороть. Проблема в том что ресурсы израсходованны не все, в то время как простейшая команда "Операции - Проведение Документов" само окошко с выбором чего проводить может открывать 3-6 секунд. Проведение же документа может быть и того дольше.

На esxi есть виртуальные машины
1с01 - 20Gb RAM, 12CPU
1c02 - 10Gb RAM, 12CPU - резерный по отношению к 1с01
sql01 - 6Gb RAM, 4CPU
ts01 - 16Gb, 4CPU - терминальные сервера
ts02 - 8Gb, 4CPU - делят 50 на 50 все подключения

В 1с около 30 баз.
Подозревая что тормоза происходят из-за количества баз:
На сервере подняты четыре кластера на портах: 1541/1542/1543/1544. Все базы разделенны между четырьмя кластерами. Регулируя количество процессов в кластере я могу гипотетически менять производительнось группы баз. (На самом деле тормозит все так, что нет особо смысла что-то менять)

Настройки 1с01
Кластер 1541 = Активных сеансов 15
2 рабочих процесса
1 Резервный
Кластер 1542 = Активных сеансов 8
3 рабочих процесса
1 Резервный
+ на сервере 1с02 2 рабочих и 1 резервный
Кластер 1543 = Активных сеансов 3
2 рабочих процесса
1 Резервный
Кластер 1544 = Активных сеансов 0 (регламентые задания по мониторингу)
1 рабочий процесс
1 Резервный
Итого 8 рабочих процессов, 4 резервных + 2рабочих и 1 резервный на 1с04

По поводу ресурсов - загруженность процессора близится к 0-5%, очереди записи на диск - нету, сеть между виртуалками 100МБит, оперативная память 1с03 остается свободной 3-4гб.
Все базы типовые, регламентированные задания у всех кроме баз мониторинга выключены.
Тормозит эта конструкция неимоверно. Замеры АПДЕКС встроенные в УПП показывают сплошные 0-0,25. Регламентные процедуры переиндексации и обновления статистики в sql настроенны.
1 Галахад
 
гуру
29.01.13
14:48
А чего так сильно SQL обделили?
2 zva
 
29.01.13
15:22
1с01 - 20Gb RAM, 12CPU
sql01 - 6Gb RAM, 4CPU

1. Я бы поменял конфигурацию серверов  точностью до наоборот
2. По поводу кучи рабочих процессов:
цитата с итс:
"В 32-разрядном сервере "1С:Предприятия" запуск нескольких rphost позволяет лучше использовать оперативную память сервера и снизить издержки от фрагментации памяти.
В 64-разрядном сервере "1С:Предприятия" один rphost может полностью использовать и оперативную память, и процессорные ресурсы сервера.
Поэтому для 64-разрядного сервера "1С:Предприятия" нормальным следует считать запуск одного рабочего процесса на один сервер.
Из-за ошибок в платформе "1С:Предприятие" и в конфигурациях возможны аварийные завершения процессов rphost. Запуск нескольких рабочих процессов снижает критичность аварийного завершения одного рабочего процесса. Аварийные завершения рабочих процессов нельзя считать их нормальным поведением. Если подобные случаи наблюдаются в процессе эксплуатации "1С:Предприятия", то целесообразно провести необходимые расследования для выявления причин и устранения подобных ситуаций. Запуск нескольких рабочих процессов в данном случае можно считать временной мерой для снижения издержек от нестабильной работы сервера.
Большое количество рабочих процессов:
увеличивает издержки на служебные вызовы между процессами сервера "1С:Предприятия" и может привести к снижению общей производительности системы;
занимает дополнительные IP порты (по 2 на каждый процесс). Диапазоны портов, определенные по умолчанию, могут оказаться недостаточными;
повышает общую сложность поведения сервера "1С:Предприятия".
Рекомендуется начинать наладку системы на базе "1С:Предприятия" с одного рабочего процесса на сервер, и только при наличии необходимости увеличивать их количество.
"
Закон Брукера: Даже маленькая практика стоит большой теории.