Hogyan ismerjük fel, hogy a stream a RAM-ra támaszkodik

A „stream közben akadozik a gép” érzést szinte mindig processzorhülyének írják le. Ezt a legkönnyebb monitorozni, ez tűnik fel elsőként a Feladatkezelőben. De amikor a CPU és a GPU 50–70%-on terhelt, a kép mégis akadozik, gyakrabban a memória a hibás. Az alábbiakban bemutatjuk, hogyan különböztessük meg a kevés RAM-ot a túlmelegedéstől, a throttlingtól és az encoder szűk keresztmetszetétől, találgatás nélkül.

Először zárjuk ki a nyilvánvalót

A memória ellenőrzésének csak akkor van értelme, miután kizártuk a gyakoribb okokat. Ha a stream szakadozik, és az OBS „Encoding overloaded” üzenetet ír, az az encoder túlterhelése, nem a memóriáé. Ha csak a játék lagol, a stream pedig egyenletesen megy, nézzük a GPU-t és a játék beállításait. Ha az interfész és minden egyszerre fagy, kezdjük a hőmérsékletekkel és a throttlinggal.

Győződjünk meg róla, hogy a probléma nem a hálózatban van: az azonos időközönkénti megszakadások, a bitráta ugrálása a közvetítés statisztikáiban és a hálózat miatti dropped frames üzenetek a csatornára utalnak, nem a hardverre. A memória általában másképp jelentkezik — rendszerszintű akadozással még azelőtt, hogy maga a közvetítés károsodna.

Hogyan néz ki a kevés RAM a gyakorlatban

A tünetek elmosódottak, ezért könnyen összetéveszthetők bármivel. A tipikus kép a következő:

• A stream az első 20–40 percben normálisan megy, aztán fagyások és visszaesések kezdődnek, amelyek idővel fokozódnak.
• Az ablakok közötti váltás, a chat vagy a böngésző megnyitása a donációs panellel észrevehető, egy-két másodperces akadást okoz.
• Az OBS jelenete tíz forrással és overlay-jel lassan indul, és forrás hozzáadásakor az interfész megfagy.
• A rendszer aktívan dolgozik a lemezzel, pedig semmit nem rögzítünk és nem telepítünk.
• A játék, a böngésző vagy maga az OBS néha hibaüzenet nélkül bezárul.

Az időbeli fokozódás a fő jel. A kevés processzor vagy GPU az első perctől stabil visszaesést ad. Ha viszont a degradáció fokozódó, szinte biztosan nő a memóriafogyasztás, és nem a teljes mennyiség a hibás, hanem az egyik folyamat szivárgása.

Monitorozás: mit nézzünk és hol

Három értékre van szükségünk egyszerre: a teljes foglalt memória mennyiségére, a swap mennyiségére és az adott folyamatok fogyasztására. A Windows Feladatkezelője az első kettőt mutatja, de a folyamatokhoz kényelmesebbek a harmadik féltől származó segédprogramok — ezek időbeli grafikonokat adnak, nem pillanatképet.

Mire figyeljünk a grafikonokon

• A foglalt memória 85–90% felett marad, és még tétlenségben sem csökken.
• A swap használatának görbéje nő, pedig nem indítottunk semmi újat.
• Egy folyamat (OBS, böngésző, játék) fogyasztása monoton nő a stream alatt látható ok nélkül.
• A Feladatkezelő teljesítmény lapján a memória „In memory” és „Available” értéket mutat, és kevés marad elérhető még zárt alkalmazások mellett is.

Fontos a dinamikát nézni, nem egyetlen számot. A magas memóriafoglaltság önmagában nem diagnózis: a modern operációs rendszerek cache-t tartanak, és addig adnak neki memóriát, amíg szükség nem lesz rá. A probléma ott kezdődik, ahol a rendszer nem tudja gyorsan felszabadítani a memóriát egy új folyamat számára — és lemezre vált.

Stream és játék egy monitoron

Indítsuk el a streamet a háttérben, nyissuk meg az erőforrás-figyelőt, és játsszunk 20–30 percet. Jelöljük meg azt a pillanatot, amikor a fagyások elkezdődnek, és nézzük meg a memória grafikonját abban a másodpercben. Ha az első fagyás előtt a swap felfelé indult, és az elérhető memória majdnem nullára esett, megtaláltuk az okot. Ha a memória egyenletes, és a fagyások egybeesnek a GPU csúcsaival, a probléma nem benne van.

Az OBS naplói mint bizonyítékforrás

Az OBS naplót vezet, amelyben láthatók a kihagyott képkockák és azok okai. Nyissuk meg a „Súgó → Naplófájlok → Aktuális napló megtekintése” menüpontot, és keressük a kihagyott képkockákra és a túlterhelésre vonatkozó sorokat. Különítsük el a kétféle kihagyást: a renderelés miattit és a hálózat miattit.

• A renderelés miatti kihagyások alacsony CPU- és GPU-terhelés mellett okot adnak a memóriában, a lemezen vagy magában az OBS-ben keresni a problémát.
• A hálózat miatti kihagyások nem kapcsolódnak a memóriához, a csatorna és a bitráta-beállítások orvosolják.
• Az erőforráshiányra vonatkozó üzenetek forrás hozzáadásakor vagy ablakrögzítéskor gyakran akkor jönnek, amikor a rendszer már lemezre váltott.

A naplók nem mondják ki szó szerint, hogy „kevés a RAM-od”. De ha a renderelési kihagyások nem az első perctől kezdődnek, hanem a stream végére fokozódnak, és a memória közben felfelé kúszik, a kép összeáll.

Stresszteszt találgatás helyett

A hipotézis ellenőrzésének legmegbízhatóbb módja a probléma irányított reprodukálása. Kapcsoljuk ki a streamet, zárjunk be minden feleslegeset, indítsuk el a jelenetet a maximális számú forrással és böngészős overlay-jel, majd nyissuk meg a játékot. Nézzük, milyen foglalt memóriaszintnél kezdődnek a fagyások.

Ezután távolítsuk el a jelenetből a források egy részét (különösen a böngészőseket — ezek erősebben húzzák a memóriát, mint gondolnánk), és ismételjük meg. Ha a fagyások küszöbe feljebb tolódott, igazoltuk a függőséget. A processzorterhelés közben alig változik — ez a kontrolljegy.

Ne keverjük ezt össze a memória stabilitásának memtesttel való tesztelésével: az a modulokat hibákra ellenőrzi, nem a mennyiség hiányára. Nekünk nem hibás cellák keresésére van szükségünk, hanem a munkafolyamat reprodukálására.

A böngészős források — a rejtett fogyasztó

A donációs widgetek, a chat, az előfizetői animációk, az értesítési panelek az OBS-ben böngészős források. Mindegyik külön motorban él, és saját cache-t tart. Öt ilyen forrás a játék felével összemérhető memóriát ehet meg, és ezt észre sem vesszük, amíg meg nem nyitjuk a Feladatkezelőt.

Ellenőrizzük egyenként: kapcsoljuk ki a forrásokat sorban, figyelve a foglalt memóriát és a jelenet viselkedését. Gyakran a „szivárgás” egyetlen animált widgetnek bizonyul, amely az adás során adatokat halmoz fel. A forrás statikus képre cserélése vagy a widget oldalának ütemezett újraindítása megoldja a problémát frissítés nélkül.

Amikor nem a mennyiség, hanem a sebesség a hibás

Előfordul, hogy a memória elegendő, de alacsony frekvencián vagy egycsatornás módban működik. Ilyenkor a fagyások nem a lapozás miatt lesznek, hanem az átviteli sebesség miatt — különösen, ha egyszerre játszunk és streamelünk, és az integrált grafika megosztja a memóriát a rendszerrel. Ellenőrizzük, hogy a modulok kétcsatornás módban működnek-e, és milyen frekvencián.

Az egycsatornás mód gyakori oka a furcsa visszaeséseknek formálisan elegendő mennyiség mellett. A Feladatkezelő megmutatja, hány foglalat van foglalt; a pontos frekvenciához olyan segédprogram kell, mint a CPU-Z. Ha a modulok rosszul vannak a különböző csatornákban, az áthelyezés növekedést ad új hardver vásárlása nélkül.

Mit tegyünk, miután a diagnózis megerősítést nyert

Ha a memóriahiány megerősítést nyert, több lehetőség van, és mindegyiknek ára van. A mennyiség növelése a legközvetlenebb út, de vásárlást és annak ellenőrzését igényli, hogy az alaplap támogatja-e a szükséges módot és frekvenciát. A felesleges dolgok bezárása ingyenes, de nem mindig lehetséges: a játéknak és az OBS-nek egyszerre kell futnia.

Át lehet helyezni a terhelés egy részét: a böngészős overlay-eket külön eszközre tenni, a jelenet felbontását csökkenteni, az egyszerre rögzített ablakok számát csökkenteni, a gyorsítótárazó bővítményeket kikapcsolni. Ez nem szünteti meg az okot, de eltolja a küszöböt, ahol a fagyások elkezdődnek. Az adott folyamat szivárgását (leggyakrabban a böngészős forrásét) a forrás adás közbeni újraindítása vagy a widget cseréje orvosolja.

A swapot is érdemes korlátozni: ha a rendszer hozzászokott, hogy lemezre vált, ezt kis memóriahiány esetén is megteszi, súlyosbítva a fagyásokat. De a swap kikapcsolása valódi mennyiségi hiány esetén az alkalmazások bezárulásához vezet — ez szélsőséges intézkedés, nem megoldás.

Ellenőrzőlista

1. Győződjünk meg róla, hogy az OBS naplóiban a képkockakihagyások renderelés miatt vannak, nem hálózat miatt.
2. Zárjuk ki a CPU/GPU túlmelegedését és throttlingját.
3. Indítsuk el a streamet teljes jelenettel és játékkal, figyeljük a memóriát és a swapot 20–30 percig.
4. Jelöljük meg az első fagyás pillanatát, és vessük össze az elérhető memória és a swap grafikonjával.
5. Kapcsoljuk ki a böngészős forrásokat egyenként, és ellenőrizzük, eltolódott-e a fagyások küszöbe.
6. Ellenőrizzük a memória működési módját: két csatorna, megadott frekvencia.
7. Csak ezután vonjunk következtetést a frissítésről.

A sorrend fontos: ha kihagyjuk az első két lépést, könnyen memóriát vásárolunk, és azt tapasztaljuk, hogy a fagyások megmaradtak, mert a dolog a túlmelegedésben vagy az encoder szűk keresztmetszetében volt.