При работе с информационными базами 1С большого объема, особенно когда они хранятся на 32-разрядном сервере PostgreSQL, пользователи часто сталкиваются с критической ошибкой "Недостаточно свободной памяти на сервере 1С:Предприятия" при попытке выгрузки данных в файл формата .dt. Эта ситуация не только блокирует важные операции, но и может указывать на более глубокие проблемы в инфраструктуре.
Первопричина данной проблемы кроется в фундаментальных ограничениях 32-разрядных систем. Рассмотрим подробнее, почему возникают такие ошибки и как мы можем их устранить.
32-разрядные операционные системы и приложения, включая 32-разрядную версию PostgreSQL, имеют существенные ограничения на объем адресуемой оперативной памяти. Каждый процесс на такой системе может использовать, как правило, не более 2 ГБ оперативной памяти (в некоторых конфигурациях ОС Windows это значение может быть увеличено до 3 ГБ, но это скорее исключение). Когда размер базы данных 1С, хранящейся в PostgreSQL, начинает превышать 5 ГБ, а тем более достигает 30-60 ГБ, как в нашем случае, 32-разрядная версия PostgreSQL сталкивается с критической нехваткой адресного пространства для эффективной работы.
32-разрядные процессоры также имеют ограничения в 2 ГБ на размер файловой системы, а также другие ограничения операционной системы, что в совокупности значительно снижает производительность при работе с базами данных, превышающими 5 ГБ. Хотя базы до 30 ГБ могут работать, мы неизбежно столкнемся с ухудшением производительности и стабильности.
Для 1С:Предприятия это становится особенно заметно при операциях, требующих обработки больших объемов данных за одну транзакцию, таких как выгрузка базы в .dt файл. Сервер 1С, взаимодействуя с PostgreSQL, пытается загрузить в память значительные части данных для формирования файла, но наталкивается на жесткие ограничения 32-разрядной архитектуры, что приводит к сообщению о нехватке памяти.
Посмотрим на официальную рекомендацию 1С:
Уже на протяжении почти десяти лет фирма "1С" указывает на эту проблему в своих рекомендациях, публикуемых при каждом обновлении платформы. При загрузке или выгрузке конфигураций большого объема и возникновении ошибки "Недостаточно свободной памяти на сервере 1С:Предприятия" они прямо рекомендуют использовать PostgreSQL x86-64. Это ключевой момент, который часто упускается из виду, особенно когда система изначально работает без видимых проблем с меньшими базами.
Переход на 64-разрядную версию PostgreSQL и, что не менее важно, на 64-разрядный сервер 1С:Предприятия, кардинально решает проблему с памятью. 64-разрядные системы могут адресовать значительно больший объем оперативной памяти (до нескольких терабайт), что позволяет:
shared_buffers) и для выполнения операций сортировки и хеширования (через work_mem и maintenance_work_mem), значительно сокращая обращения к диску.
.dt файлов.
Важно отметить, что 64-разрядная версия PostgreSQL может быть более требовательна к памяти в том смысле, что каждый указатель занимает вдвое больше места. Однако это компенсируется возможностью адресовать огромные объемы ОЗУ, а архитектура PostgreSQL, которая в значительной степени полагается на операционную систему для кеширования данных, делает необходимость в нативной 64-разрядной версии менее критичной, чем для многих других СУБД, при условии, что ОС 64-разрядная и может адресовать большой объем памяти.
Мы рекомендуем проверить и настроить следующие параметры PostgreSQL, особенно после перехода на 64-разрядную версию:
shared_buffers: Объем памяти, выделяемый для кеширования данных сервером PostgreSQL. Его значение рекомендуется устанавливать от 15% до 25% от общего объема ОЗУ машины. При значениях выше нескольких гигабайт стоит рассмотреть включение "huge pages" в ОС для снижения накладных расходов на таблицы страниц виртуальной памяти.
work_mem: Объем памяти, используемый для операций сортировки и хеш-таблиц перед записью на временные диски. Это контролирует, сколько памяти будет использовано для каждой отдельной операции сортировки или хеширования перед тем, как данные начнут записываться на временные диски. Для больших запросов это может быть критично.
maintenance_work_mem: Максимальный объем памяти для операций обслуживания, таких как VACUUM и CREATE INDEX. Увеличение этого параметра может значительно ускорить эти операции.
Для оценки максимального использования ОЗУ PostgreSQL можно использовать формулу: shared_buffers + (temp_buffers + work_mem) * max_connections, где max_connections — это максимальное количество одновременных подключений к базе данных.
Пошаговое решение:
10.5_24.1C_x64. Перенос данных можно осуществить с помощью логических дампов (pg_dump/pg_restore) или физического копирования данных (pg_basebackup).
.dt файлов или используя дампы PostgreSQL. После этого выгрузка .dt файлов большого объема должна проходить без ошибок памяти.В ходе миграции и интенсивной работы серверной инфраструктуры могут выявиться скрытые аппаратные проблемы, как это произошло в рассматриваемом случае с диском SSD. Перегрев твердотельных накопителей – это реальная и достаточно распространенная проблема, особенно для высокопроизводительных NVMe SSD, но и для SATA SSD это также актуально при плохой вентиляции.
Контроллер и чипы NAND внутри SSD выделяют тепло в процессе работы. Основной причиной перегрева является электрическое сопротивление, а также плотная компоновка электронных компонентов. Отсутствие достаточного воздушного потока и высокая температура окружающей среды усугубляют проблему накопления тепла.
Когда температура чипа SSD достигает критических значений (обычно около 70 градусов Цельсия), может активироваться механизм thermal throttling. Он принудительно снижает производительность накопителя, чтобы дать ему остыть. Это помогает предотвратить повреждение данных, но значительно замедляет работу системы. Избыточный нагрев увеличивает энергию электронов в транзисторах SSD, что облегчает их утечку и приводит к увеличению количества битовых ошибок, а затем и к некорректируемым ошибкам. Высокие температуры также могут сокращать срок службы SSD.
В нашем случае проблема проявлялась в виде "отвала диска", зависания сервера под нагрузкой и сильного нагрева. Если вы сталкиваетесь с подобными симптомами, необходимо провести диагностику:
Если диагностика подтверждает проблемы с SSD, мы можем предпринять следующие шаги:
В процессе работы с базами данных 1С и PostgreSQL крайне важно понимать разницу между различными методами копирования данных и их назначением. Как было отмечено в ходе обсуждения, файл .dt не является полноценной резервной копией.
.dt файл — это не резервная копия
Выгрузка информационной базы в файл .dt в 1С используется, в основном, для получения образа базы данных, независимо от способа хранения (файловый или клиент-серверный режим), и позволяет переключаться между ними. Однако этот метод имеет серьезные недостатки, которые делают его непригодным для надежного резервного копирования:
.dt может либо завершиться с ошибкой, либо создать "битый" файл, который невозможно будет загрузить. В отличие от этого, при копировании файла базы данных (например, 1Cv8.1CD для файловой версии) сохраняются все данные, и базу можно попытаться восстановить после сбоя.
.dt файл — это одномоментный снимок, он не позволяет восстановить базу данных на произвольный момент времени после последнего полного бэкапа.
.dt файла не гарантирует, что 'все нормально', как показала ситуация, когда снимок базы загружался уже битый.
Для клиент-серверного режима работы с 1С и PostgreSQL мы настоятельно рекомендуем использовать штатные средства СУБД для создания резервных копий. PostgreSQL предлагает три основных подхода к резервному копированию:
pg_dump:
Этот метод создает текстовый файл, содержащий SQL-команды для воссоздания структуры базы данных и вставки всех данных. Это гибкий способ, который позволяет восстанавливать отдельные базы данных или даже переносить данные между разными версиями PostgreSQL. Для создания дампа конкретной базы данных мы можем использовать следующую команду:
pg_dump -h localhost -p 5432 -U user -Fc dbname > dbname_$(date +%Y%m%d%H%M%S).backup
Для создания дампа всех баз данных и глобальных объектов:
pg_dumpall -h localhost -p 5432 -U user > all_databases_$(date +%Y%m%d%H%M%S).sql
-Fc указывает на использование собственного формата архива PostgreSQL, который эффективнее текстового, а $(date +%Y%m%d%H%M%S) добавляет метку времени к имени файла.
pg_basebackup:
Этот метод создает полную копию всего кластера базы данных PostgreSQL. Он идеально подходит для быстрого восстановления всей системы. Физические копии необходимы для реализации восстановления на определенный момент времени (Point-in-Time Recovery, PITR), так как они служат базовой точкой для применения WAL-файлов. Пример команды:
pg_basebackup -h localhost -p 5432 -U user -D /path/to/backup/directory -F tar -P -v
Где -D указывает целевую директорию для бэкапа, -F tar создает tar-архив, -P включает индикатор прогресса, а -v делает вывод более подробным.
Это самый надежный метод, который позволяет восстановить базу данных на любой момент времени с точностью до транзакции. PostgreSQL записывает все изменения данных в файлы Write-Ahead Log (WAL). При непрерывном архивировании эти WAL-файлы регулярно сохраняются в безопасное место. В сочетании с полными физическими копиями это обеспечивает максимальную устойчивость к потерям данных и возможность восстановления на произвольный момент времени.
Настройка включает в себя параметры в файле конфигурации postgresql.conf, такие как wal_level = replica, archive_mode = on и archive_command = 'cp %p /path/to/wal_archive/%f'. Мы должны заменить /path/to/wal_archive/ на фактический путь к архивному хранилищу WAL-файлов.
Для обеспечения максимальной надежности мы рекомендуем комбинированную стратегию, которая будет включать как физические, так и логические резервные копии, а также непрерывное архивирование:
pg_basebackup для создания полных физических копий кластера PostgreSQL. Это обеспечит быструю базу для восстановления.
pg_dump для отдельных баз данных. Это обеспечит дополнительную гибкость, например, для восстановления конкретных таблиц или миграции между версиями PostgreSQL.
Следуя этим рекомендациям, мы значительно повысим отказоустойчивость нашей системы 1С и минимизируем риски потери данных, обеспечивая спокойствие и надежность в работе.