Сильно снизилась стабильность сервера

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

Конфигурация:
Сервер ЛЭРС УЧЁТ: 2x Intel Xeon 5650@ 2.7-3.06Ghz, 6c/12t, RAM 24GB, SSD
Сервер базы данных: 2x Intel Xeon 5650@ 2.7-3.06Ghz, 6c/12t, RAM 24GB, HDD

На обоих Ubuntu Server 22.04.1 LTS

Ничего кроме ЛЭРС УЧЁТ и БД не установлено.

Параметры доступа в систему ЛЭРС УЧЁТ отправил на support@lers.ru

В параметрах доступа на данный момент нет какой либо необходимости.

Уточните, пожалуйста, компьютеры, указанные в конфигурации, являются физическими или виртуальными? Тот факт, что вы привели характеристики Сервера баз данных, говорит о том, что он также внезапно останавливает свою работу одновременно с Сервером ЛЭРЧ УЧЕТ? Если нет, то уточните в связи с чем были приведены характеристики Сервера баз данных?

Дождитесь падения Сервера ЛЭРС УЧЕТ и приложите журнал работы Сервера ЛЭРС УЧЕТ и журнал работы контейнера Docker, в котором он запущен, за день, когда ситуация воспроизведется. На сколько я помню из ваших предыдущих тем, в настройках Docker у вас задан автоматический перезапуск контейнера при падении службы Сервера ЛЭРС УЧЕТ. Пожалуйста, предварительно отключите данную настройку автоматического перезапуска.

я не могу ронять сервер в рабочее время. Слишком много людей им пользуется. А в ночное время(когда нет подключенных пользователей)проблем нет.

Антон Чичков ранее указывал на ошибки связи с БД, но сервер БД на наш взгляд стабилен, связь с сервером ЛЭРС УЧЁТ организована кабелем 2 метра.

Физические.

Все же для анализа необходимы запрошенные журналы. Уже обсудили этот вопрос.

Дополню, что журнал docker лучше всего сохранять с метками времени, добавив в команду его получения параметр “--timestamps” (подробнее в документации docker). Команду сохранения журнала необходимо выполнить сразу после падения Сервера.

Без журналов мы не сможем понять в чём причина проблемы. Если сервер аварийно останавливается нужен журнал docker, если есть ошибки при одновременной работе пользователей, нужны журналы сервера за дату, когда такие проблемы наблюдались. И лучше всего чтобы мы знали примерное время когда проводить анализ.

В логах сервера пусто… Решил копнуть логи postgresql. Оказалось что ЛЭРС создаёт более 100 одновременных подключений(а по-умолчанию 100 максимум). Увеличил до 1000, за последние сутки полёт нормальный.

П.С. во всех гайдах фигурирует такая фраза “если ваше ПО создаёт столько подключений - это не нормально, оптимизируйте работу с db”

П.П.С. Ну и ещё увеличил буфер до 8GB(25% of total memory)

Уточните, показал ли что нибудь журнал docker? И что именно вами было обнаружено в журналах postgresql? Приведите, пожалуйста, выдержку из этого журнала, а лучше сам журнал.

в журналах докера абсолютно ничего. в журналах постгрес увидел org.postgresql.util.PSQLException: FATAL: sorry, too many clients already. в большом количестве.

назревает вопрос: Что будет когда я дам доступ 500-1000 жителям в личный кабинет?

Опять же не понятно, зачем сервер уходит в ребут при проблемах связи с БД ?

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

Тот факт, что в журналах docker у вас пусто скорее говорит о проблемах с docker. Получается что перезапускается именно он. Возможно при постоянных сбоях подключения БД возникает нехватка ресурсов, что приводит к такому исходу.

ЛЭРС и так использует пул подключений к БД, по умолчанию 150, вроде. Если пул исчерпан, система ждёт освобождения. Поэтому, ограничение, которое дополнительно накладывает postgres, вполне может приводить к таким последствиям.

Не думаю, что 1000-5000 пользователей подключатся и начнут работать одновременно. В любом случае, один сервер вполне может справится с такой нагрузкой.

Интересно так же про увеличение буфера. Правильно я понял, что вы разрешили серверу postgres использовать четверть доступного объёма RAM? У вас же выделенный сервер для БД, зачем его ограничивать четвертью? База данных будет работать гораздо эффективнее если все часто используемые страницы поместятся в памяти. Дайте ему хотя бы 75 процентов от общего объёма.

Уверены? Все руководства по обслуживанию postgres рекомендуют указывать в качестве буфера 25% оперативной памяти.

Возможно, я не совсем правильно понял что это за параметр. В администрировании postgres не силён и подумал, что это аналог предельного объёма RAM, который задаётся для SQL Server. Если так, то, конечно, нужно делать так, как пишут в руководствах.

Кстати, в систему встроены метрики, по которым можно следить как работает ЛЭРС и какую нагрузку производит сервер БД. Если возможно, добавьте в docker-compose.yml в секцию environment сервиса lers строку LERS_SERVER_Telemetry__MetricsEnabled: true. Соберём метрики и дадим вам доступ к панели, чтобы вы их тоже видели.

Сервер начал работать дюже бодрее, также ни одной ошибки / отключения пользователей за прошедшее с изменений время.
П.С. Предлагаю добавить рекомендацию по установке буфера и максимального числа подключений в руководство по установке связки с postgresql.

Тогда, пожалуйста, напишите какие параметры Postgres вы устанавливали.

@anbeluaev, все же сообщите, пожалуйста, какие именно параметры были задействованы вами? Данная информация будет полезной всем пользователям, столкнувшимся с данной проблемой.

Со своей стороны мы включим ее в документацию по настройке PostgreSQL при использовании с ЛЭРС УЧЕТ.

Я не считаю себя достаточно компетентным в данном вопросе, чтобы давать точные рекомендации. Но могу посоветовать эту статью Tuning Your PostgreSQL Server - PostgreSQL wiki