8.х Медленная работа регистров бухгалтерии в клиент-сереверном варианте 1С 8.2

Тема в разделе "Установка платформы "1С:Предприятие 8"", создана пользователем sektet, 26 янв 2011.

  1. TopicStarter Overlay
    sektet
    Offline

    sektet

    Регистрация:
    26 янв 2011
    Сообщения:
    4
    Симпатии:
    0
    Баллы:
    1
    Столкнулся с такой проблемой - очень медленно записывается и очищается набор записей регистра бухгалтерии в клиент-серверном варианте работы 1С 8.2:
    Создаю набор записей, заполняю его (15 тысяч записей), после заполнения записываю его и вот сама запись продолжается 12-15 мин. В файловом варианте запись длится 1-1.5 мин. То же самое с очисткой того же набора записей, в серверном варианте 12-15 мин. в файловом 1-1.5, причём очищается набор записей в серверном варианте даже дольше чем записывается. Сервер 1С и SQL крутятся на одной машине, железо довольно мощное - 8 ядер, 8 гигов памяти, запущено 2 процесса rphost, пользователь 1 (переношу остатки). В момент записи/очистки одно из ядер грузится на 100%.
    Подскажите пожалуйста - это нормально или нет, в чём может быть проблема?
  2. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    Какой размер базы на сервере (изначально и после загрузки), какая дисковая подсистема на сервере.
  3. TopicStarter Overlay
    sektet
    Offline

    sektet

    Регистрация:
    26 янв 2011
    Сообщения:
    4
    Симпатии:
    0
    Баллы:
    1
    Размер базы 6Гб (900 мб данные 5 Гб лог) - это до загрузки, после загрузки не могу посмотреть потому как сейчас не на работе, вообще вроде не должен измениться поскольку я уже неоднократно загружал и удалял в ней данные (пишу обработку по переносу остатков), при этом базу SQL не сжимал. Дискова подсистема - 6 винтов SATA по 140Гб объединенных в RAID10(аппаратный). MS Server 2008 + MS SQL 2008, конфигурация 1С Бухгалтерия предприятия редакция 2.0. Мы только переходим на 1С 8.2 с 7.7, поэтому опыта ни какого, и не знаю может это нормально?
  4. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    К сожалению, это может быть всё что угодно, а инфы мало. Если интересно начните с мониторинга трех основных счетчиков производительности в момент записи/удаления - загрузка процессора (понятно) , обмен страниц/сек (обозначает количество страниц, которые переносятся из RAM в файл подкачки) - в среднем должно быть меньше 20 (пики допустимы, но если все 10-15 минут значения намного больше - значит недостаток оперативки), средняя длина очереди к дискам (норм. значение 2*количество дисков, т.е. 16) - зависит как от обращения к БД, так и от нехватки RAM, нужно смотреть в связке с предыдущим счетчиком.
    ОС 32-битная или 64-битная? При 32-битной версии ОС, насколько я помню, нужно делать какие-то шаманства, чтобы увидеть RAM больше 4Gb, и в самом SQL Server'e включить режим AWE.
  5. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    Просмотрел этот момент :angry:
    В в свойствах SQL Server ,на закладке Memory назначить минимальный размер памяти хотя бы 2 Гб, на закладке Processors проверить - все ли ядра используются, на закладке Advanced можно попробовать увеличить значение Max Degree of Parallelism (отвечает за то, сколько ядер может использоваться при выполнении запроса), уменьшить значение Cost Threshold for Parallelism.
  6. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    BVB_berserk, а такой вопрос: если мы увеличиваем Max Degree of Parallelism - получается мы снижаем скорость параллельной работы пользователей? Ведь если количество ядер одно на один запрос, то получается на четырехядерном процессоре у нас сможет идти паралельная обработка четырех запросов, а так если мы скажем увеличим до двух - то получится только 2 запроса паралельно. Так? Или я что-то не правильно понимаю?
  7. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    Смысл в том, что запросы идут разного веса. Если у тебя строго по одному ядру на запрос, то может получиться ситуация, когда 1 пользователь ждёт результат своего мега-запроса (его ядро висит в 100%), а остальные 3 ядра ничего не делают, т.к. все ушли на обед :)
    Но даже в ситуации, когда запрос (допустим) занял все 4 ядра, остальные запросы не будут тупо ждать, когда же он завершится. На каждый запрос SQL Server создаёт worker thread, которые и обрабатывает CPU, выделяя каждому worker thread своё время, т.е. все запросы будут обрабатываться (но естественно дольше, чем, если бы очереди не было).
    Но это всё теория, т.к. Значение по умолчанию этого параметра равно 0, при котором SQL Server сам определяет использовать параллельные планы или нет :angry:
  8. mialord
    Offline

    mialord Модераторы Команда форума Модератор

    Регистрация:
    31 июл 2009
    Сообщения:
    5.398
    Симпатии:
    40
    Баллы:
    54
    А теперь о правилах хорошего тона.
    Если Вы пишите большие наборы записей в регистры, то перед записью надо отключать расчет итогов, и включать только после окончания записи, не надо издеваться над системой.
  9. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    Дельное замечание. Про него позабыл, ухватился за низкую производительность по сравнению с файловой версией :)
  10. TopicStarter Overlay
    sektet
    Offline

    sektet

    Регистрация:
    26 янв 2011
    Сообщения:
    4
    Симпатии:
    0
    Баллы:
    1
    Я уточню: сервер IBM System x3550 M2 с двумя 4-х ядерными Xeon E5540 (с технологией Hyper-Threading), поэтому диспетчер задач показывает 16 процессоров. При записи/очистки набора записей процесс RPHOST грузит одно из ядер на 100% (общую загрузку ЦП он показывает 6%) , процесс sqlservr
    показывает загрузку ЦП 0% - 1%. ОС - 32 бит, SQL Server - 32 бит.

    Может всётаки дело не в системе а в самой платформе 1С (сервере 1С),в том как он работает с регистрами бухгалтерии? В обыкновенный регистр накопления 6 тыс. записей пишутся 5 сек.
  11. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    В общем, ещё один вариант пришёл в голову. Посмотрите размер лога БД до загрузки и после. Подозреваю, что он у вас настроен на AutoGrowth по 100Мб и во время такой операции загрузки расширяется, что конкретно затягивает время - если журнал транзакций полон, то работа приостанавливается, СУБД захватывает и инициализирует новый кусок 100 МБ для журнала, после чего работа продолжается, пока в журнале транзакций снова не закончится место.
    Лучше сразу задайте размер лога гигов 20 (вам же места не жалко, правда?)
  12. TopicStarter Overlay
    sektet
    Offline

    sektet

    Регистрация:
    26 янв 2011
    Сообщения:
    4
    Симпатии:
    0
    Баллы:
    1
    К сожалению игра с настройками SQL Server ничего не дала (по крайней мере на глаз разницы не видать),
    но нарисовалась следующая картина:

    В варианте клиент-сервер, для регистотров - УстановитьИспользованиеИтогов(Истина)
    Время записи - 766 сек. Количество записей - 15 068(регистр бухгалтерии) / 5 823 (регистр накопления)
    Время очистки того же количества записей 657 сек.
    В варианте клиент-сервер, для регистотров - УстановитьИспользованиеИтогов(Ложь)
    Время записи 59 сек.
    Время очистки 11 сек.

    В файловом варианте, для регистотров - УстановитьИспользованиеИтогов(Истина)
    Время записи - 64 сек. Количество записей - 15 068(регистр бухгалтерии) / 5 823 (регистр накопления)
    Время очистки того же количества записей 60 сек.
    В файловом варианте, для регистотров - УстановитьИспользованиеИтогов(Ложь)
    Время записи - 52 сек.
    Время очистки 13 сек.

    ВСЕМ СПАСИБО ЗА КОММЕНТАРИИ!

Поделиться этой страницей