Ubuntu 24.04 APT повільний: кеш/проксі хитрощі, що пришвидшують офісні оновлення

Швидкий план діагностики

Коли кажуть «APT повільний», мають на увазі будь-що з цього:

• Отримання метаданих повільне (apt update зависає на «Connecting»)
• Завантаження пакетів повільне (apt upgrade повзе)
• Розпакування/налаштування повільні (обмеження CPU/диску, не пов’язано з мережею)
• Все повільне, бо проксі «допомагає»

По-перше: вирішіть, мережа це, дзеркало чи локальне I/O

1. Виміряйте швидкість завантаження до дзеркала з одного клієнта і з одного «відомо гарного» хоста в мережі. Якщо обидва повільні — проблема в WAN/дзеркалі/проксі. Якщо лише клієнти — проблема в клієнті/проксі/DNS.
2. Перевірте затримки DNS. Повільний DNS змушує APT виглядати завислим, бо воно й справді чекає.
3. Розділіть фазу завантаження і встановлення, завантаживши тільки пакети (apt-get -d) і окремо заміряючи розпакування.

По-друге: перевірте поведінку проксі

1. Якщо ви за корпоративним проксі, перевірте, чи виконує він інспекцію TLS, сканування контенту або «кешує» погано.
2. Підтвердіть, що APT справді використовує той проксі, про який ви думаєте. Часто він не налаштований на серверах, або налаштований двічі.

По-третє: вирішіть клас виправлення

• Офіс з 10–300 Ubuntu машин: розгорніть apt-cacher-ng в локальній мережі. Це оптимальне рішення.
• Сувора відповідність політикам + стабільний набір пакетів: розгляньте повне дзеркало або менеджер репозиторіїв (більше операцій, більше контролю).
• Одна машина на поганому Wi‑Fi: оберіть краще дзеркало та виправте DNS; не будуйте імперію кешування.

Чому APT «здається повільним» в офісі

Продуктивність APT формується стеком невеликих затримок. У дата-центрі ці затримки низькі й передбачувані. В офісі вони хаотичні: повторні передачі Wi‑Fi, проміжні DNS, прозорі проксі, «захисні» пристрої та WAN-канал, який ділять відеодзвінки й синхронізація фотоколекції розміром із невеликий місяць.

APT також має специфічний профіль трафіку:

• Багато дрібних метаданих під час apt update (файли Release, списки індексів).
• Потім менше, але більших завантажень пакетів під час встановлення/оновлення.
• Потім локальне дискове I/O та CPU під час розпакування і post-install скриптів.

Перша фаза — де офіси страждають. APT може отримувати десятки файлів з різних репозиторіїв. Якщо кожне HTTPS-з’єднання має повільний рукопотиск або кожен DNS-запит триває 200 мс, сума виходить великою. Кеш/проксі в LAN зводить цю латентність до одного швидкого переходу.

Суб’єктивна порада: Якщо у вас більше ніж кілька систем Ubuntu на одному сайті, перестаньте дозволяти кожній окремо завантажувати ті ж пакети з Інтернету. Це не «децентралізація». Це просто марнотратство.

Короткий жарт для настрою: APT не повільний; він просто терпляче чекає, поки ваш проксі закінчить думати.

Цікавий контекст і факти

• APT з’явився наприкінці 1990-х як інструмент вищого рівня для Debian, призначений для надійної роботи з залежностями між репозиторіями.
• «Acquire» — це окремий підсистема всередині APT; більшість скарг «APT повільний» насправді пов’язані з налаштуванням Acquire, DNS і транспортом — не з dpkg.
• Історично APT використовував обережно кілька з’єднань, бо дзеркала й пропускна здатність були рідкісні; сучасні мережі змінили обмеження, але APT все ще віддає перевагу коректності.
• Екосистема дзеркал Ubuntu глобально розподілена; «найкраще» дзеркало для офісу може змінюватися залежно від пірування ISP, а не географії.
• HTTPS став очікуваним стандартом з часом; він покращує цілісність і приватність, але додає наклад на рукопотиск і робить деякі прозорі кешуючі пристрої марними.
• Індекси пакетів стискаються (часто .gz), що економить трафік, але означає, що CPU може бути важливим на слабких системах або перевантажених віртуалках.
• apt-cacher-ng набув популярності через простоту: він кешує без потреби в повному дзеркалі та без перезаписування структури репозиторію.
• У багатьох офісах DNS — прихований вузький горлик, бо внутрішні резолвери форвардять запити вгору зі фільтрацією, логуванням і обмеженнями за частотою.

Одна перефразована ідея, варта пам’яті в операціях: Werner Vogels часто підкреслював думку, що «усе ламається, тож проєктуйте для відмов» (парафраз). Повільність APT зазвичай — м’яка відмова: не настільки зламана, щоб викликати інцидент, але достатньо, щоб марнувати час усім.

Практичні завдання: команди, виводи, що це означає і рішення

Це польові завдання. Запустіть їх на одному ураженому клієнті спочатку, потім на майбутньому хості кеша/проксі. Не гадуйте. Вимірюйте.

Завдання 1: Підтвердити, яка частина повільна (update vs download vs install)

cr0x@server:~$ sudo time apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 8s (13.2 kB/s)
Reading package lists... Done

real    0m9.214s
user    0m0.391s
sys     0m0.103s

Що це означає: Ви витрачаєте секунди на отримання дрібних метаданих. Це вказує на DNS, рукопотиск проксі або затримки на запит.

Рішення: Зосередьтеся на DNS/proxy/kешуванні, а не на диску чи CPU.

Завдання 2: Заміряти лише час завантаження для оновлень (пропустити час встановлення)

cr0x@server:~$ sudo time apt-get -y -d dist-upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded:
  openssl openssh-client
Need to get 4,812 kB of archives.
Get:1 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssl amd64 3.0.13-0ubuntu3.2 [1,402 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssh-client amd64 1:9.6p1-3ubuntu13.4 [3,410 kB]
Fetched 4,812 kB in 2s (2,406 kB/s)

real    0m3.011s
user    0m0.233s
sys     0m0.116s

Що це означає: Якщо це швидко, а повне оновлення повільне — вузьке місце в локальному встановленні/розпакуванні/скриптах.

Рішення: Якщо завантаження швидке, перестаньте звинувачувати дзеркала. Перевірте диск і блокування dpkg.

Завдання 3: Перевірити блокування dpkg/apt і завислі процеси

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | head
root        1421  0.0  0.1  18220  4800 ?        Ss   09:01   0:00 /usr/lib/apt/apt.systemd.daily
root        1507  0.2  0.3  56340 12420 ?        S    09:02   0:01 /usr/bin/dpkg --configure -a

Що це означає: Системний щоденний сервіс systemd може вже виконувати оновлення або конфігурування пакетів.

Рішення: Не боріться з ним. Дайте йому завершити роботу або плануйте офісні оновлення поза робочим часом.

Завдання 4: Перевірити налаштовані репозиторії і транспорт (HTTP vs HTTPS)

cr0x@server:~$ grep -R --no-filename -E '^(deb|deb-src)\s' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | head -n 8
deb http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu noble-security main restricted universe multiverse

Що це означає: Ви використовуєте HTTP тут (звично для основних репозиторіїв Ubuntu). HTTPS може бути повільнішим через інспекційні пристрої; HTTP може бути заблоковано в деяких середовищах.

Рішення: Оберіть транспорт, який коректно працює з вашою мережею; кешування працює найкраще, коли шлях стабільний.

Завдання 5: Перевірити, до якого дзеркала ви насправді підключаєтесь (і чи є перенаправлення)

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
     release v=24.04,o=Ubuntu,a=noble-updates,n=24.04,l=Ubuntu,c=main,b=amd64
     origin archive.ubuntu.com

Що це означає: Підтверджує origin і пріоритети репозиторію.

Рішення: Якщо ви пізніше розгорнете кеш, переконайтеся, що origin зміниться на ваш хост кеша.

Завдання 6: Діагностувати затримку DNS (часто реальний винуватець)

cr0x@server:~$ resolvectl status | sed -n '1,40p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11

Що це означає: Ви використовуєте внутрішній DNS. Це нормально — доки він не повільний або не фільтрує агресивно.

Рішення: Якщо внутрішній DNS перевантажений, виправте його або додайте локальний кешуючий резолвер на сайті.

Завдання 7: Закремяйте час DNS-запитів для дзеркал

cr0x@server:~$ time getent ahosts archive.ubuntu.com | head -n 3
91.189.91.83    STREAM archive.ubuntu.com
91.189.91.83    DGRAM
91.189.91.83    RAW

real    0m0.215s
user    0m0.004s
sys     0m0.004s

Що це означає: 215 мс для запиту — не катастрофа, але помножте на десятки запитів, плюс повтори, плюс проксі-запити — і це стає проблемою.

Рішення: Якщо бачите >100 мс регулярно в LAN, вважайте DNS продакшн-залежністю і кешуйте його локально.

Завдання 8: Заміряти час встановлення TCP/TLS-з’єднання

cr0x@server:~$ curl -I -s -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' http://archive.ubuntu.com/ubuntu/
dns:0.021 connect:0.034 tls:0.000 ttfb:0.102 total:0.103

Що це означає: Для HTTP немає TLS. Якщо запустите те саме для HTTPS-репозиторію і побачите великий tls, можливо, втручається проксі або інспекційний блок.

Рішення: Латентність можна вирішити локальним кешем, бо повільні рукопотиски відбуваються один раз на об’єкт в іншому випадку.

Завдання 9: Перевірити проблеми з MTU (класичне «працює, але повільно»)

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Що це означає: MTU 1500 — нормально. Якщо ви на VPN/VXLAN/PPPoE і MTU не співпадає, можуть бути повторні передачі і зависання.

Рішення: Якщо завантаження випадково зависає, протестуйте path MTU і виправте край мережі, а не APT.

Завдання 10: Подивіться, чи APT використовує проксі (і який саме)

cr0x@server:~$ apt-config dump | egrep -i 'Acquire::(http|https)::Proxy' | head
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";

Що це означає: APT явно налаштований використовувати проксі.

Рішення: Якщо цей проксі віддалений (HQ), а ваш офіс — ні, ви додали непотрібні RTT. Розмістіть кеш ближче або обійдіть його для Ubuntu-репозиторіїв.

Завдання 11: Підтвердити доступність проксі і чи він є точкою звуження

cr0x@server:~$ curl -s -o /dev/null -w 'proxy_connect:%{time_connect} total:%{time_total}\n' http://proxy.office.local:3128/
proxy_connect:0.003 total:0.004

Що це означає: LAN-проксі досяжний швидко. Якщо це триває секунди, ваш «офісний проксі» не локальний або перевантажений.

Рішення: Виправте локальність/потужність проксі перед тим, як переконфіговувати APT.

Завдання 12: Проінспектувати повтори/таймаути APT (ознаки втрат)

cr0x@server:~$ sudo apt -o Debug::Acquire::http=true update 2>&1 | egrep -i 'Connecting|Waiting|Retrying' | head -n 20
Connecting to archive.ubuntu.com (91.189.91.83)
Waiting for headers
Connecting to security.ubuntu.com (185.125.190.39)
Waiting for headers

Що це означає: Затримки «Waiting for headers» вказують на затримки сервера/проксі, перевантаження або втрачені пакети більше ніж на обмеження пропускної здатності.

Рішення: Розгорніть кеш в LAN, щоб зменшити зовнішні кругові поїздки; якщо проблема лишається — досліджуйте WAN-втрати і наклад інспекції проксі.

Завдання 13: Переконатися, що у кеш-хоста достатньо місця

cr0x@server:~$ df -h /var/cache | tail -n 1
/dev/sda2        200G   38G  153G  20% /var

Що це означає: Достатньо вільного місця для кешу пакетів. apt-cacher-ng ефективний навіть з помірним дисковим простором, але йому не слід бракувати місця.

Рішення: Якщо місця мало, виділіть окремий том для кеша і встановіть політику витіснення.

Завдання 14: Підтвердити, що кеш дійсно віддає hits після розгортання

cr0x@server:~$ sudo tail -n 8 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 10:12:41|O|171|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb
2025-12-29 10:13:02|H|612|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb

Що це означає: O — запит до origin (miss). H — кеш-хіт. Хіти дають прискорення і економію трафіку.

Рішення: Якщо бачите лише origin-запити, клієнти не вказують на кеш або кешування для цього шляху репозиторію вимкнено.

Варіанти кешування і проксі (що розгорнути)

Є три основні стратегії для офісів. Кожна має своє місце. Дві з них легко ускладнити надміру.

1) apt-cacher-ng в LAN (найкращий варіант за замовчуванням)

Що це: HTTP-проксі, яке розуміє патерни Debian/Ubuntu репозиторіїв і кешує пакети та індексні файли за запитами клієнтів.

Чому це працює: Другий клієнт отримує пакети зі швидкістю LAN. 50-й клієнт майже не зачіпає WAN.

Компроміси: Це спільна залежність. Якщо ви зробите її крихкою, ви це почуєте. Якщо ви її запустите нудно — ніхто не помітить, а це найкраща похвала в операціях.

2) Загальний HTTP-проксі (Squid або корпоративний проксі)

Що це: Загальний проксі, який може або не може ефективно кешувати залежно від поведінки HTTPS і правил кешування.

Коли працює: Якщо більшість трафіку репозиторію йде по HTTP і політика кешування проксі адекватна.

Коли болить: HTTPS-репозиторії плюс інтерцепція та сканування можуть перетворити APT на повільний документальний фільм про TLS-рукопотиски.

3) Повне локальне дзеркало / управління репозиторіями

Що це: Ви віддзеркалюєте репозиторії Ubuntu локально (або запускаєте менеджер репозиторіїв, що синхронізує потрібний вміст).

Коли виправдано: Великі парки машин, суворий контроль змін, мережі з обмеженим доступом або потреба в детермінованій доступності під час зовнішніх технічних проблем.

Недолік: Більше дискового простору, більше операцій, більше тікетів «чому це дзеркало не синхронізується».

Розгортання apt-cacher-ng (рекомендується для більшості офісів)

Це офісний виграш: одна невелика VM або міні‑ПК на сайті, кілька рядків конфігурації, і оновлення перестають бути щотижневим мережевим інцидентом.

Налаштування сервера на Ubuntu 24.04

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

Значення: Базова система достатньо здорова для встановлення пакетів.

cr0x@server:~$ sudo apt install -y apt-cacher-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  apt-cacher-ng
Setting up apt-cacher-ng (3.7.4-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/apt-cacher-ng.service → /usr/lib/systemd/system/apt-cacher-ng.service.

Значення: Сервіс встановлено і ввімкнено.

Рішення: Визначте, як клієнти до нього звертатимуться (DNS-ім’я) і чи потрібно слухати на всіх інтерфейсах.

Підтвердіть, що він слухає

cr0x@server:~$ sudo ss -lntp | egrep ':3142'
LISTEN 0      4096         0.0.0.0:3142      0.0.0.0:*    users:(("apt-cacher-ng",pid=1824,fd=7))

Значення: Порт за замовчуванням 3142 відкритий на всіх інтерфейсах. Якщо це занадто відкрите для вашої мережі, обмежте через правила файрвола.

Базовий файрвол (обмежити підмережами офісу)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 3142 proto tcp
Rule added

Значення: Тільки ця підмережа може користуватись кешем.

Рішення: Якщо у вас кілька VLAN, додайте явні правила для кожної підмережі; не відкривайте на весь світ і не сподівайтеся.

Налаштування клієнта: вказати APT на кеш

На кожному клієнті Ubuntu створіть невеликий фрагмент конфігурації. Використовуйте DNS для імені хоста кеша, щоб мати можливість змінити його пізніше без відвідування всіх машин.

cr0x@server:~$ echo 'Acquire::http::Proxy "http://aptcache.office.local:3142";' | sudo tee /etc/apt/apt.conf.d/02proxy
Acquire::http::Proxy "http://aptcache.office.local:3142";

Значення: HTTP-запити будуть йти через ваш кеш.

Рішення: Якщо ваші джерела — HTTPS, ви все одно можете проксувати HTTPS через HTTP-проксі, але протестуйте з вашим політично‑безпечним стеком; деякі середовища блокують CONNECT.

Перевірте, що клієнти потрапляють у кеш

Запустіть update на клієнті, потім перевірте логи на сервері кеша.

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Fetched 126 kB in 1s (148 kB/s)
Reading package lists... Done

Значення: Вивід клієнта не завжди явно покаже проксі. Правда — у логах кеша.

cr0x@server:~$ sudo tail -n 5 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 11:03:11|O|250|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease
2025-12-29 11:03:12|O|411|archive.ubuntu.com|ubuntu|dists/noble-updates/main/binary-amd64/Packages.gz
2025-12-29 11:04:02|H|7|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease

Значення: Перший запит отримав з origin, другий клієнт (або другий запуск) потрапив у кеш.

Рішення: Якщо ніколи не бачите хітів, клієнти можуть обходити проксі через існуючі налаштування, змінні оточення або політику мережі.

Операційна гігієна, що зберігає швидкість

• Розміщуйте дані кеша на диску, який не конкурує з великими логами чи базами даних.
• Моніторте використання диска і кількість інодів (поява багатьох дрібних файлів).
• Плануйте перезавантаження: переконайтеся, що сервіс швидко стартує і правила файрвола зберігаються.
• Тримайте все просто. Кеш — не місце для творчих експериментів.

Правильне використання корпоративного HTTP(S) проксі

Деякі офіси вже мають корпоративний проксі. Якщо він локальний, здоровий та налаштований не псувати завантаження пакетів, ви можете його використовувати повторно. Якщо проксі віддалений (через HQ), це часто причина повільних оновлень у філіях.

Вирішіть, чи варто обходити проксі для Ubuntu репозиторіїв

Якщо політика дозволяє, обхід проксі для відомих дзеркал оновлень може дати великий приріст. Правильний підхід залежить від того, як організація контролює вихідний трафік. Якщо безпека вимагає видимості у проксі, тоді розгорніть локальний кеш/проксі на сайті і дайте йому виходити в інтернет контрольовано.

Налаштуйте проксі явно (не покладайтеся на змінні оточення)

cr0x@server:~$ sudo tee /etc/apt/apt.conf.d/02proxy >/dev/null <<'EOF'
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";
EOF

Значення: APT використовуватиме проксі незалежно від оболонки користувача.

Рішення: Централізуйте це через інструменти управління конфігурацією. Ручні правки проксі — причина «працює на моєму ноуті» у вигляді системного адміністратора.

Слідкуйте за побічними ефектами TLS-інспекції

Якщо ваш проксі робить TLS-інспекцію, ви можете бачити:

• Довгі TLS-рукопотиски (клієнт чекає, поки проксі просканує)
• Випадкові затримки при великих завантаженнях (буферизація/сканування контенту)
• Іноді помилки невідповідності хешу, якщо шлях змінює вміст (рідко, але трапляється)

APT орієнтований на цілісність. Це добре. Також це означає, що «корисні» пристрої, які переписують контент, не ваші друзі.

Другий короткий жарт (останній): Єдине гірше за повільний проксі — це повільний проксі, який наполягає, що пришвидшує ваш трафік.

Повне локальне дзеркало: коли воно виправдане (а коли це хобі)

Повне дзеркало — дорослий варіант для великих середовищ. Воно дає вам:

• Незалежність від зовнішніх відмов або нестабільних дзеркал
• Повторюваний вміст (те, що ви тестували, — те, що ви розгортаєте)
• Кращі історії відповідності (що було доступне в певний момент)

Воно також додає рутинні задачі:

• Графіки синхронізації, планування сховища та виявлення корупції
• Управління ключами і підписування при переадресації або кураторстві
• Більше рухомих частин, які можуть викликати дзвінок о 2 ночі

Правило використання: якщо проблема в офісі — «занадто багато машин завантажують одне й те ж», apt-cacher-ng вирішує це з мінімальним церемоніалом. Якщо ж потрібні контрольовані, куратовані репозиторії — будьте готові будувати дзеркало/менеджер репозиторіїв і прийняти операційне навантаження.

Клієнтське тонке налаштування, яке дійсно допомагає

Клієнтське тонке налаштування — місце, де люди витрачають час даремно. Кеш/проксі дає великий приріст. Проте кілька налаштувань на клієнті можуть зменшити незручності.

Оберіть краще дзеркало (але не перетворюйте це на спорт)

За замовчуванням дзеркала Ubuntu зазвичай підходять, але «зазвичай» не означає гарантію продуктивності. Правильне дзеркало для вашого ISP і сайту може відрізнятися.

Практичний метод: протестуйте два-три дзеркала з офісу в робочий і позаробочий час. Якщо дзеркало швидке опівночі і повільне о 10 ранку — це, ймовірно, проблема навантаження/пірингу, а не ваша конфігурація. В офісах вам потрібна передбачуваність, а не «найкращий випадок».

Обмежте сюрпризи від unattended-upgrades

Unattended upgrades корисні. Безкоординовані unattended upgrades по сайту — це як ви дізнаєтеся, що ваш WAN-канал не нескінченний.

Рознесіть їх у часі. Або налаштуйте їх тягнути пакети через сайт-кеш, щоб WAN-удар відбувався раз.

Не «оптимізуйте», вимикаючи перевірки підписів

Якщо хтось пропонує обійти верифікацію для «прискорення» — відхиліть цю пропозицію так само, як би відхилили б/у парашут. Перевірки цілісності не опціональні; вони — сенс менеджера пакетів.

Короткі кейси з реальної експлуатації

Інцидент: хибна впевненість («це дзеркало»), яка з’їла тиждень

Середня компанія мала філію, де оновлення Ubuntu займали 20–40 хвилин. Команда вирішила, що винне дзеркало Ubuntu, бо traceroute виглядав «довгим», а тест швидкості до якогось випадкового сайту був нормальний. Вони міняли дзеркала тричі і навіть зафіксували конкретний регіональний ендпоїнт.

Нічого не змінювалося. Деякі ранки було терпимо; після обіду — жахливо. Класична переривчаста біда.

Справжній винуватець — DNS. Резолвер філії форвардив всі запити назад у HQ через стек безпеки, що логував і фільтрував. Під час пікових годин шлях мав спайки затримок і іноді тайм-аути. Патерн APT з «багатьма дрібними запитами» змусив думати, що дзеркало — причина, бо резолювання імен постійно зависало перед першим байтом.

Вони виправили це, додавши локальний кешуючий DNS резолвер у філії, а потім розгорнули apt-cacher-ng. Питання дзеркал зникло. Категорія заявок зникла. Урок був болісно простим: не звинувачуйте сервіс, який видно, доки не виміряєте залежність, яку не видно.

Оптимізація, що відбилася боком: «один проксі для всіх сайтів»

Інша організація централізувала все за одним проксі для «кращого контролю». Філії були налаштовані використовувати його для APT, браузерів, усього. Проксі мав багато CPU і пам’яті, і його панель показувала зелений статус. Здавалося б, все ок.

Але філії були розділені каналами з великою латентністю. Трафік APT став парадом CONNECT тунелів і дрібних запитів, кожен платив RTT-податок. Гірше, проксі робив сканування контенту, що буферизувало завантаження перед відпуском — корисно для шкідливих програм, але не для менеджера пакетів, який тягне сотні мегабайт.

Вони пробували налаштовувати паралелізм і таймаути APT. Це зробило ситуацію галасливішою, але не швидшою. Деякі клієнти почали частіше таймаути, бо стали агресивнішими у створенні з’єднань, які приречені бути повільними.

Виправлення — припинити ставити філії як тонкі клієнти HQ. Вони розгорнули невеликий кеш/проксі на сайті (ще під контролем, з логуванням на виході) і дозволили сайту кешу виходити назовні. Використання WAN впало, скарги користувачів зникли, і центральний проксі повернувся до своєї ролі політико‑ферзи без того, щоб бути довгим якірним фактором продуктивності.

Нудна, але правильна практика, що врятувала день: «хост кеша як скот»

Одна команда розгорнула apt-cacher-ng по десятках сайтів. Вони зробили дещо зовсім нецікаве: стандартизували образ VM кеша, використали той самий порт, ті самі правила файрвола, ту саму розмітку диска і керували фрагментом проксі клієнта за допомогою CM.

Вони також трактували кеш як витратний ресурс. Ніяких мистецьких налаштувань на коробці. Якщо щось відбувалося — вони просто розгортали заново. Логи відсилалися централізовано; метрики були базові (використання диска, піднятість сервісу, швидкість запитів). Вміст кеша сам по собі не був дорогим — його можна було відновити за використанням.

Потім на сайті стався стрибок живлення, що пошкодив диск кеша. Користувачі знову почали скаржитися на повільні оновлення, але нічого іншого не було зламано. VM кеша відновили з шаблону за менше ніж годину, DNS вказав на нову інстанцію, і клієнти продовжили роботу. Ніяких героїчних дій, ніяких викликів уночі. Просто винагорода за нудність.

Типові помилки: симптом → причина → виправлення

1) apt update «висне» на Connecting/Waiting for headers

Симптом: Здається, що воно зависло, потім продовжує.

Причина: Повільний DNS, наклад проксі, втрата пакетів або пристрій безпеки, що буферизує відповіді.

Виправлення: Заміряйте DNS; виміряйте connect/TTFB за допомогою curl; розгорніть LAN-кеш; виправте WAN-втрати; уникайте віддалених hairpin-проксі.

2) Завантаження спочатку швидке, потім повільніє до повного краху

Симптом: Перші мегабайти ок, потім стає повільним або нестабільним.

Причина: Проблеми з MTU/PMTUD, сканування/буферизація в проксі або повторні передачі Wi‑Fi.

Виправлення: Перевірте MTU і VPN‑наклад; протестуйте по дроту; обійдіть або локалізуйте проксі; тримайте кеш у LAN, щоб зменшити чутливість до WAN.

3) «Hash Sum mismatch» або помилки підписів репозиторію з’являються періодично

Симптом: APT відмовляється використовувати завантажені метадані.

Причина: Прозорий проксі змінює вміст, пошкоджений кеш, що віддає неповні файли, або несинхронні дзеркала.

Виправлення: Вимкніть прозоре кешування для трафіку репозиторію; очистіть кеш проксі для уражених об’єктів; переключіться на стабільне дзеркало; перевірте диск кеша.

4) Кеш розгорнутий, але прискорення немає

Симптом: Клієнти досі завантажують з Інтернету; логи кеша показують переважно misses.

Причина: Клієнти не налаштовані, HTTPS-репозиторії обходять кеш, або інший проксі перекриває налаштування.

Виправлення: Перевірте apt-config dump; стандартизируйте фрагмент у /etc/apt/apt.conf.d/; валідируйте по логах кеша і на контрольному клієнті.

5) apt-cacher-ng заповнює диск

Симптом: Диск кеш-хоста закінчується, і оновлення падають.

Причина: Немає політики витіснення, занадто багато репозиторіїв (включаючи PPA) або замалий диск.

Виправлення: Виділіть реальний диск; зменшіть сплеск репозиторіїв; встановіть збереження/очистку; моніторте /var/cache/apt-cacher-ng.

6) «403 Forbidden» або «Proxy Authentication Required» від APT

Симптом: APT відразу падає через проксі.

Причина: Проксі вимагає автентифікацію, блокує CONNECT або блокує певні домени/шляхи.

Виправлення: Використовуйте незахищений сайт-кеш; налаштуйте автентифікацію проксі в APT лише якщо політика дозволяє і ви можете безпечно керувати обліковими даними; додайте домени репозиторіїв у біллист.

7) Оновлення швидкі, але встановлення повільне

Симптом: Завантаження завершуються швидко; потім «Unpacking…» тягнеться вічно.

Причина: Повільний диск, вичерпані IOPS на спільному сховищі, CPU‑обмежені VM або важкі dpkg тригери/postinst скрипти.

Виправлення: Розділіть часи завантаження і встановлення; перемістіть VM на краще сховище; дослідіть важкі postinst скрипти; уникайте оновлень під час пікового навантаження.

Чеклісти / покроковий план

Покроково: від «APT повільний» до швидких оновлень в офісі

1. Виберіть одного репрезентативного клієнта (по можливості по дроту) і запустіть Завдання 1 та Завдання 2, щоб відокремити повільність метаданих/завантажень/встановлення.
2. Заміряйте затримки DNS (Завдання 6 і Завдання 7). Якщо DNS повільний — виправте його першим; кеш не виправить затримки резолюції.
3. Перевірте, чи існує проксі (Завдання 10). Якщо він віддалений — замініть hairpin-поведінку локальним кешем.
4. Розгорніть apt-cacher-ng на невеликій VM на сайті (Завдання: встановлення, перевірка прослуховування, файрвол).
5. Вкажіть 3–5 тестових клієнтів використовувати кеш через /etc/apt/apt.conf.d/02proxy.
6. Підтвердіть хіти кеша по логах (Завдання 14). Не святкуйте перемогу, поки не побачите хіти.
7. Розгорніть конфіг клієнта через інструменти управління (Ansible, Puppet, Chef, Intune скрипти або інші). Ручні правки не масштабуються і важко відкатуються.
8. Рознесіть розклади оновлень або залиште unattended upgrades, але переконайтеся, що вони тягнуть через кеш.
9. Додайте базовий моніторинг: сервіс up, використання диска і простий тренд hit/miss по логам.
10. Напишіть план відкату: один рядок для видалення проксі-фрагмента, повернення DNS і як заново розгорнути VM кеша.

Чекліст: як виглядає «добре» після виправлення

• apt update завершується за секунди при повторних запусках.
• Логи кеша показують здорове співвідношення origin-запитів і хітів; після першого дня хіти домінують.
• Використання WAN під час вікон патчів більш рівномірне (не зубчасте скачкоподібне завантаження).
• Жоден клієнт не жорстко прописаний на випадкові зовнішні дзеркала без причини.
• Конфігурація проксі узгоджена і централізовано керується.
• Хост кеша має вільний простір і не «пейджиться» сам на диск.

Чекліст: чого уникати (бо це створює нові проблеми)

• Запуск одного централізованого проксі для всіх сайтів, якщо у кожного сайту немає низьколатентних каналів до нього.
• Прозорі кешуючі пристрої для трафіку репозиторіїв, особливо при використанні HTTPS.
• Десятки PPA по парку. Кожен додає метадані і змушує кеш часто перегортатися.
• «Оптимізації», що вимикають перевірки або послаблюють безпеку APT.

FAQ

1) Чи справді мені потрібен сервер кешу для лише 20 машин?

Якщо ті 20 машин регулярно оновлюються і ділять той самий WAN-канал, так — особливо якщо офіс має затримки, обмежену пропускну здатність або дорогий вихідний трафік. apt-cacher-ng невеликий і окупає себе зменшенням чекання і рідшими піковими навантаженнями на лінію.

2) Чи працює apt-cacher-ng з HTTPS репозиторіями?

Часто так, через проксінг (CONNECT). Наскільки добре — залежить від політик вашого проксі та інспекції TLS. Тестуйте на кількох клієнтах і перевіряйте хіти в логах. Якщо ваш стек безпеки ламає CONNECT або змушує інспекцію, розгляньте повне дзеркало всередині меж мережі.

3) Чи завжди локальне дзеркало швидше за apt-cacher-ng?

Не завжди. Дзеркало може бути дуже швидким, але воно важче в операційній підтримці. apt-cacher-ng кешує на запит: він зберігає те, що фактично використовує ваш флот. Для більшості офісів це вигідний компроміс.

4) Чому apt update повільний, а швидкість завантаження apt upgrade виглядає нормально?

Тому що apt update — це багато дрібних файлів і чутливе до DNS і встановлення з’єднань. Локальний кеш сильно допомагає, бо перетворює віддалені запити на локальні.

5) Чи варто збільшувати parallel downloads APT?

Лише після вирішення кешування і вибору дзеркала. Збільшення паралелізму може погіршити ситуацію на перевантаженому проксі або нестабільному WAN. Спочатку виміряйте; не сипте з’єднаннями на проблему.

6) Чи можна ділити один кеш між кількома офісами?

Можна, але це рідко оптимально, якщо між офісами висока латентність або мережа ненадійна. Сутність — прибрати WAN RTT з гарячого шляху. Розміщуйте кеши ближче до клієнтів.

7) А що з snap — вони виграють від APT кеша?

Ні. Snap завантажується окремо від APT і користується іншою інфраструктурою. Спочатку вирішіть питання з APT, потім за потреби оцініть проксування/кешування snap-пакетів окремо.

8) Як я дізнаюся, що проксі є вузьким місцем?

Порівняйте часи з проксі і без нього на тестовому хості (або тимчасово прибравши налаштування проксі). Також заміряйте час підключення до проксі і до дзеркала, і шукайте «Waiting for headers» в debug-виводі APT.

9) Чи безпечно кешувати пакети Ubuntu?

Так, якщо кеш налаштований коректно і вміст не змінюється. Пакети підписані і перевіряються через метадані репозиторію. Не використовуйте прозорі пристрої, що переписують відповіді. Тримайте хост кеша оновленим і обмеженим для вашої мережі.

10) Який мінімальний моніторинг додати для кеш-сервера?

Життєздатність сервісу (systemd), використання диска і об’єм логів. Якщо хочете одну додаткову метрику — відстежуйте співвідношення hit ratio; воно показує, чи дійсно клієнти ним користуються.

Висновок: що можна зробити цього тижня

Якщо оновлення Ubuntu 24.04 в офісі повільні, ставтеся до цього як до звичайної проблеми продуктивності: ізолюйте фазу, виміряйте залежності, а потім усуньте вузьке місце з найбільшим ефектом. Для офісів це часто — латентність на запитах і повторні завантаження, а не сама пропускна здатність.

Зробіть це в такому порядку:

1. Запустіть швидкий план діагностики на одному клієнті: розділіть метадані vs завантаження vs встановлення.
2. Заміряйте DNS і поведінку проксі. Якщо DNS повільний — виправте його першим.
3. Розгорніть apt-cacher-ng в локальній мережі і вкажіть клієнтів на нього через керований APT-фрагмент.
4. Перевірте хіти кеша в логах і стежте, як WAN‑використання вирівнюється під час вікон оновлень.
5. Тримайте все нудним: стандартний образ, базовий моніторинг і простий сценарій відновлення.

Кінцевий стан, до якого прагнути, — не «APT швидкий на моїй машині». Це «оновлення не проблема для всього офісу». Ось це і є той виграш у продуктивності, з яким можна жити.