Вопрос по масштабированию и быстродействию системы

ЛЭРС УЧЁТ Установка, обновление, администрирование
1

Здравствуйте!

У нас в ЛЭРС Учет 10 многоквартирных домов с поквартирным опросом. В настоящий момент квартирных точек учета более 5000. Начали сталкиваться с серьезным снижением быстродействия системы. Падение производительности шло постепенно с добавлением новых точек учета, с ростом базы данных (сейчас БД около 100 Гб). На данный момент любые окна, связанные обращением к БД, открываются очень долго, а иногда попытка открытия завершается ошибкой “превышено время ожидания обращения к БД” (или что-то вроде того). Формирование отчетов идёт тоже очень долго, особенно поквартирных. Так же, когда одновременно опрашивается много приборов, сервер вообще начинает тупить. Согласно монитору ресурсов Windows проц основном грузит именно сервер ЛЭРС, и только потом сервер SQL. Примерно 80/20 при 100% загрузке.

Теперь собственно вопрос. Как быть с последующими новыми домами? Понятно, что добавлять на этот сервер уже не стоит, это явно перебор. Как правильно масштабировать систему? Тупо поставить второй аналогичный сервер “всё в одном” (ЛЭРС, SQL, служба опроса)? Или лучше как-то разделить SQL, ЛЭРС, службу опроса? Может быть еще какие-то варианты есть? Чтобы получить максимальное быстродействие, без явных затупов.

2

Уточните пожалуйста текущие характеристики ПК, на котором работает Сервер ЛЭРС Учет.
Насколько мне известно, серверу баз данных для максимального быстродействия требуется объем ОЗУ, равный объему базы данных (100 ГБ в вашем случае), в связи с этим хотелось бы уточнить сколько ОЗУ задействуется у вас сейчас при работе сервера БД?
Возможно требуется дополнительная настройка MSSQL сервера, либо увеличение объема ОЗУ.
В теме Перенос базы на другой жесткий диск Вы упоминали что база данных у вас расположена на жёстком диске. Использование NVMe накопителей должно дать существенный прирост к быстродействию сервера, а резервные копии можно как раз хранить на HDD.

Возможно стоит в параметрах обслуживания БД указать более короткие сроки хранения журналов, что позволит уменьшить объем БД.
Проверьте выполняется ли еженедельное обслуживание индексов БД.
Возможно включено протоколирование отладочных сообщений - оно сильно увеличивает нагрузку на сервер.

На мой взгляд предпочтительнее чтобы пользователи системы работали с одним сервером ЛЭРС Учет, не переключаясь между ними в процессе работы.
В связи с этим я бы предложил в случае необходимости разместить сервер баз данных и сервер ЛЭРС на разных ПК, объединённых в одну локальную сеть. Службу опроса тоже можно разместить на отдельном ПК при необходимости.

3

Большое спасибо за такой развернутый ответ!
Теперь мои ответы. Начну в обратном порядке.

  1. Протоколирование отладочных сообщений - отключено

  2. Еженедельное обслуживание индексов БД - выполняется (воскр, 5:00). И на это время весь опрос вообще встревает, не может ничего сохранить в базу, идут десятки ошибок (timeout). Думаю переделать расписание автоопроса, чтобы в это время ничего не опрашивалось.

  3. Журналы (скрин ниже) места почти не занимают. Единственное “Протокол выполнения сессий опроса” занимает много места, но это вроде как не журнал, и вообще я не нашел точного сопоставления, в настройках некоторые вещи называются не так, как в отчете (на скрине).

  4. Базу данных я действительно перенес с системного SSD на отдельный жесткий диск. Потому что, во-первых, на системном SSD закончилось место, а во-вторых, мне кажется HDD понадежнее будет. Есть нюанс. На жесткий диск я перенес только LERS.mdf и LERS.ldf. Всё остальное, включая tempdb.mdf, осталось на системном SSD. Я так понял, что всё проходит сначала через tempdb.mdf, поэтому скорость не должна пострадать (например при опросе новых данных).

  5. Характеристики ПК
    проц.: Core i5-7500 @3.40GHz
    ОЗУ: 16Гб
    ОС: Win 7-64 макс
    системный раздел: Samsung SSD 860 EVO
    раздел для LERS.mdf и LERS.ldf: HDD WD Re

  6. Объем ОЗУ для работы MS SQL ограничен 10Гб (в настройках). Сейчас планируется заменить 16Гб на 32Гб. Уже куплено, нужно только поставить. Ждём окно, когда сможем остановить сервер. Посмотрим даст ли это прирост производительности. Согласно вашему описанию, получается этого все равно недостаточно.

  7. БД согласно отчету ЛЭРС сейчас занимает 91,2 Гб, но файл LERS.mdf весит 118,6 Гб…

    2024-04-23_192509
    2024-04-23_192509760×640 58.4 KB

4

Чтобы понять картину стоит увидеть и скрин настроек сроков хранения данных в базе.

Для поквартирного учета у вас подозрительно много часовых данных. Вы их используете для диагностики и долго храните?
В моей практике, часовые в таких системах запрашивают только при необходимости и вручную.

5

Нужно отметить, что 5000 точек учёта это серьёзный размер системы, и характеристики вашего компьютера для него слабоваты.

Размер в 100ГБ наводит на мысль, что опрос этих точек выполняется достаточно интенсивно. Скорее всего, несколько раз в день, а то и несколько раз в час. После окончания опроса запускаются алгоритмы расчёта, которые и загружают процессор системы.

Следующее бутылочное горлышко в производительности - объём базы. Для 100Гб выданная SQL Server оперативная память в 10Гб это очень мало. SQL Server сейчас интенсивно занимается записью и чтением данных из страниц в памяти. То, что tempdb осталась на SSD это, конечно, хорошо. Но после окончания транзакции всё равно идёт запись в основное хранилище, а это в разы более медленный HDD.

@7in вам уже дал основные рекомендации

Я, в свою очередь, могу добавить следующее.

Основная нагрузка идёт после опроса в момент расчёта и сохранения данных. Стоит подумать, нужен ли вам такой интенсивный опрос. Возможно, данные стоит считывать раз в сутки ночью, после того как приборы сформировали все архивы. В это время пользователи с системой не работают, и возможные подтормаживания роли не сыграют.

Сроки хранения, конечно, стоит выбрать, но на производительности это сильно не скажется, хотя, безусловно поможет работе в условиях ограниченной оперативной памяти.

По масштабированию системы. Стоит оставить один SQL Server, но вынести сервер БД и, по возможности, службу опроса на отдельные компьютеры. Кроме того, базу данных SQL Server стоит хранить на SSD. И если есть возможность, поставить два разных SSD один для файла MDF, другой для LDF.

Эти действия точно помогут вам справиться с зависаниями и позволят расширить систему как минимум до 10К точек.

6

Обратите внимание на Завершение поддержки Windows 7 для компонентов сервера ЛЭРС.

Процессор i5-7500 имеет 4 ядра/4 потока и поддерживает максимум 64ГБ ОЗУ.
Если ваша материнская плата поддерживает сокет 1151-v2 - можно обновиться до i5-9400(f), или если сможете найти i9-9900 - будет 6 или 8 ядер соответственно и поддержка до 128ГБ ОЗУ.

7

Только текущие данные хранятся 365 дней, потом удаляются. Остальные данные хранятся пока вечно. Пока. В дальнейшем конечно придется настраивать их удаление тоже.

В часовых данных как раз самое главное. Мы их используем для диагностики и долго храним, всё верно. Это так и было задумано.

8

В общем я понял, что я сильно недооценил значение ресурсов для SQL сервера. Будем исправлять.

Размер в 100ГБ наводит на мысль, что опрос этих точек выполняется достаточно интенсивно. Скорее всего, несколько раз в день, а то и несколько раз в час

Опрос сейчас настроен 1 раз в час. Хотелось всегда иметь самые актуальные данные. Но как это связано с размером базы? Что я один раз в сутки считаю данные, что каждый час, данных от этого больше не станет. Мы в любом случае вычитываем часовые архивы. Единственное журналов опроса станет в 24 раза меньше. )))

После окончания опроса запускаются алгоритмы расчёта, которые и загружают процессор системы.

А если мы не используем интерполяцию данных и вычитываем только те архивы, которые реально есть в счётчике? Всё равно запускается какой-то расчёт?

Возможно, данные стоит считывать раз в сутки ночью, после того как приборы сформировали все архивы. В это время пользователи с системой не работают, и возможные подтормаживания роли не сыграют.

Я уже тоже об этом подумал. Видимо это первое, что я сделаю. Придется пожертвовать актуальностью данных, но в плюсе будет то, что днём сервер ЛЭРС будет практически не занят. И уже точно не наложится формирование отчётов и множество опросов.

но вынести сервер БД и, по возможности, службу опроса на отдельные компьютеры.

Т.е. SQL сервер - комп №1, служба опроса - комп №2. Я правильно понял? А где разместить сервер ЛЭРС? На комп №3? Или на комп №1 вместе с SQL сервером?

9

Можно использовать как 2, так и 3 отдельных ПК.
В любом случае у вас Сервер ЛЭРС и сервер SQL должны оказаться на разных ПК.
В случае использования двух ПК я бы расположил сервер ЛЭРС УЧЕТ и службу опроса на ПК № 1, а сервер БД на ПК № 2.

Это необходимо проверить в свойствах точек учета, на вкладке “расчёт и хранение” - если все виды расчета там отключены - то расчёт после опроса запускаться не будет.

Это не совсем так. Опрос данных каждый час как Вы и сказали увеличивает количество протоколов выполнения сессий опроса, которые на вашем скриншоте занимают третье место по по объему в БД. Будет меньше сессий опроса в сутки - будет меньше протоколов - будет меньше размер БД

10

Раз так, мое предположение подтвердилось. Полагаю больше половины из 100 Гб может оптимизировано вами. А работа с базой меньшего размера даст прирост производительности. Конечно, про прочие рекомендации забывать не нужно.

Этот вывод я сделал исходя из анализа вашей диаграммы БД и того, что опрашивать и тем более хранить стоит только то, что требуется/потребуется по технологии работы заказчика и/или отвечает целям системы

  1. запрашивать текущие с индивидуальных приборов учета, я думаю, нужно, только если прибор не отдает интеграторы суточные/месячные. А уж хранить их даже для диагностики не вижу смысла, т.к. вряд ли вы делаете запросы чаще 1 раза в час и текущие не добавляют новой информации к часовым данным. Т.е., при необходимости из текущих можно восстанавливать нужные данные и не хранить сами текущие
  2. нужны ли вам часовые интеграторы для диагностики, или достаточно данных потребления? Возможно, часовые интеграторы могут быть оптимизированы.
  3. наличие полного профиля часовых данных потребления за весь период работы системы дает информацию о графике жизни всех квартир ваших домов. Что это обозначает в плане безопасности - сами придумаете. Подумайте, точно ли вам нужны для диагностики всегда часовые. В системах, с которыми мы работаем - часовые запрашивают вручную при необходимости.

П.С. для5 домов по +/- 250 квартир, посчитал для случая 4 счетчика на квартиру у вас очень большая база. Сейчас перед глазами система из 3 домов по 300-350 квартир – от 2 до 3 лет жизни МКД – всего 1,5 Гб. Даже с учетом молодости системы разница существенная. И эта система выполняет все нужные УК задачи, в том числе и диагностику.