Недавно столкнулся с необычным случаем: сервер 1С у заказчика работал отвратительно.
Чтобы было понятно, о чем речь, приведу пример: запуск толстого клиента может занять десять минут. Когда его измеряли? тест Гилева , то результат был ниже худшего.
Посмотрев непосредственные результаты измерений других пользователей, я понял, что это не единственный случай.
Мы не говорим об оптимизации, когда нужно повысить производительность на 10-20%, мы говорим о поиске причин низкой производительности и их устранении.
Согласитесь, это несколько разные вещи.
В Интернете есть масса статей о повышении производительности, которые ограничиваются лишь настройкой сервера 1С и (или) настройкой сервера базы данных.
Но я не встречал статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях.
Обычно администраторы спешат посмотреть результаты мониторинга.
Случай, с которым я столкнулся, показал практически нулевую загрузку процессора, наличие свободной оперативной памяти, отсутствие очереди на сетевом интерфейсе и только очередь на диск показала, что не всё в порядке.
Пришлось провести полную проверку, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но результат дает. Возможно, для кого-то такой подход неприемлем, более того, некоторые считают его непрофессиональным подходом, но я не могу им помочь.
Аппаратный уровень
Звучит банально, но начать стоит с проверки работоспособности оборудования.Дело в том, что о проблемах с железом можно только догадываться, если смотреть на уровень операционной системы.
В моем случае не работал один из дисков дискового массива.
Как ни странно, жёсткий диск оказался рабочим и, поставив его на место, начал работать, хотя мне пришлось немного подождать, пока все данные синхронизируются (он вроде давно был отключен).
Если бы все закончилось так, то этой статьи не было бы.
На всякий случай сервер прошел аппаратное тестирование (стресс-тесты, тест памяти, физическая проверка дисков и контроллеров), которое не выявило никаких проблем.
Уровень операционной системы
Вторым пунктом нашей программы была проверка и настройка операционной системы, суть которой заключается в следующем:- привести в порядок файловую систему;
- отключить ненужные службы, удалить ненужные и главное вредоносные программы;
- проверьте оптимальные настройки операционной системы.
Речь идет о:
- проверка логической структуры диска;
- удаление временных и ненужных файлов;
- дефрагментация файловой системы.
В моем случае после приведения файловой системы в порядок сервер немного «ожил», но этого все равно было недостаточно.
Зачем нужна антивирусная проверка и отключение неиспользуемых сервисов, думаю, объяснять не нужно, но пренебрегать этим не стоит. Посмотрите, возможно на этом сервере были установлены какие-то программы, которые уже не нужны.
Ну и обновите систему и программы.
Что касается оптимальных настроек операционной системы, то в моем случае был установлен режим энергосбережения.
После включения режима максимальной производительности тест Гилева показал удовлетворительные результаты, но именно этот сервер должен был показать лучшие результаты.
Для выяснения причин отслеживалось использование ресурсов, хотя с самого начала было понятно, что нужно искать те процессы, которые занимают большую часть дисковой подсистемы.
В моем случае лучшим показателем была «Длина очереди диска».
Напомню, остальные показатели были в норме, конечно немного изменились по сравнению с исходными, но в целом показатель остался длиной очереди к диску.
Результаты мониторинга были очевидны: «ворами» ресурсов оказались процессы сервера 1С и сервера баз данных.
Уровень обслуживания
В моем случае сервер 1с располагался вместе с сервером базы данных MS SQL на одной машине, но аппаратная конфигурация сервера полностью обеспечивала их совместную деятельность, а вот настройки этих двух сервисов были совсем не оптимальными.Этим настройкам посвящено множество статей, например, этот , здесь мы остановимся только на тех, которые не требуют дополнительных вложений, например, на покупке жесткого диска.
Для сервера MS SQL в каждой базе значения параметра авторасширения базы были увеличены до 500 МБ, так как базы данных 1С быстро растут. Также был настроен план ежедневного обслуживания, в который помимо создания дампа базы данных добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов.
В моем случае это значительно уменьшило количество операций записи.
В качестве дополнительных мер можно рекомендовать еженедельную дефрагментацию базы данных и реорганизацию индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество подключений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Такой совет больше похож на «танцы с бубен», но они дают результат. В данном случае изменение этих параметров привело к значительному сокращению операций чтения-записи на сервере, и все сработало как положено.
Тест Гилева также подтвердил повышение производительности.
Базовый уровень
Проведя измерения под нагрузкой и после выхода пользователей из системы, я наткнулся на странный результат — под нагрузкой тест Гилева показал лучшие результаты, чем в простое! Также было замечено, что на тестовых базах данных выполняется огромное количество фоновых заданий.Тестовые базы данных использовались системными администраторами для выполнения различных тестовых задач.
Я попросил их удалить - и все стало на свои места.
Конечно, решать вам, стоит ли хранить тестовые базы на рабочем сервере, но лучше найти для этого какое-то другое решение, например, использовать файловый вариант. Для одной из баз данных не удалось уменьшить журнал транзакций, а для другой базы индексы не были воссозданы.
Для обоих случаев есть одно простое и эффективное решение.
Прежде чем описать это, следует уточнить, что здесь мы имеем одно и то же имя для разных объектов: базы данных 1С и базы данных MS SQL, причем первые могут быть не базами данных MS SQL, а, например, базами данных PostgreSQL. В свою очередь последние не обязательно будут базами для 1С.
Исходя из этого, резервные копии баз 1С (dt-файл) можно разворачивать и на других СУБД, но никто не запрещает развертывать из этой же копии и на MS SQL. Делаем резервные копии баз 1С средствами 1С, затем удаляем базы 1С с сервера 1С, а затем создаем их заново, заливая содержимое из файла dt. Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал бесперебойно, дисковая подсистема работала в штатном режиме, пользователи были довольны быстрой работой в 1с, администраторы удивлялись тому, как быстро теперь выполняются обновления.
Заключение
Если для поиска причин низкой производительности использовать только один уровень, то можно игнорировать причины, лежащие на других уровнях, то есть результат не будет достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне.Надеюсь, что этот материал поможет кому-то побороть проблему низкой производительности сервера 1С.
Теги: #Администрирование сервера #Администрирование базы данных #сервер ms sql #windows server 2008 #1c server
-
Сведберг, Теодор
19 Oct, 24 -
Компания
19 Oct, 24 -
Блог Компании Z-Wave.me
19 Oct, 24 -
На Другой Стороне Стенда
19 Oct, 24
