Инженерный отчет: Аппаратный профиль и аудит производительности Сервера 1

Инженерный отчет: Аппаратный профиль и аудит производительности Сервера 1

Date:
wt., cze 2, 2026
By:
V B

Инженерный отчет: Аппаратный профиль и аудит производительности Сервера 1

Этот документ содержит детальный анализ физических ресурсов вашего сервера на основе реальных системных данных, полученных через Webmin. В отчете приведен аудит производительности процессора, оперативной памяти с учетом уже запущенного стека OpenCms + Apache OFBiz, структуры разделов накопителя NVMe и сетевых интерфейсов, а также даны практические рекомендации по оптимизации.

1. Сводная спецификация оборудования (Точка А)

  • Материнская плата: LENOVO 3111 (фирменная SFF/Tiny платформа, ориентировочно Lenovo ThinkCentre M700/M900 Tiny).

  • Процессор (CPU): Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz (Архитектура Skylake, 2 физических ядра / 4 вычисликовых потока).

  • Оперативная память (RAM): 7.64 GiB физической ОЗУ (8 GB установленной памяти DIMM).

  • Дисковая подсистема: 256 ГБ NVMe SSD (nvme0n1), разбит на 5 разделов с использованием современных файловых систем Btrfs и ext4.

  • Сетевые интерфейсы: 1 Гбит/с Ethernet-контроллер Intel Corporation I219-V (enp0s31f6).

  • Шина USB: 2 контроллера (USB 2.0 Root Hub и USB 3.0 Root Hub xHCI). Внешние диски на текущий момент физически отключены или обесточены.

2. Сравнительный анализ оперативной памяти (До и После оптимизации)

Благодаря отключению графического окружения kUbuntu, удалению тяжелых десктопных пакетов и очистке снимков snap, мы получили радикальное улучшение распределения ресурсов памяти при запущенном стеке.

Сравнительная таблица показателей ОЗУ:

Параметр памяти (Mem) Точка А: Графический режим (KDE) Точка Б: Headless-режим (Текущий статус) Разница / Результат

Total (Всего)

7.64 GiB

7.64 GiB

Без изменений (Аппаратный лимит)

Used (Реально занято)

3.30 GiB (Без Java-стека)

~1.30 – 2.50 GiB (С запущенными OpenCms and OFBiz)

Расход памяти снижен на ~2.0 GiB!

Free / Available (Свободно)

472 MiB (Доступно 4.3 GiB)

5.10 GiB (С запущенным Java-стеком)

Доступный объем вырос в 11 раз!

Buff/Cache (Дисковый кэш)

4.20 GiB

2.73 GiB

Оптимальный кэш для NVMe

2.1. Анализ текущего состояния памяти (Точка Б)

  • Потребление системы и Java-приложений: То, что система вместе с запущенными Tomcat/OpenCms и OFBiz удерживает объем свободной/доступной памяти на уровне 5.1 GiB, — это выдающийся показатель. В headless-режиме kUbuntu освободила все ресурсы, которые ранее тратились на отрисовку рабочего стола и обслуживание тяжелых графических приложений.

  • Качество работы дискового кэша: Выделенные 2.73 GiB под кэш (Cached) гарантируют, что наиболее часто запрашиваемые файлы баз данных и статический контент OpenCms находятся непосредственно в сверхбыстрой оперативной памяти. Физическая нагрузка на NVMe SSD снижена до минимума, а скорость отклика веб-интерфейсов для клиентов будет максимальной.

3. План оптимизации производительности (Через Webmin)

Наша цель — зафиксировать лимиты Java-машин и ограничить процессорные ресурсы, чтобы сделать сервер максимально стабильным при любых пиковых нагрузках.

Шаг 3.1. Высвобождение дополнительной памяти под кэш СУБД

  1. Отключение KDE (SDDM) по умолчанию: [УСПЕШНО ВЫПОЛНЕНО]

    • В Webmin перейдите в Tools $\rightarrow$ Command Shell.

    • Выполнена команда перевода системы в текстовый headless-режим:

      sudo systemctl set-default multi-user.target

    • Результат: После перезагрузки сервера used снизился, а чистый объем свободной памяти вырос до 5.1 GiB (даже с учетом активного Java-стека).

    • Как временно или постоянно включить KDE (SDDM) назад:

      Если вам физически у монитора сервера потребуется привычный рабочий стол kUbuntu:

      • Разовый запуск графической оболочки (до первой перезагрузки):

        sudo systemctl start sddm

      • Полный возврат графического интерфейса в автозагрузку системы по умолчанию:

        sudo systemctl set-default graphical.target

  2. Удаление тяжелых десктопных пакетов и очистка снимков данных (Snap Snapshots): [УСПЕШНО ВЫПОЛНЕНО]

    • Браузер Firefox и почтовый клиент Thunderbird удалены из системы.

    • Сводные команды для выполнения окончательной очистки диска:

      sudo snap forget 2
sudo snap remove thunderbird
sudo snap forget 1

    • Результат: Системный SSD полностью освобожден от тяжелых snap-архивов и снимков данных, занимавших сотни мегабайт.

Шаг 3.2. Оптимизация Btrfs (Отключение CoW для баз данных) — [УСПЕШНО ВЫПОЛНЕНО]

Чтобы предотвратить фрагментацию диска и падение скорости чтения СУБД:

  1. Определены директории хранения баз данных (в Webmin или через консоль).

  2. В Command Shell успешно применен атрибут отключения Copy-on-Write (CoW) для папок хранения СУБД:

    # Для PostgreSQL:
sudo chattr +C /var/lib/postgresql
# Для MariaDB/MySQL:
sudo chattr +C /var/lib/mysql

    Результат: Для папок баз данных принудительно отключена избыточная перезапись CoW на файловой системе Btrfs. Это предотвратит фрагментацию файлов БД, снизит нагрузку на контроллер SSD и обеспечит стабильно высокий уровень IOPS.

Шаг 3.3. Фиксация лимитов Heap Size Java, смена GC и кодировки (Изоляция версий Java)

Для обеспечения надежной работы стека в условиях, когда в ОС могут быть параллельно установлены разные версии Java (Java 8, 11, 17, 21), мы полностью отказываемся от использования глобальной переменной java и жестко привязываем запуск приложений к конкретному системному пути Java 11: /usr/lib/jvm/java-11-openjdk-amd64/.

  1. Для OpenCms 19.0 (Tomcat в /opt/tomcat/latest/):

    • В File Manager перейдите в каталог /opt/tomcat/latest/bin/ и откройте файл setenv.sh. Если этого файла физически нет, создайте его через верхнее меню File Manager.

    • Рекомендуемая оптимизация памяти и изоляция пути Java:

      Вставьте в файл setenv.sh следующие строки:

      # Explicitly point to Java 11 path to prevent conflicts with other Java versions
export JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"
export JRE_HOME="/usr/lib/jvm/java-11-openjdk-amd64"

# JVM tuning parameters
export CATALINA_OPTS="$CATALINA_OPTS -Xms1536m -Xmx2048m -XX:+UseG1GC -XX:+UseStringDeduplication"

  2. Для Apache OFBiz (Установка в /srv/Ofbiz/IG/):

    • Рекомендуемая оптимизация (Переход в Production Mode):

      • Анализ: Запуск OFBiz через Gradle Wrapper (./gradlew ofbiz) порождает в памяти три тяжелых процесса (сам OFBiz, Gradle Client и Gradle Daemon), расходуя лишние 457.19 MiB ОЗУ.

      • Реализация: Скомпилируйте OFBiz в единый дистрибутив (./gradlew build или ./gradlew assemble), после чего настройте системную службу systemd (/etc/systemd/system/ofbiz.service) на запуск напрямую собранного JAR-файла с жестким указанием пути к Java 11.

      • Параметры запуска JAR в службе (с явным указанием пути):

        /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Xms1536m -Xmx2048m -Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:+UseStringDeduplication -jar /srv/Ofbiz/IG/build/libs/ofbiz.jar

      • Результат: Вы полностью избавляетесь от присутствия Gradle в оперативной памяти во время работы ERP, сэкономив 457.19 MiB ОЗУ, изолируете версию Java (даже если дефолтной в системе станет Java 17/21), переведете систему на безопасную кодировку UTF-8 и зафиксируете стабильные 2 ГБ для Java-кучи.

Шаг 3.4. Создание и настройка службы systemd для OFBiz (ofbiz.service)

Поскольку в вашей текущей системе файл службы ofbiz.service ещё не создан, нам необходимо его создать. Это позволит запускать OFBiz автоматически при загрузке системы, безопасно управлять им через панель Webmin, жестко изолировать используемую версию Java от общесистемных альтернатив, а также ограничить потребление ресурсов процессора.

  1. Создание файла службы через Webmin File Manager:

    • В левом меню Webmin перейдите в Tools (Инструменты) $\rightarrow$ File Manager (Файловый менеджер).

    • Перейдите в каталог /etc/systemd/system/.

    • В верхнем меню File Manager нажмите кнопку File (Файл) $\rightarrow$ Create new file (Создать новый файл).

    • Назовите файл ofbiz.service и нажмите Create.

    • Дважды кликните по созданному файлу и вставьте туда следующую конфигурацию, где исполняемый файл Java прописан по его абсолютному пути в JDK 11:

      [Unit]
Description=Apache OFBiz ERP Service
After=network.target mysql.service postgresql.service

[Service]
Type=simple
User=survrus
Group=survrus
WorkingDirectory=/srv/Ofbiz/IG

# Start the compiled JAR directly using explicit Java 11 binary path (prevents version conflicts)
ExecStart=/usr/lib/jvm/java-11-openjdk-amd64/bin/java -Xms1536m -Xmx2048m -Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:+UseStringDeduplication -jar /srv/Ofbiz/IG/build/libs/ofbiz.jar

# Automatically restart the service on failure (after 15 seconds)
Restart=always
RestartSec=15

# Soften process priority to level 5 (MySQL has priority 0, Tomcat -5)
Nice=5
# Strictly limit the service to a maximum of 50% CPU usage
CPUQuota=50%

[Install]
WantedBy=multi-user.target

    • Нажмите кнопку Save (Сохранить) в верхнем правом углу текстового редактора и закройте его.

  2. Применение настроек и активация службы:

    • Перейдите в Webmin $\rightarrow$ Tools $\rightarrow$ Command Shell.

    • Выполните команду для перечитывания конфигураций systemd:

      sudo systemctl daemon-reload

    • Зарегистрируйте новую службу в автозагрузку системы:

      sudo systemctl enable ofbiz.service

    • Запустите службу OFBiz:

      sudo systemctl start ofbiz.service

Шаг 3.5. Управление службой Tomcat через Webmin (Запуск, Остановка, Перезапуск)

Для управления веб-контейнером Tomcat (обслуживающим OpenCms) и применения новых настроек памяти из setenv.sh, используйте визуальные инструменты Webmin.

  1. Способ А: Графическое управление через модуль "Bootup and Shutdown"

    • В левом меню Webmin перейдите в System (Система) $\rightarrow$ Bootup and Shutdown (Загрузка и выключение).

    • В таблице служб найдите имя вашей службы (например, tomcat или tomcat.service).

    • Кликните по названию службы для перехода в меню настроек.

    • Нажмите на одну из кнопок управления действием:

      • Start Now (Запустить сейчас) — запуск Tomcat и инициализация OpenCms.

      • Stop Now (Остановить сейчас) — безопасное завершение сессий и выгрузка JVM из памяти.

      • Restart (Перезапустить) — быстрая перезагрузка процесса для применения изменений в setenv.sh (рекомендуется выполнять в часы минимальной активности пользователей).

    • Здесь же вы можете активировать автозапуск службы при старте ОС, переключив флаг Start at boot? в положение Yes.

  2. Способ Б: Управление через встроенный Command Shell

    • Если вам удобнее контролировать вывод терминала без открытия SSH на ПК/Mac, перейдите в Tools (Инструменты) $\rightarrow$ Command Shell.

    • Используйте стандартные команды systemd:

      • Остановить Tomcat: sudo systemctl stop tomcat

      • Запустить Tomcat: sudo systemctl start tomcat

      • Мягкий перезапуск: sudo systemctl restart tomcat

      • Проверить подробный статус и убедиться, что подтянулся правильный путь к Java 11:

        sudo systemctl status tomcat

      • Посмотреть логи Tomcat в реальном времени:

        sudo journalctl -u tomcat -n 50 -f

4. Результаты анализа после 1 дня работы (Динамический аудит)

После 24 часов эксплуатации в оптимизированном режиме получены следующие реальные данные распределения ресурсов:

4.1. Анализ распределения памяти и подкачки

  • Физическая память (Real Memory):

    • 7.64 GiB total / 3.96 GiB free / 3.58 GiB cached

    • Реально занято процессами (Active Used): Всего ~0.1 GiB (100 MiB) физически невыгружаемой системной памяти ОС. Всё остальное пространство распределено под кэш ввода-вывода (3.58 GiB) и свободный резерв (3.96 GiB).

  • Пространство подкачки (Swap Space):

    • 4.59 GiB total / 4.27 GiB free

    • Используется Swap: Всего 0.32 GiB (320 MiB). Своппинг отсутствует, износ SSD нулевой.

4.2. Анализ профилей запущенных процессов

  1. Tomcat / OpenCms (PID 986 — пользователь tomcat):

    • Потребление: 1.04 GiB виртуального адресного пространства.

    • Параметры запуска по умолчанию: -Xms512M -Xmx1024M -XX:+UseParallelGC

    • Директория установки: /opt/tomcat/latest/ (CATALINA_HOME).

    • Аудит Nice-уровня: -20 (рекомендуется снизить до -5).

  2. Службы Apache OFBiz (PID 3322 — пользователь survrus):

    • Потребление: 690.58 MiB виртуальной памяти.

    • Параметры запуска по умолчанию: -Xms128M -Xmx1024M -Dfile.encoding=US-ASCII

    • Директория установки: /srv/Ofbiz/IG/ (OFBiz Home).

    • Аудит Nice-уровня: -20 (критический приоритет реального времени, унаследованный от родительского Gradle Wrapper PID 3153). Рекомендуется понизить до 0 или 5.

  3. СУБД MySQL / MariaDB (PID 56756 — пользователь mysql):

    • Потребление: 258.39 MiB. Стабильная работа на Btrfs с отключенным Copy-on-Write (CoW).

  4. Фоновые утилиты сборщика Gradle (Служебные процессы сборки):

    • Gradle Wrapper Client (PID 3153 — пользователь survrus): * Команда запуска: java -Xmx64m -Dorg.gradle.appname=gradlew -classpath /srv/Ofbiz/IG/gradle/wrapper/gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain ofbiz

      • Потребление: 105.07 MiB.

      • Аудит Nice-уровня: -20 (критический приоритет).

    • Gradle Daemon (PID 3186 — пользователь survrus): * Команда запуска: org.gradle.launcher.daemon.bootstrap.GradleDaemon 5.0-rc-5

      • Потребление: 352.12 MiB.

      • Аудит Nice-уровня: -20 (критический приоритет).

      • Рекомендация: Эти процессы (PID 3153 and PID 3186) висят в памяти постоянно, забирая суммарно 457.19 MiB ОЗУ и нагружая планировщик CPU, так как OFBiz был запущен через Gradle Wrapper. Перевод OFBiz на native-запуск скомпилированного JAR через службу systemd позволит полностью погасить оба этих процесса, высвободив ~457 MiB RAM и разгрузив ядра процессора.

  5. Fail2ban Security Server (PID 963) & Webmin Session (PID 98854): Работа в штатном режиме (суммарно ~110 MiB).