Приветствую!
Конфигурация: виртуальная машина , 8 ядер Ryzen 9 7900X , 16GB, SSD Samsung 990PRO , Win 10 PRO, PostgreSQL_1C_16.6_64bit , Платформа 1С 8_3_25_1520, база 1С Бухгалтерия, нетиповая, размер 15 Гб.
С бухгалтерской базой работает 10 человек.
В тесте Гилева : в однопоточном - 45 баллов, в многопоточном - после прохождения теста рекомендованное количество пользователей - 160.
Через dt выгрузил базу из MS SQL и загрузил в PostgreSQL. Часть документов стала зависать при проведении. Зависает на 5-10 минут.
Например: обычное требование-перемещение проводится 5 минут.
Поступление из переработки - проводится 15 минут.
В момент зависания что на сервере PostgreSQL , что на сервере приложений 1С активность нулевая, диск и процессор в пределах 0-1% загрузки.
При этом зависают при проведении не все типы документов, например документы реализации , кассовые - это все работает ок.
Перезаливал базу повторно из dt, выполнял на базе vacuumdb и reindexdb, пробовал enable_nestloop = off , обновился на версию платформы 8_3_25_1520, выполнял тестирование и исправление с реструктуризацией таблиц.
Все отлично отрабатывает , ошибок нет, но при этом документы по прежнему проводятся по 10 минут.
Куда смотреть?
Файл настройки PostgreSQL прикрепил , но там вроде ничего сверхкриминального я не указал. Пробовал запускать PostgreSQL с конфигом по умолчанию - ничего не поменялось, так же зависает при проведении.
Или дело не в PostgreSQL, а в коде 1С. Тут да, база не типовая, но требование - накладная то типовая, почему проводится так долго...
Конфигурация: виртуальная машина , 8 ядер Ryzen 9 7900X , 16GB, SSD Samsung 990PRO , Win 10 PRO, PostgreSQL_1C_16.6_64bit , Платформа 1С 8_3_25_1520, база 1С Бухгалтерия, нетиповая, размер 15 Гб.
С бухгалтерской базой работает 10 человек.
В тесте Гилева : в однопоточном - 45 баллов, в многопоточном - после прохождения теста рекомендованное количество пользователей - 160.
Через dt выгрузил базу из MS SQL и загрузил в PostgreSQL. Часть документов стала зависать при проведении. Зависает на 5-10 минут.
Например: обычное требование-перемещение проводится 5 минут.
Поступление из переработки - проводится 15 минут.
В момент зависания что на сервере PostgreSQL , что на сервере приложений 1С активность нулевая, диск и процессор в пределах 0-1% загрузки.
При этом зависают при проведении не все типы документов, например документы реализации , кассовые - это все работает ок.
Перезаливал базу повторно из dt, выполнял на базе vacuumdb и reindexdb, пробовал enable_nestloop = off , обновился на версию платформы 8_3_25_1520, выполнял тестирование и исправление с реструктуризацией таблиц.
Все отлично отрабатывает , ошибок нет, но при этом документы по прежнему проводятся по 10 минут.
Куда смотреть?
Файл настройки PostgreSQL прикрепил , но там вроде ничего сверхкриминального я не указал. Пробовал запускать PostgreSQL с конфигом по умолчанию - ничего не поменялось, так же зависает при проведении.
Или дело не в PostgreSQL, а в коде 1С. Тут да, база не типовая, но требование - накладная то типовая, почему проводится так долго...
Прикрепленные файлы:
postgresql.conf
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) ТиИ, реструктуризация.
ЗЫ: эта тема раз в полгода поднимается, до сих пор 1С не может написать об этом большими буквами на своем желтом заборе.
выполнял тестирование и исправление с реструктуризацией таблиц
Куда нажимал, что крутил?
Конфигурация: виртуальная машина , 8 ядер
Что там с включением в биосах аппаратной виртуализации? Что за виртуальная машина?
ЗЫ: эта тема раз в полгода поднимается, до сих пор 1С не может написать об этом большими буквами на своем желтом заборе.
(4)
Тестирование и исправление с опциями : проверка логической целостности, реиндексация, пересчет итогов, реструктуризация.
НЕ помогло.
(4)
Ок, еще раз запустил только реструктуризацию. Эффекта нет, такие же тормоза при проведении.
(4)
Все что надо - включено, виртуальная машина Hyper-V , второго поколения.
Куда нажимал, что крутил?
Тестирование и исправление с опциями : проверка логической целостности, реиндексация, пересчет итогов, реструктуризация.
НЕ помогло.
(4)
ТиИ, реструктуризация.
Ок, еще раз запустил только реструктуризацию. Эффекта нет, такие же тормоза при проведении.
(4)
Что там с включением в биосах аппаратной виртуализации? Что за виртуальная машина?
Все что надо - включено, виртуальная машина Hyper-V , второго поколения.
(5) Ну тогда собирай планы выполнения запросов. Долгое чтение прямо говорит о том, что нет индексов, или они по какой-то причине не используются. Сколько записей в таблице аналитик? Какие индексы у нее есть? Какой запрос генерит 1С?
Я бы пошел таким путем:
0. Посмотрел бы запрос и план. Для начала можно просто сохранить куда-нить.
1. Грохнул бы индексы вообще все у таблицы аналитик.
2. Добавил бы индексы по ключам из where запроса, который генерит 1С при чтении менеджером записи.
3. Запустил бы запрос в консоли постгреса с explain, посмотрел бы, что поменялось.
4. Если время выполнения стало нормальным, то оставил бы все как есть, записав, что и как, ну и продолжил бы ждать ответа каких-нить людей, которые в этом чтло-то понимают.
Предположу, что в последних релизах, если сохроанять совместимость уровня 8.3.17, а может даже если вообще ее сохранять любую, все работает так себе. Я заметил, что на 26-й версии гилев в файловой аж в 2 раза медленнее работает, если стоит совместимость базы теста по умолчанию. Если убрать совестимость, то все становится нормально. В серверной базе тоже при убирании совместимости растет производительность, но не в два раза, а на 5-10%. Но после изменения совместимости тоже нужна реструктуризация. Т.е. сначала поднимается совместимость, потом запускается реструктуризация, потом уже тестится.
Я бы пошел таким путем:
0. Посмотрел бы запрос и план. Для начала можно просто сохранить куда-нить.
1. Грохнул бы индексы вообще все у таблицы аналитик.
2. Добавил бы индексы по ключам из where запроса, который генерит 1С при чтении менеджером записи.
3. Запустил бы запрос в консоли постгреса с explain, посмотрел бы, что поменялось.
4. Если время выполнения стало нормальным, то оставил бы все как есть, записав, что и как, ну и продолжил бы ждать ответа каких-нить людей, которые в этом чтло-то понимают.
Предположу, что в последних релизах, если сохроанять совместимость уровня 8.3.17, а может даже если вообще ее сохранять любую, все работает так себе. Я заметил, что на 26-й версии гилев в файловой аж в 2 раза медленнее работает, если стоит совместимость базы теста по умолчанию. Если убрать совестимость, то все становится нормально. В серверной базе тоже при убирании совместимости растет производительность, но не в два раза, а на 5-10%. Но после изменения совместимости тоже нужна реструктуризация. Т.е. сначала поднимается совместимость, потом запускается реструктуризация, потом уже тестится.
(6) в 1С я не силен , тут надо уметь в отладку 1С
Доп. сведения:
берем документ, который проводится 5 минут.
Это Склад - Расход материалов (требования-накладные)
В документе 14 позиций номенклатур разного количества.
ОК, делаем копированием из этого документа два документа : в первом оставляем первые 7 позиций, остальные удаляем, во втором - вторые 7. Т.е. просто делаем то же самое, только двумя документами , вместо одного.
Так первый проводится за 10 сек.
Второй - за 3 минуты.
Это как?
Причем результаты воспроизводимы.
Т.е. у нас получается один и тот же запрос выполняется с разной скоростью в зависимости от того, с какой номенклатурой мы работаем.
Есть ли смысл тогда копать в сторону планов запросов? Т.е. я так понимаю что наша цель - получить sql запрос, который выполняется на СУБД , чтобы посмотреть с какими таблицами он работает и посмотреть индексы этих таблиц. А сейчас получается что один и тот же запрос по разному отрабатывает для разной номенклатуры...
Просмотрел карточки номенклатуры из второго документа - они ничем не отличаются с точки зрения заполненности от карточек номенклатуры из первого. Но это я смотрел просто визуально в 1С. Может можно посмотреть как то еще?
Причем все это сугубо особенности работы с PostgreSQL, в файловой все ок, проводится за секунду.
Доп. сведения:
берем документ, который проводится 5 минут.
Это Склад - Расход материалов (требования-накладные)
В документе 14 позиций номенклатур разного количества.
ОК, делаем копированием из этого документа два документа : в первом оставляем первые 7 позиций, остальные удаляем, во втором - вторые 7. Т.е. просто делаем то же самое, только двумя документами , вместо одного.
Так первый проводится за 10 сек.
Второй - за 3 минуты.
Это как?
Причем результаты воспроизводимы.
Т.е. у нас получается один и тот же запрос выполняется с разной скоростью в зависимости от того, с какой номенклатурой мы работаем.
Есть ли смысл тогда копать в сторону планов запросов? Т.е. я так понимаю что наша цель - получить sql запрос, который выполняется на СУБД , чтобы посмотреть с какими таблицами он работает и посмотреть индексы этих таблиц. А сейчас получается что один и тот же запрос по разному отрабатывает для разной номенклатуры...
Просмотрел карточки номенклатуры из второго документа - они ничем не отличаются с точки зрения заполненности от карточек номенклатуры из первого. Но это я смотрел просто визуально в 1С. Может можно посмотреть как то еще?
Причем все это сугубо особенности работы с PostgreSQL, в файловой все ок, проводится за секунду.
(7)
Создайте файлик logcfg.xml с таким содержанием.
Положите а-ля, C:\Program Files\1cv8\conf
в результате получите запросы выполняющиеся > 50 сек
Сохраните документ, результат в студию.
Есть ли смысл тогда копать в сторону планов запросов? Т.е. я так понимаю что наша цель - получить sql запрос, который выполняется на СУБД , чтобы посмотреть с какими таблицами он работает и посмотреть индексы этих таблиц. А сейчас получается что один и тот же запрос по разному отрабатывает для разной номенклатуры...
Создайте файлик logcfg.xml с таким содержанием.
Положите а-ля, C:\Program Files\1cv8\conf
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="Сюда написать путь для лога, типа C:\Temp\MyLog" history="12">
<event>
<eq property="name" value="DBPOSTGRS"/>
<ge property="duration" value="50000"/>
</event>
<property name="all"/>
<property name="all">
<event>
<eq property="name" value="DBPOSTGRS"/>
</event>
</property>
</log>
</config>
Показать<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="Сюда написать путь для лога, типа C:\Temp\MyLog" history="12">
<event>
<eq property="name" value="DBPOSTGRS"/>
<ge property="duration" value="50000"/>
</event>
<property name="all"/>
<property name="all">
<event>
<eq property="name" value="DBPOSTGRS"/>
</event>
</property>
</log>
</config>
в результате получите запросы выполняющиеся > 50 сек
Сохраните документ, результат в студию.
(9)
Сделал. Во вложении.
Запрос в файле я видел и в консоли PostgreeSQL через запрос показывающий выполняющиеся запросы
SEL ECT pid, age(clock_timestamp(), query_start), usename, query, state
FR OM pg_stat_activity
WHERE state != 'idle' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
Но дальше я не знаю что с этим делать.
В запросе работа с таблицей _InfoRg18250
Если посмотреть индексы в PostgreeSQL через запрос
SEL ECT * FR OM pg_indexes;
то по таблице _InfoRg18250 видно 3 индекса (файл прилагаю).
Посмотрел коэффициент использования индексов через запрос
SELECT relname,
100 * idx_scan / (seq_scan + idx_scan) percent_of_times_index_used,
n_live_tup rows_in_table
FR OM pg_stat_user_tables
WH ERE seq_scan + idx_scan > 0
ORDER BY n_live_tup DESC;
по таблице _InfoRg18250 это 96
тогда почему тормоза то?
Сделал. Во вложении.
Запрос в файле я видел и в консоли PostgreeSQL через запрос показывающий выполняющиеся запросы
SEL ECT pid, age(clock_timestamp(), query_start), usename, query, state
FR OM pg_stat_activity
WHERE state != 'idle' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
Но дальше я не знаю что с этим делать.
В запросе работа с таблицей _InfoRg18250
Если посмотреть индексы в PostgreeSQL через запрос
SEL ECT * FR OM pg_indexes;
то по таблице _InfoRg18250 видно 3 индекса (файл прилагаю).
Посмотрел коэффициент использования индексов через запрос
SELECT relname,
100 * idx_scan / (seq_scan + idx_scan) percent_of_times_index_used,
n_live_tup rows_in_table
FR OM pg_stat_user_tables
WH ERE seq_scan + idx_scan > 0
ORDER BY n_live_tup DESC;
по таблице _InfoRg18250 это 96
тогда почему тормоза то?
Прикрепленные файлы:
25021323.log
data-1739465529866.csv
data-1739466033744.csv
(10)
Все запросы выполняются за ноль целых хрен десятых миллисекунд. Так что проблема где-то еще походу. По всей видимости надо собрать полный лог, а не только базу данных. Что-то там еще происходит. Может ждет авторизации товарища майора, который вручную каждый раз кнопку жмет в кармане )))
ЗЫ: если запрос в консоли постгреса запустить, то сколько времени это занимает?
log
Execution Time: 0.030 ms
Все запросы выполняются за ноль целых хрен десятых миллисекунд. Так что проблема где-то еще походу. По всей видимости надо собрать полный лог, а не только базу данных. Что-то там еще происходит. Может ждет авторизации товарища майора, который вручную каждый раз кнопку жмет в кармане )))
ЗЫ: если запрос в консоли постгреса запустить, то сколько времени это занимает?
(11)
дополню:
если просто выполнить этот запрос в консоли - выполнится быстро
но если я нажимаю кнопку "провести документ" в 1С , и после этого начинаю смотреть активные запросы в консоли постгреса , то я вижу этот запрос, он появляется и далее он и выполняется, и выполняется, и выполняется ... pid не меняется , только age растет
если запрос в консоли постгреса запустить, то сколько времени это занимает?
дополню:
если просто выполнить этот запрос в консоли - выполнится быстро
но если я нажимаю кнопку "провести документ" в 1С , и после этого начинаю смотреть активные запросы в консоли постгреса , то я вижу этот запрос, он появляется и далее он и выполняется, и выполняется, и выполняется ... pid не меняется , только age растет
Прикрепленные файлы:
(10) Закинул лог в deepseek, оно ответило:
Рекомендации от ИИ |
|---|
| Анализ логов и рекомендации по производительности
1. Проблемы, выявленные в логах Множественные однотипные запросы: В логе повторяются почти идентичные SQL-запросы к таблице _InfoRg18250 с разными значениями в условиях WHERE. Пример: Каждый запрос содержит 12-14 условий, включая сравнение бинарных данных (bytea). Использование индекса: Индекс _inforg18250_2 используется, но его эффективность под вопросом из-за большого количества условий. Риск: Индекс может не покрывать все поля из WHERE, что приводит к дополнительным проверкам строк (Filter). Контекст выполнения: Запросы выполняются в рамках проведения документа "ТребованиеНакладная" (модуль УчетНДСБП). Проблема: Множественные вызовы метода СформироватьДвиженияСписаниеТоваровНаРасходы генерируют высокую нагрузку. Тип данных: Условие T1._Fld11554 = CAST(0 AS NUMERIC) может приводить к неявному приведению типов, если _Fld11554 хранится как INTEGER. 2. Рекомендации по оптимизации 2.1. Оптимизация индексов Добавьте составной индекс: CRE ATE INDEX _inforg18250_optimized_idx ON _InfoRg18250 (_Fld11554, _Fld18251RRef, _Fld18252RRef, ..., _Fld18256RRef); Включите все поля из WHERE для покрывающего индекса. Это сократит время поиска. Проверьте статистику индексов: ANALYZE _InfoRg18250; Это поможет PostgreSQL точнее планировать запросы. 2.2. Исправление условия WHERE Убедитесь, что тип данных _Fld11554 соответствует NUMERIC. Если это INTEGER, измените условие на: T1._Fld11554 = 0 Это исключит неявное приведение типов и улучшит использование индекса. 2.3. Оптимизация бизнес-логики 1С Кеширование данных: Если запросы выполняются для одних и тех же данных, кешируйте результаты в переменных 1С. Пример: Сохраните результат ПолучитьТаблицуСписанныеПартииНДС в временном хранилище. Сокращение числа запросов: Объедините условия или используйте пакетную обработку строк. Например, загрузите все необходимые данные одним запросом. 2.4. Настройка PostgreSQL Увеличьте размер кеша: ALTER SYSTEM SET shared_buffers = '4GB'; -- 25% от RAM Настройте work_mem: ALTER SYSTEM SET work_mem = '64MB'; Это улучшит сортировку и агрегацию. 2.5. Мониторинг транзакций Проверьте длительность транзакции Trans=1. Если она выполняется дольше 1 секунды: Упростите логику проведения документа. Разбейте транзакцию на этапы с промежуточными коммитами (если это допустимо в 1С). 3. Проверка эффективности Сравните планы выполнения до и после изменений: EXPLAIN ANALYZE SEL ECT ...; Мониторинг через pg_stat_activity: SELECT query, total_time FR OM pg_stat_activity WHERE query LIKE '%_InfoRg18250%'; Логирование медленных запросов: # postgresql.conf log_min_duration_statement = 1000 -- логировать запросы > 1 сек 4. Пример из практики После добавления составного индекса и исправления условия _Fld11554 = 0: Время выполнения запроса сократилось с 0.03 мс до 0.01 мс. Нагрузка на CPU сервера PostgreSQL снизилась на 15%. Итог: Основные узкие места — неоптимальные индексы и бизнес-логика 1С. Рекомендуется провести аудит индексов, оптимизировать код 1С и настроить параметры PostgreSQL. |
На виртуалке тех данные проца можно выкидывать, данные диспетчера задач туда же, очередность записи на диск так же. + я так понимаю вы все равно бухгалтерию типовую оптимизировать под свои задачи не будете. Почему не поставить платформу без виртуальной машины?
Вариант решения можно сделать следующий
Вариант решения можно сделать следующий
По ходу это виртуалка.
Попробовал Hyper-V - новая виртуалка - с нуля Win 10 PRO + Постгре 17 версии (думал, вдруг новая версия поможет) - новая база - импорт из dt - проблема в силе.
Обычный офисный комп - с нуля Win 10 PRO + Постгре 16 , аналогичный текущему - новая база - импорт из dt - провелось сразу же.
Гарантировано могу сказать только после переноса текущей машины на реальное железо.
Но почему?
Кроме проблемной базы на этой же виртуалке крутятся другие базы 1С - нареканий нет.
Мало того, даже в этой базе кассовые документы, платежки и др. проводятся нормально.
Да даже конкретно расход материалов из примера выше : с одними позициями проводится ок , с другими - виснет.
Попробовал Hyper-V - новая виртуалка - с нуля Win 10 PRO + Постгре 17 версии (думал, вдруг новая версия поможет) - новая база - импорт из dt - проблема в силе.
Обычный офисный комп - с нуля Win 10 PRO + Постгре 16 , аналогичный текущему - новая база - импорт из dt - провелось сразу же.
Гарантировано могу сказать только после переноса текущей машины на реальное железо.
Но почему?
Кроме проблемной базы на этой же виртуалке крутятся другие базы 1С - нареканий нет.
Мало того, даже в этой базе кассовые документы, платежки и др. проводятся нормально.
Да даже конкретно расход материалов из примера выше : с одними позициями проводится ок , с другими - виснет.
(18)
с одними позициями проводится ок , с другими - виснет
Чудес не бывает, но профилировать виртуалку я вам вряд ли предложу, ибо и сам с логами профилировщика вряд ли что пойму. Поставьте виртуалбокс, поглядите там. Может дело в каком-то механизме обмена данными между 1С и постгресом, который как-то через какое-то место фильтруется.
По итогу оказалось, что это была проблема даже не виртуальных машин как таковых , а конкретного хоста Hyper-V.
Сервер приложений 1С тоже работает как виртуальная машина.
И если виртуальные машины сервера приложений 1С и Постгреса работали на одном хосте - начинались вышеописанные косяки.
Попробовал вынести Постгрес на железо без виртуализации - работает нормально.
Но после попробовал мигрировать виртуалку Постгрес на другой хост Hyper-V - работает нормально .
После мигрировал виртуалку сервера приложений на тот же хост ,куда перевел Постгрес - работает нормально.
То есть как виртуальные машины сервер приложений и Постгрес работают нормально даже в рамках одного хоста.
Получается дело в конкретном хосте Hyper-V, где они были размещены изначально.
Переустановил там Hyper-V , после чего мигрировал обратно на него сервер приложений и Постгрес - работает нормально.
Сервер приложений 1С тоже работает как виртуальная машина.
И если виртуальные машины сервера приложений 1С и Постгреса работали на одном хосте - начинались вышеописанные косяки.
Попробовал вынести Постгрес на железо без виртуализации - работает нормально.
Но после попробовал мигрировать виртуалку Постгрес на другой хост Hyper-V - работает нормально .
После мигрировал виртуалку сервера приложений на тот же хост ,куда перевел Постгрес - работает нормально.
То есть как виртуальные машины сервер приложений и Постгрес работают нормально даже в рамках одного хоста.
Получается дело в конкретном хосте Hyper-V, где они были размещены изначально.
Переустановил там Hyper-V , после чего мигрировал обратно на него сервер приложений и Постгрес - работает нормально.
(22) отказоустойчивость, снижение времени восстановления
Если "упал" железный сервер: мне надо восстановится из резервной копии на другое железо - это время. Дальше, встает вопрос "что с базой". Не обязательно Постгрес , у меня есть ПО которое работает на СУБД Sybase. А до Постгрес работал MS SQL.
Если бэкап базы делается раз в сутки - то все, потеряли информацию за сутки. Если делается бэкап логов БД - докатываем базу из логов, это опять же время. Опять же как часто делаем бэкапы логов.
А что в случае, если это виртуальные машины Hyper-V.
У Hyper-V есть встроенный механизм репликаций. Настраивается в пару кликов мышкой, ничего сложного.
Есть основной сервер - где крутятся все критичные для бизнеса виртуалки. Есть резервный, куда постоянно реплицируются изменения с основного. Частоту репликации можно выставить 30 сек, 5 минут, 15 минут.
Если падает хост с виртуалками - просто стартуем виртуалки на резервном сервере.
Нет простоя по времени восстановления на другое железо , максимальные потери данных в БД = выставленной частоте репликации. В моем случае приемлемо 5 минут - с учетом интенсивности работы операторов с БД нет проблем повторно ввести документы за последние 5 минут.
Плюс у Hyper-V есть расширенная репликация. То есть с основного реплицируем на резервный, а потом с этого резервного можно реплицировать еще на один, дополнительный сервер. Доп. страховка.
Или вопрос обслуживания: надо обслужить сервер по железу. С виртуалками - переключаемся на другой сервер по сути без простоя по работе: либо через "живую" миграцию, либо через ту же "плановую" репликацию, далее спокойно занимаемся обслуживанием.
Если "упал" железный сервер: мне надо восстановится из резервной копии на другое железо - это время. Дальше, встает вопрос "что с базой". Не обязательно Постгрес , у меня есть ПО которое работает на СУБД Sybase. А до Постгрес работал MS SQL.
Если бэкап базы делается раз в сутки - то все, потеряли информацию за сутки. Если делается бэкап логов БД - докатываем базу из логов, это опять же время. Опять же как часто делаем бэкапы логов.
А что в случае, если это виртуальные машины Hyper-V.
У Hyper-V есть встроенный механизм репликаций. Настраивается в пару кликов мышкой, ничего сложного.
Есть основной сервер - где крутятся все критичные для бизнеса виртуалки. Есть резервный, куда постоянно реплицируются изменения с основного. Частоту репликации можно выставить 30 сек, 5 минут, 15 минут.
Если падает хост с виртуалками - просто стартуем виртуалки на резервном сервере.
Нет простоя по времени восстановления на другое железо , максимальные потери данных в БД = выставленной частоте репликации. В моем случае приемлемо 5 минут - с учетом интенсивности работы операторов с БД нет проблем повторно ввести документы за последние 5 минут.
Плюс у Hyper-V есть расширенная репликация. То есть с основного реплицируем на резервный, а потом с этого резервного можно реплицировать еще на один, дополнительный сервер. Доп. страховка.
Или вопрос обслуживания: надо обслужить сервер по железу. С виртуалками - переключаемся на другой сервер по сути без простоя по работе: либо через "живую" миграцию, либо через ту же "плановую" репликацию, далее спокойно занимаемся обслуживанием.
(23)
В постгресе есть потоковая репликация. Фактически все основано на сохранении журнала, файлы которого можно выгружать в любое место - достаточно путь в конфигах прописать. Периодически делать бэкап кластера. И если у вас два сервера, то куда лучше репликацией это сделать, чем переносом на "вторую виртуалку", т.к. второй сервер может быть в режиме "всегда готов".
Ну и есть проблема постгреса при работе с сетевыми хранилищами - он слишком много файликов пишет и держит открытыми, на любой байт для каждого файлика поедет полный пакет по сетке. Так что идея с переключением СХД тоже сильно снижает производительность. Хотя... Тут же 7900Х - о каких СХД я говорю )))
Если "упал" железный сервер
Если "упал" железный сервер с виртуалкой? У вас там второй есть?
В постгресе есть потоковая репликация. Фактически все основано на сохранении журнала, файлы которого можно выгружать в любое место - достаточно путь в конфигах прописать. Периодически делать бэкап кластера. И если у вас два сервера, то куда лучше репликацией это сделать, чем переносом на "вторую виртуалку", т.к. второй сервер может быть в режиме "всегда готов".
Ну и есть проблема постгреса при работе с сетевыми хранилищами - он слишком много файликов пишет и держит открытыми, на любой байт для каждого файлика поедет полный пакет по сетке. Так что идея с переключением СХД тоже сильно снижает производительность. Хотя... Тут же 7900Х - о каких СХД я говорю )))
(23)
А что падает? диски, так если на виртуалке диски то будет тоже самое. а если не дай бог шифратора поймают, то он точно так же через пять минут себя же и скопирует.
Если есть рядом еще одна железка, то опять же зачем виртуалка, в части 1с конечно геморой с лицензиями и переносом.
Спасибо за подробный ответ, раньше хотя бы так развернуто не пытались ответить.
Если "упал" железный сервер: мне надо восстановится из резервной копии на другое железо
А что падает? диски, так если на виртуалке диски то будет тоже самое. а если не дай бог шифратора поймают, то он точно так же через пять минут себя же и скопирует.
Если есть рядом еще одна железка, то опять же зачем виртуалка, в части 1с конечно геморой с лицензиями и переносом.
Спасибо за подробный ответ, раньше хотя бы так развернуто не пытались ответить.
(27) если дублировать каждый сервис в отдельности - железа не напасешься.
Есть сервисы, которые критичны для бизнеса, но у них невысокие системным требования.
Они могут не уметь в кластер , но надо выполнить требование RTO = не более 15 минут и не потерять данные.
Как этого добиться без виртуализации?
Выше совершенно справедливо заметили, что Постгре умеет в кластер актив-актив, и если есть два сервера то лучше сделать так.
Ок, но мы решим задачу только для Посгре, заняв под него два железных сервера.
А как насчет специализированного ПО , например довольно древнего СКУД , для которого слова "кластер" вообще в словаре нет ), там судя по интерфейсу корни растут из времен Windows XP.
Но для этого ПО так же нужно выполнить условия по времени восстановления и не потерять данные.
Виртуализация позволяет более эффективно использовать железо , на одном сервере работают несколько виртуалок без ущерба в производительности для каждой в отдельности.
Репликация позволяет дублировать актуальное состояние машин на резервную площадку, вне зависимости от того какое ПО используется и умеет оно в кластер или нет.
Да, это не актив-актив , если что - надо будет врукопашную переключится, но это займет минуты и это лучше, чем восстанавливать с нуля.
Для бэкапа виртуалок использую Veeam , через него же можно восстановится на любую дату в рамках заданной глубины резервного копирования в том числе в режиме мгновенного восстановления.
Есть сервисы, которые критичны для бизнеса, но у них невысокие системным требования.
Они могут не уметь в кластер , но надо выполнить требование RTO = не более 15 минут и не потерять данные.
Как этого добиться без виртуализации?
Выше совершенно справедливо заметили, что Постгре умеет в кластер актив-актив, и если есть два сервера то лучше сделать так.
Ок, но мы решим задачу только для Посгре, заняв под него два железных сервера.
А как насчет специализированного ПО , например довольно древнего СКУД , для которого слова "кластер" вообще в словаре нет ), там судя по интерфейсу корни растут из времен Windows XP.
Но для этого ПО так же нужно выполнить условия по времени восстановления и не потерять данные.
Виртуализация позволяет более эффективно использовать железо , на одном сервере работают несколько виртуалок без ущерба в производительности для каждой в отдельности.
Репликация позволяет дублировать актуальное состояние машин на резервную площадку, вне зависимости от того какое ПО используется и умеет оно в кластер или нет.
Да, это не актив-актив , если что - надо будет врукопашную переключится, но это займет минуты и это лучше, чем восстанавливать с нуля.
Для бэкапа виртуалок использую Veeam , через него же можно восстановится на любую дату в рамках заданной глубины резервного копирования в том числе в режиме мгновенного восстановления.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот