Da bi razumeli dejansko obremenitev opreme, je bilo treba preizkusiti delovanje terminalskega strežnika 1C v proizvodnji, kar sem naredil pred kratkim, zdaj pa želim predstaviti rezultate, da jih lahko vsi vidijo.
Več si preberite v članku.
Druge članke o 1C boste našli v ustreznem razdelku -.
V več prejšnjih člankih o 1C sem delal na izračunu konfiguracij strežnika za različne obremenitve, ki jih povzročajo prizadevanja glavnih uporabnikov 1C, in sicer zaposlenih v računovodskih in prodajnih oddelkih. Naloge računovodij niso odvisne samo od priprave poročil in vnosa podatkov v program, zato je bolje, da imajo popoln terminalski dostop in od tam delajo z vsem, kar potrebujejo (). Za upravitelje je vse veliko bolj preprosto in zanje je objava aplikacije () povsem sprejemljiv primer uporabe.
Nisem tvegal, da bi strežnik dal v proizvodnjo, ne da bi opravil pravo testiranje, zato je bilo organizirano obsežno testiranje. Zame osebno je bila njegova prednost v tem, da sem lahko v praksi potrdil (ali ovrgel) svoje teoretične izračune, katerih osnova so bili zelo subjektivni kazalniki delovanja delovnih postaj zaposlenih.
Testno okolje
Torej, za testiranje smo vzeli strežnik s CPE Intel Xeon E5-1650 v3 @ 3,50 GHz, 128 GB RAM, 2*SSD v RAID 1. Na tem strežniku je razporejen virtualni stroj, ki je le terminalski strežnik, na katerem so nameščene aplikacije 1C 8.2, 1C 8.3, MS Office 2013 Pro.
Takoj bom rekel, da je bila narava obremenitve mešana, to je, da so bile stranke, ki so delale prek RemoteApp, in tiste, ki so se v celoti prijavile prek RDP in uporabljale programe, potrebne za svoje delo (ne samo 1C, ampak tudi Office). ). Porazdelitev je bila približno naslednja: 24 sej RemoteApp, 5 odjemalcev RDP.
Uporabniki so bili soočeni z nalogo, da se vsakih 30 minut za dve uri prijavljajo v aplikacije in v njih opravljajo vsakdanja opravila – sestavljanje poročil, tiskanje podatkov, objavljanje dokumentov, izvoz podatkov v druge formate itd. Glavna stvar je, da ni bilo cilja postaviti strežnika cilj je bil dati realno povprečno dnevno obremenitev.
Rezultati testa
Vse se je začelo kot običajno - uporabniki iz tretjega potiska, že od vodij oddelkov in več, so se začeli prijavljati v 1C in opravljati rutinska opravila. Vse to ni trajalo dolgo in imel sem samo eno priložnost, da kazalnike delovanja strežnika čim bolj približam dejanski obremenitvi. Tole sem dobil na koncu:
RAM (dinamično dodeljen pomnilnik je bil nastavljen na virtualnem strežniku, tako da se je po potrebi trenutna količina RAM-a nenehno spreminjala navzgor):
Zdaj je treba analizirati rezultate in narediti sklepe.
Analiza podatkov
Treba je opozoriti, da so se izračuni za procesor izkazali za izjemno natančne.
V članku sem empirično ugotovil, da je poraba virov procesorja ene seje 1C RemoteApp v povprečju 122.775 enot zmogljivosti procesorja (podatki o zmogljivosti vzeti s spletne strani www.cpubenchmark.net). V drugem članku sem izračunal vire, ki so potrebni za izvajanje celotne seje RDP in so znašali 4% Core i5 4460, to je 0,04 * 6622 (podatki so tudi z www.cpubenchmark.net) = 264,88.
Skupaj dobimo:
- polna seja RDP poje 264,88 Enote zmogljivosti procesorja;
- seja 1C RemoteApp porabi 122,775 enote.
Na vrhu sem omenil, da je bilo 24 uporabnikov RemoteApp in 5 uporabnikov RDP. Štejemo:
24 * 122,775 + 5 * 264,88 = 4271
Relativni indeks zmogljivosti Intel Xeon E5-1650 v3 je 13477 enot. Se pravi teoretično Obremenitev procesorja naj bo okoli 32 % (4271 / 13477 * 100).
Graf obremenitve procesorja kaže, da je v časovnem intervalu 10:30 - 10:50 CPU obremenjen za 25 - 40% (konice se ne štejejo). Seveda ne boste dobili ravne črte obremenitve procesorja 32 %; še vedno bodo nihanja od minimumov do relativnih maksimumov, vendar na splošno lahko domnevamo, da se dejanski podatki ujemajo s teoretičnimi. Mimogrede, več kot je uporabnikov na vašem strežniku, bolj enakomerna bo obremenitev.
Pravzaprav so se podatki RAM-a izkazali za bolj dragocene. Po izračunih iz prejšnjih člankov sem imel:
- 2 GB na sejo RDP;
- 100 MB na sejo RemoteApp.
To pomeni, da bi morala biti količina zasedenega pomnilnika največ 12,4 GB + malo za OS. A kot se je izkazalo in kot sem načeloma slutil, je bila ta vrednost v praksi povsem druga številka. 1C se je na mojo žalost izkazal za zelo požrešnega za RAM. Poleg tega se aplikacija obnaša tako, da se ji, ko zasede nekaj prostora, ne zdi potrebno sprostiti v trenutku, ko je ne potrebujete več:
No, ali je normalno, da pojeste 2 GB RAM-a in sedite in ne delate nič (obremenitev procesorja seje je 0%). Sodobni programerji sploh ne skrbijo za optimalno uporabo virov. Osebno sem bil med študijem na univerzi prisiljen prepisati kodo aplikacije, če je bila napisana neracionalno z vidika uporabe računalniških virov. Očitno je kvalifikacija sodobnih programerjev padla pod cokel ali pa je to le pristop - zakaj bi optimizirali že napisano kodo, ko pa je bolje razvijati nove funkcionalnosti. Na splošno ni bistvo, bombardirano je in to je v redu.
Od 16 GB "zvočnikov", ki so bili dodeljeni strežniku, jih je pojedel vse in najverjetneje zahteval več. Teoretično, če ni dovolj RAM-a, bo OS zamenjal disk in v tem primeru se začne močan padec zmogljivosti. V mojem primeru ni bilo tako in najverjetneje je bil to posledica SSD-ja, ki ni pokazal skoraj nobene obremenitve - le dva kratkotrajna vrha v celotnem testnem obdobju (od 10:00 do 12:00). Vendar, kot kaže praksa, ne priporočam shranjevanja na RAM terminalskega strežnika.
Fotografija Alena Tulyakova, tiskovna agencija “Clerk.Ru”
Članek opredeljuje glavne napake, ki jih delajo skrbniki začetniki 1C, in prikazuje, kako jih rešiti na primeru testa Gilev.
Glavni namen pisanja tega članka je preprečiti ponavljanje očitnih odtenkov za tiste skrbnike (in programerje), ki še niso pridobili izkušenj z 1C.
Sekundarni cilj je, da če imam kakšne pomanjkljivosti, me bo Infostart na to najhitreje opozoril.
Test V. Gileva je že postal nekakšen "de facto" standard. Avtor je na svoji spletni strani podal precej jasna priporočila, jaz pa bom le predstavil nekaj rezultatov in komentiral najverjetnejše napake. Seveda se lahko rezultati testov na vaši opremi razlikujejo; to je samo vodilo, kaj bi moralo biti in čemu si lahko prizadevate. Takoj bi rad opozoril, da je treba spremembe izvajati korak za korakom in po vsakem koraku preveriti, kakšen rezultat je dal.
Na Infostartu so podobni članki, povezave do njih bom dal v ustrezne razdelke (če kaj pogrešam, mi predlagajte v komentarjih, bom dodal). Torej, predpostavimo, da je vaš 1C počasen. Kako diagnosticirati težavo in kako razumeti, kdo je kriv, skrbnik ali programer?
Začetni podatki:
Testiran računalnik, glavni poskusni zajček: HP DL180G6, opremljen z 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Za primerjavo, Core i3-2100 kaže primerljive rezultate v enonitnem testu. Oprema, ki sem jo namerno izbral, ni bila najnovejša, z moderno opremo so rezultati opazno boljši.
Za testiranje ločenih strežnikov 1C in SQL, strežnik SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.
Za testiranje 10 Gbitnega omrežja so bili uporabljeni adapterji Intel 520-DA2.
Različica datoteke. (baza je na strežniku v skupni mapi, odjemalci se povezujejo preko omrežja, CIFS/SMB protokol). Algoritem korak za korakom:
0. Dodajte Gilevo testno bazo podatkov v datotečni strežnik v isto mapo kot glavne baze podatkov. Iz odjemalskega računalnika se povežemo in izvedemo test. Rezultat si zapomnimo.
Razume se, da naj bi tudi pri starih računalnikih izpred 10 let (Pentium na vtičnici 775) čas od klika na bližnjico 1C:Podjetje do prikaza okna baze podatkov trajal manj kot minuto. (Celeron = počasen).
Če je vaš računalnik slabši od Pentiuma na vtičnici 775 z 1 GB RAM-a, potem sočustvujem z vami in težko boste dosegli udobno delo na 1C 8.2 v datotečni različici. Razmislite o nadgradnji (skrajni čas je) ali o prehodu na terminalski (ali spletni, v primeru tankih odjemalcev in upravljanih obrazcev) strežnik.
Če računalnik ni slabši, potem lahko brcnete skrbnika. Preverite vsaj delovanje omrežja, protivirusnega programa in gonilnika za zaščito HASP.
Če je Gilevov test na tej stopnji pokazal 30 "papagajev" ali več, vendar delovna baza 1C še vedno deluje počasi, je treba vprašanja usmeriti na programerja.
1. Kot vodilo, koliko lahko odjemalski računalnik “stisne”, preverimo delovanje samo tega računalnika, brez omrežja. Testno bazo namestimo na lokalni računalnik (na zelo hiter disk). Če odjemalski računalnik nima običajnega SSD-ja, se ustvari pomnilniški disk. Zaenkrat najenostavnejši in brezplačen je Ramdisk enterprise.
Za testiranje različice 8.2 zadostuje 256 MB pomnilniški disk in! Najpomembnejši. Po ponovnem zagonu računalnika, pri delujočem pomnilniškem disku, mora biti na njem 100-200 MB prostega prostora. V skladu s tem mora biti brez pomnilniškega diska za normalno delovanje 300-400 MB prostega pomnilnika.
Za testiranje različice 8.3 zadostuje 256 MB pomnilniški disk, vendar potrebujete več prostega RAM-a.
Pri testiranju morate pogledati obremenitev procesorja. V primeru, ki je blizu idealnemu (ramdisk), lokalna datoteka 1c med delovanjem naloži 1 procesorsko jedro. V skladu s tem, če med testiranjem jedro vašega procesorja ni popolnoma naloženo, poiščite šibke točke. Opisan je nekoliko čustven, a na splošno pravilen vpliv procesorja na delovanje 1C. Samo za referenco, tudi na sodobnih Core i3 z visokimi frekvencami so številke 70-80 povsem realne.
Najpogostejše napake na tej stopnji.
- Nepravilno nastavljen protivirusni program. Protivirusnih programov je veliko, nastavitve za vsakega so drugačne, rekel bom le, da s pravilno konfiguracijo ne moti niti splet niti Kaspersky 1C. S privzetimi nastavitvami lahko odvzamete približno 3-5 papig (10-15%).
- Način delovanja. Iz neznanega razloga malo ljudi posveča pozornost temu, vendar je učinek najpomembnejši. Če potrebujete hitrost, potem morate to storiti tako na odjemalskih kot na strežniških računalnikih. (Gilev ima dober opis. Edino opozorilo je, da na nekaterih matičnih ploščah, če izklopite Intel SpeedStep, ne morete vklopiti TurboBoosta).
Način delovanja lahko (in po možnosti) omogočite na dveh mestih:
- prek BIOS-a. Onemogoči načine C1, C1E, Intel C-state (C2, C3, C4). V različnih biosih se imenujejo drugače, vendar je pomen enak. Iskanje traja dolgo, potreben je ponovni zagon, a če to storite enkrat, ga lahko pozabite. Če v BIOS-u naredite vse pravilno, se bo hitrost povečala. Na nekaterih matičnih ploščah lahko nastavitve BIOS-a konfigurirate tako, da način delovanja sistema Windows ne bo imel vloge. (Primeri nastavitev BIOS-a iz Gileva). Te nastavitve se v glavnem nanašajo na strežniške procesorje ali "napredni" BIOS, če tega niste našli in NIMATE Xeon, je v redu.
- Nadzorna plošča - Napajanje - Visoka zmogljivost. Minus - če računalnik dlje časa ni bil na servisu, bo glasneje ropotal ventilator, se bolj segreval in porabil več energije. To je pristojbina za uspešnost.
| To so privzete nastavitve. BIOS C-state omogočen, način uravnotežene porabe energije |  |
| BIOS C-state omogočen, način visoke zmogljivosti Za Pentium in Core se lahko ustavite tam, Še vedno lahko iz Xeona iztisnete malo "papagajev". |  |
| V BIOS-u je stanje C onemogočeno, način visoke zmogljivosti. Če ne uporabljate Turbo boost, bi moralo izgledati tako strežnik prilagojen za delovanje |  |
In zdaj številke. Naj vas spomnim: Intel Xeon 5650, ramdisk. V prvem primeru test pokaže 23,26, v zadnjem - 49,5. Razlika je skoraj dvojna. Številke se lahko razlikujejo, vendar razmerje ostaja v bistvu enako za Intel Core.
Dragi skrbniki, lahko kritizirate 1C, kolikor želite, vendar če končni uporabniki potrebujejo hitrost, morate omogočiti način visoke zmogljivosti.
c) Turbo Boost. Najprej morate razumeti, ali na primer vaš procesor podpira to funkcijo. Če podpira, potem lahko še vedno povsem legalno dobite nekaj zmogljivosti. (Ne želim se dotikati vprašanj frekvencnega overclockinga, zlasti strežnikov, to storite na lastno odgovornost in tveganje. Vendar se strinjam, da povečanje hitrosti vodila s 133 na 166 zelo opazno poveča hitrost in odvajanje toplote)
Kako vklopiti turbo boost je napisano na primer . Ampak! Za 1C obstaja nekaj odtenkov (ne najbolj očitnih). Težava je v tem, da se največji učinek turbo pospeševanja pojavi, ko je vklopljeno stanje C. In dobimo nekaj takega:
Upoštevajte, da je množitelj največji, jedrna hitrost je čudovita in zmogljivost visoka. Toda kaj se bo zgodilo kot rezultat z 1s?
Toda na koncu se izkaže, da je glede na teste zmogljivosti procesorja različica z množiteljem 23 prednjačila, glede na Gilevove teste v datotečni različici je zmogljivost z množiteljem 22 in 23 enaka, v odjemalec-strežnik pa je enaka. različica - različica z množiteljem 23 je grozna grozna grozna (tudi če je C-state nastavljen na raven 7, je še vedno počasnejša kot z izklopljenim C-state). Zato priporočamo, da sami preverite obe možnosti in izberete najboljšo. Vsekakor je razlika med 49,5 in 53 papigami precejšnja, sploh brez večjega truda.
Zaključek - turbo boost mora biti vklopljen. Naj vas spomnim, da ni dovolj, da v BIOS-u omogočite postavko Turbo boost, pogledati morate tudi druge nastavitve (BIOS: QPI L0s, L1 - onemogočeno, čiščenje zahtev - onemogočeno, Intel SpeedStep - omogoči, Turbo boost - omogoči. Nadzorna plošča – Možnosti napajanja – Visoka zmogljivost). In še vedno bi (tudi za file verzijo) izbral možnost, kjer je c-state izklopljen, čeprav je množitelj manjši. Izpadlo bo nekaj takega...
Precej sporna točka je frekvenca pomnilnika. Dokazano je na primer, da ima frekvenca spomina zelo močan vpliv. Moji testi niso odkrili takšne odvisnosti. Ne bom primerjal DDR 2/3/4, pokazal bom rezultate spreminjanja frekvence v isti vrstici. Pomnilnik je enak, vendar smo v BIOS-u prisiljeni nastaviti nižje frekvence.
 |  |  |
In rezultati testov. 1C 8.2.19.83, za različico datoteke lokalni pomnilniški disk, za odjemalec-strežnik 1C in SQL na enem računalniku, skupni pomnilnik. Turbo boost je v obeh različicah onemogočen. 8.3 prikazuje primerljive rezultate.
Razlika je znotraj merske napake. Posebej sem izvlekel posnetke zaslona CPU-Z, da pokažem, da se s spremembo frekvence spreminjajo tudi drugi parametri, ista CAS Latency in RAS v CAS Delay, ki nevtralizira spremembo frekvence. Razlika bo sicer ob fizični menjavi pomnilniških modulov, iz počasnejših v hitrejše, a tudi tam številke niso posebej pomembne.
2. Ko smo uredili procesor in pomnilnik odjemalskega računalnika, preidemo na naslednje zelo pomembno mesto - omrežje. O prilagajanju omrežja je bilo napisanih veliko knjig, obstajajo članki o Infostartu (in drugi), vendar se tukaj ne bom osredotočil na to temo. Preden začnete s testiranjem 1C, se prepričajte, da iperf med dvema računalnikoma prikazuje celotno pasovno širino (za kartice 1 Gbit - no, vsaj 850 Mbit ali še bolje 950-980), da ste upoštevali nasvet Gileva. Potem - najpreprostejši preizkus delovanja bo, nenavadno, kopiranje ene velike datoteke (5-10 gigabajtov) po omrežju. Posredni znak normalnega delovanja v omrežju 1 Gbit bo povprečna hitrost kopiranja 100 MB / s, dobro delovanje - 120 MB / s. Rad bi vas opozoril na dejstvo, da je šibka točka (vključno) lahko obremenitev procesorja. Protokol SMB v Linuxu je precej slabo vzporeden in med delovanjem zlahka "požre" eno procesorsko jedro in ne porabi več.
In še nekaj. S privzetimi nastavitvami odjemalec windows najbolje deluje s strežnikom windows (ali celo delovno postajo windows) in protokolom SMB/CIFS, odjemalec linux (debian, ubuntu ni pogledal drugih) bolje deluje z linuxom in NFS ( deluje tudi s SMB, vendar so na NFS papige višje). Dejstvo, da se med linearnim kopiranjem strežnik Windows Linux v NFS hitreje prekopira v en tok, ne pomeni nič. Nastavitev Debiana za 1C je tema za ločen članek, nanjo še nisem pripravljen, čeprav lahko rečem, da sem v datotečni različici dobil celo nekoliko boljšo zmogljivost kot različica Win na isti opremi, vendar s postgresom z več 50 uporabnikov Še vedno imam vse zelo slabo.
Najpomembnejša stvar, ki jo "zažgani" skrbniki vedo, vendar začetniki ne upoštevajo. Obstaja veliko načinov za nastavitev poti do baze podatkov 1c. Lahko naredite servershare, lahko naredite 192.168.0.1share, lahko neto uporabite z: 192.168.0.1share (v nekaterih primerih bo tudi ta metoda delovala, vendar ne vedno) in nato določite pogon Z. Zdi se, da vse te poti kažejo na isto stvar na istem mestu, vendar za 1C obstaja samo ena metoda, ki povsem zanesljivo zagotavlja normalno delovanje. Torej, to je tisto, kar morate storiti pravilno:
V ukazni vrstici (ali v pravilnikih ali kar koli vam ustreza) - ne uporabite DriveLetter: servershare. Primer: net use m: serverbases. Posebej ne poudarjam naslova IP, ampak ime strežnika. Če ime strežnika ni vidno, ga dodajte v dns na strežniku ali lokalno v datoteko hosts. Toda naslov mora biti po imenu. V skladu s tem na poti do baze podatkov dostopajte do tega diska (glejte sliko).
In zdaj bom s številkami pokazal, zakaj je to nasvet. Začetni podatki: Intel X520-DA2, Intel 362, Intel 350, kartice Realtek 8169 OS Win 2008 R2, Win 7, Debian 8. Najnovejši gonilniki, uporabljene posodobitve. Pred testiranjem sem se prepričal, da Iperf daje polno pasovno širino (razen 10 Gbit kartic je uspel iztisniti le 7,2 Gbit, kasneje bom videl zakaj, testni strežnik še ni pravilno nastavljen). Diski so različni, ampak povsod je SSD (posebej sem vstavil en sam disk za testiranje, ni naložen z ničemer drugim) ali raid iz SSD-ja. Hitrost 100 Mbit je bila dosežena z omejevanjem nastavitev adapterja Intel 362 Med 1 Gbit bakrenim Intel 350 in 1 Gbit optičnim Intel X520-DA2 (dobljenim z omejevanjem hitrosti adapterja). Največja zmogljivost, turbo boost je izklopljen (zgolj zaradi primerljivosti rezultatov turbo boost pri dobrih rezultatih doda malo manj kot 10%, pri slabih rezultatih morda sploh ne vpliva). Različice 1C 8.2.19.86, 8.3.6.2076. Ne navajam vseh številk, ampak samo najbolj zanimive, da boste imeli s čim primerjati.
| 100 Mbit CIFS Win 2008 - Win 2008 kontakt po ip naslovu | 100 Mbit CIFS Win 2008 - Win 2008 kliče po imenu | 1 Gbit CIFS Win 2008 - Win 2008 kontakt po ip naslovu | 1 Gbit CIFS Win 2008 - Win 2008 kliče po imenu | 1 Gbit CIFS Win 2008 - Win 7 kliče po imenu | 1 Gbit CIFS Win 2008 - Debian kliče po imenu | 10 Gbit CIFS Win 2008 - Win 2008 kontakt po ip naslovu | 10 Gbit CIFS Win 2008 - Win 2008 kliče po imenu |
|
| 11,20 | 26,18 | 15,20 | 43,86 | 40,65 | 37,04 | 16,23 | 44,64 | |
| 1C 8.2 | 11,29 | 26,18 | 15,29 | 43,10 | 40,65 | 36,76 | 15,11 | 44,10 |
| 8.2.19.83 | 12,15 | 25,77 | 15,15 | 43,10 | 14,97 | 42,74 | ||
| 6,13 | 34,25 | 14,98 | 43,10 | 39,37 | 37,59 | 15,53 | 42,74 | |
| 1C 8.3 | 6,61 | 33,33 | 15,58 | 43,86 | 40,00 | 37,88 | 16,23 | 42,74 |
| 8.3.6.2076 | 33,78 | 15,53 | 43,48 | 39,37 | 37,59 | 42,74 |
Zaključki (iz tabele in iz osebnih izkušenj. Velja samo za različico datoteke):
- Preko omrežja lahko dobite povsem običajne številke za delo, če je to omrežje pravilno konfigurirano in je pot pravilno vnesena v 1C. Tudi prvi Core i3 z lahkoto proizvede 40+ papagajev, kar je kar dobro, pa to niso samo papige, pri realnem delu se razlika tudi pozna. Ampak! Omejitev pri delu z več (več kot 10) uporabniki ne bo več omrežje, tu je še vedno dovolj 1 Gbit, ampak blokada pri večuporabniškem delu (Gilev).
- platforma 1C 8.3 je mnogokrat bolj zahtevna glede pravilne konfiguracije omrežja. Osnovne nastavitve - glej Gilev, vendar imej v mislih, da je na vse mogoče vplivati. Opazil sem pospešek zaradi odstranitve (in ne samo izklopa) protivirusnega programa, odstranitve protokolov, kot je FCoE, zamenjave gonilnikov na starejšo, vendar Microsoftovo certificirano različico (zlasti za poceni kartice, kot sta ASUS in DLC), odstranitve druge omrežne kartice s strežnika. Obstaja veliko možnosti, skrbno konfigurirajte svoje omrežje. Lahko pride do situacije, ko platforma 8.2 daje sprejemljive številke, 8.3 pa dva ali celo večkrat manj. Poskusite igrati z različico platforme 8.3, včasih dobite zelo velik učinek.
- 1C 8.3.6.2076 (mogoče kasneje, nisem še iskal točne različice) je še vedno lažje konfigurirati preko omrežja kot 8.3.7.2008. Normalno delovanje preko omrežja od 8.3.2008 (pri primerljivih papigah) mi je uspelo doseči le nekajkrat, za bolj splošen primer tega nisem mogel ponoviti. Nisem kaj dosti razumel, a sodeč po povojih stopal iz Process Explorerja tam posnetek ni tako dober kot v 8.3.6.
- Kljub temu, da je pri delu v 100 Mbitnem omrežju njegova obremenitev majhna (lahko rečemo, da je omrežje prosto), je hitrost delovanja še vedno precej manjša kot pri 1 Gbit. Razlog je zakasnitev omrežja.
- Pri vseh drugih pogojih (dobro delujoče omrežje) je za 1C 8.2 povezava Intel-Realtek 10% počasnejša od Intel-Intel. Toda realtek-realtek lahko na splošno kar nenadoma povzroči močno ugrezanje. Torej, če imate denar, je bolje, da imate Intelove omrežne kartice povsod; če nimate denarja, potem namestite Intel samo na strežnik (vaš CO). In velikokrat je več navodil za nastavitev omrežnih kartic Intel.
- Privzete protivirusne nastavitve (na primer drweb različice 10) zasedajo približno 8-10% papagajev. Če ga konfiguriraš kot mora (dovoliš procesu 1cv8, da naredi vse, čeprav ni varno), je hitrost enaka kot brez antivirusa.
- NE berite gurujev Linuxa. Strežnik s sambo je odličen in brezplačen, če pa na strežnik namestite Win XP ali Win7 (ali še bolje - strežniški OS), bo datotečna različica 1c delovala hitreje. Da, samba in protokolni sklad ter omrežne nastavitve in še veliko, veliko več je mogoče dobro nastaviti v debian/ubuntu, vendar je to priporočljivo za strokovnjake. Nima smisla namestiti Linux s privzetimi nastavitvami in potem govoriti, da je počasen.
- Delovanje diskov, povezanih preko net use, je kar dobra ideja preveriti s fio. Vsaj jasno bo, ali gre za težave s platformo 1C ali z omrežjem/diskom.
- Za enouporabniško različico se ne spomnim testov (ali situacije), kjer bi bila vidna razlika med 1 Gbit in 10 Gbit. Edina stvar, kjer je 10Gbit za datotečno različico dala boljše rezultate, je povezovanje diskov preko iSCSI, vendar je to tema za poseben članek. Vseeno menim, da za datotečno različico zadostujejo 1 Gbit kartice.
- Ne razumem, zakaj pri 100 Mbit omrežju 8.3 deluje opazno hitreje kot 8.2, a je bilo dejstvo. Vsa druga oprema, vse druge nastavitve so popolnoma enake, samo v enem primeru je testiran 8.2, v drugem pa 8.3.
- Nenastavljen NFS win-win ali win-lin daje 6 papagajev, nisem jih vključil v tabelo. Po uglaševanju sem dobil 25, vendar je bil nestabilen (razlika v meritvah je bila več kot 2 enoti). Ne morem še dati priporočil glede uporabe sistema Windows in protokola NFS.
Terminalski strežnik. (baza je na strežniku, odjemalci se povezujejo preko omrežja, RDP protokol). Algoritem korak za korakom:
- Gilevovo testno bazo dodamo na strežnik v isto mapo kot glavne baze podatkov. Povezujemo se z istega strežnika in izvajamo test. Rezultat si zapomnimo.
- Na povsem enak način kot v datotečni različici konfiguriramo procesor. V primeru terminalskega strežnika ima na splošno glavno vlogo procesor (predpostavlja se, da ni očitnih šibkih točk, kot je pomanjkanje pomnilnika ali ogromna količina nepotrebne programske opreme).
- Konfiguracija omrežnih kartic v primeru terminalskega strežnika praktično ne vpliva na delovanje 1c. Če želite zagotoviti “posebno” udobje, če vaš strežnik proizvede več kot 50 papagajev, se lahko igrate z novimi različicami protokola RDP, samo za udobje uporabnikov, hitrejši odziv in drsenje.
- Kadar aktivno dela večje število uporabnikov (in tukaj že lahko poskusite povezati 30 ljudi v eno bazo, če se potrudite), je zelo priporočljiva namestitev SSD diska. Iz nekega razloga se domneva, da disk ne vpliva posebej na delovanje 1C, vendar se vsi testi izvajajo z omogočenim predpomnilnikom krmilnika za pisanje, kar je napačno. Testna zbirka podatkov je majhna, kar dobro se prilega predpomnilniku, zato visoke številke. V pravih (velikih) podatkovnih bazah bo vse popolnoma drugače, zato je predpomnilnik za teste onemogočen.
| Raid 10 4x SATA 7200 ATA ST31500341AS | Raid 10 4x SAS 10k | Raid 10 4x SAS 15k | En SSD | Ramdisk | Ramdisk | Predpomnilnik omogočen RAID krmilnik |
|
| 21,74 | 28,09 | 32,47 | 49,02 | 50,51 | 53,76 | 49,02 | |
| 1C 8.2 | 21,65 | 28,57 | 32,05 | 48,54 | 49,02 | 53,19 | |
| 8.2.19.83 | 21,65 | 28,41 | 31,45 | 48,54 | 49,50 | 53,19 | |
| 33,33 | 42,74 | 45,05 | 51,55 | 52,08 | 55,56 | 51,55 | |
| 1C 8.3 | 33,46 | 42,02 | 45,05 | 51,02 | 52,08 | 54,95 | |
| 8.3.7.2008 | 35,46 | 43,01 | 44,64 | 51,55 | 52,08 | 56,18 |
- Omogočen predpomnilnik RAID krmilnika odpravi vse razlike med diski, številke so enake za sat in cas. Testiranje z njim na majhni količini podatkov je neuporabno in ni indikativno.
- Za platformo 8.2 je razlika v zmogljivosti med možnostma SATA in SSD več kot dvakratna. To ni tipkarska napaka. Če med preizkusom pogonov SATA pogledate monitor zmogljivosti. potem lahko jasno vidite "Aktivni čas delovanja diska (v%)" 80-95. Da, če omogočite predpomnilnik samih diskov za snemanje, se bo hitrost povečala na 35, če omogočite predpomnilnik krmilnika raid - do 49 (ne glede na to, kateri diski se trenutno testirajo). Toda to so sintetični predpomnilniki; v resničnem delu z velikimi bazami podatkov nikoli ne bo 100-odstotnega razmerja zadetkov predpomnilnika.
- Hitrost tudi poceni diskov SSD (testiral sem na Agility 3) je povsem dovolj za poganjanje datotečne različice. Snemalni vir je druga stvar, pogledati ga morate v vsakem posameznem primeru, jasno je, da ga bo Intel 3700 imel za red velikosti višje, vendar je cena ustrezna. In ja, razumem, da pri testiranju SSD diska v večji meri testiram tudi predpomnilnik tega diska, realnih rezultatov bo manj.
- Najbolj pravilna (z mojega vidika) rešitev bi bila dodelitev 2 diskov SSD v zrcaljeni raid za bazo podatkov datotek (ali več baz podatkov datotek) in tam ne bi postavili ničesar drugega. Da, z ogledalom se SSD-ji enakomerno obrabijo in to je minus, vendar je vsaj krmilna elektronika nekako zaščitena pred napakami.
- Glavne prednosti pogonov SSD za datotečno različico se bodo pokazale, ko bo veliko baz podatkov, vsaka z več uporabniki. Če obstaja 1-2 podatkovni bazi in je približno 10 uporabnikov, bodo SAS diski dovolj. (v vsakem primeru pa poglej nalaganje teh diskov, vsaj preko perfmona).
- Glavne prednosti terminalskega strežnika so, da ima lahko zelo šibke odjemalce in da omrežne nastavitve veliko manj vplivajo na terminalski strežnik (spet vaš K.O.).
Če test Gilev pokaže majhne številke in imate procesor z visokim taktom in hitre diske, potem mora skrbnik vzeti vsaj perfmon, nekje zabeležiti vse rezultate in gledati, opazovati in sklepati. Dokončnega nasveta ne bo.
Možnost odjemalec-strežnik.
Testi so bili izvedeni šele 8.2, ker pri 8.3 je vse čisto hudo odvisno od verzije.
Za testiranje sem izbral različne možnosti strežnika in omrežja med njimi, da bi prikazal glavne trende.
| 1C: Xeon 5520 SQL: Xeon E5-2630 | 1C: Xeon 5520 SQL: Xeon E5-2630 Optični kanal - SSD | 1C: Xeon 5520 SQL: Xeon E5-2630 Optični kanal - SAS | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 SQL: Xeon E5-2630 Optični kanal - SSD | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | |
| 16,78 | 18,23 | 16,84 | 28,57 | 27,78 | 32,05 | 34,72 | 36,50 | 23,26 | 40,65 | 39.37 | |
| 1C 8.2 | 17,12 | 17,06 | 14,53 | 29,41 | 28,41 | 31,45 | 34,97 | 36,23 | 23,81 | 40,32 | 39.06 |
| 16,72 | 16,89 | 13,44 | 29,76 | 28,57 | 32,05 | 34,97 | 36,23 | 23,26 | 40,32 | 39.06 |
Zdi se, da sem pretehtal vse zanimive možnosti, če vas še kaj zanima, napišite v komentarje, poskusil bom to narediti.
- SAS v sistemih za shranjevanje je počasnejši od lokalnih diskov SSD, čeprav imajo sistemi za shranjevanje večje velikosti predpomnilnika. SSD-ji, tako lokalni kot v sistemih za shranjevanje, delujejo s primerljivimi hitrostmi za Gilevov test. Ne poznam nobenega standardnega večnitnega testa (ne samo snemanja, ampak vse opreme), razen testa obremenitve 1C iz MCC.
- Spreminjanje strežnika 1C s 5520 na 5650 je skoraj podvojilo zmogljivost. Da, konfiguracije strežnikov se ne ujemajo popolnoma, vendar kaže trend (ni presenetljivo).
- Povečanje frekvence na SQL strežniku vsekakor daje učinek, vendar ne tako kot na 1C strežniku; MS SQL strežnik je odličen (če ga vprašate) za uporabo več jeder in prosti pomnilnik.
- Spreminjanje omrežja med 1C in SQL z 1 Gbit na 10 Gbit daje približno 10% papig. Pričakoval sem več.
- Omogočanje skupnega pomnilnika še vedno daje učinek, čeprav ne 15%, kot je opisano v članku. Bodite prepričani, da to storite, na srečo je hitro in enostavno. Če je nekdo med namestitvijo strežniku SQL dal imenovani primerek, potem za delovanje 1C mora biti ime strežnika podano ne s FQDN (tcp/ip bo deloval), ne prek localhost ali samo ServerName, ampak prek ServerNameInstanceName, na primer zz- testzztest. (V nasprotnem primeru bo prišlo do napake DBMS: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Knjižnice skupnega pomnilnika, uporabljene za vzpostavitev povezave s strežnikom SQL Server 2000, ni bilo mogoče najti. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE=08001, stanje=1, Resnost=10, izvorno=126, vrstica=0).
- Za uporabnike, manjše od 100, je edina točka pri razdelitvi na dva ločena strežnika licenca Win 2008 Std (in starejša), ki podpira samo 32 GB RAM-a. V vseh drugih primerih je treba 1C in SQL zagotovo namestiti na en strežnik in dati več (vsaj 64 GB) pomnilnika. Dati MS SQL manj kot 24-28 GB RAM-a je neupravičen pohlep (če mislite, da imate dovolj pomnilnika za to in vse deluje v redu, bi vam morda zadostovala datotečna različica 1C?)
- Kako slabše deluje kombinacija 1C in SQL v virtualnem stroju, je tema ločenega članka (namig - opazno slabše). Tudi v Hyper-V ni vse tako jasno ...
- Način uravnoteženega delovanja je slab. Rezultati so precej skladni z različico datoteke.
- Številni viri pravijo, da način odpravljanja napak (ragent.exe -debug) povzroči znatno zmanjšanje zmogljivosti. No, zmanjša, ja, vendar 2-3% ne bi rekel pomemben učinek.
Vsak strokovnjak za podporo ima izkušnje s sprejemanjem abstraktnih pritožb uporabnikov. Vsem so znane formulacije: »ona zelo dolgo razmišlja«, »imam rdeče okno«, »sistem nekako narobe deluje« in tudi »to se že dolgo ni zgodilo in tukaj je je spet.”
V takšni situaciji je zelo težko takoj ugotoviti, kje je napaka in kaj storiti najprej. V tem članku bomo pogledali, od česa je odvisna učinkovitost 1C, tj. visoko obremenjeni sistemi, ustvarjeni na podlagi 1C:Enterprise, v situacijah, ko simptomi niso popolnoma razumljeni in ni mogoče postaviti posebne diagnoze.
Glavni razlogi, ki vplivajo na delovanje 1C
V več kot 60% primerov so razlogi za nizko produktivnost:
- Neoptimalne poizvedbe in konfiguracijska koda (26 % primerov);
- Neoptimalno indeksiranje objektnih tabel (19% primerov);
- Neoptimalna obremenitev diskovnega podsistema (16% primerov).
S tem se strinjajo vodilni Microsoftovi razvijalci.
Tako je za doseganje znatnega izboljšanja delovanja aplikacije baze podatkov mogoče optimizirati obseg dostopa do podatkov, vključno z logično in fizično zasnovo baz podatkov (kolikor je to mogoče v 1C), pa tudi z ustvarjanjem pravega poizvedb in z uporabo optimalnega indeksiranja. Nekatere težave z zmogljivostjo podatkovne baze je mogoče rešiti s povečanjem zmogljivosti strojne opreme, vendar ne vedno: napačne zasnove aplikacijske rešitve ni mogoče nadomestiti z zmogljivejšim strežnikom. Nič nenavadnega ni, da imajo podjetja uporabnika z nakupom nove opreme, ne da bi razumeli vzroke težave z delovanjem, znatne stroške, vendar problem ostaja nerešen.
Kakovostna diagnostika delovanja 1C z uporabo celotnega nabora obstoječih orodij je ključ do uspešnega reševanja problemov in optimizacije stroškov.
Prvi korak pri prepoznavanju in reševanju težav z nizko učinkovitostjo je razvoj celovitega seznama ključnih problematičnih dejavnosti, vključno z njihovo trenutno hitrostjo in pričakovano prihodnjo hitrostjo.
primer:
Nepravilno: Program zamrzne pri ustvarjanju poročila. Želim, da se oblikuje hitreje.
Pravilno: Poročilo »Izpis dolga« se ustvari v 5 minutah 10 sekundah. Pričakovana hitrost generiranja tega poročila je največ 20 sekund.
Ko je seznam težav sestavljen in digitaliziran, je treba analizirati vzroke, začenši z iskanjem problematične kode, če obstaja (na primer "težke" zahteve, dolgo čakanje na zaklepanja, zastoji itd.).
Orodja za prepoznavanje problematične kode
- »1C: Center za upravljanje zmogljivosti« (modul, vključen v paket orodij »1C: Corporate«, ki ga proizvaja 1C);
- Storitve v oblaku Gilev;
- Standardna orodja vodilnih proizvajalcev, vgrajena v DBMS.
Učinkovitost uporabe teh orodij je zagotovljena s kvalifikacijo razvijalca "1C: tehnološki strokovnjak", kar pomeni njegovo sodelovanje pri obsežnih implementacijah 1C. Hkrati lahko različni strokovnjaki na podlagi svojih individualnih izkušenj dajo prednost enemu ali drugemu orodju/metodi.
Vzporedno z uporabo enega izmed predstavljenih orodij se uporabljajo tudi standardna orodja za spremljanje obremenitev opreme (Performance monitors counters).
Na podlagi dobljenih meritev se določi razred vzroka:
- Težava je v kodi;
- In/ali je težava v strojni opremi;
- Težava je v drugih programih, ki zahtevajo veliko virov in se uporabljajo na produkcijskih strežnikih.
Testiranje obremenitve 1C - metoda za ocenjevanje strežniške opreme
Kot že omenjeno, med dejavniki, ki lahko pozitivno in negativno vplivajo na delovanje 1C, pomembno mesto zasedajo strežniška strojna oprema in njena konfiguracija. Oglejmo si možnosti za meritve, oceno obremenitve in testiranje delovanja sistema pod naslednjimi pogoji:
- Strežnik 1C je na voljo in se nahaja:
- Skupaj z DBMS;
- Na ločenem strežniku.
Za oceno skladnosti parametrov obstoječe strežniške opreme z zahtevami sistema je potrebno zbrati podatke o obremenitvi strojne opreme, vključno s procesorjem, tj. 1C obremenitveno testiranje. V ta namen se uporablja »Performance Monitor« - orodje, ki vam omogoča merjenje opreme na delovnem vezju in branje števcev zmogljivosti.
Spodaj je osnovni nabor števcev, ki jih je treba konfigurirati za spremljanje delovanja strojne opreme v sistemu Windows. Zbiranje poteka iz vseh strežnikov, kjer so nameščeni strežniki 1C.
Če ima števec odstotkov obremenitve procesorja za pogled »Procesor« visoko vrednost, morate identificirati procese, ki jih je mogoče ustaviti, ne da bi to vplivalo na delovanje strežnika, in jih tudi prenesti na druge strežnike.
Pogled »Proces« vam bo omogočil, da konfigurirate spremljanje za vsak posamezen proces, kot tudi določite, kateri procesi vzamejo največ časa procesorja. Če je na strežniku nameščen samo strežnik 1C, potem, da bi razumeli, kakšno obremenitev postavlja na strojno opremo, morate konfigurirati zbirko naslednjih števcev:
| \Process("1cv8*")\% procesorskega časa |
| \Process("ragent*")\% procesorskega časa |
| \Process("ragent*")\Private Bytes |
| \Process("ragent*")\Virtual Bytes |
| \Process("rmngr*")\% procesorskega časa |
| \Process("rmngr*")\Private Bytes |
| \Process("rmngr*")\Virtual Bytes |
| \Process("rphost*")\% procesorskega časa |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Virtual Bytes |
| \Process("1cv8*")\Private Bytes |
| \Process("1cv8*")\Virtual Bytes |
Če je trenutni sistem v nezadovoljivem stanju, je treba na podlagi zbranih meritev z uporabo linearne povezave izračunati parametre opreme za namestitev ciljnega sistema.
če načrtuje se le nakup strežniške opreme, njegove parametre je mogoče izračunati s posnemanjem delovanja načrtovanega sistema, vendar v manjšem obsegu, z uporabo obstoječe opreme. V ta namen se uporablja »1C: Test Center«, ki je vključen v 1C Corporate Toolkit. Na podlagi dobljenih meritev se z uporabo računskih metod določijo parametri načrtovanega sistema in s tem zahteve za opremo. Ta test se lahko večkrat uporablja za različne meritve, po predhodni dopolnitvi in razširitvi funkcionalnosti. Ta tehnika ima visoko natančnost in enostavnost izračuna.
V okviru proučevanja možnosti zakupa zmogljivosti namenskega strežnika ne samo za spletno industrijo, temveč tudi za gostovanje različnih vrst informacijskih in računovodskih sistemov, smo na primeru delovanja v namenskem okolju aplikacije 1C poskušali kvalitativno oceniti delovanje. različici strežnika 8.2 in 8.3 v povezavi CentOS 6.4+ PostgreSQL 9.1.2-1.1C, vse programske komponente (x_64).
Fizična platforma je bil strežnik HP ProLiant DL120 G7 (CPE Intel Xeon E3-1230, 8 GB, 2 trda diska SATA HP MB0500EBZQA brez RAID), hitrost internetne povezave do strežnika je bila 100 Mbit/s, hitrost povezave odjemalca je bila od 5 do 12 Mbit/s.
Po branju številnih gradiv in razprav o različnih internetnih virih (kot so http://www.infostart.ru, www.3nity.ru, www.mista.ru, www.ixbt.com itd.), posvečenih težavam z zmogljivostjo aplikacij 1C v različici odjemalec-strežnik smo se odločili za uporabo prosto distribuiranega testa V. Gileva (http://www.gilev.ru/tpc1cgilv/), katerega rezultati omogočajo kvalitativno primerjavo različnih nizov strežnikov in njihove komponente, OS, DBMS in različice aplikacijskih strežnikov 1C, da bi določili optimalno konfiguracijo celotnega kompleksa, tudi v cenovnem razredu.
Rezultati testa so predstavljeni na posnetkih zaslona:
Treba je opozoriti, da je prišlo do dokaj opaznega zmanjšanja rezultata testa na platformi 1C različice 8.3.3 (za različico 8.2.18 je bilo pri vseh drugih pogojih število točk 60), kar je očitno posledica razlika v izvajanju programske kode na različnih platformah. Odjemalski del je deloval v običajnem aplikacijskem načinu (debel odjemalec).
Možnost večnitnega delovanja je bila preizkušena tudi na naslednjem testu kot primeru (http://infostart.ru/public/173394/). Ta preizkus vam omogoča, da ocenite približno število sočasnih uporabnikov, pri katerih je odzivni čas sistema še sprejemljiv.
IGOR ČUFAROV, vodja oddelka za integrirane avtomatizirane sisteme v Radiozavod JSC, [e-pošta zaščitena]
40 točk v Gilev testu –
mit ali resničnost?
V zvezi s testom Gilev se nadaljujejo burne razprave, vključno s tistimi, ki temeljijo na nasprotujočih si rezultatih. Delil bom svoje izkušnje z uporabo tega orodja.
Izvori dvoumnosti
Ko se prvič soočijo s testom Gilev, so številni strokovnjaki presenečeni nad nenavadnimi rezultati, pridobljenimi z njegovo pomočjo. Namizna strojna oprema lahko na primer pokaže boljše rezultate kot drag in zmogljiv strežnik. Različica datoteke prejme višjo oceno kot SQL. In če je z drugim incidentom vse bolj ali manj jasno, je to razloženo tako v dokumentaciji za test kot v številnih razpravah na forumih, potem nihče še ni naredil jasnih zaključkov iz relativno nizkih rezultatov na dragi strežniški opremi.
Preden poročamo o dobljenih rezultatih, je vredno omeniti nekaj besed o samem testu Gilev in povedati, kaj je.
Ime »Gilev Test« se nanaša na obremenitveni test TPC-1C, ki je na voljo za brezplačen prenos na .
Znani rezultati
Vir podaja zanimive rezultate primerjave strežnika na osnovi 2*Intel Xeon E5620 2,4 Ghz z 48 GB RAM-a in osebnega računalnika na osnovi Intel Core i5 3,0 Ghz s 16 GB RAM-a. Brez dodatnih nastavitev in trikov, kot pravijo »out of the box«, je delovna postaja v Gilevovem testu »razbila« strežnik in pokazala 155% višjo zmogljivost.
Strežnik je dosegel približno 17 točk, namizje pa več kot 40. Kot rezultat poskusov (večina je vključevala zmanjšanje virov namizja, da bi ugotovili, koliko bi to poslabšalo rezultat testa) in nastavitev strežnika je avtorjem članka uspelo doseči 25,6 točke.
Rezultat, odkrito povedano, je daleč od 40 na običajni sistemski enoti. Torej, ali je bolje namestiti strežnik 1C na proračunsko strojno opremo, kupljeno v najbližjem kiosku? seveda ne.
Razprava na dogodku Infostart 2016
Nekaj dni pred mojim potovanjem na konferenco Infostart Event 2016 v Sankt Peterburgu se je na spletni strani courses-po-1s pojavil zanimiv dvourni video o delovanju sistema 1C:Enterprise v virtualiziranih okoljih, izbiri opreme in težavah z zmogljivostjo. .rf.
Na konferenci Infostart Event 2016 naj bi spregovoril avtor tega webinarja Andrey Burmistrov - 1C strokovnjak za tehnološka vprašanja velikih izvedb, ki je delal tako v podjetju 1C kot na številnih velikih izvedbah pri nas, mentor več kot 2000 strokovnjakov v tečaju »Optimizacija zmogljivosti 1C« in priprava na 1C: Expert.
V luči zanimanja za temo sem se z Andrejem pogovarjal tako virtualno kot naknadno na sami konferenci. Eno od vprašanj, ki sem mu jih postavil na okrogli mizi HighLoad, se je nanašalo na možnost objave webinarja z referenčnim testiranjem različnih možnosti strežniške strojne opreme - s SSD, z navadnim trdim diskom, v različnih strojnih konfiguracijah. Odgovor je zvenel nekako takole: »Hvala, to je zanimiva ideja. Mogoče nam bo uspelo. Dajte nam Intel P3700, P3600 in z veseljem ju bomo preizkusili. Ni tako enostavno dobiti SSD nekje za testiranje za en teden.«
Tako se je izkazalo, da skoraj nihče od mojih sogovornikov na lastne oči ni videl več kot 30 točk v načinu SQL, tisti, ki so to videli, pa so ugotovili, da ni na strežniški opremi.
Začaran krog? Pojavilo se je resno vprašanje: "40 točk v testu Gilev na strežniški strojni opremi v načinu SQL - mit ali resničnost?"
Preberite celoten članek v reviji “Sistemski skrbnik”, št. 5, 2017, na straneh 10-15.
PDF različico te številke lahko kupite pri našem
