Оптимізація споживання ресурсів: Як запустити 200 профілів на одному сервері

Запустити один антидетект-профіль може кожен. Запустити двісті на одному сервері без деградації продуктивності і масових крашів — це вже інженерне завдання. Більшість операторів, що масштабуються від 20-30 до 100+ профілів, стикаються з однаковими проблемами: браузери пожирають RAM швидше, ніж очікувалось, CPU впирається в обмеження при паралельній автоматизації, і все це рано чи пізно призводить до OOM killer, що вбиває процеси в найневідповідніший момент.

Правильна конфігурація сервера і профілів дозволяє радикально збільшити щільність: 200 профілів замість 40 на тому ж залізі.

Реалістична оцінка ресурсів на профіль

Перш ніж оптимізувати, потрібно зрозуміти базовий стан.

Споживання RAM на профіль суттєво залежить від:

Браузерного рушія (Firefox на базі Camoufox/Stealthfox в середньому легший за Chromium на 15-30%)
Кількості відкритих вкладок
Складності сторінок (media-важкі сайти vs прості форми)
Увімкнених розширень
Наявності JavaScript-важких фреймворків на сайтах

Типові показники для одного активного профілю:

Базовий Chromium-профіль (1 вкладка, простий сайт): 200-280 MB
Firefox-профіль (1 вкладка, простий сайт): 150-220 MB
Chromium з кількома вкладками і JS-важким сайтом: 400-700 MB
Firefox з кількома вкладками: 300-500 MB

Для 200 одночасних профілів з одною вкладкою на простих сайтах:

Chromium: 40-56 GB RAM
Firefox: 30-44 GB RAM

Для 200 профілів під реальним навантаженням (кілька вкладок, активна автоматизація):

Chromium: 80-140 GB RAM
Firefox: 60-100 GB RAM

Конфігурація сервера: вибір заліза

CPU — браузери є CPU-інтенсивними під час завантаження та JavaScript-виконання, але відносно легкими в idle. Для 200 профілів, що виконують паралельну автоматизацію, рекомендується мінімум 32 CPU cores. AMD EPYC або Intel Xeon з великою кількістю ядер оптимальні для багатопотокових навантажень.

RAM — найбільш критичний ресурс. Для 200 Firefox-профілів у реалістичному сценарії планувального мінімум 128 GB RAM, оптимально 256 GB. Для Chromium — 192 GB мінімум.

Диск — профілі зберігаються на диску. Кожен профіль з cookies, localStorage та кешем: 50-500 MB. Для 200 профілів — 10-100 GB. Використовуйте SSD або NVMe — HDD створить I/O bottleneck при паралельному запуску.

Мережа — для 200 активних з’єднань через проксі потрібен хороший апплінк. Мінімум 1 Gbps dedicated.

Linux-оптимізації: системний рівень

Swap configuration — для браузерних навантажень swap не є виходом: коли браузер pagefaults на swap, він фактично завмирає. Але правильно налаштований swap (zswap або zram) як compressed memory може дати ефективне збільшення доступної RAM.

# zram: стиснута оперативна пам'ять (CPU trade-off, але зазвичай варто)
sudo apt install zram-tools

# /etc/default/zramswap
ALGO=zstd          # zstd або lz4 - кращий коефіцієнт, ніж lzo
PERCENT=25         # 25% від RAM у zram (наприклад, 32GB із 128GB)
PRIORITY=100       # Використовувати zram першим

sudo systemctl restart zramswap

# Перевірка
zramctl

OOM Killer налаштування — за замовчуванням OOM killer може вбити будь-який процес. Захистіть управляючий демон:

# Захист daemon від OOM killer (значення -1000 = повний захист)
echo -1000 > /proc/$(pgrep santiago-daemon)/oom_score_adj

# Або через systemd unit:
# OOMScoreAdjust=-900

Дайте браузерним процесам середній пріоритет для OOM, щоб при нестачі RAM вбивались менш пріоритетні процеси першими:

echo 500 > /proc/$(pgrep camoufox)/oom_score_adj

vm.overcommit_memory — для браузерного навантаження:

# /etc/sysctl.d/99-browser-farm.conf

# Дозволяємо overcommit з перевіркою (режим 1 - дозволяє завжди,
# режим 0 - перевіряє, режим 2 - строгий)
vm.overcommit_memory = 1

# Агресивніше звільнення кешу при нестачі пам'яті
vm.vfs_cache_pressure = 200

# Dirty page writeback - більш агресивний для зменшення буферів
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

# Мінімізуємо swappiness (при наявності zram)
vm.swappiness = 10

# Збільшення ліміту відкритих файлів
fs.file-max = 2097152

# Збільшення ліміту inotify watches (Electron/браузери використовують)
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512

# Застосування без перезавантаження
sudo sysctl -p /etc/sysctl.d/99-browser-farm.conf

Limits для процесів:

# /etc/security/limits.d/browser-farm.conf
* soft nofile 1048576
* hard nofile 1048576
* soft nproc 65536
* hard nproc 65536

cgroups v2: ізоляція ресурсів між профілями

cgroups v2 дозволяє точно контролювати, скільки RAM і CPU отримує кожен профіль або група профілів.

# Перевірка, чи активовані cgroups v2
mount | grep cgroup2

# Якщо не активовано - додайте до GRUB_CMDLINE_LINUX в /etc/default/grub:
# systemd.unified_cgroup_hierarchy=1

Створення ієрархії cgroups для ферми профілів:

# Батьківська група для всіх браузерів
mkdir -p /sys/fs/cgroup/browser-farm

# Ліміт RAM для всієї ферми (наприклад, 100 GB)
echo "107374182400" > /sys/fs/cgroup/browser-farm/memory.max

# CPU ліміт (наприклад, 80% від усіх ядер)
echo "80000 100000" > /sys/fs/cgroup/browser-farm/cpu.max

# Підгрупа для кожного профілю (або батчу профілів)
for i in $(seq 1 200); do
    mkdir -p /sys/fs/cgroup/browser-farm/profile-$i
    # 512 MB на профіль
    echo "536870912" > /sys/fs/cgroup/browser-farm/profile-$i/memory.max
    # 50% одного ядра на профіль
    echo "50000 100000" > /sys/fs/cgroup/browser-farm/profile-$i/cpu.max
done

Призначення процесу до cgroup:

# При запуску профілю
PROFILE_PID=$(...)
echo $PROFILE_PID > /sys/fs/cgroup/browser-farm/profile-1/cgroup.procs

Оптимізація запуску профілів: batch-стратегія

Запуск 200 профілів одночасно — неефективна стратегія. Кожен браузер при запуску споживає значно більше CPU (компіляція JS, рендеринг першої сторінки), ніж в усталеному режимі.

Хвильовий запуск — запускайте профілі батчами по 10-20 з паузою між батчами:

import asyncio
import time

async def start_profile_batch(profile_ids: list, batch_size: int = 15, delay: float = 30.0):
    """
    Запускаємо профілі батчами з паузою між батчами.
    delay - секунди між батчами, щоб система стабілізувалась.
    """
    for i in range(0, len(profile_ids), batch_size):
        batch = profile_ids[i:i + batch_size]
        
        # Запускаємо батч паралельно
        tasks = [start_single_profile(pid) for pid in batch]
        results = await asyncio.gather(*tasks, return_exceptions=True)
        
        # Перевіряємо помилки
        for pid, result in zip(batch, results):
            if isinstance(result, Exception):
                print(f"Profile {pid} failed to start: {result}")
        
        # Пауза перед наступним батчем
        if i + batch_size < len(profile_ids):
            print(f"Batch started, waiting {delay}s before next batch...")
            await asyncio.sleep(delay)

Пул активних профілів — замість запуску всіх 200 профілів одночасно, використовуйте систему пулу: 50 профілів активні, 150 — “сплячі” (збережений стан, браузер закритий). При завершенні завдання для одного профілю він повертається в пул, і наступний завантажується.

Моніторинг споживання ресурсів

Базові метрики — відстеження в реальному часі:

#!/bin/bash
# monitor-farm.sh

watch -n 5 '
echo "=== Memory Overview ==="
free -h

echo ""
echo "=== Top Browser Processes by Memory ==="
ps aux --sort=-%mem | grep -E "camoufox|firefox|chrome" | head -20 | \
    awk '"'"'{printf "PID: %s | MEM: %s%% | %s\n", $2, $4, $11}'"'"'

echo ""
echo "=== CPU Load ==="
uptime

echo ""  
echo "=== Active Profile Count ==="
pgrep -c camoufox || echo "0"
'

Prometheus + Grafana для довгострокового моніторингу:

# prometheus.yml - збір метрик з node_exporter
scrape_configs:
  - job_name: 'browser-farm'
    static_configs:
      - targets: ['localhost:9100']
    scrape_interval: 15s

Ключові метрики для дашборду:

node_memory_MemAvailable_bytes — вільна RAM
node_memory_SwapFree_bytes — вільний swap
process_resident_memory_bytes{job="camoufox"} — RAM per процес
node_load1 — load average за 1 хвилину
node_disk_io_time_seconds_total — I/O навантаження

Оптимізація конфігурації браузера

Для кожного профілю можна знизити споживання RAM через налаштування браузера.

Firefox-специфічні оптимізації через user.js або prefs.js:

// Зниження споживання RAM Firefox
user_pref("browser.sessionhistory.max_entries", 5);  // Менше history у пам'яті
user_pref("browser.cache.memory.capacity", 32768);    // 32MB кеш замість авто
user_pref("browser.cache.disk.enable", false);         // Вимкнути disk cache (профіль на RAM)
user_pref("media.autoplay.enabled", false);            // Вимкнути автовідтворення медіа
user_pref("gfx.webrender.all", false);                 // Вимкнути WebRender (менше GPU)
user_pref("layers.acceleration.disabled", true);       // Вимкнути GPU acceleration
user_pref("javascript.options.mem.gc_incremental_slice_ms", 10);

Headless vs Headful — якщо профілям не потрібен видимий інтерфейс, headless режим економить GPU-ресурси і усуває необхідність у X11/Wayland. Але деякі антидетект-рішення мають обмеження в headless режимі (наприклад, деякі WebGL fingerprinting параметри відрізняються).

Xvfb для headful без монітора — для ферми без фізичного дисплею:

# Один Xvfb для всіх браузерів
Xvfb :99 -screen 0 1920x1080x24 -ac &
export DISPLAY=:99

Або індивідуальні дисплеї для кращої ізоляції (але більше ресурсів):

for i in $(seq 100 299); do
    Xvfb :$i -screen 0 1280x720x24 -ac &
done

Дискова оптимізація

tmpfs для тимчасових даних — браузерний кеш і тимчасові файли можуть зберігатися в оперативній пам’яті:

# /etc/fstab
tmpfs /tmp/browser-cache tmpfs defaults,size=8G,noexec,nosuid 0 0

Profile storage — профілі з cookies та LocalStorage повинні зберігатися на SSD. Для 200 профілів зі збереженими сесіями: 200 × 200MB = 40GB NVMe.

Профілювання I/O — визначення bottleneck:

# Моніторинг I/O у реальному часі
iotop -o -d 2

# Профілювання конкретного процесу
strace -e trace=read,write,open,close -p $PID 2>&1 | grep -v "ENOENT"

Якщо I/O є вузьким місцем — розгляньте NVMe RAID 0 або виділення кешу браузерів на tmpfs.

Практичний benchmark: 200 профілів

Реальні результати з оптимізованого сервера (AMD EPYC 7543, 256 GB RAM, NVMe SSD):

Сценарій	Без оптимізації	З оптимізацією	Економія
50 Firefox профілів	18 GB RAM	12 GB RAM	33%
100 Firefox профілів	40 GB RAM	26 GB RAM	35%
200 Firefox профілів	85 GB RAM	54 GB RAM	36%
200 профілів, активна автоматизація	140 GB RAM	90 GB RAM	36%

Ключові оптимізації, що дали найбільший ефект:

Firefox замість Chromium: -20% RAM
zram (zstd, 25%): ефективне збільшення RAM на 15-20%
Обмеження browser cache через prefs: -10-15% RAM на профіль
Хвильовий запуск: пік споживання CPU знизився на 60%
cgroups ліміти: усунення OOM-катастроф при перевантаженні

200 профілів на одному сервері — досяжна мета при правильній конфігурації. Ключ — розуміти реальне споживання ресурсів вашого конкретного сценарію (які сайти, яка активність) і налаштовувати оптимізації під нього, а не за загальними рекомендаціями.