Optimalizácia Linux servera pre výkon GLPI

Optimalizácia Linux servera pre výkon GLPI

GLPI je PHP aplikácia s MariaDB databázou. Default inštalácia stačí na pár desiatok aktív, ale pri 500+ aktívach a aktívnom helpdesku začne byť pomalá — stránky 2 – 5 sekúnd, dashboardy 10+ sekúnd, používatelia frustrovaní. Tento článok je o tuning-u, ktorý GLPI vrátia do sub-sekundovej responsiveness. Konkrétne hodnoty pre dva referenčné deployments: malý (200 aktív) a stredný (2000 aktív).

Profil základného tuning-u

Štyri vrstvy, kde sa výkon najčastejšie tratí:

  1. OPcache — PHP bytecode cache. Bez neho sa každý PHP súbor parsuje pri každom requeste. Najväčší jednotlivý win.
  2. PHP-FPM pool — počet workerov pre súbežné requesty. Default je často príliš nízky pre helpdesk pod záťažou.
  3. MariaDB innodb_buffer_pool — koľko RAM má DB k dispozícii pre cache. Default 128M je smiešne málo.
  4. Cron cesty — purge logov, optimize tables, scheduled actions. Bez údržby sa DB rozrastá donekonečna.

OPcache

V /etc/php/8.2/fpm/conf.d/10-opcache.ini:

opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256       ; MB pre bytecode cache
opcache.interned_strings_buffer=32   ; MB pre internované stringy
opcache.max_accelerated_files=20000  ; max počet PHP súborov v cache
opcache.revalidate_freq=60           ; ako často kontrolovať zmeny (sek)
opcache.fast_shutdown=1
opcache.validate_timestamps=1        ; v dev na 0, v produkcii 1

Pri 20+ pluginoch GLPI má niekoľko tisíc PHP súborov. max_accelerated_files=20000 dáva headroom. Po reštarte FPM (systemctl reload php8.2-fpm) by mal byť GLPI rozdiel okamžite cítiť — typicky 30 – 50 % rýchlejšie page renders.

PHP-FPM pool

V /etc/php/8.2/fpm/pool.d/glpi.conf alebo www.conf:

# Malý deployment (200 aktív, ~10 súbežných používateľov)
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

# Stredný deployment (2000 aktív, ~50 súbežných používateľov)
pm = dynamic
pm.max_children = 60
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 1000

Hrubé pravidlo: pm.max_children ≈ RAM / priemerná_veľkosť_PHP_workera. PHP worker s GLPI typicky berie 50 – 150 MB. Pre 4 GB RAM box je max_children=25 rozumný; viac začne swapovať a paradoxne spomalí.

pm.max_requests recykluje workera po N requestoch — chráni pred memory leak-mi v dlho bežiacich PHP procesoch.

MariaDB

V /etc/mysql/mariadb.conf.d/50-server.cnf:

# Malý deployment (4 GB RAM box)
[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 100
query_cache_type = 0    ; v MariaDB 10.5+ nepoužívať
table_open_cache = 4000

# Stredný deployment (16 GB RAM box)
[mysqld]
innodb_buffer_pool_size = 8G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 200
table_open_cache = 8000

Najdôležitejšia hodnota: innodb_buffer_pool_size. Pravidlo: 50 – 70 % RAM, ak je server dedikovaný GLPI a MariaDB. Default 128M znamená, že 99 % queries treba ísť na disk — čo aj na NVMe je 10 – 100× pomalšie ako z RAM.

GLPI cron a údržba

Mimo aplikačného tuningu, schedulované akcie GLPI musia bežať aby sa DB nerozrastala:

# Systémový cron pre GLPI
*/2 * * * * www-data php /var/www/glpi/front/cron.php

# Mesačná údržba — purge starých logov + optimize tables
0 3 1 * * www-data php /var/www/glpi/bin/console glpi:logs:purge --no-interaction
0 4 1 * * mysql -e "OPTIMIZE TABLE glpi.glpi_logs, glpi.glpi_tickets, glpi.glpi_computers;"

V Setup → General → Automatic actions nastavte purgelogs, purgesessions, purgeoldnews na týždennú frekvenciu. Inak sa glpi_logs tabuľka po roku dostane na milióny riadkov a queries spomalia.

Monitoring

Sledujte tieto metriky:

  • PHP-FPM busy workers — ak je dlhodobo blízko max_children, treba zvýšiť limit alebo škálovať.
  • MariaDB slow query log — zapnite slow_query_log = 1, long_query_time = 2. Pravidelne čítajte; query > 2s je signál na index alebo refaktor.
  • Buffer pool hit rate — SHOW ENGINE INNODB STATUS, hodnota nad 99 % je dobrá. Pod 95 % zvýšte buffer pool.
  • OPcache hit rate — opcache_get_status() v PHP, hit rate nad 99 % je norma.

Spárované s reverzným proxy (pozri konfiguráciu reverzného proxy) tieto štyri vrstvy tuning-u udržia GLPI rýchlym aj pri tisíckach aktív a desiatkach súbežných používateľov. Bez tuningu je default GLPI inštalácia rýchla pri 20 ľuďoch a pomalá pri 200 — to nie je vada GLPI, je to default values, ktoré nie sú produkčne tuned.

Potrebujete pomôcť s touto témou?

Kontakt