Сам админ, не программист.
Имею сервер HP proliant DL380 G7, 2 процессора Е5630 @ 2.53 GHz,72Gb ОЗУ DDR3 2132MHz, 3 тома RAID1, диски все SAS 10k 6G, 300GB, RAID smart array p410i , write cashe отключен. Включены режим электропитания высокая производительность, согласно рекомендациям сервера hp так же в bios настроено высокая производительность.
Первая виртуальная машина (ВМ) терминал.
Вторая ВМ 1с Сервер + SQL.
Под нее выделено два тома RAID1. 2008r2 + mssql 2005 sp4(лицензия) + платформа 8.3.13.1690.
ВМ выделено 12 Виртуальных процессоров. озу 55GB, sql отдано 39GB ОЗУ.
TempDB - находятся на системном диске начальный размер 512 мб, приращение 512мб , Data весит 1Гб и log менее 512Мб. Лог и данные находятся вместе, на отдельном диске. Протокол sharedmemory включен.
Сделаны оптимизации по тесту Гилёва. Получаю ~13 условных"попугаев". На физической получаю ~25 попугаев.
Лишнего ПО нет, всё стоит по минимуму, антивируса нет.
Но суть в другом - долгая обработка ЗУП 3.1, что на ВМ, что на физической. При выполнении тестов на физической машине, все ВМ останавливал, разницу заметил не существенную, 9 сек на ВМ, и 7-8 сек на физической. Операция расчетный листок сотрудника за 1 месяц.
Пробовал отключить hyper threading , получил падение производительности системы в целом, вернул обратно.
Запустил тест SQL
И вижу, что ASYNC_NETWORK_IO имеет высокие показатели. Судя по описанию автора скрипта, этот тип ожидания говорит о том, что sql ждет пока клиент заберет данные, т.е. ждет сервер 1с. Как понимаю дело не в MSSQL, а в том, что сервер 1с "долго" забирает данные у MSSQL.
Что самое удивительно рядом находятся несколько других баз, 18 баз включая тестовые , 6 постоянно работающих размером суммарным объемом 47 ГБ . Количество пользователей не более 30 чел.
Настроил счетчики производительности на виртуальной машине, забирает zabbix, скрин приложил.
Единственный показатель который часто превышает показатели, это счетчик "Система\Контекстных переключений/с" - средний показатель 5,23 тыс
Как найти проблему и что сделать для улучшения производительности ЗУП 3.1 ? Есть вариант конечно, что купить пару SSD в raid1, диски на 15к 4шт raid10 под базы, но сумма выходит примерно 1/3 от нового сервера и возникает вопрос в актуальности такого решения? Мне кажется, что проблема больше в процессоре, чем в дисковой подсистеме.
Подскажите, в какую сторону копнуть?
Имею сервер HP proliant DL380 G7, 2 процессора Е5630 @ 2.53 GHz,72Gb ОЗУ DDR3 2132MHz, 3 тома RAID1, диски все SAS 10k 6G, 300GB, RAID smart array p410i , write cashe отключен. Включены режим электропитания высокая производительность, согласно рекомендациям сервера hp так же в bios настроено высокая производительность.
Первая виртуальная машина (ВМ) терминал.
Вторая ВМ 1с Сервер + SQL.
Под нее выделено два тома RAID1. 2008r2 + mssql 2005 sp4(лицензия) + платформа 8.3.13.1690.
ВМ выделено 12 Виртуальных процессоров. озу 55GB, sql отдано 39GB ОЗУ.
TempDB - находятся на системном диске начальный размер 512 мб, приращение 512мб , Data весит 1Гб и log менее 512Мб. Лог и данные находятся вместе, на отдельном диске. Протокол sharedmemory включен.
Сделаны оптимизации по тесту Гилёва. Получаю ~13 условных"попугаев". На физической получаю ~25 попугаев.
Лишнего ПО нет, всё стоит по минимуму, антивируса нет.
Но суть в другом - долгая обработка ЗУП 3.1, что на ВМ, что на физической. При выполнении тестов на физической машине, все ВМ останавливал, разницу заметил не существенную, 9 сек на ВМ, и 7-8 сек на физической. Операция расчетный листок сотрудника за 1 месяц.
Пробовал отключить hyper threading , получил падение производительности системы в целом, вернул обратно.
Запустил тест SQL
И вижу, что ASYNC_NETWORK_IO имеет высокие показатели. Судя по описанию автора скрипта, этот тип ожидания говорит о том, что sql ждет пока клиент заберет данные, т.е. ждет сервер 1с. Как понимаю дело не в MSSQL, а в том, что сервер 1с "долго" забирает данные у MSSQL.
Что самое удивительно рядом находятся несколько других баз, 18 баз включая тестовые , 6 постоянно работающих размером суммарным объемом 47 ГБ . Количество пользователей не более 30 чел.
Настроил счетчики производительности на виртуальной машине, забирает zabbix, скрин приложил.
Единственный показатель который часто превышает показатели, это счетчик "Система\Контекстных переключений/с" - средний показатель 5,23 тыс
Как найти проблему и что сделать для улучшения производительности ЗУП 3.1 ? Есть вариант конечно, что купить пару SSD в raid1, диски на 15к 4шт raid10 под базы, но сумма выходит примерно 1/3 от нового сервера и возникает вопрос в актуальности такого решения? Мне кажется, что проблема больше в процессоре, чем в дисковой подсистеме.
Подскажите, в какую сторону копнуть?
Прикрепленные файлы:
По теме из базы знаний
- ЗУП 3.1: Проверка адресов сотрудников
- Пакетная загрузка/выгрузка табеля/табелей из/в Excel для ЗУП 3.1
- Сводный отчет о среднем заработке. ЗУП 3.1
- Пример создания кадрового отчета для ЗУП 3.1
- Система интерактивных ролей и обработчиков с возможностью интерактивной настройки и не только (платформа 8.3.17+, расширение) для УТ 11 (все), КА 2, ERP 2, Розница 2, УНФ 1.6/3.0, БП 3, ЗУП 3.1, ААА 6
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
А в чём проявляется "долгая обработка" ?
У меня вот то же по сравнению с ЗУП 2.5 в ЗУП 3.1 всё тормозит безбожно, но у меня они на одном сервере и в каждой работают по 30+ пользователей.
И в ЗУП 3 всё работает в раза два или три дольше чем в 2.5. Количество сотрудников одинаковое, параллельно ведём учёт первого квартала в двух базах.
Но суть в другом - долгая обработка ЗУП 3.1, что на ВМ, что на физической.
А в чём проявляется "долгая обработка" ?
У меня вот то же по сравнению с ЗУП 2.5 в ЗУП 3.1 всё тормозит безбожно, но у меня они на одном сервере и в каждой работают по 30+ пользователей.
И в ЗУП 3 всё работает в раза два или три дольше чем в 2.5. Количество сотрудников одинаковое, параллельно ведём учёт первого квартала в двух базах.
(3) Симптомы:
Расчетный листок,где собираются данные по сотруднику по которому производится расчет ЗП за месяц, с учетом вычетов. Если ЗУП 2.5 получение того же расчетного листка занимает ~4 сек, то в ЗУП 3.1 ~8 сек и выше до 12 сек. ( как по вашему коэффициенту 2-3раза ) бухгалтер естественно жалуется на тормоза, т.к. таких надо обработать около 300 чел.
Расчетный листок,где собираются данные по сотруднику по которому производится расчет ЗП за месяц, с учетом вычетов. Если ЗУП 2.5 получение того же расчетного листка занимает ~4 сек, то в ЗУП 3.1 ~8 сек и выше до 12 сек. ( как по вашему коэффициенту 2-3раза ) бухгалтер естественно жалуется на тормоза, т.к. таких надо обработать около 300 чел.
(5) Увы, но ничего не попишешь. Новые конфигурации (УФ - "управляемые формы"), такие как ЗУП 3.1 вместо ЗУП2.5 и БП3.0 вместо БП2 - медленнее своих предшественников. Это факт. И ничего с этим по-сути не поделаешь.
На мой субъективный взгляд это следствие изменения архитектуры - теперь применяется "настоящее" деление на клиент и сервер, почти все данные обрабатываются на сервере. Сделано это в угоду действительно больших внедрений на тысячи пользователей.
Вспомните про то что 1С в файловом режиме (база в виде файла, а не sql) изначально быстрее чем серверный вариант. Но с ростом числа пользователей sql очень медленно теряет производительность (иными словами, начинает слегка подтормаживать от большого числа пользователей) - в то время как файловый вариант зачастую просто "встает колом" уже на 50 пользователях.
Тут видимо та же аналогия.
На мой субъективный взгляд это следствие изменения архитектуры - теперь применяется "настоящее" деление на клиент и сервер, почти все данные обрабатываются на сервере. Сделано это в угоду действительно больших внедрений на тысячи пользователей.
Вспомните про то что 1С в файловом режиме (база в виде файла, а не sql) изначально быстрее чем серверный вариант. Но с ростом числа пользователей sql очень медленно теряет производительность (иными словами, начинает слегка подтормаживать от большого числа пользователей) - в то время как файловый вариант зачастую просто "встает колом" уже на 50 пользователях.
Тут видимо та же аналогия.
То что вы описываете - не тормоза , а субъективное ощущение замедленной работы после ЗУП 2,5...
Привыкнут ваши бухгалтера! У меня примерно такие же параметры системы, но без виртуалки. Расчетный листок открывается за 12 сек на 1 человека а на 400 открывется за 40сек.
Запросы в ЗУП 3.1 патологически медленные.
Это совершенно не показатели тормозов! Сколько сек проводятся документы?
Но по любому - как вы сами убедились виртуальная машина вносит свои тормоза...
Поэтому все опытные 1С-ники не рекомендуют ставить 1С на виртуалки.
Привыкнут ваши бухгалтера! У меня примерно такие же параметры системы, но без виртуалки. Расчетный листок открывается за 12 сек на 1 человека а на 400 открывется за 40сек.
Запросы в ЗУП 3.1 патологически медленные.
Это совершенно не показатели тормозов! Сколько сек проводятся документы?
Но по любому - как вы сами убедились виртуальная машина вносит свои тормоза...
Поэтому все опытные 1С-ники не рекомендуют ставить 1С на виртуалки.
Тест "Гилева", делал на SQL или файловый вариант ?
E5630 ,частота 2,5, мало, 1С любит частоту, больше чем кол-во ядер.
У клиента был сервак с двумя Xeon E5645 2,4, с УТ 11, жаловался на долгое проведение документов, тест показывал ~25 попугаев, заменили процы на Xeon X5450 3.0 ГГц, получили ~ 50 попугаев.
E5630 ,частота 2,5, мало, 1С любит частоту, больше чем кол-во ядер.
У клиента был сервак с двумя Xeon E5645 2,4, с УТ 11, жаловался на долгое проведение документов, тест показывал ~25 попугаев, заменили процы на Xeon X5450 3.0 ГГц, получили ~ 50 попугаев.
(7) Ядра тоже важны для количества пользователей.
100 пользователей при частоте 4 ГГц и 4 ядрах замучаются работать, а при 2.5 ГГц и скажем 48 ядер у нас чувствуют себя прилично...
То есть тест то покажет 50 попугаев, но клиентам не хватит свободных ядер для всех своих rphost-ов - будут конкретные зависания
То есть подход должен быть комплексный, учитывающий число пользователей...
100 пользователей при частоте 4 ГГц и 4 ядрах замучаются работать, а при 2.5 ГГц и скажем 48 ядер у нас чувствуют себя прилично...
То есть тест то покажет 50 попугаев, но клиентам не хватит свободных ядер для всех своих rphost-ов - будут конкретные зависания
То есть подход должен быть комплексный, учитывающий число пользователей...
(17) может. Это же тест "Попугаев".
Кроме того, автор сменил многоядерный на малоядерныйно с большей частотой. Даже на десктопный i7.
Кстати, Fragster (Ежов) тоже писал что всякие десктопные i3-i5 дают фору любому xeon.Вот:
Другое дело, что синтетические тесты это одно, а реальная работа конкретной базы на конкретном железе - другое.
Кроме того, автор сменил многоядерный на малоядерныйно с большей частотой. Даже на десктопный i7.
Кстати, Fragster (Ежов) тоже писал что всякие десктопные i3-i5 дают фору любому xeon.Вот:
Другое дело, что синтетические тесты это одно, а реальная работа конкретной базы на конкретном железе - другое.
после перехода на ЗУП.3 - ощутив все тормоза УФ - пользователи выли - покупали новые сервера - скорость немного улучшалась... пользователи постепенно успокаивались, а точнее , привыкали....
А какая у тебя задача в данном случае? Если тебе поручили разобраться, почему он тормозит как штатному сотруднику, то в 3.1.9 сильно пересмотрена структура расчета, в частности изменена обработка "МенеджерРасчетаЗарплаты" на более оптимальное выполнение. Возможно и за остальные проблемные участки конфигурации тоже скоро возьмутся. Другое дело, что с этим оптимальным расчетом пришло неоптимальное количество косяков и ошибок, поэтому система пока не в деле. Т.е. разработчики официально признали, что тройка тормозит неприлично и решили ее переделать
(22) Да, именно разобраться почему тормозит. Все настройки оптимизации sql я постарался реализовать по максимуму, но эффекта не получил. После пояснений в сообщениях стало понятна причинно-следственная связь. Да и опыт на другой машине всё подтвердил. При высокой частоте процессора обработка нужной операции ведется удовлетворительно, "как в старом" ЗУП 2,5.
Пока сделал предложение заменить процессоры на топовые из 1366, по частоте выше на 38%, потом постараюсь переехать на физическую машину. Дальше уже будет потолок. Вваливать в сервер деньги контроллер + ssd + 15к sas - около 100тыс, мне кажется уже не разумным действием. Прирост существенный даст только процессор.
Пока сделал предложение заменить процессоры на топовые из 1366, по частоте выше на 38%, потом постараюсь переехать на физическую машину. Дальше уже будет потолок. Вваливать в сервер деньги контроллер + ssd + 15к sas - около 100тыс, мне кажется уже не разумным действием. Прирост существенный даст только процессор.
Сам внедрял ЗУП на 600 сотрудников.
Суть в том, что ЗУП не рассчитана на обработку начислений по одному человеку. Как минимум по подразделениям или организации в целом.
И тогда заполнение и проведение документа кажется не таким уж тормазнутым. У меня получалось, что на одного сотрудника 35-40 секунд, что на 600 человек 40-60 секунд. Потом мы сделали странный финт ушами. Стали работать с ЗУП, через веб сервер Апач. И скорость заполнения / проведения документа улучшилась до 10-16 секунд.
Почему так, не знаю...
Суть в том, что ЗУП не рассчитана на обработку начислений по одному человеку. Как минимум по подразделениям или организации в целом.
И тогда заполнение и проведение документа кажется не таким уж тормазнутым. У меня получалось, что на одного сотрудника 35-40 секунд, что на 600 человек 40-60 секунд. Потом мы сделали странный финт ушами. Стали работать с ЗУП, через веб сервер Апач. И скорость заполнения / проведения документа улучшилась до 10-16 секунд.
Почему так, не знаю...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот