Перейти до вмісту

Оптимізація сервера для роботи з MediaWiki

Матеріал з K2 ERP Wiki

Це здатна викликати 429, затримки або навіть 504. Залишайте свій робочий варіант.

sudo mkdir -p /var/www/wiki.erp.kyiv.ua/cache </syntaxhighlight> 

# Backend Nginx має бачити реальний IP клієнта. # POST is not limited, so MediaWiki save actions are not affected. include /etc/nginx/sites-enabled/*;
map "$is_heavy_bot:$mw_heavy_query:$mw_heavy_uri:$request_method" $bot_heavy_key {
pm.max_requests = 500
 ~*meta-webindexer 1;


##
# Limit only bot GET/HEAD requests. }</code> потрібно додати:

sudo tail -n 100 /var/log/nginx/error.log 

limit_req zone=bot_heavy_slow burst=5 nodelay;

Приклад: </syntaxhighlight> 

}

'''Не варто віддавати всю RAM під PHP-FPM.''' Потрібен запас для MySQL/MariaDB. ##

}
$wgShowIPinHeader = false;
</div>

unknown "bot_heavy_key" variable


  2. Heavy MediaWiki query detection 
include fastcgi_params;

Приклад:

Не можна робити так: 

<syntaxhighlight lang="bash">
Правильний результат:


##
# Heavy MediaWiki URI detection
##

<syntaxhighlight lang="ini">
$wgUseFileCache = true;

MySQL / MariaDB
 ~*ClaudeBot 1;
User-agent: SemrushBot
slowlog = /var/log/php8.4-fpm-slow.log


##
# Limit only bots + heavy GET/HEAD requests
##

~^1:0:1:HEAD$ $binary_remote_addr;

sudo systemctl reload nginx fastcgi_read_timeout 300s; htop Crawl-delay: 30 action=edit </syntaxhighlight> 

##
# Rate limit zones
##

 set $skip_cache 1;
З <code>nodelay</code>:
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;
== 14. File cache MediaWiki ==

Рекомендований стартовий варіант:
fastcgi_cache_key "$scheme$request_method$host$request_uri";
User-agent: CCBot

=== 3.3 Перевірка real IP ===

 set $skip_cache 1;

<syntaxhighlight lang="bash">
SET GLOBAL slow_query_log = 'ON';

gzip_min_length 1024;

oldid= Disallow: /*action=edit </syntaxhighlight> 

</div>
ps aux | grep php-fpm | sort -k3 -nr | head -20
Повний приклад PHP location:
</div>
action=raw

 default 0;

 include fastcgi_params;
limit_req zone=bot_heavy_slow burst=5 nodelay;
 ~*(^|&)(hidebots=|limit=|from=|target=|namespace=|offset=|dir=) 1;
 ~*/wiki/Special: 1;

request_slowlog_timeout = 5s

Поточні запити: User-agent: Bytespider

У PHP location: opcache.enable=1 Додати cron від користувача www-data: 

add_header Cache-Control "public";

</syntaxhighlight> set_real_ip_from 192.168.20.225; додати або перевірити:

</syntaxhighlight> 

=== Етап 2. PHP-FPM ===

gzip_comp_level 5;

У <code>LocalSettings.php</code>:
Crawl-delay: 30
sudo systemctl reload nginx

Disallow: /*oldid=

=== 2.3 Топ User-Agent ===

pm.min_spare_servers = 12
всередині <code>server { ... # Перевірити, що <code>POST</code> не лімітується. # Slowlog PHP-FPM і slow query log MySQL потрібні для пошуку реальної причини затримок. Після впровадження цих змін сервер має краще витримувати активність ботів, не створюючи проблем для звичайних користувачів і редакторів MediaWiki. pm.min_spare_servers = 10

if ($request_method != GET) { Пошук старих або неповних правил: Причина: у location застосовують, коли потрібноlimit_req zone=bot_heavy_slow, але в http { } не оголошено $bot_heavy_key. # Rate limit має діяти тільки на GET/HEAD, не на POST. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; pm.start_servers = 12

python3 ... # OPcache, APCu і кешування анонімних сторінок суттєво зменшують навантаження. Please slow down.\n"; Якщо в htop видно процеси: index.php?title= sudo nano /etc/nginx/nginx.conf sudo nginx -t 

pm.max_spare_servers = 20
limit_req_status 429;
 ~*PetalBot 1;

Перевірити кількість кодів відповідей:
 fastcgi_send_timeout 300s;
pm.max_children = 60
'''Якщо 504 виникає при збереженні сторінки, потрібно перевірити:'''

<syntaxhighlight lang="text">
'''критично:''' збільшення timeout не лікує причину повільної роботи, але дає довгим операціям, як приклад збереженню великої сторінки, завершитися без 504. всередину секції <code>http { ... }</code>:
'''Мета статті:''' зменшити навантаження на сервер MediaWiki, стабілізувати роботу php8.4-fpm, обмежити агресивних ботів за швидкістю, але не закривати їм доступ на 100%. # Увімкнути slowlog. # MediaWiki jobs краще виконувати через cron.</div>
Перегляд:

<syntaxhighlight lang="nginx">

<div style="border-left: 6px solid #2b7cff; background: #eef5ff; padding: 12px; margin: 12px 0;">

~*PerplexityBot 1;
↓
add_header X-FastCGI-Cache $upstream_cache_status always;
fastcgi_cache_bypass $skip_cache;

apc.user_ttl=3600

sudo chown -R www-data:www-data /var/cache/nginx/mediawiki 

Після змін:

Або:

 limit_req zone=bot_slow burst=20 nodelay;
'''Помилка:'''
Тоді можна поставити:

<syntaxhighlight lang="text">
* * * * * /usr/bin/php /var/www/wiki.erp.kyiv.ua/maintenance/runJobs.php --maxjobs 100 --maxtime 50 > /dev/null 2>&1

"1:GET" $binary_remote_addr;

sudo tail -f /var/log/php8.4-fpm-slow.log } 

 ↓

На frontend Nginx у блоці, який прокидує запити на backend, повинно бути:
<syntaxhighlight lang="php">
Backend Nginx

pm.max_children = RAM, доступна для PHP-FPM / середній розмір одного PHP-FPM процесу

sudo tail -n 50000 /var/log/nginx/access.log | awk -F\" '{print $6}' | sort | uniq -c | sort -nr | head -30

Special: 

fastcgi_no_cache $skip_cache;

8. Таймаути для уникнення 504

upstream timed out while reading response header from upstream

proxy_send_timeout 300s;

</syntaxhighlight> if ($query_string != "") { 

real_ip_header X-Real-IP;

<syntaxhighlight lang="bash">
Nginx здатна затримувати зайві запити в черзі. '''Якщо backend Nginx бачить тільки IP frontend-проксі, то limit_req буде рахувати всіх користувачів і ботів як одного клієнта.'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">

'''критично:''' якщо перед MediaWiki стоїть ще один Nginx, backend-сервер повинен бачити реальні IP користувачів, а не тільки IP frontend-проксі. * оновити розширення <code>SyntaxHighlight</code>;
* уникати дуже великих блоків <code>&lt;syntaxhighlight&gt;</code>;
* закешувати сторінки з великими блоками коду;
* обмежити ботам швидкість доступу до <code>oldid</code>, <code>diff</code>, <code>history</code>;
* перевірити PHP-FPM slowlog.<syntaxhighlight lang="bash">

# Увімкнути APCu. # Перевірити довгі запити. opcache.interned_strings_buffer=32
<div style="border-left: 6px solid #d32f2f; background: #ffebee; padding: 12px; margin: 12px 0;">
 ~^1:0:1:GET$ $binary_remote_addr;

</div>

<div style="border-left: 6px solid #d32f2f; background: #ffebee; padding: 12px; margin: 12px 0;">
sudo nano /var/www/wiki.erp.kyiv.ua/robots.txt
<syntaxhighlight lang="ini">
User-agent: PerplexityBot

real_ip_recursive on;

<syntaxhighlight lang="text">
User-agent: Amazonbot

gzip on;

Встановлення:

</syntaxhighlight>

Очікуваний заголовок: 

'x_real_ip="$http_x_real_ip" '

</syntaxhighlight>

}

sudo nginx -t

opcache.save_comments=1 location ~ \.php$ { Disallow: /*action=history 

fastcgi_pass unix:/run/php/php8.4-fpm.sock;

</syntaxhighlight> 

access_log off;

} 

== конфігурація php8. 9.4-fpm ==
pm = dynamic
Crawl-delay: 30

</syntaxhighlight> Перезапуск:

api.php limit_req zone=bot_slow burst=20 nodelay; 

limit_req zone=bot_heavy_slow burst=5 nodelay;

Якщо в slow query log багато запитів до таблиць page, revision, text, recentchanges, logging, потрібно окремо аналізувати індекси, розмір таблиць і проблемні сторінки. </syntaxhighlight> 

<syntaxhighlight lang="nginx">

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

} 

Увімкнення slow query log:

<syntaxhighlight lang="php">
 proxy_read_timeout 300s;
'''Перевага цього блоку:''' обмежуються тільки боти, тільки GET/HEAD-запити. # Обережно впровадити FastCGI cache для анонімних GET. proxy_read_timeout 300s;

sudo nano /etc/php/8.4/fpm/pool.d/www.conf
client=192.168.20.225
 ~*AhrefsBot 1;

map $http_user_agent $is_heavy_bot {
pm.max_children = 80
<syntaxhighlight lang="nginx">
<syntaxhighlight lang="bash">
У <code>server { ... # Перевірити OPcache. Окремо варто відзначити Nginx, системи, файлового кешу і службових задач MediaWiki.<syntaxhighlight lang="bash">

у секції <code>http { ... # Ботів потрібно обмежувати за швидкістю, а не блокувати на 100%.<syntaxhighlight lang="text">
<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">
limit_req zone=bot_slow burst=20 nodelay;
Перевірка:

Файл здатна бути:

Якщо основне навантаження створюють процеси:

=== 2.4 Топ URL ===
sudo systemctl reload nginx
 ~*MJ12bot 1;

$wgParserCacheType = CACHE_ACCEL;

== 6. Чому потрібен nodelay ==
</div>
 proxy_set_header X-Forwarded-Proto $scheme;
<syntaxhighlight lang="text">
Crawl-delay: 10

<syntaxhighlight lang="text">

 fastcgi_pass unix:/run/php/php8.4-fpm.sock;
X-FastCGI-Cache: HIT

sudo mkdir -p /var/cache/nginx/mediawiki
== 7. Перевірка Nginx ==
limit_req zone=bot_slow burst=20;

User-agent: AhrefsBot

Перевірити середній розмір PHP-FPM процесу:

Файл pool-конфігурації:

access_log /var/log/nginx/wiki_realip_debug.log realip_debug; Перезапуск: 

== 15. FastCGI cache в Nginx для анонімних GET ==
 proxy_connect_timeout 60s;
</div>

sudo systemctl restart php8.4-fpm

Неправильний результат:

</syntaxhighlight>

</syntaxhighlight>

ps aux | grep "php-fpm: pool" | awk '{sum+=$6; n++} END {if (n>0) print "avg:", sum/n/1024, "MB", "count:", n}' </syntaxhighlight> </syntaxhighlight>

OPcache для PHP 8. 11.4

або: 

default "";

</syntaxhighlight> Crawl-delay: 30 send_timeout 300s;

limit_conn_zone $bot_limit_key zone=bot_conn:20m;

У location з proxy_pass:

20. Діагностика 504 Gateway Timeout

Crawl-delay: 30

location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|webp|woff|woff2)$ { sudo tail -f /var/log/mysql/mysql-slow.log 

fastcgi_read_timeout 300s;

location / {

21. Рекомендований порядок впровадження

як приклад: 

SET GLOBAL long_query_time = 1;

=== 3.1 Frontend Nginx ===

real_ip_recursive on; $wgMessageCacheType = CACHE_ACCEL; 

 ~*YandexBot 1;
  2. Real client IP from frontend nginx

Без nodelay: так само критично, щоб обмеження не зачіпали POST, бо збереження сторінок MediaWiki виконується саме через POST. action=history

</syntaxhighlight>

proxy_set_header Host $host; </syntaxhighlight> sudo tail -n 50000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -30

fastcgi_cache_path /var/cache/nginx/mediawiki levels=1:2 keys_zone=MEDIAWIKI:200m inactive=60m max_size=5g; 

↓

</syntaxhighlight>

robots. 16.txt без повного блокування

server reached pm.max_children setting 

<syntaxhighlight lang="bash">

<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">

<syntaxhighlight lang="text">
Перевірка:

У backend Nginx:

sudo tail -n 50000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -50

Подивитися конкретні URL з 504:

location @rate_limited { sudo apt install php8.4-apcu

8.1 Frontend Nginx

Висновок

request_terminate_timeout = 300s
MediaWiki
<syntaxhighlight lang="nginx">
include /etc/nginx/conf.d/*.conf;

'xff="$http_x_forwarded_for" '

Перевірка:

12. APCu для кешу MediaWiki

add_header Retry-After 30 always;

У http { ... # Поставити request_terminate_timeout = 300s. ~*(^|&)(action=edit|action=history|action=raw|action=info|action=purge) 1; 

sudo nano /etc/php/8.4/fpm/conf.d/20-apcu.ini

 limit_req zone=bot_slow burst=20 nodelay;
sudo nginx -t
<syntaxhighlight lang="nginx">

map "$is_heavy_bot:$request_method" $bot_limit_key {

} 

default 0;

sudo nano /etc/nginx/sites-available/wiki.erp.kyiv.ua sudo chown -R www-data:www-data /var/www/wiki.erp.kyiv.ua/cache У PHP location додати: 

~*SemrushBot 1;

18. Перевірка MySQL / MariaDB

User-agent: * 

~*Bytespider 1;
send_timeout 300s;

 ~*facebookexternalhit 1;

</div>
<syntaxhighlight lang="bash">
 fastcgi_read_timeout 300s;

log_format realip_debug '$host client=$remote_addr proxy=$realip_remote_addr '

}
Приклад:
}

<syntaxhighlight lang="text">

$wgFileCacheDirectory = "$IP/cache";

Рекомендації:

sudo nano /etc/php/8.4/fpm/php.ini sudo nano /etc/nginx/nginx.conf 

fastcgi_send_timeout 300s;

<code>504 Gateway Timeout</code> означає, що Nginx не дочекався відповіді від upstream. sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr

=== 4.1 Повний блок для http { } ===

<syntaxhighlight lang="ini">

# Налаштувати <code>real_ip</code> на backend Nginx. # Перевірити, що авторизовані сторінки не кешуються. Це небезпечно, бо клієнти зможуть підробляти IP через HTTP-заголовки. }</code>:

 ↓

=== 9.2 Як порахувати pm.max_children ===
 return 429 "Too many requests. # Додати кешування статичних файлів.<syntaxhighlight lang="bash">

sudo systemctl restart php8.4-fpm
Після зміни:
У <code>LocalSettings.php</code>:
<syntaxhighlight lang="text">
sudo tail -f /var/log/nginx/wiki_realip_debug.log
<syntaxhighlight lang="bash">
 ~*Special: 1;

 default "";
'''robots.txt не виступає як захистом від агресивних ботів.''' Але коректні боти можуть враховувати <code>Crawl-delay</code> і не сканувати важкі URL. }</code>:
 ~*Baiduspider 1;
<syntaxhighlight lang="bash">

</syntaxhighlight> користувач системи / бот Crawl-delay: 30

дозволені запити проходять одразу, а зайві швидше отримують:

Етап 5. База даних

Увага: якщо PHP-FPM у вас слухає TCP, як приклад 127.0.0.1:9000, не змінюйте fastcgi_pass на socket. Основна ідея оптимізації MediaWiki: не без зусиль збільшити кількість PHP-FPM воркерів, а зменшити кількість важких запитів, які доходять до PHP. # Збереження сторінок не повинно потрапляти під bot limit. # Перевірити повідомлення server reached pm.max_children. # Проаналізувати важкі розширення. # Збільшити proxy_read_timeout і fastcgi_read_timeout до 300s.== 17. Кешування статичних файлів ==

У PHP location: sudo grep -R "bot_heavy_key\|mw_heavy_uri\|bot_limit_key\|is_heavy_bot\|limit_req" /etc/nginx/ mysqladmin status

Етап 3. MediaWiki

 ~^1:1:1:HEAD$ $binary_remote_addr;
== 3. Коректне визначення реального IP через два Nginx ==

Перезапуск:

<syntaxhighlight lang="bash">
Disallow: /*action=raw
 fastcgi_connect_timeout 60s;

 ~*Applebot 1;

== 13. Винесення MediaWiki Job Queue з веб-запитів ==
12000 MB / 180 MB = 66
На backend Nginx у файлі:

map $request_uri $mw_heavy_uri {
limit_req_zone $bot_heavy_key zone=bot_heavy_slow:20m rate=10r/m;

* чи POST не потрапляє під rate limit;
* чи достатній <code>proxy_read_timeout</code> на frontend Nginx;
* чи достатній <code>fastcgi_read_timeout</code> на backend Nginx;
* чи не впирається PHP-FPM у <code>pm.max_children</code>;
* чи не виконуються MediaWiki jobs під час веб-запиту;
* що показує PHP-FPM slowlog.</div>

'''Slowlog допоможе знайти реальну причину повільної роботи.''' Часто там видно <code>Parser</code>, <code>LinksUpdate</code>, <code>SpecialPage</code>, <code>SyntaxHighlight</code>, <code>api.php</code>, <code>RecentChange</code> або <code>JobQueue</code>. pm.max_spare_servers = 30

# Увімкнути slow query log. # Винести Job Queue в cron. У <code>LocalSettings.php</code>:
<syntaxhighlight lang="bash">

set_real_ip_from 192.168.20.225;

потрібно збільшити <code>pm.max_children</code>.

Шукати:

apc.ttl=3600 Рекомендовані параметри:

</syntaxhighlight>

Формула: 

proxy_set_header Host $host;

Найважливіші зміни: 

~^1:1:0:GET$ $binary_remote_addr;

fastcgi_connect_timeout 60s; unknown "mw_heavy_uri" variable Disallow: /w/index.php?title=Special: 

~*anthropic-ai 1;

client=92.222.104.195 proxy=192.168.20.225 sudo systemctl restart php8.4-fpm proxy_set_header X-Real-IP $remote_addr;

Перегляд: </syntaxhighlight> </syntaxhighlight>

</syntaxhighlight>

У конфігу сайту, як приклад: Crawl-delay: 30 

proxy_pass http://BACKEND_IP;

sudo journalctl -u php8.4-fpm | grep -i "max_children" | tail -20 sudo systemctl restart php8.4-fpm

5. конфігурація server-блоку MediaWiki

limit_conn bot_conn 5;

</syntaxhighlight> curl -I https://wiki.example.com/wiki/Main_Page 

$wgSessionCacheType = CACHE_ACCEL;

real_ip_header X-Real-IP;

4. Обмеження швидкості ботів без повного блокування

Frontend Nginx

php -i | grep -i opcache

~^1:1:1:GET$ $binary_remote_addr;

Помилка:

9.1 Перевірка нестачі воркерів

limit_req_zone $bot_limit_key zone=bot_slow:20m rate=1r/s; sudo tail -n 5000 /var/log/nginx/access.log | awk '$9 == 504 {print $1, $6, $7, $9, $12}' | tail -50 захисту живих користувачів краще використовувати nodelay забезпечується через Рекомендація:; так само реалізовано щоб Nginx не накопичував довгу чергу запитів. ##

  1. Bot detection

php8.4-fpm Цей блок потрібно вставити у:

</syntaxhighlight> location ~ \.php$ { pm = dynamic } 

~*/Special: 1;

</syntaxhighlight> </syntaxhighlight> proxy_set_header X-Forwarded-Proto $scheme; 

 expires 30d;
<syntaxhighlight lang="bash">
 fastcgi_cache_valid 404 1m;
$wgMainCacheType = CACHE_ACCEL;
IP frontend Nginx виступає ключовою рисою де <code>192.168.20.225 </code>. extensions/SyntaxHighlight_GeSHi/... pm.start_servers = 10
Disallow: /*diff=

'''Причина:''' у конфігу застосовується для <code>$mw_heavy_uri</code>, але не оголошено відповідний <code>map</code>. php-fpm: pool www

 ~*ChatGPT-User 1;
<syntaxhighlight lang="nginx">
 ~*GPTBot 1;

== 19. SyntaxHighlight та інші важкі розширення ==

User-agent: ClaudeBot
<div style="border-left: 6px solid #2b7cff; background: #eef5ff; padding: 12px; margin: 12px 0;">

↓

apc.enabled=1

</syntaxhighlight> 

fastcgi_cache_valid 200 301 302 10m;

<div style="border-left: 6px solid #388e3c; background: #e8f5e9; padding: 12px; margin: 12px 0;">

це означає, що сторінки з підсвіткою коду можуть створювати велике навантаження. }</code> можна тимчасово додати:
 ~*CCBot 1;

 ~^1:1:0:HEAD$ $binary_remote_addr;
Створити каталог:
 ~*BLEXBot 1;

=== 8.2 Backend Nginx ===
<syntaxhighlight lang="bash">
 set $skip_cache 1;

php -m | grep -i apcu
 fastcgi_connect_timeout 60s;
 fastcgi_cache MEDIAWIKI;

== 1. Типова схема роботи ==
У потрібному <code>server { ... POST-запити, тобто збереження сторінок, не повинні потрапляти під цей rate limit. це означає, що навантаження йде через PHP / MediaWiki. }</code> додати:
pm.max_requests = 500

Це одна з найважливіших оптимізацій для збереження сторінок. MediaWiki jobs не повинні виконуватись у звичайному веб-запиті користувача. # Використати nodelay. }, бажано до рядків: </syntaxhighlight> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; </syntaxhighlight>

set $skip_cache 0; 

default 0;

sudo nano /etc/php/8.4/fpm/conf.d/10-opcache.ini У файлі:

</syntaxhighlight>

if ($http_cookie ~* "UserID|Token|session|mediawiki") { 

proxy_send_timeout 300s;

</syntaxhighlight>

proxy_connect_timeout 60s; </syntaxhighlight> Якщо все добре: }

Конфігурація:

</syntaxhighlight> 

=== Етап 4. Кешування Nginx ===

<syntaxhighlight lang="cron">
map $query_string $mw_heavy_query {

~*Amazonbot 1;

2. Діагностика навантаження

задача — не забороняти ботам доступ через 403, а зменшити швидкість їхніх запитів. # Оптимізувати індекси або проблемні сторінки. # PHP-FPM має мати достатньо воркерів. '"$request" $status "$http_user_agent"';

</syntaxhighlight> Загальний статус:

2.2 Топ IP за кількістю запитів

</syntaxhighlight> 

proxy_set_header X-Real-IP $remote_addr;

apc.gc_ttl=3600 У розглянутій конфігурації сайт функціонує приблизно так:

Файл: 

opcache.validate_timestamps=1

Типові помилки

opcache.max_accelerated_files=20000 request_slowlog_timeout = 5s 

<syntaxhighlight lang="nginx">
<div style="border-left: 6px solid #388e3c; background: #e8f5e9; padding: 12px; margin: 12px 0;">

error_page 429 = @rate_limited;
Створити каталог:

} Якщо виступає як: 

~*DotBot 1;

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

Crawl-delay: 30

fastcgi_send_timeout 300s; 

}
$wgJobRunRate = 0;
Перевірка:
=== Етап 1. Безпечні термінові дії ===
<syntaxhighlight lang="text">

<syntaxhighlight lang="bash">

</div>

</div>
'''Особливо важкі запити для MediaWiki:'''
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
set_real_ip_from 0.0.0.0/0;
opcache.memory_consumption=256

</syntaxhighlight> 429 Too Many Requests

User-agent: GPTBot

</syntaxhighlight>

10. PHP-FPM slowlog

2.1 Перевірка процесів

Увага: FastCGI cache потрібно впроваджувати обережно, щоб не кешувати сторінки авторизованих користувачів. "1:HEAD" $binary_remote_addr;

  1. Збільшити pm.max_children. # Увімкнути файловий кеш. sudo crontab -u www-data -e

diff=

3.2 Backend Nginx

mysqladmin processlist </syntaxhighlight> opcache.revalidate_freq=60

slowlog = /var/log/php8.4-fpm-slow.log У http { ... # Додати rate limit тільки для ботів і тільки для GET/HEAD. ~*(^|&)(diff=|oldid=|curid=) 1; pm.max_children = 60 apc.shm_size=256M

Отримано з https://wiki.kyiv.ua/index.php?title=Оптимізація_сервера_для_роботи_з_MediaWiki&oldid=1304