Čo zvláda Raspberry Pi? Časť II

V mojom predchádzajúcom blogu „Čo zvláda Raspberry Pi?“ som testoval konfiguráciu, kde bol na Raspberry Pi nainštalovaný systém D2000. Jeho komunikačný proces (D2000 KOM) slúžil ako Modbus TCP Server aj ako Modbus TCP Client. Ukázal som, že Raspberry Pi dokázal odosielať/prijímať hodnoty 100 meraných bodov (jedna zmena každého bodu za sekundu) a uložiť ich do lokálnej databázy PostgreSQL. Potom som vytvoril „rýchlu“ konfiguráciu s použitím iba 10 meraných bodov, ktoré boli dotazované „tak rýchlo, ako sa dá“. Výsledkom bolo 1290 - 1390 hodnôt za sekundu (čas vzorkovania jednotlivých hodnôt každého meraného bodu bol pod 10 ms), ktoré boli opäť uložené v databáze PostgreSQL.

Keď som v zverejnil odkaz na svoj pôvodný blog, prišla v Reddit diskusii táto zásadná námietka:

Your demo ignores the primary bottleneck: getting the data over wire.

V skutočnosti bola proti použitým komunikačným protokolom ďalšia námietka, ale keďže nemám PLC Simatic S-7 alebo AB, budem túto zatiaľ ignorovať. Takže skúsme upravené nastavenie: presunieme databázu PostgreSQL z RPI na iný počítač. A zmerajme, o koľko sa výkon zhorší. Alebo .. žeby nie?

Konfigurácia

Ok, takže som vytvoril databázu na Windows Serveri (10 rokov starý virtuálny Windows 2008 so 4 GB RAM a 2 vCPU), kde beží starý dobrý 32-bitový PostgreSQL 9.6. Takže sme virtualizovaní a pracujeme na Windows. Ako ste si mohli všimnúť, je pre mňa jednoduchšie recyklovať staré veci ako vytvárať úplne nové konfigurácie.

Upravil som aj súbor pg_hba.conf, aby sa RPI (IP adresa 172.16.0.184) mohlo dostať do tejto databázy (viď posledný riadok):

A upravil som odbc.ini na RPI, aby som sa pripojil k tomuto vzdialenému PostgreSQL serveru (IP adresa 172.16.10.50):

Pre istotu som sa pripojil k RPI a príkazom „SHOW_INFO“ skontroloval konfiguráciu D2000 Archívu.

Na nasledujúcom screenshote sú vidieť dve veci:

Pretože archívna databáza PostgreSQL je na Windows, zobrazí sa červené varovanie„GetDiskFreeSpace: Invalid path: D:\PostgreSQL\9.0\D2000“. To znamená, že pre adresár, kde sa nachádza archívna databáza (čo je zjavne cesta na Windows serveri), nie je možné zisťovať dostupné voľné miesto (takže sa musíme zaobísť bez varovaní „disk s databázou je takmer plný“). Zatiaľ to nevadí
Informácia o databáze PostgreSQL je „dba@myapp_archive_self (OID=765031) on 172.16.10.50/32:5432 [PostgreSQL 9.6.9, compiled by Visual C++ build 1800, 32-bit]“. Sme teda pripojení k vzdialenému serveru (172.16.10.50), na ktorom je spustená 32-bitová verzia PostgreSQL 9.6.

Mimochodom, RPI je pripojený k 100 MBit switchu v mojej kancelárii. Na ceste k serveru Windows sú minimálne ďalšie 2 switche. Utilita „ping“ hlási latenciu okolo 0,3 ms.

Teraz sa pokúsime spustiť základnú konfiguráciu.

Testovanie - pomalé čítanie

Začatie čítania 100 meraných bodov raz za sekundu:

Databáza je prázdna (veľkosť 11 MB), PerformedDatabaseRequest = 100 (za sekundu), RPI bez problémov stíha.

Len aby sme sa uistili, že zapisujeme na iný server:

Existujú 2 databázové spojenia na zápis, jedno na čítanie (toto predvolené nastavenie som nezmenil), jedno na pravidelné mazanie starých údajov a posledné na zápis zmien konfigurácie.

A pozrime sa na záťaž RPI: archiv, kom, kernel, event. Postgres nie je vidieť (aj keď stále ho používa kernel ako konfiguračnú a logovaciu databázu, momentálne však takmer nič nerobí).

Testovanie - rýchle čítanie

Takže, toto bolo až nudne nezaujímavé. Zastavme pomalú komunikáciu a začnime rýchlu!

Teraz sa začali objavovať problémy. Po niekoľkých minútach vidím rastúce číslo „PendingDbRequest“, čo znamená, že latencia siete (alebo Windows Server) nám bráni v dostatočne rýchlom zápise a niektoré hodnoty čakajú v pamäťových frontách D2000 Archívu na RPI.

Čo je zaujímavé - pri porovnaní čísel so scenárom „PostgreSQL na RPI“ z pôvodného blogu sa počet vložených hodnôt v skutočnosti zvýšil (z približne 1290 - 1390 na 1700 - 1800). To sa dá vysvetliť - na beh komunikačného procesu bolo možné venovať viac procesorového času, keď bola archívna databáza PostgreSQL presunutá mimo RPI.

A takto vyzerá zaťaženie procesora:

Vzdáme sa teraz, porazení latenciou siete? V žiadnom prípade. D2000 Archiv má v rukáve množstvo optimalizácií výkonu! Jedna z nich bola vyvinutá na zvládnutie záťaže veľkých systémov, ale dá sa využiť na potlačenie vplyvu latencie siete. Kúzelný trik spočíva v použití viacerých paralelných zapisovacích taskov.

Zvýšime počet paralelných zapisovacích taskov z 2 na .. povedzme 10 (aby každý archivovaný bod mohol mať svoju vlastný task). Týmto spôsobom sa na vkladanie údajov do databázy PostgreSQL používa viac paralelných spojení na zápis. Zmenili sme teda WriteThreadsCount z 2 na 10 (implementácia tejto funkcie trvala niekoľko týždňov .. asi pred 10 rokmi .. ale stálo to za to).

Po reštartovaní procesu D2000 Archív sa zvýšil počet pripojení k PostgreSQL serveru.

Počítadlo „PendingDbRequest“ je teraz neustále na nule. Vykonané požiadavky sú medzi 1700 a 1800, niekedy idú ešte vyššie:

A čo tak test „FREEZE 30 30“ na zistenie maximálnej priepustnosti tohto scenára?

Ako vidíte, za 10 sekúnd bolo spracovaných viac ako 54000 hodnôt (akumulovaných za 30 sekúnd, čo je 18 000 hodnôt za sekundu). To je 5400 hodnôt za sekundu. V skutočnosti za týchto 10 sekúnd prišlo z komunikácie ďalších 18 000 hodnôt, ktoré boli spracované. To nám dáva 5400 + 1800 = 7200 hodnôt za sekundu pre tím „RPI + virtualizovaný Widows Server “ . Len pre pripomenutie, špičkový výkon v scenári „all-on-RPI“ opísanom v pôvodnom blogu bol okolo 2500 hodnôt za sekundu.

Testovanie - vzdialený server Modbus

Keď som včera napísal niekoľko predchádzajúcich odsekov, začal som byť zvedavý, ako veľmi bude Modbus TCP komunikácia ovplyvnená latenciou siete. Takže dnes ráno som exportoval linku, stanicu Modbus Server a desať „rýchlych“ výstupných meraných bodov Modbus Servera spolu s užívateľskou premennou, ktorá body ovláda. A potom som ich importoval do aplikácie bežiacej na starej pracovnej stanici HP (dátum výroby: 2008, Windows Vista, 2-jadrový procesor). Časy pingovania sú ešte horšie ako v prípade databázového servera, aj keď sú tieto dva počítače v mojej kancelárii na rovnakom switchi:

Poďme si overiť, či komunikácia funguje - použil som predvolený port Modbus TCP 502:

A pozrime sa, koľko hodnôt sa zapisuje do archívnej databázy:

Fíha. Očakával som určitý pokles počtu. Namiesto toho sme však prešli z 1700 - 1800 na približne 2800-2900 hodnôt za sekundu. Tomu sa mi nechcelo uveriť, a tak som sa pozrel priamo na štatistiku linky B.ModbusCliFast. Stĺpec „Changes“ obsahuje počet zmenených hodnôt na tejto stanici za posledných 10 sekúnd - na ďalšom screenshote je to 28402.

Ako sa správa zaťaženie procesora na RPI? Ako vidíte, proces D2000 Archív spotrebuje väčšinu CPU. Zaťaženie D2000 Kom procesu je približne polovica toho, čo bývalo pred presunutím servera Modbus na iný počítač.

Pozrime sa na údaje v archívnej databáze. Časové značky sa väčšinou líšia o 5 alebo menej milisekúnd.

Záver

Dovoľte mi zopakovať to, čo som napísal v mojom pôvodnom blogu. Berte tieto výsledky iba ako orientačné. Závisia od použitého hardvéru (a softvéru). Avšak zápis do PostgreSQL databázy umiestnenej na systéme Windows v skutočnosti zlepšil celkový výkon. Rovnako tak presunutie Modbus TCP servera na starú pracovnú stanicu Windows. Zdá sa teda, že výhody “odľahčenia” RPI sú väčšie ako nevýhody latencie siete. Na jednej strane to potvrdzuje skutočnosť, že RPI zďaleka nie je super rýchle. Na druhej strane to dokazuje, že Raspberry Pi je dostatočne rýchle na to, aby sa dalo použiť na použiť aj na zber dát a ich ukladanie do vzdialenej SQL databázy.

30. marca 2021, Ing. Peter Humaj, www.ipesoft.com

Čo zvláda Raspberry Pi? Časť II

Peter Humaj

Iné blogy

Komunikácia - MQTT Sparkplug

Komunikácia - optimalizácia v protokole Ethernet/IP

Diagnostika a ladenie databázových operácií v D2000