Администратор видит медленную 1С, но не видит виновника. Процессор Linux свободен, rphost потребляет память, а PostgreSQL ждёт диск — три экрана дают три неполных ответа.
Обновление Metrika42 сводит проверку в один маршрут: Linux-хост, сервер 1С, PostgreSQL, технологический журнал и APDEX. Раньше типовые сценарии продукта охватывали Windows и Microsoft SQL Server. Теперь Metrika42 поддерживает PostgreSQL 12 и новее. Об этом сообщила команда Metrika42 на сайте EFSOL.
Новое покрытие пригодится администраторам, которые уже перевели 1С на Linux и PostgreSQL. Если вы только собираете такую инфраструктуру, начните с установки сервера 1С на Linux.
Metrika42 помогает определить проблемный слой. Она не заменяет аудит PostgreSQL: после локализации блокировок, чтения с диска или работы autovacuum настройки должен проверить DBA.
Вместо трёх отдельных проверок появился один маршрут
До обновления Linux и PostgreSQL выпадали из типового сценария Metrika42. Администратору приходилось отдельно смотреть состояние ОС, процессы кластера и показатели СУБД.
Теперь данные PostgreSQL встроены в действующие разделы мониторинга серверов, 1С и СУБД. Отдельный верхнеуровневый раздел для них не создавали. Такой интерфейс сохраняет последовательность проверки: от состояния хоста к прикладному эпизоду.
| Слой | Какие данные доступны | На какой вопрос отвечают |
|---|---|---|
| Linux-хост | CPU по системе и ядрам, Load Average, RAM, swap | Хватает ли вычислительных ресурсов и памяти |
| Диски и сеть Linux | iowait, очереди операций, файловые системы, сетевые ошибки | Не задерживает ли ОС обращения 1С к данным |
| Сервер 1С | RPHost, RAgent, RManager, вызовы, память, паузы процессов | Тормозит ли весь кластер или отдельный процесс |
| Пользовательские сеансы | CPU, память, срок жизни, вызовы, трафик, чтение и запись | Не создаёт ли один сеанс основную нагрузку |
| PostgreSQL | подключения, транзакции, блокировки, чтение, кэш, временные файлы | Упирается ли операция в СУБД |
| Технологический журнал и APDEX | прикладные события и оценка времени операций | Какой пользовательский эпизод требует разбора |
Таблица сокращает область поиска, но не доказывает причину сбоя. Рост iowait указывает на ожидание ввода-вывода, а не на конкретный неисправный диск или запрос.
Начинайте проверку с Linux
Метрики 1С без состояния хоста дают слабый контекст. Высокая загрузка rphost может оказаться следствием ожидания диска, нехватки памяти или сетевой ошибки.
Сначала сопоставьте загрузку процессоров с Load Average. Сам по себе высокий Load Average не доказывает нехватку CPU: в него попадают и процессы, которые ждут ресурс.
Затем проверьте RAM и swap. Metrika42 также отслеживает крупные промахи страниц памяти и заблокированные процессы. Эти показатели помогают заметить ситуацию, когда сервер занят переносом данных между памятью и диском.
После памяти переходите к файловым системам и дисковой подсистеме. Смотрите iowait и очереди операций вместе. Рост обоих показателей направляет проверку к накопителям, контроллеру, виртуальному хранилищу или соседней нагрузке.
Сеть проверяйте до разбора PostgreSQL. Ошибки интерфейса или нестабильный канал между сервером 1С и СУБД увеличивают время обращений к базе, хотя сами службы работают.
Если Linux не показывает нехватки ресурсов и сбоев ввода-вывода, переходите к кластеру. Устройство процессов и параметры рабочих серверов подробно описаны в руководстве по настройке кластера 1С.
RAS-метрики отделяют перегрузку кластера от тяжёлого сеанса
Metrika42 получает расширенный набор данных от RAS-экспортера. Система отслеживает RPHost, RAgent и RManager в режиме, близком к реальному времени. О расширении этих метрик сообщил CNews со ссылкой на представителей EFSOL.
Начните с серверных процессов. Сопоставьте загрузку CPU, физическую и виртуальную память, время работы и паузы. Один процесс с отличающимся профилем нагрузки сужает дальнейшую проверку.
Следующий срез — серверные вызовы. Metrika42 фиксирует их активность, среднее время обращения к базе и длительность блокировок при операциях 1С. Вместе эти данные показывают, где проходит задержка: до СУБД, внутри обращения или при ожидании другого сеанса.
После процессов откройте показатели пользователей. Там доступны ресурсная нагрузка, процессорное время, память, срок жизни сеанса, число вызовов и трафик. Также видны обращения к СУБД и операции чтения-записи.
Этот срез отделяет общий сбой от локального. Если нагрузка распределена между процессами и сеансами, ищите системное ограничение. Если выделяется один сеанс, выясняйте, какую операцию выполняет пользователь.
Не делайте вывод по одной метрике. Долгий сеанс может быть обычным фоновым заданием, а большой трафик — штатным обменом. Значение появляется только при сопоставлении времени, вызовов, памяти и обращений к базе.
PostgreSQL уточняет направление проверки
После Linux и RAS переходите к PostgreSQL. Metrika42 собирает данные о подключениях, транзакциях и откатах. Следом доступны длительные запросы, блокировки, взаимоблокировки и ожидания типа Lock.
Дисковый контур раскрывают временные файлы, физическое чтение и попадания в кэш. Нагрузку SQL можно смотреть по отдельным базам. Тексты запросов при этом не выводятся в пользовательские панели.
Отдельная группа охватывает WAL, checkpoint и autovacuum. Metrika42 также показывает основные параметры конфигурации и состояние сбора телеметрии. Эти показатели направляют DBA к нужному участку настроек.
| Признак | Что сопоставить в Metrika42 | Следующий шаг |
|---|---|---|
| Растут iowait и дисковая очередь | Linux, физическое чтение PostgreSQL, временные файлы | Проверить накопители, хранилище и запросы с большим чтением |
| Увеличивается время операций 1С | Серверные вызовы, обращения к базе, ожидания Lock | Найти сеансы и транзакции, которые удерживают блокировки |
| Появляются взаимоблокировки | Deadlock и связанные пользовательские сеансы | Разобрать порядок операций и границы транзакций |
| Растёт число откатов | Транзакционная активность, ошибки приложения, блокировки | Найти операции, которые не завершают транзакцию |
| Увеличиваются временные файлы | SQL-нагрузка по базам, память, физическое чтение | Проверить запросы и настройки памяти PostgreSQL |
| Растёт физическое чтение | Попадания в кэш, дисковая нагрузка, размер активных данных | Проверить память, планы запросов и работу хранилища |
| Меняется профиль WAL и checkpoint | WAL, checkpoint, дисковая очередь | Проверить частоту контрольных точек и скорость записи |
| Autovacuum не справляется с нагрузкой | Autovacuum, транзакции, SQL-нагрузка | Проверить журналы PostgreSQL и настройки обслуживания таблиц |
Metrika42 показывает слой и наблюдаемый симптом. Причину внутри PostgreSQL подтверждают по журналам, планам запросов и конфигурации СУБД.
Например, рост временных файлов не означает, что нужно сразу увеличивать work_mem. Такая правка действует на операции и соединения, поэтому общий расход памяти может вырасти. Сначала DBA должен определить запросы и оценить параллельную нагрузку.
То же относится к autovacuum и checkpoint. Отдельный график сообщает о поведении системы, но не даёт готового значения параметра. Настройки зависят от объёма записи, размера активных таблиц и возможностей дисковой подсистемы.
Если вы ещё выбираете СУБД, мониторинг не заменит сравнение лицензий, поддержки и эксплуатации. Эти различия собраны в материале о выборе между SQL Server и PostgreSQL для 1С.
Для PostgreSQL нужна отдельная учётная запись
Metrika42 поддерживает PostgreSQL 12 и новее. Перед подключением проверьте версию каждого наблюдаемого экземпляра, включая резервные узлы.
Для сбора данных создают отдельную учётную запись с минимально необходимыми правами. Не используйте администратора СУБД только ради телеметрии. Такой доступ расширит последствия ошибки в конфигурации мониторинга.
После подключения проверьте, что данные действительно поступают. Metrika42 показывает отсутствие телеметрии как отсутствие данных, а не как нулевое значение. Пустой график нельзя трактовать как нулевую нагрузку.
Это различие особенно заметно после перезапуска агента, смены пароля или ограничения сетевого доступа. Сначала подтвердите сбор данных. Только потом сравнивайте показатели до и после события.
В пользовательские панели не выводятся пароли, персональные данные и тексты SQL-запросов. Для разбора конкретного запроса всё равно потребуются средства PostgreSQL и доступ с подходящими правами.
Что проверить после обновления
Рабочий порядок начинается не с самого заметного графика. Идите сверху вниз, чтобы не принять следствие за причину.
- Подтвердите, что версия PostgreSQL — 12 или новее.
- Проверьте отдельную учётную запись и поступление телеметрии.
- Сопоставьте CPU, Load Average, RAM, swap, диски и сеть Linux.
- Проверьте RPHost, RAgent, RManager и пользовательские сеансы.
- Сопоставьте вызовы 1С с подключениями, блокировками и откатами PostgreSQL.
- Проверьте чтение, кэш, временные файлы, WAL, checkpoint и autovacuum.
- Уточните прикладной эпизод по технологическому журналу и APDEX.
Если проблема видна уже на Linux, не начинайте с параметров PostgreSQL. Если хост стабилен, но один сеанс выделяется по вызовам и памяти, ищите операцию пользователя. Если RAS показывает ожидание базы, переходите к транзакциям, блокировкам и чтению СУБД.
Обновление нужно тем, кто эксплуатирует 1С на Linux и PostgreSQL и хочет быстрее выбрать направление проверки. После локализации проблемы глубокую настройку СУБД передайте DBA: Metrika42 собирает признаки, но не проводит аудит PostgreSQL.