В начале 2024 года, в условиях активного импортозамещения и опасений возможных принудительных мер со стороны властей по переходу на отечественное ПО, мы начали искать альтернативные решения. Основываясь на опыте использования 1С, которое активно применяется в России, и после изучения материалов Гилева, мы решили рассмотреть PostgresPro Ent.

Проведя базовые тесты, нас устроила его функциональность, встроенная кластеризация BiHa PostgresPro Ent и административная панель PPEM. Все выглядело красиво и удобно. В итоге было принято решение закупить лицензии на PostgresPro Ent для двух серверов и развернуть на них часть баз 1С.

Развертывание прошло быстро и без значительных затруднений. Мы создали несколько инстансов для удобства восстановления, так как в отличие от MSSQL, в Postgres нельзя работать с резервными копиями отдельных баз данных без риска потери данных, а только с инстансом целиком.

В процессе эксплуатации выявились некоторые неприятные особенности. В частности, очень долгое резервное копирование с использованием pg_probackup. База 1С на MS SQL, объемом около 100 ГБ, копируется на сервер резервного копирования за 5-10 минут, в то время как аналогичная база на PostgresPro Enterprise требует более 2 часов. Многие могут предложить использовать более мощное оборудование или смотреть в сторону инкрементальных бэкапов (в плане обслуживания MSSQL мы используем как полные таки и инкрементальные). Но проблема заключается в самой логике работы pg_probackup, которая не позволяет сразу архивировать все файлы в один архив и далее работать уже с ними, а фактически учитывая структуру базы 1С там не одна тысяча мелких файлов которые очень "замечательно" копируются по сети, даже 10GBps не изменяет ситуацию. Также возникло множество мелких вопросов, требующих дополнительных компетенций, но пути решения были найдены, хотя и не всегда оптимальные. Вывод: PostgresPro требуется значительного много времени что бы догнать MS SQL в удобстве использования и обслуживания.

Однако главная особенность PostgresPro Enterprise заключается в следующем: при покупке бессрочной лицензии PostgresPro Enterprise, после окончания базовой подписки на техническую поддержку, вы не можете использовать ПО как вам хочется. Вы становитесь привязанными к тому оборудованию, на которое было установлено ПО (вспомним OEM лицензии от MicroSoft), и ваша бессрочная лицензия фактически превращается в лицензию по подписке. Этот факт выяснился через год после покупки, когда мы решили заменить серверы на более новые. Доступ к репозиторию уже был закрыт, так как закончился срок базовой техподдержки. Обращения в техническую поддержку не дали результатов: ответ сводился к предложению купить подписку на техническую поддержку или отказаться от использования ПО.

Таким образом, могу посоветовать: тщательно взвесить все за и против перед переходом на отечественное ПО, чтобы избежать подобных проблем.

p.s. Если у администрации ресурса возникнут сомнения в правдивости этого поста, могу предоставить номера обращений и даже предоставить скрины ответов PostgresPro Enterprise.

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

Разыскиваются файлы для обновления BIOS сервера Huawei 2288H V5, как я понимаю, нужны

Mainboard BIOS upgrade package (2x10GE optical port 2xGE electrical port)

Mainboard iBMC upgrade package

Mainboard CPLD upgrade package

Скачать с офсайта при наличии личного кабинета и заведённого туда по S\N сервера не получается, ни с VPN ни без. Просто сообщают, что вы превысили количество попыток подключения.

Реквизиты сервера следующие:

Product Name (Alias) : 2288H V5 (2288H V5 10GE SFP+)

iBMC Firmware Version 3.31 (U4282)

BIOS Version 1.09 (U47)

CPLD Version 2.02 (U4269)

iBMC Primary U-Boot Version 2.1.13 (Dec 24 2018 - 20:23:20)

iBMC Secondary U-Boot Version 2.1.13 (Dec 24 2018 - 20:23:20)

PCB Version .B

Board ID 0x0017

Mainboard Manufacturer Huawei

Mainboard Model BC11SPSCB

PCH Model LBG QS/PRQ - 2 - S1

BOM Code 02311XBK

За помощь готов отблагодарить по договорённости. Благодарю за внимание.

Вы когда-нибудь запускали ps aux в своем Linux-терминале и замечали странные строки с пометкой <defunct>? Поздравляю, вы столкнулись с зомби-процессами! Звучит жутковато, не так ли? Но не паникуйте. Хотя они и носят такое зловещее имя, обычно они безвредны, но могут указывать на проблемы и просто засоряют вывод системных утилит. Давайте разберемся, что это такое и как от них избавиться.

Что такое Зомби-Процесс?

В мире Unix/Linux, когда процесс завершает свою работу, он не исчезает полностью сразу. Он переходит в состояние "зомби". В этом состоянии процесс уже мертв – он не потребляет CPU и почти не занимает память (кроме записи в таблице процессов). Он ждет одного: чтобы его родительский процесс "признал" его смерть, прочитав его код завершения с помощью системного вызова wait().

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

Вы можете легко их найти:

ps aux | grep defunct # Или, чтобы отфильтровать сам grep:
ps aux | grep '[Zz]' # Ищем процессы в состоянии Z (Zombie)

Вы увидите что-то вроде:

nik 1651 0.5 0.0 0 0 tty1 Z мар30 27:18 [chromium] <defunct>

Здесь [chromium] с PID 1651 – наш зомби.

Почему Зомби Нельзя Просто "Убить"?

Логичный вопрос: почему бы просто не использовать kill?

kill 1651 # Не сработает!
kill -9 1651 # Тоже не сработает!

Ответ прост: зомби уже мертв. Вы не можете убить то, что уже неживое. Команда kill отправляет сигналы живым процессам, прося их завершиться (или убивая принудительно). Зомби сигналы не обрабатывает.

Как же Избавиться от Зомби? Ключ – в Родителе!

Раз зомби ждет своего родителя, значит, именно на родителя нам и нужно воздействовать. Задача – заставить родительский процесс выполнить свою работу и "похоронить" дочерний зомби-процесс.

Шаг 1: Найти Родителя

У каждого процесса есть родитель (Parent Process ID, или PPID). Найти его можно несколькими способами:

• С помощью ps:

  ps -o pid,ppid,stat,cmd -p <PID_зомби> # Например: ps -o pid,ppid,stat,cmd -p 1651

  В колонке PPID будет нужный нам идентификатор.

• С помощью pstree (нагляднее):

  pstree -p

  Найдите в дереве ваш зомби-процесс и посмотрите, какой процесс находится над ним. Допустим в дереве видно что:

  lxpanel(1357)─┬─chromium(1651) # <--- Вот он, зомби!

  Здесь родитель – lxpanel с PID 1357.

Шаг 2: Воздействовать на Родителя

Теперь, когда мы знаем PID родителя (<PPID>), у нас есть несколько вариантов:

1. Отправить Сигнал SIGHUP (Мягкий способ): Иногда этот сигнал заставляет процесс перечитать свою конфигурацию и, как побочный эффект, собрать статусы завершившихся дочерних процессов.

   kill -HUP <PPID>

2. Завершить Родительский Процесс (Радикальный Способ)

Если SIGHUP не помог, можно попробовать корректно завершить родительский процесс:

kill <PPID> # Отправляет SIGTERM (15) – мягкое завершение

Если процесс не реагирует, можно принудительно убить его:

kill -9 <PPID> # SIGKILL (9) – немедленное завершение

⚠️ Важно:

• Если родительский процесс критически важен (например, init, systemd или ваш оконный менеджер), его завершение может привести к потере графической сессии или даже перезагрузке системы.

• В случае с lxpanel (как в нашем примере) – это панель задач LXDE, и её завершение удалит панель, но система останется работоспособной.

Что Если Родитель – xinit или startx?

Если зомби-процесс был запущен через startx (например, вручную из терминала), то его родительская цепочка выглядит так:

login → bash → startx → xinit → Xorg → lxsession → ... → зомби

Что произойдёт, если убить xinit?

• Графическая среда завершится (исчезнут все окна, панель, обои).

• Вы вернётесь в терминал, из которого запускали startx.

• Зомби-процесс исчезнет, так как xinit (его родитель) завершится.

А если убить startx?

• startx – это просто скрипт, и его завершение вернёт вас в терминал, но графическая сессия (xinit и Xorg) останется работать.

• Зомби-процесс может остаться, если его родитель – не startx, а что-то глубже (например, lxsession).

Крайний Вариант – Перезагрузка

Если зомби не мешает работе, но раздражает в ps, а все попытки убить родителя не сработали – можно просто перезагрузить систему.

sudo reboot

После перезагрузки все зомби исчезнут, так как ядро очищает таблицу процессов.

Как Предотвратить Появление Зомби?

1. Пишите корректные программы

   • Если вы разрабатываете софт, используйте wait() или waitpid() для сбора статусов дочерних процессов.

   • В скриптах на Bash можно использовать trap для обработки завершения дочерних процессов.

2. Используйте reap-утилиты

   • Некоторые системы (например, systemd) автоматически собирают зомби.

   • Можно использовать reaper-скрипты, которые периодически вызывают wait для сиротливых процессов.

3. Проверяйте логи

   • Если зомби появляются часто, это может указывать на баг в программе. Проверьте логи (journalctl, dmesg).

Заключение

Зомби-процессы – не страшные монстры, а просто "непохороненные" процессы. Они почти не вредят системе, но могут указывать на баги в софте. Теперь вы знаете, как их находить и устранять!

🔹 Ваш опыт:

• Встречали ли вы зомби-процессы в своей системе?

• Какой способ борьбы с ними оказался самым эффективным?