Цей документ побудований на реальній сесії діагностики: система Ubuntu гальмувала,

і я крок за кроком знаходив та усував всі причини. Кожен розділ містить

команду → реальний вивід → пояснення → дію.

# або зручніша кольорова версія:

htop

# Топ-10 процесів за CPU:

ps -eo pcpu,pmem,user,args –sort=-pcpu | head -n 10

61.2 0.9 alex ffmpeg -fflags nobuffer -rtsp_transport tcp …

61.0 0.8 alex ffmpeg -fflags nobuffer -rtsp_transport tcp …

14.7 2.1 alex /opt/google/chrome/chrome …

7.4 0.8 alex /opt/google/chrome/chrome –type=renderer …

6.5 1.0 alex /usr/share/code/code –type=zygote

• %CPU — відсоток завантаження процесора. Два ffmpeg разом дають 120%+ (більше одного ядра).

• %MEM — відсоток оперативної пам’яті.

• У мому випадку виявлено: Python-скрипт запускав окремий ffmpeg на кожного клієнта!

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

Пам’: 31Gi 8,8Gi 16Gi 253Mi 5,6Gi 21Gi

Своп: 2,0Gi 0B 2,0Gi

• “дост.” (available) 21 ГБ — пам’яті більш ніж достатньо.

• Своп = 0B — система навіть не торкнулась swap-розділу. Проблема не в RAM.

• Якщо “дост.” близьке до нуля — система починає використовувати swap і гальмує.

# Тільки помилки:

dmesg -T –level=err,warn

Some data may be corrupt. Please run fsck.

[пн бер 9 11:26:54 2026] EXT4-fs (sdc2): recovery complete

[пн бер 9 11:26:54 2026] EXT4-fs (sdc2): mounted filesystem r/w

• “Volume was not properly unmounted” — флешка/диск відключена некоректно.

• Система намагається читати пошкоджені сектори → I/O wait → фризи.

• Рішення: розмонтувати пристрій і запустити fsck для виправлення помилок.

sudo umount /dev/sdc1

sudo umount /dev/sdc2

# Якщо “target is busy”:

sudo umount -l /dev/sdc2

# 2. Виправити FAT-розділ

sudo fsck.vfat -a /dev/sdc1

# 3. Виправити EXT4-розділ

sudo e2fsck -p /dev/sdc2

Dirty bit is set. Automatically removing dirty bit.

*** Filesystem was changed ***

/dev/sdc1: 599 files, 261648/516190 clusters

/dev/sdc2: без помилок, 332906/1937712 файлів, 3385954/7740923 блоків

• “без помилок” — файлова система тепер чиста.

• Після виправлення фізично витягніть пристрій і перевірте, чи зникли фризи.

df -h

# Кількість файлів (inodes)

df -i

/dev/sdb3 439G 396G 21G 96% /

tmpfs 16G 240M 16G 2% /dev/shm

/dev/sdb2 512M 6,1M 506M 2% /boot/efi

• Коли на SSD менше 10% вільного місця — контролер не може виконувати TRIM.

• Це призводить до різкого падіння швидкості запису і мікрофризів.

• Рішення: звільнити місце (кеш, логи, перенос файлів на HDD).

25G /home/alex/Музика

19G /home/alex/.cache

16G /home/alex/.local

12G /home/alex/.config

9G /home/alex/Android

5G /home/alex/snap

• www (141 ГБ) — основний робочий каталог розробника. Кандидат для переносу на HDD.

• .cache (19 ГБ) — можна безпечно видалити, він перествориться автоматично.

• Музика/Відео — медіафайли краще зберігати на великому HDD.

sudo apt clean

# Обрізати системні логи до 500 МБ

sudo journalctl –vacuum-size=500M

# Очистити кошик

rm -rf ~/.local/share/Trash/*

# Очистити кеш програм (перествориться автоматично)

rm -rf ~/.cache/*

sudo apt install smartmontools

# Побачити список дисків

lsblk

├─sda1 … 579M

├─sda2 … 846,8G

├─sda3 … 466,9G

└─sda5 … 548,8G

sdb 8:16 0 447,1G 0 disk

└─sdb3 8:19 0 446,6G 0 part / ← системний SSD!

sdc 8:32 1 29,8G 0 disk ← флешка/зовнішній диск

sudo smartctl -H /dev/sdb

# Деталі для SSD

sudo smartctl -A /dev/sdb | grep -E “Percentage|Media|Error”

# Критичні параметри для HDD

sudo smartctl -A /dev/sda | grep -E “Reallocated|Pending|Offline”

=== START OF READ SMART DATA SECTION ===

SMART overall-health self-assessment test result: PASSED

Для HDD:

• Reallocated_Sector_Count > 0 → диск починає “сипатися”, плануйте заміну.

• Current_Pending_Sector → сектори, які не вдалося прочитати.

• UDMA_CRC_Error_Count росте → проблема в кабелі SATA.

Для SSD:

• Percentage Used → знос пам’яті у відсотках.

• Media and Data Integrity Errors → мають бути нулями.

Timing cached reads: 21824 MB in 1.99 seconds = 10962.49 MB/sec

Timing buffered disk reads: 1558 MB in 3.00 seconds = 519.05 MB/sec

• SSD SATA — 400–550 MB/s (наш результат 519 MB/s — відмінно!).

• SSD NVMe — 2000–7000 MB/s.

• HDD — 80–160 MB/s.

• Якщо SSD показує < 200 MB/s — можливі проблеми з контролером або перегрів.

blkid /dev/sda2

# Якщо ext4 — монтувати так:

sudo mkdir -p /mnt/storage

sudo mount /dev/sda2 /mnt/storage

# Якщо NTFS (Windows-диск) — отримаємо помилку:

# “Mount is denied because the NTFS volume is already exclusively opened”

# → перевірити, куди вже змонтовано:

lsblk | grep sda2

• Якщо диск NTFS (Windows), Linux не може монтувати його двічі.

• Перевірте: lsblk — можливо, система вже автоматично змонтувала диск у /media/alex/…

• Використовуйте цей шлях замість /mnt/storage.

blkid /dev/sda2

# Відкрити fstab для редагування

sudo nano /etc/fstab

# Додати рядок (для ext4):

UUID=ВАШ-UUID /mnt/storage ext4 defaults 0 2

# Перевірити без перезавантаження

sudo mount -a

sudo rsync -avP ~/www /mnt/storage/alex/

# ТІЛЬКИ після перевірки, що дані скопійовані!

ls -la /mnt/storage/alex/www

# Видаляти оригінал тільки після підтвердження

rm -rf ~/www

# Створити символічне посилання

ln -s /mnt/storage/alex/www ~/www

• НІКОЛИ не видаляйте оригінал перед тим, як перевірити копію.

• Використовуйте rsync -avP — він показує прогрес і перевіряє цілісність.

• Після переносу перевірте: ls -la і розмір папки (du -sh).

• Символічне посилання (ln -s) дозволяє системі “бачити” папку на старому місці.

• Оригінальний код: метод _stream() запускав subprocess.Popen(FFMPEG_CMD) при кожному підключенні.

• 2 відкриті вкладки браузера = 2 ffmpeg = 120%+ CPU.

• При 5 вкладках система “лягала” повністю.

• Рішення: один глобальний ffmpeg, всі клієнти читають з нього.

“ffmpeg”, “-fflags”, “nobuffer”, “-rtsp_transport”, “tcp”,

“-i”, RTSP_URL,

“-f”, “mjpeg”, “-q:v”, “5”,

“-r”, “10”, # ← було 15, знижено до 10 FPS

“-preset”, “ultrafast”, # ← новий параметр: мін. навантаження на CPU

“-vf”, “scale=1280:-1”, # ← -1 замість 960: зберігає пропорції

“pipe:1”

]

def __init__(self):

self.last_frame = b””

self.lock = threading.Lock()

self.running = True

def start(self):

threading.Thread(target=self._run_ffmpeg, daemon=True).start()

def _run_ffmpeg(self):

while self.running:

proc = subprocess.Popen(

FFMPEG_CMD, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL,

preexec_fn=lambda: os.nice(10) # Низький пріоритет

)

# … читаємо кадри і зберігаємо в self.last_frame

def get_frame(self):

with self.lock:

return self.last_frame

# Глобальний менеджер — один для всього сервера

manager = StreamManager()

manager.start()

• ffmpeg завжди запущений в одному екземплярі.

• 10 відкритих вкладок браузера = навантаження CPU таке ж, як при одній.

• os.nice(10) — процес поступається ресурсами системі та іншим програмам.

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