Odpoveď je jasná - viac je 64 bitov a to by mohol byť rýchly koniec dnešného blogu :-). Zaujímavejšia otázka ale je, čo je lepšie. Odpoveď na ňu sa môže líšiť v závislosti od konkrétnej situácie. Skúsme si ju teda rozobrať.

D2000 od verzie 9.0 (r. 2012) existuje na platforme Windows v 32 aj 64-bitovej verzii. Predtým existovala 64-bitová verzia iba na platforme OpenVMS (od r. 2002) a na platfome HP-UX (od r.2008 - viď blog o D2000 a programovacom jazyku ADA).

D2000 umožňuje bezproblémovú komunikácium medzi 32-bitovými a 64-bitovými procesmi a to dokonca aj na rôznych platformách, takže bežne spolupracujú 32 a 64-bitové procesy na Windows s 64-bitovými procesmi na OpenVMS a Linuxe. A úplnou chuťovkou je HP-UX, ktorý beží na procesore Itanium v big-endian móde - a napriek tomu máme zákazníkov, ktorí prevádzkujú D2000 kernel (a iné serverovské procesy) na HP-UX a k nemu sa pripájajú klientské procesy z little-endian platforiem ako 32 či 64-bitové Windows. Je to umožnené tým, že vnútorný komunikačný protokol D2000 zabezpečuje korektné streamovanie platformovo závislých štruktúr medzi rôznymi platformami.

Takže od roku 2012 sa pri nových projektoch aj pri upgradoch pýtame - chcete 32 alebo 64-bitovú verziu?

V niektorých prípadoch je odpoveď jasná. Pokiaľ je operačný systém 32-bitový (v minulosti Windows 2003 alebo staršie Windows 2008, dnes embedded 32-bitové Windows 7 a vyššie), niet čo riešiť.

V súčasnosti je väčšina projektov realizovaných na 64-bitových Windows (2008, 2012 a 2016). Takže máme na výber.

Existuje názor “neriešte to a dajte tam 64-bitov”. Skúsme porovnať výhody a nevýhody 32 a 64-bitových verzií a rozhodnúť sa podľa toho, čo v konkrétnej situácii potrebujeme.

Rýchlosť
32-bitová verzia je o niečo rýchlejšia ako 64-bitová (testy v minulosti ukazovali rozdiel na úrovni 5-10%).

Náročnosť na pamäť

32-bitová verzia je pochopiteľne menej náročná na pamäť - všetky ukazovatele sú 32-bitové. Takže tá istá aplikácia bude v 32-bitovej verzii potrebovať menej pamäte na reprezentáciu objektov v kerneli, archíve, kalkulačke atď.
Rozdiel v náročnosti závisí od toho, aké množstvo ukazovateľov sa v aplikácii používa. Napr. Izochrónna cache archívu používa binárne stromy (každý prvok má teda 2 ukazovatele). Na jednu archívnu hodnotu je potrebných 48 bajtov v 32-bitovej verzii, resp. 56 bajtov v 64-bitovej verzii (rozdiel 8 bajtov je spôsobený tým, že v 32-bitovej verzii dva ukazovatele potrebujú 8 bajtov a v 64-bitovej 16 bajtov).

Dostupná veľkú pamäť

64-bitové procesy môžu využiť viac ako 3 GB operačnej pamäte na dáta. Ktoré procesy ale reálne takýto objem potrebujú? 

• Kernel - pri veľkých aplikáciách (desiatky tisíc tagov, desiatky klientov). Navyše, pokiaľ sa používajú štruktúrované premenné väčších rozmerov alebo práca s databázou (čítanie/zápis väčších objemov dát naraz s použitím štruktúrovaných premenných, prípadne práca s BLOBmi), môže v kerneli dochádzať ku fragmentácii pamäte, takže dôjde k stavu, keď kernel potrebuje alokovať súvislý blok (napr. 1MB) a už nemá ako. V takomto prípade je riešenie použiť 64-bitovú verziu.
  
  
• Archív - u mnohých zákazníkov je dnes zapnutá tzv. Izochrónna cache (detaily v blogu o enterprise vlastnostiach archívu), ktorá podstatne zrýchľuje čítanie z archívu tým, že sa držia v pamäti dáta za posledných N hodín alebo N dní. Pokiaľ má zákazník k dispozícii dostatočnú RAM, je možné konfigurovať cache o veľkosti aj niekoľko GB.

Obr 1: 8GB izochrónna cache pre takmer 150 miliónov položiek s hĺbkou takmer
2 dni a 16 hodín zodpovedá priemerne 650 archivovaným hodnotám za sekundu

• EDA server - podobne ako pri archíve, cache EDA servera uchováva vektory načítané z databázy alebo vypočítané EDA serverom a zrýchľuje tak prácu užívateľov.
  
  
• Iné procesy - nenapadá ma ďalší proces, ktorý by vyslovene vyžadoval 64-bitovú verziu. Možno KOM proces (pri veľkom množstve komunikačných liniek a staníc) - ale väčšina aplikácií používa radšej niekoľko menších KOM procesov ako jeden veľký - aj kvôli zníženiu vplyvov pri riešení komunikačných problémov (napr. v prípade, že je potrebné patchovanie alebo reštart KOM procesu, neovplyvní to ostatné komunikácie bežiace na iných KOM procesoch).

Ochrana voči pretečeniu

V praxi sa na niektorých aplikáciách vyskytli problémy s nárastom pamäte spotrebovanej jedným procesom. Príčiny boli rôzne - od chýb v použitých knižniciach (napr. ODBC ovládače) cez chyby v D2000 až po chyby aplikačných programátorov (napr. “zabudnuté” handle alebo preplnené dátové kontajnery).

Pokiaľ takýto problém nastane pri 32-bitovej verzii, vedie k pádu procesu pri vyčerpaní 3 GB RAM (za predpokladu, že operačný systém má pamäte dosť). Pokiaľ je použitá 64-bitová verzia, tak je schopná spotrebovať všetku dostupnú pamäť a tak ohroziť stabilitu celého systému - pády iných procesov z nedostatku pamäte, výrazné swapovanie Windows a podobne.

Kompatibilita, ovládače, dll

V niektorých prípadoch potrebujeme 32-bitové procesy: DbManager kvôli prístupu do databáz pre ktoré sú iba 32-bitové ODBC ovládače (napr.Sybase 9 a staršie), KOM kvôli použitiu 32-bitových knižníc pre konkrétne protokoly (napr. protokol AMiT ATOUCH32 DB-Net). Prípadne máme nainštalovaný 32-bitový Excel a kvôli reportom doňho potrebujeme 32-bitový D2000 WorkBook alebo EDA WorkBook.

Takže .. kompromis?

Ako rozumný kompromis sa mi javí použitie 32-bitovej verzie s tým, že “čo je treba”, presunie sa na 64-bitov.

Príklad z praxe? Nedávno sme u konkrétneho zákazníka dokončili spájanie dvoch veľkých aplikácií do jednej. Táto má vyše 100 000 tagov a viac ako 70 000 archívnych objektov (archívy majú vyše 200 GB a trezorové databázy niekoľko TB dát). Komunikácia používa 30 KOM procesov, na ktorých je takmer 200 liniek a vyše 2400 staníc. Viac ako 10 procesov EVENT, niekoľko DbManagerov, dva EDA servery. K aplikácii pristupuje vyše 60 užívateľov cez hrubého klienta a ďalší cez webových klientov. A navyše je aplikácia redundantná. Takže žiadne “orezávatko”. A pritom ešte začiatkom tohto týždňa bežala celá aplikácia ako 32-bitová - s výnimkou archívov, ktoré používajú 4 GB izochrónnej cache.

Až tento týždeň, keď začali problémy s fragmentáciou pamäte, prešli sme s procesom Kernel na 64-bitov. Migrácia trvala cca 2 hodiny a z pohľadu klientov bola bezvýpadková - došlo iba k jednému prepnutiu redundancie. Čo bolo pritom potrebné?

• Nainštalovať na oba aplikačné servery 64-bitové ODBC ovládače a nakonfigurovať 64-bitové DSN pre konfiguračnú a logovaciu databázu.
  
  
• Nakopírovať potrebné 64-bitové binárky do adresára bin64: kernel.exe, d2start.exe, cfgsynchroauto.exe, d2smc.exe, d2auth.dll (posledná menovaná knižnica kvôli tomu, že zákazník používa Kerberos autentifikáciu). Ako alternatívu kopírovania sme mohli spustiť kompletnú inštaláciu 64-bitovej verzie.
  
  
• Nakopírovať adresár java64.
  
  
• Upraviť konfiguráciu všetkých procesov spúšťaných kernelom tak, aby sa explicitne spúšťali 32-bitové verzie z adresára bin. Napríklad pre KOM proces nahradiť cestu “kom.exe” za “..\bin\kom.exe”. Bez toho by sa 64-bitový kernel.exe v adresári bin64 snažil spustiť kom.exe v tomto adresári (takže buď by nespustil nič, ak by tam binárka nebola, alebo by spustil 64-bitový KOM, čo sme nechceli).
  
  
• Vypnúť aplikáciu a “vymeniť” 32-bitové DSN pre konfiguračnú a logovaciu databázu za 64-bitové (32-bitové premenovať na .old a 64-bitovým predpripraveným v prvom kroku zmeniť mená podľa 32-bitových). Podobne upraviť DSN vzdialenej konfiguračnej databázy, ktoré sa používa pri štarte redundancie (Aplikacia.VzdialenyServer.Syscfg).
  
  
• Upraviť servis, ktorý spúšťa watchdog aplikácie (utilitu d2start.exe), aby spúšťal 64-bitovú verziu z adresára bin64.
  
  
• Spustiť aplikáciu a skontrolovať bežiace procesy.
  
  
• Prepnúť redundanciu na 64-bitový kernel a zopakovať postup na druhom serveri.

Záver

Netvrdím, že môj názor na použitie 32 a 64-bitovej D2000 je jediný správny. Je ovplyvnený súčasnou realitou u zákazníkov a problémami, na ktoré narážame - napr. potreba optimalizovať spotrebu pamäte alebo zabrániť procesu “vyžrať” dostupnú pamäť. V týchto dňoch prichádza na svet nová verzia 11.1.55, ktorá je k dispozícii aj na Linuxe - ale iba ako 64-bitová, takže diskusia o bitoch pre túto perspektívnu platformu je zatiaľ bezpredmetná :)

Je možné, že aj pre platformu Windows raz v budúcnosti už 32-bitová verzia existovať nebude. Ale kým tu je, máme možnosť využívať jej výhody a kombinovať ich s výhodami 64-bitovej verzie podľa potrieb konkrétnych zákazníkov.

12.2.2018, Ing. Peter Humaj, www.ipesoft.com