Savjeti za automatizaciju. Savjeti za automatizaciju 1s 8 je spor

Ovaj članak govori o glavnim faktorima: kada se 1C usporava, 1C se zamrzava i 1C radi sporo. Podaci su pripremljeni na osnovu SoftPoint-ovog višegodišnjeg iskustva u optimizaciji velikih IT sistema izgrađenih na kombinaciji 1C + MS SQL.

Za početak, vrijedi napomenuti mit da 1C nije dizajniran za istovremeni rad velikog broja korisnika, aktivno podržan od strane korisnika foruma koji u ovim objavama nalaze udobnost i razlog da ostave sve kako jest. Uz dovoljno strpljenja i nivo znanja, sistem možete dovesti do bilo kojeg broja korisnika. Spor rad i zamrzavanje 1C više neće biti problem.

Iz prakse: Najlakše je optimizirati 1C v7.7 (Optimizacija 1C 8.1, 1C 8.2, 1C 8.3 je teži zadatak, jer se aplikacija sastoji od 3 linka). Dobijanje do 400 istovremenih korisnika je prilično tipičan projekat. Do 1500 je već teško, zahtijeva naporan rad.

Drugi mit: da biste poboljšali performanse 1C i riješili se zamrzavanja 1C, morate instalirati moćniji server. U pravilu, u projektima optimizacije u 95% slučajeva moguće je postići prihvatljive performanse ili bez nadogradnje, ili ažuriranjem neznatnog dijela opreme, na primjer, dodavanjem RAM-a. Istovremeno, treba napomenuti da oprema i dalje mora biti bazirana na serveru, posebno diskovni podsistem. Zastarjeli podsistem diska samo je jedan od razloga zašto je 1C spor.

Glavno ograničenje u radu s više korisnika u 1C je mehanizam blokiranja. Brave u 1C, a ne serverska oprema, obično sprečavaju veliki broj ljudi da rade u bazi podataka. Da biste prevladali ovu nevolju, morate naporno raditi i promijeniti logiku brava u 1C - spustiti ih iz tabele u red po red. Tada će, na primjer, držanje dokumenta blokirati samo jedan, a ne sve dokumente u sistemu.

Slika 1. Red za blokiranje 1C u sistemu za praćenje PerfExpert, sa informacijama o 1C korisnicima, konfiguracijskom modulu i specifičnom linijom koda u ovom modulu.

Promjena mehanizma za zaključavanje 1C vrlo je složena tehnologija. Nije svatko u stanju izvući takav trik, a za njih ostaje samo jedan način - optimizirati strukturu i ubrzati vrijeme izvršavanja operacija. Činjenica je da su blokiranje u 1C i vrijeme potrebno za dovršetak operacija vrlo međusobno povezani pokazatelji. Na primjer, ako operacija postavljanja dokumenta traje 15 sekundi, onda je kod velikog broja korisnika velika vjerovatnoća da će prilikom postavljanja neko drugi pokušati objaviti dokument i čekati u bravi. Ako dovedete vrijeme izvršenja na najmanje 1 sekundu, tada će se blokiranje 1C za ovu operaciju značajno smanjiti.

Opasnije u smislu blokiranja su grupne obrade, koje mogu biti duge u vremenu izvršenja i istovremeno uzrokovati 1C blokiranje. Svaka obrada koja mijenja podatke, poput ponovnog redoslijeda ili grupne obrade dokumenata, zaključava tabele i sprječava druge korisnike da objavljuju dokumente. Naravno, što se ovi procesi brže izvode, to je vrijeme blokiranja kraće i korisnicima je lakše raditi.

Teški izvještaji koji obavljaju samo operacije čitanja također mogu biti opasni u smislu zaključavanja, iako se čini da ne zaključavaju podatke. Takvi izvještaji utiču na intenzitet blokiranja u 1C, usporavajući druge operacije u sistemu. Odnosno, ako je izvještaj vrlo težak i zauzima najveći dio resursa servera, može se ispostaviti da su prije pokretanja izvještaja ista izvršenja izvršena 1 sekundu, a tokom izvršavanja izvještaja 15 sekundi. Naravno, sa povećanjem vremena izvršavanja operacija, povećava se i intenzitet blokiranja.

Slika 2. Učitavanje na radnom serveru u kontekstu konfiguracijskih modula, od svih korisnika. Svaki modul ima svoju boju. Postoji jasna neravnoteža u opterećenju stvorenom od 1C.

Glavno pravilo pri optimizaciji je da dokument traje minimalno vremena i da obavlja samo potrebne operacije. Na primjer, proračuni registra se često koriste u obradi knjiženja bez specificiranja uslova filtriranja. U ovom slučaju morate odrediti filtere za registre koji vam omogućavaju da dobijete najbolju selektivnost, ne zaboravljajući da bi, prema uvjetima filtriranja, registar trebao imati odgovarajuće indekse.

Osim pokretanja teških izvještaja, neoptimalne postavke MS SQL-a i MS Windows-a mogu usporiti vrijeme izvršavanja operacija i samim tim povećati intenzitet 1C blokiranja. Ovaj problem se nalazi kod 95% kupaca. Treba napomenuti da se radi o serverima ozbiljnih organizacija, au njihovu podršku i konfiguraciju uključeni su čitavi odjeli visokokvalifikovanih administratora.

Glavni razlog neispravne konfiguracije servera je strah administratora da bilo šta promijene na pokrenutom serveru i pravilo "Najbolje je neprijatelj dobrog". Ako administrator promijeni postavke servera i počnu problemi, tada će se sav bijes nadležnih izliti na nemarnog administratora. Stoga mu je isplativije da sve ostavi kako jeste i ne učini ni jedan korak bez naređenja pretpostavljenih, nego da eksperimentiše na svoju odgovornost.

Drugi razlog je nedostatak jasnih informacija o problemima optimizacije mreže. Mnogo je mišljenja, koja su često potpuno kontradiktorna. Svako mišljenje posvećeno optimizaciji ima svoje protivnike i fanatike koji će ga braniti. Kao rezultat toga, internet i forumi zbunjuju postavke servera, a ne pomažu. U situaciji takve neizvjesnosti, administrator ima još manje želje da promijeni nešto na serveru, što barem nekako funkcionira.

Na prvi pogled slika je jasna - potrebno je optimizirati sve što usporava 1C server. Ali zamislimo sebe na mjestu takvog optimizatora - recimo da imamo 1C 8.1 8.2 8.3 SCP i 50 korisnika koji rade u isto vrijeme. Jednog užasnog dana, korisnici počinju da se žale da je 1C spor i moramo da rešimo ovaj problem.

Prije svega, pogledamo šta se dešava na serveru - odjednom postoji neka vrsta nezavisnog antivirusa koji vrši potpuno skeniranje sistema. Inspekcija pokazuje da je sve pristojno - server je učitan ispod 100%, i to samo sqlservr procesom.

Iz prakse: jedan od mlađih administratora je na vlastitu inicijativu uključio automatsko ažuriranje na serveru, Windows i SQL su se radosno ažurirali, a nakon ažuriranja počelo je ogromno usporavanje rada korisnika 1C ili se 1C jednostavno zamrzava .

Sljedeći korak je provjeriti koji programi učitavaju MS SQL. Inspekcija pokazuje da je opterećenje generirano iz približno 20 konekcija poslužitelja aplikacija.

Iz prakse: program koji brzo ažurira podatke na sajtu je zapeo, i umesto da se ažurira svaka 4 sata, uradio je to bez zaustavljanja, bez pauza, velikog opterećenja servera i blokiranja podataka.

Dalja analiza situacije suočava se sa velikim poteškoćama. Već smo saznali da opterećenje dolazi direktno iz 1C, ali kako razumjeti šta tačno korisnici rade? Ili barem ko su oni. Pa, ako u organizaciji ima 10 korisnika 1C, onda možete jednostavno proći kroz njih i saznati šta sada rade, ali u našem slučaju ih je pedeset, a raštrkani su po nekoliko zgrada.

U primjeru koji razmatramo situacija još nije komplikovana. I zamislite da usporavanje nije bilo danas, nego juče. Danas se situacija ne ponavlja, sve je u redu, ali treba da shvatite zašto operateri nisu mogli da rade juče (prirodno su se žalili tek pred odlazak od kuće, jer vole da ćaskaju po ceo dan, jer ništa ne radi, njima se sviđa više od rada). Ovaj slučaj naglašava potrebu za serverskim sistemom evidentiranja koji će uvijek čuvati historiju glavnih parametara servera i iz kojeg se redoslijed događaja može vratiti.

Sistem evidentiranja je jednostavno nezamjenjiv alat u optimizaciji sistema. Ako tome dodate mogućnost pregleda trenutnog stanja na mreži, dobićete sistem za praćenje stanja servera. Svaki projekat optimizacije počinje prikupljanjem statistike stanja servera kako bi se identifikovala uska grla.

Kada smo počeli da radimo na polju optimizacije, isprobali smo mnoge sisteme za nadzor servera, nažalost nismo uspeli da nađemo nešto što bi rešilo ovaj problem na odgovarajućem nivou, pa smo morali sami da kreiramo sistem. Rezultat je bio jedinstven proizvod, PerfExpert, koji je omogućio automatizaciju i pojednostavljenje procesa optimizacije IT sistema. Program se odlikuje čvrstom integracijom sa 1C, odsustvom bilo kakvog zamjetnog dodatnog opterećenja i više puta dokazanom prikladnošću za praktičnu upotrebu u borbenim situacijama.

Da se vratimo na naš primjer, najvjerovatniji ishod je: Administrator kaže “Krivi su programeri koji su napisali konfiguraciju”, programeri odgovaraju – “Sve imamo dobro napisano – server ne radi dobro.” A kolica su, kako kažu, još tu. Kao rezultat toga, 1C usporava, zamrzava se ili sporo radi.

U svakom slučaju, da biste riješili probleme performansi 1C, preporučujemo da prvo kupite i koristite praćenje performansi PerfExpert , to će vam omogućiti da donesete ispravnu odluku upravljanja i uštedite novac. Proizvod je pogodan kako za male IS 1C:Enterprise - do 50 korisnika, tako i za sisteme - od 1000 korisnika. Od jula 2015. praćenje učinka PerfExpert dobio certifikat 1C: Kompatibilan, testiran u Microsoft i pomaže u rješavanju problema performansi ne samo za 1C sisteme, već i za druge informacione sisteme zasnovane na MS SQL Server (Axapta, CRM Dynamics, Doc Vision i drugi).

Ako su vam se svidjeli podaci, preporučeni sljedeći koraci su:

- Ako želite samostalno rješavati probleme tehničke izvedbe 1C (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) i drugi informacioni sistemi, a zatim za vas jedinstvena lista tehničkih članaka u našem Almanahu (Brave i zastoji, veliko opterećenje CPU-a i diska, održavanje baze podataka i podešavanje indeksa samo su mali dio tehničkog materijala koji ćete tamo pronaći).
.
- Ako želite da razgovarate o problemima performansi sa našim stručnjakom ili naručite PerfExpert rešenje za praćenje performansi onda ostavite zahtjev i mi ćemo Vas kontaktirati u najkraćem mogućem roku.

Iz različitih razloga, korisnici 1C programa s vremena na vrijeme nailaze na probleme s performansama 1C. Na primjer: dokument se dugo obrađuje, dugo se generira izvještaj, greške u transakciji, program se zamrzava, spor odgovor na radnje korisnika itd. Prateći naša uputstva, možete postići značajan uspeh u brzini programa, sprečiti prekoračenje sistemskog ograničenja. Ovo nije lijek za sve bolesti, ali većina razloga za 1C kočnice leži upravo u tim problemima.

1. Nemojte pokretati zakazane i pozadinske zadatke dok korisnici rade

Prvo i najvažnije pravilo za administratore sistema je da svi pozadinski zadaci rade van radnog vremena. Sistem treba što više rasteretiti kako bi obavljao rutinske poslove (indeksiranje, postavljanje dokumenata, učitavanje podataka) i istovremeno ne ometajući rad korisnika. Ni sistem ni korisnici se neće mešati jedni u druge ako rade u različito vreme.

2. Nemojte razmjenjivati ​​RIB podatke tokom radnog dana korisnika

Iako su kompanije nedavno napustile RIB sistem razmjene podataka u korist online načina rada i terminalskog pristupa, neće biti naodmet zapamtiti da je prilikom učitavanja i preuzimanja podataka za razmjenu nemoguće izvršiti dokumentaciju i završiti posao u programu. Ako je moguće, ovaj postupak, ako ga ima, mora se izvesti pomoću pozadinskih zadataka noću.

3. Blagovremeno poboljšajte performanse računara, uskladite njegovu snagu sa stvarnim potrebama

Ne zaboravite da istovremeni rad 30 i 100 korisnika u sistemu daje različito opterećenje. Shodno tome, ukoliko se planira kvantitativni rast korisnika, IT služba bi trebalo da blagovremeno razmotri pitanje sa menadžmentom kompanije o proširenju flote mašina, nabavci dodatne memorije ili servera.

4. Softver na kojem radi 1C

Program 1C je takav da drugačije radi na operativnim sistemima. Ne zna se tačno zašto, ali jeste. Na primjer, serverska verzija 1C baze podataka na Linux OS-u u kombinaciji sa SQL Postgreom je mnogo sporija od iste 1C baze podataka, ali na Windows OS-u u sprezi sa MS SQL-om. Tačni razlozi za ovu činjenicu nisu poznati, ali očigledno negdje duboko u 1C platformi postoje problemi s kompatibilnošću sa operativnim sistemima i ne-Microsoft DBMS-om. Također je vrijedno postaviti sistem na 64-bitni server ako se planira značajno opterećenje baze podataka.

5. Indeksiranje baze podataka

Interna procedura 1C programa, koja "češlja" sistem iznutra. Postavite ga da radi kao pozadinski zakazani zadatak noću i budite mirni.

6. Onemogućavanje operativnog grupnog obračuna

Činjenica je da se tokom operativne obrade dokumenata kretanja evidentiraju u registrima, uključujući registre partijskog računovodstva. Snimanje registara paketnog knjigovodstva prilikom knjiženja dokumenata može se onemogućiti u postavkama programa. Jednom mjesečno će biti potrebno započeti obradu knjiženja dokumenata po serijama, na primjer, u vrijeme kada je najmanje opterećenje baze ili kada radi najmanje korisnika.

7. RAM

Koristite sljedeću formulu:

RAM = (DB 1+DB 2+DB N) / 100 * 70

Oko 70% ukupnog fizičkog volumena baza podataka. 1C baze vole da dobro jedu sa RAM-om. Ne zaboravi na to.

8. Ako je moguće, optimizirajte samonapisane izvještaje i obradu nesavršenim i zastarjelim kodovima

U toku života kompanije javljaju se potrebe za pisanjem izveštaja i obradom, kao i poboljšanja u upravljanju poslovnim procesima i izdvajanju specifičnih informacija. Samo sva ova poboljšanja mogu biti greška, usporavaju rad, jer. a) neki kulibini bi jednom mogli da zeznu teški netačan kod koji je teško izvršiti programom i koji zahtijeva znatan napor da bi se izvršio b) kod na kojem je napisana obrada ili izvještaj mogao bi postati moralno zastario i zahtijeva reviziju, reprogramiranje. Koristite pravilo - Što manje nešto promijenimo u programu, to bolje.

9. Čišćenje keša

Normalno ponovno pokretanje servera ponekad rješava probleme sa zastarjelim 1C kešom. Samo pokušaj. Isto tako može pomoći i istovar - učitavanje baze podataka kroz konfigurator. I posljednje brisanje keš memorije određenog korisnika je brisanje mapa u 1C sistemskom direktoriju u obliku: kexifzghjuhfv8j33hbdgk0. Ali brisanje korisničkih keširanih foldera je posljednja stvar, jer. osim uklanjanja smeća, brisanje keša ima i neprijatne posledice u vidu brisanja sačuvanih podešavanja izveštaja, interfejsa korisničkog menija.

10. Smanjenje fizičkog volumena baza podataka

Više baze znači više resursa. Naravno. Koristite standardne 1C alate za namotavanje baze. Razmislite o tome, možete iznenada odustati od podataka prije pet godina kako biste povećali produktivnost. A ako su vam i dalje potrebni podaci za posljednjih pet godina, uvijek možete koristiti kopiju baze podataka.

11. Pravilna organizacija arhitekture

Generalno, arhitektura korporativnog informacionog sistema mora biti ispravna. Šta podrazumevamo pod ispravnim sistemom? Uporedivost zadataka koji su dodijeljeni sistemu sa dostupnom opremom i softverom. Planirajte sistem zajedno sa: administratorom sistema (jer poznaje flotu mašina), 1C programerom (jer zna potrebe za resursima 1C) i šefom kompanije (jer zna za budući rast ili smanjenje kompanija).

U posljednje vrijeme korisnici i administratori su se sve više počeli žaliti da su nove 1C konfiguracije razvijene na bazi upravljane aplikacije spore, u nekim slučajevima neprihvatljivo spore. Jasno je da nove konfiguracije sadrže nove funkcije i mogućnosti, te su stoga zahtjevnije za resurse, ali većina korisnika nema razumijevanja šta prvenstveno utječe na rad 1C u načinu rada datoteka. Pokušajmo popraviti ovaj jaz.

U našem smo se već dotakli uticaja performansi diskovnog podsistema na brzinu 1C, međutim, ova studija se ticala lokalne upotrebe aplikacije na zasebnom računaru ili terminal serveru. Istovremeno, većina malih implementacija podrazumeva rad sa bazom datoteka preko mreže, gde se kao server koristi jedan od korisničkih računara, ili namenski fajl server zasnovan na običnom, najčešće i jeftinom računaru.

Mala studija resursa na ruskom jeziku na 1C pokazala je da se ovaj problem marljivo zaobilazi; u slučaju problema, obično se savjetuje da se pređe na klijent-server ili terminalski način. Takođe je postalo gotovo opšte prihvaćeno da konfiguracije na upravljanoj aplikaciji rade mnogo sporije od uobičajenih. U pravilu se argumenti daju "gvozdenim": "ovdje je Računovodstvo 2.0 upravo proletjelo, a "trojka" se jedva kreće, naravno, ima istine u ovim riječima, pa hajde da pokušamo to shvatiti.

Potrošnja resursa na prvi pogled

Prije nego što započnemo ovu studiju, postavili smo si dva cilja: otkriti jesu li upravljane konfiguracije zasnovane na aplikacijama zapravo sporije od konvencionalnih konfiguracija i koji resursi imaju najveći utjecaj na performanse.

Za testiranje smo uzeli dve virtuelne mašine sa Windows Server 2012 R2 i Windows 8.1, respektivno, sa 2 jezgra domaćina Core i5-4670 i 2 GB RAM-a, što odgovara prosečnoj kancelarijskoj mašini. Server je postavljen na RAID 0 niz od dva, a klijent je postavljen na sličan niz diskova opšte namene.

Kao eksperimentalne baze odabrali smo nekoliko konfiguracija Računovodstva 2.0, izdanje 2.0.64.12 , koji je zatim ažuriran na 3.0.38.52 , sve konfiguracije su pokrenute na platformi 8.3.5.1443 .

Prvo što privlači pažnju je povećana veličina informacione baze Trojke, koja je značajno porasla, kao i mnogo veći apetiti za RAM-om:

Već smo spremni da čujemo uobičajeno: "šta su dodali ovom trojcu", ali nemojmo žuriti. Za razliku od korisnika verzija klijent-server, za koje je potreban više ili manje kvalifikovan administrator, korisnici verzija datoteka rijetko razmišljaju o održavanju baze podataka. Takođe, zaposleni u specijalizovanim firmama koje opslužuju (čitaj - ažuriraju) ove baze retko razmišljaju o tome.

U međuvremenu, baza podataka 1C je punopravni DBMS vlastitog formata, koji također zahtijeva održavanje, a za to postoji čak i alat pod nazivom Testiranje i popravljanje infobaze. Možda je ime odigralo okrutnu šalu, što čini se da implicira da je ovo alat za rješavanje problema, ali loša izvedba je također problem, a restrukturiranje i ponovno indeksiranje, zajedno sa kompresijom tablice, dobro su poznati alati za optimizaciju baze podataka svakom RDBMS administratoru. Hajde da proverimo?

Nakon primjene odabranih radnji, baza podataka je dramatično "izgubila težinu", postajući čak i manja od "dvojke", koju također niko nikada nije optimizirao, a potrošnja RAM-a je također blago smanjena.

Nakon toga, nakon učitavanja novih klasifikatora i direktorija, kreiranja indeksa, itd. veličina baze će rasti, generalno, osnove "trojke" su veće od osnova "dvojke". Međutim, to nije važnije, ako se druga verzija zadovoljavala sa 150-200 MB RAM-a, onda je za novo izdanje već potrebno pola gigabajta i tu vrijednost treba uzeti u obzir pri planiranju potrebnih resursa za rad s programom. .

Net

Mrežni propusni opseg je jedan od najvažnijih parametara za mrežne aplikacije, posebno kao 1C u režimu datoteka, koji prenosi značajne količine podataka preko mreže. Većina mreža malih preduzeća izgrađena je na bazi jeftine opreme od 100 Mbps, pa smo započeli testiranje upoređivanjem pokazatelja performansi 1C u mrežama od 100 Mbps i 1 Gbps.

Šta se događa kada pokrenete bazu 1C datoteka preko mreže? Klijent preuzima prilično veliku količinu informacija u privremene mape, posebno ako je ovo prvo "hladno" pokretanje. Na 100 Mbps, očekivano nailazimo na propusni opseg i preuzimanje može potrajati značajno vrijeme, u našem slučaju oko 40 sekundi (cijena podjele grafikona je 4 sekunde).

Drugo pokretanje je brže, jer se dio podataka pohranjuje u keš memoriju i ostaje tamo do ponovnog pokretanja. Prelazak na gigabitnu mrežu može značajno ubrzati učitavanje programa, i "hladnog" i "vrućeg", a promatra se omjer vrijednosti. Stoga smo odlučili rezultat izraziti u relativnim iznosima, uzimajući najveću vrijednost svakog mjerenja kao 100%:

Kao što možete vidjeti iz grafikona, Accounting 2.0 se učitava dvostruko brže pri bilo kojoj brzini mreže, prijelaz sa 100 Mbps na 1 Gbps omogućava vam da ubrzate vrijeme preuzimanja za četiri puta. U ovom režimu nema razlike između optimizovane i neoptimizovane Trojke baze podataka.

Takođe smo proverili uticaj brzine mreže na rad u teškim uslovima, na primer, tokom grupnog ponovnog hostovanja. Rezultat se takođe izražava u relativnim terminima:

Ovdje je već zanimljivije, optimizirana baza "trojke" u mreži od 100 Mbit/s radi istom brzinom kao i "dvojka", a neoptimizirana pokazuje duplo lošiji rezultat. Na gigabitu su omjeri očuvani, neoptimizirana "trojka" je također duplo sporija od "dvojke", a optimizirana zaostaje za trećinu. Također, prijelaz na 1 Gb/s vam omogućava da smanjite vrijeme izvršenja za faktor tri za verziju 2.0 i dva puta za verziju 3.0.

Za procjenu utjecaja brzine mreže na svakodnevni rad koristili smo se mjerenje performansi izvođenjem niza unaprijed definiranih radnji u svakoj bazi podataka.

Zapravo, za svakodnevne zadatke propusnost mreže nije usko grlo, neoptimizirana "trojka" je samo 20% sporija od dvojke, a nakon optimizacije se ispostavi da je otprilike isto brža - utječu prednosti rada u načinu rada tankog klijenta. Prelazak na 1 Gb/s optimiziranoj bazi ne daje nikakve prednosti, a neoptimizirana baza i dvojka počinju raditi brže, pokazujući malu razliku između njih.

Iz provedenih testova postaje jasno da mreža nije usko grlo za nove konfiguracije, a upravljana aplikacija radi čak i brže nego inače. Takođe možete preporučiti prelazak na 1 Gb/s ako su vam teški zadaci i brzina učitavanja baze podataka kritični, u drugim slučajevima, nove konfiguracije vam omogućavaju efikasan rad čak i u sporim mrežama od 100 Mb/s.

Pa zašto 1C usporava? Istražićemo dalje.

Podsistem serverskog diska i SSD

U prethodnom članku smo postigli povećanje performansi 1C postavljanjem baza podataka na SSD. Možda performanse podsistema serverskog diska nisu dovoljne? Izmjerili smo performanse disk servera tokom grupnog rada u dvije baze podataka odjednom i dobili prilično optimističan rezultat.

Uprkos relativno velikom broju ulazno/izlaznih operacija u sekundi (IOPS) - 913, dužina reda čekanja nije prelazila 1,84, što je vrlo dobar rezultat za niz od dva diska. Na osnovu toga možemo pretpostaviti da će ogledalo sa običnih diskova biti dovoljno za normalan rad 8-10 mrežnih klijenata u teškim režimima.

Dakle, da li je SSD potreban na serveru? Najbolji odgovor na ovo pitanje pomoći će testiranje, koje smo proveli po sličnoj metodologiji, mrežna veza je svuda 1 Gb/s, rezultat je također izražen u relativnim vrijednostima.

Počnimo sa brzinom učitavanja baze podataka.

Nekome to može izgledati iznenađujuće, ali SSD baza na serveru ne utiče na brzinu preuzimanja baze podataka. Glavni ograničavajući faktor ovdje, kao što je pokazao prethodni test, je mrežna propusnost i performanse klijenta.

Pređimo na ponovno ožičenje:

Već smo napomenuli da su performanse diska sasvim dovoljne čak i za teške uslove rada, tako da brzina SSD-a također nije pogođena, osim neoptimizirane baze koja je sustigla optimizovanu na SSD-u. Zapravo, ovo još jednom potvrđuje da operacije optimizacije organizuju informacije u bazi podataka, smanjujući broj nasumičnih I/O operacija i povećavajući brzinu pristupa njoj.

Kod svakodnevnih zadataka slika je slična:

Samo neoptimizirana baza ima prednost od SSD-a. Naravno, možete kupiti SSD, ali bi bilo mnogo bolje razmisliti o blagovremenom održavanju baza. Također, ne zaboravite defragmentirati particiju baze podataka na serveru.

Podsistem klijentskog diska i SSD

Analizirali smo uticaj SSD-a na brzinu lokalno instaliranog 1C u , mnogo od rečenog važi i za rad u mrežnom režimu. Doista, 1C prilično aktivno koristi resurse diska, uključujući pozadinske i zakazane zadatke. Na slici ispod možete vidjeti kako Accounting 3.0 prilično aktivno pristupa disku oko 40 sekundi nakon učitavanja.

Ali u isto vrijeme treba biti svjestan da su za radnu stanicu na kojoj se aktivan rad obavlja s jednom ili dvije informacijske baze, resursi performansi konvencionalnog HDD-a masovne serije sasvim dovoljni. Kupovina SSD-a može ubrzati neke procese, ali nećete primijetiti radikalno ubrzanje u svakodnevnom radu, jer će, na primjer, preuzimanje biti ograničeno propusnošću mreže.

Spor čvrsti disk može usporiti neke operacije, ali sam po sebi ne može uzrokovati usporavanje programa.

RAM

Unatoč činjenici da je RAM sada nepristojno jeftin, mnoge radne stanice nastavljaju raditi s količinom memorije koja je instalirana kada su kupljene. Tu čekaju prvi problemi. Na osnovu činjenice da je prosječnoj "trojci" potrebno oko 500 MB memorije, možemo pretpostaviti da ukupna količina RAM-a od 1 GB za rad s programom neće biti dovoljna.

Smanjili smo sistemsku memoriju na 1 GB i pokrenuli dvije infobaze.

Na prvi pogled nije sve tako loše, program je ublažio apetite i potpuno se zadržao u okviru raspoložive memorije, ali ne zaboravimo da se potreba za operativnim podacima nije promijenila, pa gdje su oni otišli? Prebacivanje na disk, keš memoriju, swap itd., suština ove operacije je da se podaci koji trenutno nisu potrebni šalju iz brzog RAM-a, čija količina nije dovoljna, na spori disk.

Gdje to vodi? Pogledajmo kako se sistemski resursi koriste u teškim operacijama, na primjer, počnimo ponovno pokretanje grupe u dvije baze podataka odjednom. Prvo na sistemu sa 2 GB RAM-a:

Kao što vidite, sistem aktivno koristi mrežu za primanje podataka i procesor za njihovu obradu, aktivnost diska je beznačajna, u procesu obrade povremeno raste, ali nije ograničavajući faktor.

Sada smanjimo memoriju na 1 GB:

Situacija se radikalno mijenja, glavno opterećenje sada pada na hard disk, procesor i mreža miruju i čekaju da sistem pročita potrebne podatke sa diska u memoriju i tamo pošalje nepotrebne podatke.

U isto vrijeme, čak i subjektivni rad s dvije otvorene baze podataka na sistemu sa 1 GB memorije pokazao se krajnje neugodnim, direktoriji i časopisi su se otvarali sa značajnim kašnjenjem i aktivnim pristupom disku. Na primjer, otvaranje časopisa Prodaja roba i usluga trajalo je oko 20 sekundi i sve to vrijeme je bilo praćeno velikom aktivnošću diska (označeno crvenom linijom).

Da bismo objektivno procenili uticaj RAM-a na performanse konfiguracija zasnovanih na upravljanoj aplikaciji, izvršili smo tri merenja: brzinu učitavanja prve baze, brzinu učitavanja druge baze i grupno repostovanje u jednoj od baza. Obje baze su potpuno identične i stvorene su kopiranjem optimizirane baze. Rezultat se izražava u relativnim jedinicama.

Rezultat govori sam za sebe, ako vrijeme učitavanja naraste za oko trećinu, što je još uvijek prilično podnošljivo, onda vrijeme za obavljanje operacija u bazi podataka raste tri puta, o nekom udobnom radu u takvim uvjetima ne treba ni govoriti. Inače, to je slučaj kada kupovina SSD-a može poboljšati situaciju, ali je mnogo lakše (i jeftinije) riješiti se uzroka, a ne posljedica, i samo kupiti pravu količinu RAM-a.

Nedostatak RAM-a je glavni razlog zašto je rad s novim 1C konfiguracijama neugodan. Treba razmotriti minimalne prikladne konfiguracije sa 2 GB memorije na ploči. Istovremeno, imajte na umu da su u našem slučaju stvoreni "staklenički" uslovi: čist sistem, pokrenut je samo 1C i upravitelj zadataka. U stvarnom životu, pretraživač, kancelarijski paket, antivirus itd. su obično otvoreni na radnom računaru, pa polazite od potrebe za 500 MB po bazi podataka plus nešto margine kako tokom teških operacija ne biste naišli na nedostatak memorije i drastične degradacije performansi.

CPU

Centralna procesorska jedinica, bez preterivanja, može se nazvati srcem računara, jer je on taj koji na kraju obrađuje sve proračune. Da bismo procijenili njegovu ulogu, izvršili smo još jedan set testova, isti kao i za RAM, smanjivši broj jezgara dostupnih virtuelnoj mašini sa dva na jedno, dok je test izveden dva puta sa veličinama memorije od 1 GB i 2 GB.

Rezultat se pokazao prilično zanimljivim i neočekivanim, moćniji procesor je prilično efektivno preuzeo opterećenje suočenim s nedostatkom resursa, inače bez ikakvih opipljivih koristi. 1C Enterprise (u načinu rada datoteke) teško se može nazvati aplikacijom koja aktivno koristi resurse procesora, prilično nezahtjevna. A u teškim uslovima, procesor je opterećen ne toliko izračunavanjem podataka same aplikacije, koliko servisiranjem režijskih troškova: dodatnim I/O operacijama itd.

zaključci

Dakle, zašto 1C usporava? Prije svega, ovo je nedostatak RAM-a, glavno opterećenje u ovom slučaju pada na tvrdi disk i procesor. A ako ne blistaju performansama, kao što to obično biva u uredskim konfiguracijama, onda dobijamo situaciju opisanu na početku članka - "dvojka" je dobro radila, a "trojka" besramno usporava.

Drugo mjesto treba dati mrežnim performansama, spori kanal od 100 Mbps može postati pravo usko grlo, ali u isto vrijeme, način rada tankog klijenta može održati prilično udoban nivo rada čak i na sporim kanalima.

Onda treba obratiti pažnju na diskovni, kupovina SSD-a vjerojatno neće biti dobra investicija, ali zamjena diska modernijim neće biti suvišna. Razlika između generacija tvrdih diskova može se procijeniti iz sljedećeg materijala: .

I na kraju procesor. Brži model, naravno, neće biti suvišan, ali nema smisla povećavati njegove performanse, osim ako se ovaj PC ne koristi za teške operacije: grupna obrada, teški izvještaji, zatvaranje mjeseca itd.

Nadamo se da će vam ovaj materijal pomoći da brzo shvatite pitanje "zašto 1C usporava" i riješite ga najefikasnije i bez dodatnih troškova.

• Tagovi:

Molimo omogućite JavaScript da vidite

Često dobijamo pitanja o tome šta usporava 1s, posebno kada prelazimo na verziju 1s 8.3, zahvaljujući našim kolegama iz Interface LLC-a, detaljno kažemo:

U našim prethodnim publikacijama već smo se dotakli uticaja performansi diskovnog podsistema na brzinu 1C, međutim, ova studija se ticala lokalne upotrebe aplikacije na zasebnom računaru ili terminal serveru. Istovremeno, većina malih implementacija podrazumeva rad sa bazom datoteka preko mreže, gde se kao server koristi jedan od korisničkih računara, ili namenski fajl server zasnovan na običnom, najčešće i jeftinom računaru.

Mala studija resursa na ruskom jeziku na 1C pokazala je da se ovaj problem marljivo zaobilazi; u slučaju problema, obično se savjetuje da se pređe na klijent-server ili terminalski način. Takođe je postalo gotovo opšte prihvaćeno da konfiguracije na upravljanoj aplikaciji rade mnogo sporije od uobičajenih. U pravilu se argumenti daju "gvozdenim": "ovdje je Računovodstvo 2.0 upravo proletjelo, a "trojka" se jedva kreće", naravno, ima istine u ovim riječima, pa hajde da pokušamo to shvatiti.

Potrošnja resursa na prvi pogled

Prije nego što započnemo ovu studiju, postavili smo si dva cilja: otkriti jesu li upravljane konfiguracije zasnovane na aplikacijama zapravo sporije od konvencionalnih konfiguracija i koji resursi imaju najveći utjecaj na performanse.

Za testiranje smo uzeli dve virtuelne mašine sa Windows Server 2012 R2 i Windows 8.1, respektivno, sa 2 jezgra domaćina Core i5-4670 i 2 GB RAM-a, što odgovara prosečnoj kancelarijskoj mašini. Server je postavljen na RAID 0 niz od dva WD Se, a klijent je postavljen na sličan niz diskova opšte namene.

Kao eksperimentalne baze odabrali smo nekoliko konfiguracija Računovodstva 2.0, izdanje 2.0.64.12 , koji je zatim ažuriran na 3.0.38.52 , sve konfiguracije su pokrenute na platformi 8.3.5.1443 .

Prvo što privlači pažnju je povećana veličina informacione baze Trojke, koja je značajno porasla, kao i mnogo veći apetiti za RAM-om:

Već smo spremni da čujemo uobičajeno: "šta su dodali ovom trojcu", ali nemojmo žuriti. Za razliku od korisnika verzija klijent-server, za koje je potreban više ili manje kvalifikovan administrator, korisnici verzija datoteka rijetko razmišljaju o održavanju baze podataka. Takođe, zaposleni u specijalizovanim firmama koje opslužuju (čitaj - ažuriraju) ove baze retko razmišljaju o tome.

U međuvremenu, baza podataka 1C je punopravni DBMS vlastitog formata, koji također zahtijeva održavanje, a za to postoji čak i alat pod nazivom Testiranje i popravljanje infobaze. Možda je ime odigralo okrutnu šalu, što čini se da implicira da je ovo alat za rješavanje problema, ali loša izvedba je također problem, a restrukturiranje i ponovno indeksiranje, zajedno sa kompresijom tablice, dobro su poznati alati za optimizaciju baze podataka svakom RDBMS administratoru. Hajde da proverimo?

Nakon primjene odabranih radnji, baza podataka je dramatično "izgubila težinu", postajući čak i manja od "dvojke", koju također niko nikada nije optimizirao, a potrošnja RAM-a je također blago smanjena.

Nakon toga, nakon učitavanja novih klasifikatora i direktorija, kreiranja indeksa, itd. veličina baze će rasti, generalno, osnove "trojke" su veće od osnova "dvojke". Međutim, to nije važnije, ako se druga verzija zadovoljavala sa 150-200 MB RAM-a, onda je za novo izdanje već potrebno pola gigabajta i tu vrijednost treba uzeti u obzir pri planiranju potrebnih resursa za rad s programom. .

Net

Mrežni propusni opseg je jedan od najvažnijih parametara za mrežne aplikacije, posebno kao 1C u režimu datoteka, koji prenosi značajne količine podataka preko mreže. Većina mreža malih preduzeća izgrađena je na bazi jeftine opreme od 100 Mbps, pa smo započeli testiranje upoređivanjem pokazatelja performansi 1C u mrežama od 100 Mbps i 1 Gbps.

Šta se događa kada pokrenete bazu 1C datoteka preko mreže? Klijent preuzima prilično veliku količinu informacija u privremene mape, posebno ako je ovo prvo "hladno" pokretanje. Na 100 Mbps, očekivano nailazimo na propusni opseg i preuzimanje može potrajati značajno vrijeme, u našem slučaju oko 40 sekundi (cijena podjele grafikona je 4 sekunde).

Drugo pokretanje je brže, jer se dio podataka pohranjuje u keš memoriju i ostaje tamo do ponovnog pokretanja. Prelazak na gigabitnu mrežu može značajno ubrzati učitavanje programa, i "hladnog" i "vrućeg", a promatra se omjer vrijednosti. Stoga smo odlučili rezultat izraziti u relativnim iznosima, uzimajući najveću vrijednost svakog mjerenja kao 100%:

Kao što možete vidjeti iz grafikona, Accounting 2.0 se učitava dvostruko brže pri bilo kojoj brzini mreže, prijelaz sa 100 Mbps na 1 Gbps omogućava vam da ubrzate vrijeme preuzimanja za četiri puta. U ovom režimu nema razlike između optimizovane i neoptimizovane Trojke baze podataka.

Takođe smo proverili uticaj brzine mreže na rad u teškim uslovima, na primer, tokom grupnog ponovnog hostovanja. Rezultat se takođe izražava u relativnim terminima:

Ovdje je već zanimljivije, optimizirana baza "trojke" u mreži od 100 Mbit/s radi istom brzinom kao i "dvojka", a neoptimizirana pokazuje duplo lošiji rezultat. Na gigabitu su omjeri očuvani, neoptimizirana "trojka" je također duplo sporija od "dvojke", a optimizirana zaostaje za trećinu. Također, prijelaz na 1 Gb/s vam omogućava da smanjite vrijeme izvršenja za faktor tri za verziju 2.0 i dva puta za verziju 3.0.

Za procjenu utjecaja brzine mreže na svakodnevni rad koristili smo se mjerenje performansi izvođenjem niza unaprijed definiranih radnji u svakoj bazi podataka.

Zapravo, za svakodnevne zadatke propusnost mreže nije usko grlo, neoptimizirana "trojka" je samo 20% sporija od dvojke, a nakon optimizacije se ispostavi da je otprilike isto brža - utječu prednosti rada u načinu rada tankog klijenta. Prelazak na 1 Gb/s optimiziranoj bazi ne daje nikakve prednosti, a neoptimizirana baza i dvojka počinju raditi brže, pokazujući malu razliku između njih.

Iz provedenih testova postaje jasno da mreža nije usko grlo za nove konfiguracije, a upravljana aplikacija radi čak i brže nego inače. Takođe možete preporučiti prelazak na 1 Gb/s ako su vam teški zadaci i brzina učitavanja baze podataka kritični, u drugim slučajevima, nove konfiguracije vam omogućavaju efikasan rad čak i u sporim mrežama od 100 Mb/s.

Pa zašto 1C usporava? Istražićemo dalje.

Podsistem serverskog diska i SSD

U prethodnom članku smo postigli povećanje performansi 1C postavljanjem baza podataka na SSD. Možda performanse podsistema serverskog diska nisu dovoljne? Izmjerili smo performanse disk servera tokom grupnog rada u dvije baze podataka odjednom i dobili prilično optimističan rezultat.

Uprkos relativno velikom broju ulazno/izlaznih operacija u sekundi (IOPS) - 913, dužina reda čekanja nije prelazila 1,84, što je vrlo dobar rezultat za niz od dva diska. Na osnovu toga možemo pretpostaviti da će ogledalo sa običnih diskova biti dovoljno za normalan rad 8-10 mrežnih klijenata u teškim režimima.

Dakle, da li je SSD potreban na serveru? Najbolji odgovor na ovo pitanje pomoći će testiranje, koje smo proveli po sličnoj metodologiji, mrežna veza je svuda 1 Gb/s, rezultat je također izražen u relativnim vrijednostima.

Počnimo sa brzinom učitavanja baze podataka.

Nekome to može izgledati iznenađujuće, ali SSD baza na serveru ne utiče na brzinu preuzimanja baze podataka. Glavni ograničavajući faktor ovdje, kao što je pokazao prethodni test, je mrežna propusnost i performanse klijenta.

Pređimo na ponovno ožičenje:

Već smo napomenuli da su performanse diska sasvim dovoljne čak i za teške uslove rada, tako da brzina SSD-a također nije pogođena, osim neoptimizirane baze koja je sustigla optimizovanu na SSD-u. Zapravo, ovo još jednom potvrđuje da operacije optimizacije organizuju informacije u bazi podataka, smanjujući broj nasumičnih I/O operacija i povećavajući brzinu pristupa njoj.

Kod svakodnevnih zadataka slika je slična:

Samo neoptimizirana baza ima prednost od SSD-a. Naravno, možete kupiti SSD, ali bi bilo mnogo bolje razmisliti o blagovremenom održavanju baza. Također, ne zaboravite defragmentirati particiju baze podataka na serveru.

Podsistem klijentskog diska i SSD

Uticaj SSD-a na brzinu lokalno instaliranog 1C analizirali smo u prethodnom članku, mnogo toga što je rečeno važi i za rad u mrežnom režimu. Doista, 1C prilično aktivno koristi resurse diska, uključujući pozadinske i zakazane zadatke. Na slici ispod možete vidjeti kako Accounting 3.0 prilično aktivno pristupa disku oko 40 sekundi nakon učitavanja.

Ali u isto vrijeme treba biti svjestan da su za radnu stanicu na kojoj se aktivan rad obavlja s jednom ili dvije informacijske baze, resursi performansi konvencionalnog HDD-a masovne serije sasvim dovoljni. Kupovina SSD-a može ubrzati neke procese, ali nećete primijetiti radikalno ubrzanje u svakodnevnom radu, jer će, na primjer, preuzimanje biti ograničeno propusnošću mreže.

Spor čvrsti disk može usporiti neke operacije, ali sam po sebi ne može uzrokovati usporavanje programa.

RAM

Unatoč činjenici da je RAM sada nepristojno jeftin, mnoge radne stanice nastavljaju raditi s količinom memorije koja je instalirana kada su kupljene. Tu čekaju prvi problemi. Na osnovu činjenice da je prosječnoj "trojci" potrebno oko 500 MB memorije, možemo pretpostaviti da ukupna količina RAM-a od 1 GB za rad s programom neće biti dovoljna.

Smanjili smo sistemsku memoriju na 1 GB i pokrenuli dvije infobaze.

Na prvi pogled nije sve tako loše, program je ublažio apetite i potpuno se zadržao u okviru raspoložive memorije, ali ne zaboravimo da se potreba za operativnim podacima nije promijenila, pa gdje su oni otišli? Prebacivanje na disk, keš memoriju, swap itd., suština ove operacije je da se podaci koji trenutno nisu potrebni šalju iz brzog RAM-a, čija količina nije dovoljna, na spori disk.

Gdje to vodi? Pogledajmo kako se sistemski resursi koriste u teškim operacijama, na primjer, počnimo ponovno pokretanje grupe u dvije baze podataka odjednom. Prvo na sistemu sa 2 GB RAM-a:

Kao što vidite, sistem aktivno koristi mrežu za primanje podataka i procesor za njihovu obradu, aktivnost diska je beznačajna, u procesu obrade povremeno raste, ali nije ograničavajući faktor.

Sada smanjimo memoriju na 1 GB:

Situacija se radikalno mijenja, glavno opterećenje sada pada na hard disk, procesor i mreža miruju i čekaju da sistem pročita potrebne podatke sa diska u memoriju i tamo pošalje nepotrebne podatke.

U isto vrijeme, čak i subjektivni rad s dvije otvorene baze podataka na sistemu sa 1 GB memorije pokazao se krajnje neugodnim, direktoriji i časopisi su se otvarali sa značajnim kašnjenjem i aktivnim pristupom disku. Na primjer, otvaranje časopisa Prodaja roba i usluga trajalo je oko 20 sekundi i sve to vrijeme je bilo praćeno velikom aktivnošću diska (označeno crvenom linijom).

Da bismo objektivno procenili uticaj RAM-a na performanse konfiguracija zasnovanih na upravljanoj aplikaciji, izvršili smo tri merenja: brzinu učitavanja prve baze, brzinu učitavanja druge baze i grupno repostovanje u jednoj od baza. Obje baze su potpuno identične i stvorene su kopiranjem optimizirane baze. Rezultat se izražava u relativnim jedinicama.

Rezultat govori sam za sebe, ako vrijeme učitavanja naraste za oko trećinu, što je još uvijek prilično podnošljivo, onda vrijeme za obavljanje operacija u bazi podataka raste tri puta, o nekom udobnom radu u takvim uvjetima ne treba ni govoriti. Inače, to je slučaj kada kupovina SSD-a može poboljšati situaciju, ali je mnogo lakše (i jeftinije) riješiti se uzroka, a ne posljedica, i samo kupiti pravu količinu RAM-a.

Nedostatak RAM-a je glavni razlog zašto je rad s novim 1C konfiguracijama neugodan. Treba razmotriti minimalne prikladne konfiguracije sa 2 GB memorije na ploči. Istovremeno, imajte na umu da su u našem slučaju stvoreni "staklenički" uslovi: čist sistem, pokrenut je samo 1C i upravitelj zadataka. U stvarnom životu, pretraživač, kancelarijski paket, antivirus itd. su obično otvoreni na radnom računaru, pa polazite od potrebe za 500 MB po bazi podataka plus nešto margine kako tokom teških operacija ne biste naišli na nedostatak memorije i drastične degradacije performansi.

CPU

Centralna procesorska jedinica, bez preterivanja, može se nazvati srcem računara, jer je on taj koji na kraju obrađuje sve proračune. Da bismo procijenili njegovu ulogu, izvršili smo još jedan set testova, isti kao i za RAM, smanjivši broj jezgara dostupnih virtuelnoj mašini sa dva na jedno, dok je test izveden dva puta sa veličinama memorije od 1 GB i 2 GB.

Rezultat se pokazao prilično zanimljivim i neočekivanim, moćniji procesor je prilično efektivno preuzeo opterećenje suočenim s nedostatkom resursa, inače bez ikakvih opipljivih koristi. 1C Enterprise se teško može nazvati aplikacijom koja aktivno koristi resurse procesora, prilično nezahtjevna. A u teškim uslovima, procesor je opterećen ne toliko izračunavanjem podataka same aplikacije, koliko servisiranjem režijskih troškova: dodatnim I/O operacijama itd.

zaključci

Dakle, zašto 1C usporava? Prije svega, ovo je nedostatak RAM-a, glavno opterećenje u ovom slučaju pada na tvrdi disk i procesor. A ako ne blistaju performansama, kao što to obično biva u uredskim konfiguracijama, onda dobijamo situaciju opisanu na početku članka - "dvojka" je dobro radila, a "trojka" besramno usporava.

Drugo mjesto treba dati mrežnim performansama, spori kanal od 100 Mbps može postati pravo usko grlo, ali u isto vrijeme, način rada tankog klijenta može održati prilično udoban nivo rada čak i na sporim kanalima.

Onda treba obratiti pažnju na diskovni, kupovina SSD-a vjerojatno neće biti dobra investicija, ali zamjena diska modernijim neće biti suvišna. Razlika između generacija tvrdih diskova može se procijeniti iz sljedećeg materijala: Pregled dvije jeftine Western Digital Blue serije pogona od 500 GB i 1 TB.

I na kraju procesor. Brži model, naravno, neće biti suvišan, ali nema smisla povećavati njegove performanse, osim ako se ovaj PC ne koristi za teške operacije: grupna obrada, teški izvještaji, zatvaranje mjeseca itd.

Nadamo se da će vam ovaj materijal pomoći da brzo shvatite pitanje "zašto 1C usporava" i riješite ga najefikasnije i bez dodatnih troškova.

Glavna svrha pisanja članka nije ponoviti očigledne nijanse onim administratorima (i programerima) koji još nisu stekli iskustvo s 1C.

Sporedan cilj, ako imam neke nedostatke, Infostart će mi to najbrže ukazati.

Test V. Gileva je već postao svojevrsni "de facto" standard. Autor na svojoj web stranici dao je sasvim razumljive preporuke, ali ja ću jednostavno dati neke rezultate i komentirati najvjerovatnije greške. Naravno, rezultati testova na vašoj opremi mogu se razlikovati, ovo je samo smjernica, šta bi trebalo biti i čemu možete težiti. Odmah želim da napomenem da se promjene moraju vršiti korak po korak, a nakon svakog koraka provjeriti kakav je rezultat dao.

Na Infostartu postoje slični članci, u relevantne rubrike ću staviti linkove na njih (ako nešto propustim, recite mi u komentarima, dodaću). Dakle, pretpostavimo da usporite 1C. Kako dijagnosticirati problem i kako razumjeti ko je kriv, administrator ili programer?

Početni podaci:

Testirano računalo, glavni zamorac: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Za poređenje, Core i3-2100 pokazuje uporedive rezultate u jednonitnom testu. Oprema je posebno uzeta ne najnovija, na modernoj opremi rezultati su osjetno bolji.

Za testiranje udaljenih 1C i SQL servera, SQL server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Za testiranje 10 Gbit mreže korišteni su Intel 520-DA2 adapteri.

Verzija fajla. (baza leži na serveru u deljenom folderu, klijenti su povezani na mrežu, CIFS/SMB protokol). Korak po korak algoritam:

0. Dodajte Gilev test bazu podataka na server datoteka u isti folder kao i glavne baze podataka. Povezujemo se sa klijentskog računara, pokrećemo test. Sjećamo se rezultata.

Podrazumijeva se da čak i za stare računare prije 10 godina (Pentium na 775 socket ) vrijeme od klika na oznaku 1C:Enterprise do pojave prozora baze podataka trebalo bi biti manje od jedne minute. ( Celeron = spor rad).

Ako je vaš računar lošiji od uključenog Pentiuma 775 socket sa 1 GB RAM-a, onda suosjećam s vama i bit će vam teško postići ugodan rad na 1C 8.2 u verziji datoteke. Razmislite o nadogradnji (dugo zakašnjelo) ili prelasku na terminal (ili web, u slučaju tankih klijenata i upravljanih obrazaca) server.

Ako računar nije lošiji, onda možete izbaciti administratora. U najmanju ruku provjerite rad mrežnog, antivirusnog i HASP zaštitnog drajvera.

Ako je Gilevov test u ovoj fazi pokazao 30 "papagaja" i više, ali radna baza 1C i dalje radi sporo - pitanja su već za programera.

1. Za smjernicu koliko klijentski računar može "iscijediti", provjeravamo rad samo ovog računara, bez mreže. Testnu bazu stavljamo na lokalni računar (na veoma brz disk). Ako klijentski računar nema normalan SSD, tada se kreira ramdisk. Do sada, najjednostavniji i besplatni je Ramdisk enterprise.

Za testiranje verzije 8.2 dovoljno je 256 MB ramdiska, i! Najvažniji. Nakon ponovnog pokretanja računara sa ispravnim ramdiskom, trebalo bi da ima 100-200 MB slobodnog. U skladu s tim, bez ramdisk-a, za normalan rad slobodne memorije treba biti 300-400 MB.

Za testiranje verzije 8.3 dovoljan je 256 MB ramdisk, ali je potrebno više slobodnog RAM-a.

Prilikom testiranja morate pogledati opterećenje procesora. U slučaju blizu idealnom (ramdisk), lokalni fajl 1c učitava 1 jezgro procesora tokom rada. Shodno tome, ako tokom testiranja jezgro vašeg procesora nije u potpunosti učitano, potražite slabosti. Malo emocionalno, ali općenito korektno, opisan je utjecaj procesora na rad 1C. Samo za referencu, čak i na modernom Core i3 sa visokom frekvencijom, brojke 70-80 su sasvim stvarne.

Najčešće greške u ovoj fazi.

a) Neispravno konfigurisan antivirus. Postoji mnogo antivirusa, podešavanja za svaki su različita, mogu samo reći da se uz pravilnu konfiguraciju ni web ni Kaspersky 1C ne miješaju. Uz "podrazumevane" postavke - oko 3-5 papagaja (10-15%) može se oduzeti.

b) Način rada. Iz nekog razloga malo ljudi obraća pažnju na to, a učinak je najznačajniji. Ako vam je potrebna brzina, onda to morate učiniti, kako na klijentskim tako i na serverskim računarima. (Gilev ima dobar opis. Jedino upozorenje je da na nekim matičnim pločama, ako je Intel SpeedStep isključen, TurboBoost se ne može uključiti).

Ukratko, tokom rada 1C dosta se čeka na odgovor od drugih uređaja (disk, mreža, itd.). Dok se čeka odgovor, ako je način rada izbalansiran, procesor smanjuje svoju frekvenciju. Odgovor dolazi sa uređaja, 1C (procesor) treba da radi, ali prvi ciklusi idu smanjenom frekvencijom, zatim frekvencija raste - i 1C ponovo čeka odgovor uređaja. I tako - stotine puta u sekundi.

Možete (i po mogućnosti) omogućiti način rada na dva mjesta:

Preko BIOS-a. Onemogućite režime C1, C1E, Intel C-state (C2, C3, C4). U različitim biosovima nazivaju se različito, ali značenje je isto. Tražite dugo, potrebno je ponovno pokretanje, ali ako ste to učinili jednom, možete zaboraviti. Ako je sve ispravno urađeno u BIOS-u, tada će se dodati brzina. Na nekim matičnim pločama, BIOS postavke se mogu podesiti tako da način rada Windowsa neće igrati ulogu. (Primeri podešavanja BIOS-a od strane Gilev). Ove postavke se uglavnom odnose na serverske procesore ili "napredni" BIOS, ako ga niste pronašli u svom sistemu, a nemate Xeon - u redu je.

Kontrolna tabla - Snaga - Visoke performanse. Minus - ako računar nije dugo servisiran, jače će zujati sa ventilatorom, više će se zagrijavati i trošiti više energije. Ovo je cijena performansi.

Kako provjeriti da li je režim uključen. Pokrenite Task Manager - Performanse - Monitor resursa - CPU. Čekamo dok procesor ne bude zauzet ničim.

Ovo su podrazumevane postavke. BIOS C-stanje uključeno, uravnoteženi režim napajanja
BIOS C-stanje uključeno, režim visokih performansi Za Pentium i Core, možete stati na tome, još uvijek možete istisnuti neke "papagaje" iz Xeona
BIOS C-stanje isključeno, režim visokih performansi. Ako ne koristite Turbo boost - ovako bi trebalo izgledati server podešen za performanse

A sada brojke. Da vas podsetim: Intel Xeon 5650, ramdisk. U prvom slučaju, test pokazuje 23,26, u drugom - 49,5. Razlika je skoro dvostruka. Brojevi se mogu razlikovati, ali omjer ostaje prilično isti za Intel Core.

Dragi administratori, možete grditi 1C kako želite, ali ako krajnjim korisnicima treba brzina, morate omogućiti način rada visokih performansi.

c) Turbo Boost. Prvo morate razumjeti podržava li vaš procesor ovu funkciju, na primjer. Ako je tako, onda još uvijek sasvim legalno možete postići neke performanse. (Ne želim se doticati pitanja overkloka, posebno servera, radite to na vlastitu odgovornost i rizik. Ali slažem se da povećanje brzine sabirnice sa 133 na 166 daje vrlo primjetno povećanje i brzine i rasipanje topline)

Napisano je, na primjer, kako uključiti turbo boost. Ali! Za 1C postoje neke nijanse (ne najočitije). Poteškoća je u tome što se maksimalni efekat turbo boost-a manifestuje kada je C-stanje uključeno. I ispada nešto poput ove slike:

Imajte na umu da je množitelj maksimalni, brzina jezgre je najljepša, performanse su visoke. Ali šta će se dogoditi kao rezultat 1s?

	Faktor	Brzina jezgre (frekvencija), GHz	CPU-Z Single Thread	Gilev Ramdisk test verzija datoteke	Gilev Ramdisk test klijent-server
bez turbo pojačanja
C-stanje isključeno, turbo pojačanje				53.19	40,32
C-stanje uključeno, turbo pojačanje			1080	53,13	23,04

Ali na kraju se ispostavi da je prema CPU testovima performansi varijanta sa množiteljem 23 ispred, prema Gilevovim testovima u verziji fajla, performanse sa množiteljem 22 i 23 su iste, ali u klijent-server verzija, varijanta sa multiplikatorom od 23 horor horror (čak i ako je C -state postavljeno na nivo 7, i dalje je sporije nego sa isključenim C-state). Stoga, preporuka, sami provjerite obje opcije, i od njih odaberite najbolju. U svakom slučaju, razlika između 49,5 i 53 papagaja je prilično značajna, pogotovo što je bez mnogo truda.

Zaključak - turbo pojačanje mora biti uključeno. Da vas podsjetim da nije dovoljno omogućiti Turbo boost stavku u BIOS-u, potrebno je pogledati i druga podešavanja (BIOS: QPI L0s, L1 - onemogućiti, zahtijevati pročišćavanje - onemogućiti, Intel SpeedStep - omogućiti, Turbo boost - Upravljačka ploča - Napajanje - Visoke performanse) . I dalje bih se (čak i za verziju datoteke) zaustavio na opciji gdje je c-stanje isključeno, iako je množitelj manji. Nabavite ovako nešto...

Prilično kontroverzna tačka je memorijska frekvencija. Na primjer, frekvencija memorije je prikazana kao vrlo utjecajna. Moji testovi nisu otkrili takvu zavisnost. Neću porediti DDR 2/3/4, pokazaću rezultate promene frekvencije unutar iste linije. Memorija je ista, ali u BIOS-u forsiramo niže frekvencije.

I rezultate testova. 1C 8.2.19.83, za verziju datoteke lokalni ramdisk, za klijent-server 1C i SQL na jednom računaru, Zajednička memorija. Turbo pojačanje je onemogućeno u obje opcije. 8.3 pokazuje uporedive rezultate.

Razlika je unutar greške mjerenja. Posebno sam izvukao CPU-Z snimke ekrana da pokažem da se drugi parametri mijenjaju s promjenom frekvencije, ista CAS Latency i RAS do CAS Delay, što izravnava promjenu frekvencije. Razlika će biti kada se memorijski moduli fizički mijenjaju, iz sporijeg u brži, ali čak ni tu brojke nisu bitne.

2. Kada smo shvatili procesor i memoriju klijentskog računara, prelazimo na sledeće veoma važno mesto - mrežu. Mnogo je knjiga napisano o podešavanju mreže, postoje članci o Infostartu (, i drugi), ovdje se neću fokusirati na ovu temu. Prije početka testiranja 1C provjerite da li iperf između dva računara pokazuje cijeli opseg (za kartice od 1 Gbit - dobro, najmanje 850 Mbit, ali bolje 950-980), da se Gilev savjet poštuje. Zatim - najjednostavniji test rada bit će, začudo, kopiranje jedne velike datoteke (5-10 gigabajta) preko mreže. Indirektni znak normalnog rada na mreži od 1 Gbps bit će prosječna brzina kopiranja od 100 Mb / s, dobar rad - 120 Mb / s. Želim da vam skrenem pažnju na činjenicu da opterećenje procesora takođe može biti slaba tačka (uključujući). SMB Protokol na Linuxu je prilično slabo paraleliziran, a tokom rada može prilično lako „pojesti“ jedno jezgro procesora i više ga ne trošiti.

I dalje. Sa zadanim postavkama, windows klijent najbolje radi sa windows serverom (ili čak i sa radnom stanicom) i SMB / CIFS protokolom, linux klijent (debian, ubuntu nije pogledao ostalo) najbolje radi sa linuxom i NFS (također radi sa SMB, ali na NFS papagajima iznad). Činjenica da se pri linearnom kopiranju win-linux servera na nfs brže kopira u jedan stream, ništa ne znači. Podešavanje debiana za 1C je tema za poseban članak, nisam još spreman za to, iako mogu reći da sam u verziji datoteke čak imao malo bolje performanse od Win verzije na istoj opremi, ali sa postgresom sa korisnici stariji od 50 i dalje imam sve jako loše.

Najvažniji , što je poznato po "spaljenim" administratorima, ali početnici ne uzimaju u obzir. Postoji mnogo načina za postavljanje putanje do 1c baze podataka. Možete učiniti \\server\share, možete \\192.168.0.1\share, možete mrežno koristiti z: \\192.168.0.1\share (i u nekim slučajevima će ovaj metod također raditi, ali ne uvijek) i zatim navedite pogon Z. Čini se da svi ovi putevi upućuju na isto mjesto, ali za 1C postoji samo jedan način koji daje prilično stabilne performanse. Dakle, evo šta treba da uradite kako treba:

Na komandnoj liniji (ili u politikama, ili kako god vama odgovara) - koristite net DriveLetter: \\server\share. primjer: net use m:\\server\bases. Posebno naglašavam NE IP adresu, naime Ime server. Ako server nije vidljiv po imenu, dodajte ga u dns na serveru ili lokalno u hosts datoteku. Ali žalba mora biti po imenu. Shodno tome, na putu do baze podataka pristupite ovom disku (pogledajte sliku).

A sada ću u brojkama pokazati zašto su takvi savjeti. Početni podaci: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kartice. OS Win 2008 R2, Win 7, Debian 8. Najnoviji drajveri, primijenjena ažuriranja. Prije testiranja sam se uvjerio da Iperf daje punu propusnost (osim kartica od 10 Gbit, pokazalo se da istiskuje samo 7,2 Gbita, kasnije ću vidjeti zašto, test server još nije pravilno konfigurisan). Diskovi su različiti, ali svuda je SSD (posebno umetnut jedan disk za testiranje, ništa drugo se ne učitava) ili raid sa SSD-a. Brzina od 100 Mbita dobijena je ograničavanjem podešavanja adaptera Intel 362. Nije bilo razlike između 1 Gbit bakarnog Intel 350 i 1 Gbit optike Intel X520-DA2 (dobijeno ograničavanjem brzine adaptera). Maksimalne performanse, turbo boost je onemogućen (samo radi uporedivosti rezultata, turbo boost dodaje nešto manje od 10% za dobre rezultate, za loše rezultate možda neće nimalo uticati). Verzije 1C 8.2.19.86, 8.3.6.2076. Ne navodim sve brojke, već samo one najzanimljivije, pa da se ima sa čime uporediti.

	Pobjeda 2008 - Pobjeda 2008 pozivanje preko IP adrese	Pobjeda 2008 - Pobjeda 2008 Adresa po imenu	Pobjeda 2008 - Pobjeda 2008 Pozivanje putem IP adrese	Pobjeda 2008 - Pobjeda 2008 Adresa po imenu	Pobjeda 2008 - Pobjeda 7 Adresa po imenu	Windows 2008 - Debian Adresa po imenu	Pobjeda 2008 - Pobjeda 2008 Pozivanje putem IP adrese	Pobjeda 2008 - Pobjeda 2008 Adresa po imenu
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1S 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čci (iz tabele i iz ličnog iskustva. Odnosi se samo na verziju fajla):

Preko mreže možete dobiti sasvim normalne brojeve za rad ako je ova mreža normalno konfigurirana i staza je ispravno napisana u 1C. Čak i prvi Core i3s može dati 40+ papagaja, što je sasvim dobro, a to nisu samo papagaji, u stvarnom radu razlika je i primjetna. Ali! ograničenje pri radu sa nekoliko (više od 10) korisnika više neće biti mreža, ovdje je i dalje dovoljan 1 Gbit, ali blokiranje tijekom višekorisničkog rada (Gilev).

Platforma 1C 8.3 je višestruko zahtjevnija za kompetentno postavljanje mreže. Osnovna podešavanja - pogledajte Gilev, ali imajte na umu da sve može uticati. Vidio sam ubrzanje od činjenice da su deinstalirali (a ne samo isključili) antivirus, od uklanjanja protokola kao što je FCoE, od promjene drajvera na stariju, ali Microsoft certificiranu verziju (posebno za jeftine kartice kao što su asus i longs), od uklanjanja drugu mrežnu karticu sa servera. Mnogo opcija, pažljivo konfigurišite mrežu. Može doći do situacije kada platforma 8.2 daje prihvatljive brojke, a 8.3 - dva ili čak i više puta manje. Pokušajte da se poigrate sa verzijama platforme 8.3, ponekad dobijete veoma veliki efekat.

1C 8.3.6.2076 (možda kasnije, nisam još tražio tačnu verziju) preko mreže je još uvijek lakše postaviti nego 8.3.7.2008. Od 8.3.7.2008 za postizanje normalnog rada mreže (kod sličnih papagaja) ispalo je samo nekoliko puta, nisam mogao ponoviti za opštiji slučaj. Nisam puno razumio, ali sudeći po krpicama iz Process Explorera, snimak ne ide tamo kao u 8.3.6.

Unatoč činjenici da je pri radu na mreži od 100Mbps njegov raspored opterećenja mali (možemo reći da je mreža besplatna), brzina rada je i dalje mnogo manja nego na 1 Gbps. Razlog je kašnjenje mreže.

Ceteris paribus (mreža koja dobro funkcioniše) za 1C 8.2, Intel-Realtek veza je 10% sporija od Intel-Intel. Ali realtek-realtek generalno može izazvati naglo slijeganje iz vedra neba. Stoga, ako ima novca, bolje je držati Intelove mrežne kartice svuda, ako nema novca, onda stavite Intel samo na server (vaš KO). Da, i postoji mnogo puta više uputstava za podešavanje intel mrežnih kartica.

Zadane postavke antivirusa (na primjer drweb 10 verzija) oduzimaju oko 8-10% papagaja. Ako ga pravilno konfigurišete (dopustite procesu 1cv8 da uradi sve, iako nije sigurno) - brzina je ista kao i bez antivirusa.

NEMOJTE čitati Linux gurue. Server sa sambom je odličan i besplatan, ali ako stavite Win XP ili Win7 na server (ili još bolje - serverski OS), tada će verzija 1c datoteke raditi brže. Da, i samba i stek protokola i mrežne postavke i još mnogo toga u debian/ubuntu su dobro podešeni, ali ovo se preporučuje stručnjacima. Nema smisla instalirati Linux sa zadanim postavkama i onda reći da je spor.

Dobra je ideja testirati diskove povezane preko mreže sa fio . Barem će biti jasno da li se radi o problemima sa 1C platformom ili sa mrežom / diskom.

Za jednokorisničku varijantu, ne mogu se sjetiti testova (ili situacije) u kojima bi bila vidljiva razlika između 1Gb i 10 Gb. Jedino mesto gde je 10Gbps za verziju fajla dalo bolje rezultate bilo je povezivanje diskova preko iSCSI, ali ovo je tema za poseban članak. Ipak, mislim da su kartice od 1 Gbit dovoljne za verziju fajla.

Zašto, sa mrežom od 100 Mbit, 8.3 radi znatno brže od 8.2 - ne razumijem, ali činjenica se dogodila. Sva ostala oprema, sva ostala podešavanja su potpuno ista, samo je u jednom slučaju testiran 8.2, au drugom - 8.3.

Nije podešen NFS win - win ili win-lin daje 6 papagaja, nije ga uključio u tabelu. Nakon podešavanja, dobio sam 25, ali je nestabilan (zalet u mjerenjima je više od 2 jedinice). Za sada ne mogu dati preporuke o korištenju windowsa i NFS protokola.

Nakon svih podešavanja i provjera, ponovo pokrećemo test sa klijentskog računala, radujemo se poboljšanom rezultatu (ako je uspio). Ako se rezultat popravi, ima više od 30 papagaja (a posebno više od 40), manje od 10 korisnika radi istovremeno, a radna baza podataka i dalje usporava - gotovo je sigurno problem programera (ili ste već dostigao vrhunac mogućnosti verzije datoteke).

terminal server. (baza leži na serveru, klijenti su povezani na mrežu, RDP protokol). Korak po korak algoritam:

0. Dodajte Gilev test bazu podataka na server u istom folderu kao i glavne baze podataka. Povezujemo se sa istog servera i izvodimo test. Sjećamo se rezultata.

1. Na isti način kao u verziji datoteke, postavljamo rad. U slučaju terminalnog servera, procesor generalno igra glavnu ulogu (podrazumeva se da nema očiglednih slabosti, kao što je nedostatak memorije ili ogromna količina nepotrebnog softvera).

2. Postavljanje mrežnih kartica u slučaju terminalnog servera praktički nema utjecaja na rad 1s. Da biste pružili "posebnu" udobnost, ako vaš server izda više od 50 papagaja, možete se poigrati novim verzijama RDP protokola, samo za udobnost korisnika, brži odziv i skrolovanje.

3. Uz aktivan rad velikog broja korisnika (a ovdje već možete pokušati spojiti 30 ljudi na jednu bazu, ako pokušate) vrlo je poželjno instalirati SSD disk. Iz nekog razloga se vjeruje da disk posebno ne utječe na rad 1C, ali svi testovi se provode s kešom kontrolera koji je omogućen za pisanje, što je pogrešno. Testna baza je mala, staje u keš memoriju, otuda i veliki brojevi. Na pravim (velikim) bazama podataka sve će biti potpuno drugačije, pa je keš memorija onemogućena za testove.

Na primjer, provjerio sam rad Gilev testa s različitim opcijama diska. Stavio sam diskove od onoga što mi je bilo pri ruci, samo da pokažem sklonost. Razlika između 8.3.6.2076 i 8.3.7.2008 je mala (u Ramdisk Turbo boost verziji 8.3.6 daje 56.18 i 8.3.7.2008 daje 55.56, u ostalim testovima razlika je još manja). Potrošnja energije - maksimalne performanse, turbo pojačanje je onemogućeno (osim ako nije drugačije naznačeno).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Single SSD	ramdisk		Keširanje je omogućeno RAID kontroler
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1S 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

Uključena keš memorija RAID kontrolera eliminiše svu razliku između diskova, brojevi su isti i za sat i za sas. Testiranje s njim za malu količinu podataka je beskorisno i nije pokazatelj.

Za 8.2 platformu, razlika u performansama između SATA i SSD opcija je više nego dvostruka. Ovo nije greška u kucanju. Ako pogledate monitor performansi tokom testa na SATA diskovima. tada je jasno vidljivo "Vrijeme aktivnog diska (u%)" 80-95. Da, ako omogućite keš memoriju samih diskova, brzina će se povećati na 35, ako omogućite keš raid kontrolera - do 49 (bez obzira na to koji se diskovi trenutno testiraju). Ali ovo su sintetički papagaji keša, u stvarnom radu sa velikim bazama podataka nikada neće postojati 100% omjer pogodaka u keš memoriji.

Brzina čak i jeftinih SSD-ova (testirao sam na Agility 3) dovoljna je da verzija datoteke radi. Resurs za pisanje je druga stvar, ovdje morate pogledati u svakom konkretnom slučaju, jasno je da će Intel 3700 imati red veličine veći, ali tamo je cijena odgovarajuća. I da, razumijem da kada testiram SSD disk, u većoj mjeri testiram i keš ovog diska, stvarni rezultati će biti manji.

Najispravnije (sa moje tačke gledišta) rješenje bi bilo dodijeliti 2 SSD diska u mirror raid za bazu datoteka (ili nekoliko baza datoteka), a ne stavljati ništa drugo tamo. Da, sa ogledalom, SSD-ovi se troše na isti način, a to je minus, ali barem su nekako osigurani od grešaka u elektronici kontrolera.

Glavne prednosti SSD diskova za verziju datoteke pojavit će se kada postoji mnogo baza podataka, a svaka ima nekoliko korisnika. Ako ima 1-2 baze, a korisnika u regiji od 10, tada će SAS diskovi biti dovoljni. (ali u svakom slučaju - pogledajte učitavanje ovih diskova, barem kroz perfmon).

Glavne prednosti terminalnog servera su u tome što može imati vrlo slabe klijente, a mrežna podešavanja mnogo manje utiču na terminal server (opet vaša KO).

Zaključci: ako pokrenete Gilev test na terminal serveru (sa istog diska na kojem su radne baze podataka) i u onim trenucima kada se radna baza podataka usporava, a Gilev test pokaže dobar rezultat (iznad 30), onda spori kriv je rad glavne radne baze podataka, najvjerovatnije programer.

Ako Gilev test pokazuje male brojke, a imate i procesor sa visokom frekvencijom i brze diskove, onda ovdje administrator treba uzeti barem perfmon, i negdje snimiti sve rezultate, i gledati, promatrati, izvlačiti zaključke. Neće biti definitivnog savjeta.

Klijent-server opcija.

Testovi su obavljeni samo na 8.2, tk. Na 8.3, sve dosta ozbiljno zavisi od verzije.

Za testiranje sam odabrao različite opcije servera i mreže između njih kako bih pokazao glavne trendove.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiber kanal-SSD	SQL: Xeon E5-2630 Fiber kanal - SAS	SQL: Xeon E5-2630 Lokalni SSD	SQL: Xeon E5-2630 Fiber kanal-SSD	SQL: Xeon E5-2630 Lokalni SSD	1C: Xeon 5650 =	1C: Xeon 5650 = zajednička memorija	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
1S 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

Čini se da sam razmotrio sve zanimljive opcije, ako vas zanima nešto drugo - napišite u komentarima, pokušat ću to učiniti.

SAS na skladištu je sporiji od lokalnih SSD-ova, iako pohrana ima velike veličine predmemorije. SSD-ovi i lokalni sistemi i sistemi za skladištenje za Gilev test rade uporedivim brzinama. Ne znam nijedan standardni multi-threaded test (ne samo zapise, već i svu opremu) osim opterećenja 1C iz MCC-a.

Promjena 1C servera sa 5520 na 5650 dala je skoro udvostručenje performansi. Da, konfiguracije servera se ne poklapaju u potpunosti, ali pokazuje trend (ništa iznenađujuće).

Povećanje frekvencije na SQL serveru, naravno, daje efekat, ali ne isti kao na 1C serveru, MS SQL Server je savršeno u stanju (ako ga pitate) da koristi višejezgrenu i slobodnu memoriju.

Promjena mreže između 1C i SQL sa 1 Gbps na 10 Gbps daje oko 10% papagaja. Očekivalo se više.

Omogućavanje dijeljene memorije i dalje daje efekat, iako ne 15%, kao što je opisano. Obavezno to uradite, brzo je i lako. Ako je neko dao imenovanu instancu SQL serveru tokom instalacije, onda da bi 1C radio, ime servera mora biti navedeno ne preko FQDN-a (tcp / ip će raditi), ne preko localhost-a ili samo ServerName, već preko ServerName\InstanceName, jer primjer zz-test\zztest. (U suprotnom će se pojaviti sljedeća DBMS greška: Microsoft SQL Server Native Client 10.0: Dobavljač zajedničke memorije: Biblioteka dijeljene memorije koja se koristi za povezivanje sa SQL Serverom 2000 nije pronađena. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSTATE=08001, stanje=1, ozbiljnost=10, izvorno=126, red=0).

Za korisnike manje od 100, jedina tačka razdvajanja na dva odvojena servera je licenca za Win 2008 Std (i starije verzije), koja podržava samo 32 GB RAM-a. U svim ostalim slučajevima, 1C i SQL svakako treba instalirati na istom serveru i dati im više (najmanje 64 GB) memorije. Davanje MS SQL-u manje od 24-28 GB RAM-a je neopravdana pohlepa (ako mislite da imate dovoljno memorije za to i da sve radi kako treba, možda bi vam bila dovoljna verzija 1C fajla?)

Koliko gore gomila 1C i SQL-a radi u virtuelnoj mašini tema je posebnog članka (nagoveštaj - primetno lošije). Čak ni u Hyper-V stvari nisu tako jasne...

Izbalansirani način rada je loš. Rezultati se dobro slažu sa verzijom fajla.

Mnogi izvori kažu da način otklanjanja grešaka (ragent.exe -debug) daje snažno smanjenje performansi. Pa, snižava, da, ali 2-3% ne bih nazvao značajnim efektom.