Kako podesiti pametne telefone i računare. Informativni portal

Ubrzanje rada 1s 8.3 fajl. Savjeti za automatizaciju

Izraz "1C usporava" sigurno su čuli svi koji rade sa proizvodima na platformi 1C: Enterprise. Neko se žalio na ovo, neko je prihvatio žalbe. U ovom članku ćemo pokušati pokriti najčešće uzroke ovog problema i mogućnosti za njegovo rješavanje.

Okrenimo se metafori: prije nego što saznate zašto osoba nije negdje došla, treba se uvjeriti da ima noge za hodanje. Dakle, počnimo sa hardverskim i mrežnim zahtjevima.

Ako je instaliran Windows 7:

Ako je instaliran Windows 8 ili 10:



Također zapamtite da slobodan prostor na disku mora biti najmanje 2 GB, a mrežna veza mora imati brzinu od najmanje 100 Mb/s.

Nema smisla razmatrati karakteristike servera u verziji klijent-server, jer u ovom slučaju sve ovisi o broju korisnika i specifičnostima zadataka koje rješavaju u 1C.

Prilikom odabira konfiguracije za server, imajte na umu sljedeće:

  • Jedan radni proces 1C servera u prosjeku troši 4 GB (ne treba ga brkati sa korisničkom vezom, jer jedan radni proces može imati onoliko veza koliko navedete u postavkama servera);
  • Upotreba 1C i DBMS-a (posebno MS SQL-a) na jednom fizičkom serveru daje prednost pri obradi velikih količina podataka (na primjer, zatvaranje mjeseca, izračunavanje budžeta po modelu, itd.), ali značajno smanjuje performanse tokom neopterećenih operacija ( na primjer, kreiranje i vođenje implementacionog dokumenta, itd.);
  • Zapamtite da 1C serveri i DBMS moraju biti povezani preko kanala "debelog" od 1 GB;
  • Koristite diskove visokih performansi i nemojte kombinovati uloge 1C i DBMS servera sa drugim ulogama (na primjer, datoteka, AD, kontrolor domene, itd.).

Ako, nakon provjere opreme, 1C i dalje "uspori"

Imamo malu firmu, 7 ljudi, a 1C "usporava". Kontaktirali smo specijaliste, a oni su rekli da će nas spasiti samo opcija klijent-server. Ali za nas takvo rješenje nije prihvatljivo, preskupo je!

Izvršite rutinsko održavanje baze podataka *:

1. Pokrenite bazu u modu konfiguratora.


2. U glavnom meniju odaberite stavku "Administracija", a u njoj - "Testiraj i popravi".


3. Postavite sve kvadratiće kao na slici. Kliknite na Run.

* Ova procedura može trajati od 15 minuta do sat vremena, u zavisnosti od veličine baze i specifikacija vašeg računara.

Ako to ne pomogne, onda uspostavljamo klijent-server vezu, ali bez dodatnih ulaganja u hardver i softver:

1. Izaberite najmanje opterećeni računar u kancelariji od stacionarnog (ne prenosivog): mora imati najmanje 4 GB RAM-a i mrežnu vezu od najmanje 100 Mb/s.

2. Aktivirajte IIS (Internet Information Server) na njemu. Za ovo:





3. Objavite svoju bazu na ovom računaru. Na ITS-u je dostupan materijal o ovoj temi ili se obratite stručnjaku za podršku.

4. Na računarima korisnika, konfigurišite pristup bazi podataka preko tankog klijenta. Za ovo:


Otvorite prozor za pokretanje 1C.


Odaberite svoju radnu bazu. Ovdje je "Vaša baza". Kliknite Promijeni. Postavite radio dugme na poziciju "Na web serveru", navedite u liniji ispod ime ili IP adresu servera na kojem je IIS aktiviran i naziv pod kojim je objavljena baza podataka. Kliknite na "Dalje".


Postavite prekidač Main Startup Mode na način Thin Client. Kliknite na Završi.

Imamo dosta veliku firmu, ali ne baš veliku, 50-60 ljudi.Koristimo opciju klijent-server, ali 1C je užasno spor.

U ovom slučaju se preporučuje da se 1C server i DBMS server podele na dva različita servera. Prilikom podjele, obavezno zapamtite: ako su ostali na istom fizičkom serveru, koji je jednostavno virtueliziran, onda diskovi ovih servera moraju biti različiti — fizički različiti! Također, obavezno postavite zakazane zadatke na DBMS serveru kada je u pitanju MS SQL (više o tome je opisano na web stranici ITS-a)

Imamo prilično veliku kompaniju, više od 100 korisnika. Sve je konfigurirano u skladu s preporukama 1C za ovu opciju, ali prilikom izvođenja nekih dokumenata, 1C se jako "uspori", a ponekad i u potpunosti dođe do greške u blokiranju. Možda zarolati bazu?

Slična situacija nastaje zbog veličine vrlo specifičnog registra akumulacije ili računovodstva (ali češće - akumulacije), zbog činjenice da je registar ili potpuno "zatvoren", tj. ima kretanja pristizanja, ali nema kretanja potrošnje, ili je broj mjerenja po kojima se izračunavaju ostaci registra vrlo velik. Možda čak postoji mješavina prethodna dva razloga. Kako odrediti koji registar sve kvari?

Popravljamo vrijeme kada se dokumenti sporo drže, odnosno vrijeme i korisnika koji ima grešku u blokiranju.

Otvaramo dnevnik registracije.



Pronalazimo dokument koji nam je potreban, u pravo vrijeme, za pravog korisnika sa tipom događaja "Data.Conduct".



Gledamo cijeli blok do otkazivanja transakcije, ako je došlo do greške u blokiranju ili tražimo najdužu promjenu (vrijeme od prethodnog zapisa je više od minute).

Nakon toga donosimo odluku, imajući u vidu da je u svakom slučaju jeftinije umotati ovaj registar nego cijelu bazu podataka.

Mi smo veoma velika kompanija, više od 1000 korisnika, hiljade dokumenata dnevno, sopstveno IT odeljenje, ogroman park servera, optimizovali smo upite nekoliko puta, ali 1C usporava. Očigledno smo prerasli 1C i treba nam nešto moćnije.

U ogromnoj većini takvih slučajeva, nije 1C taj koji "usporava", već arhitektura korištenog rješenja. Prilikom odabira u korist novog programa za poslovanje, zapamtite da je jeftinije i lakše upisati svoje poslovne procese u program nego ih prepravljati za neki, tim više, vrlo skup program. Ovu priliku pruža samo 1C. Stoga je bolje postaviti pitanje: „Kako popraviti situaciju? Kako natjerati 1C da "leti" na takvim količinama?" Razmotrimo ukratko nekoliko opcija za "liječenje":

  • Koristite tehnologije paralelnog i asinkronog programiranja koje 1C podržava (pozadinski poslovi i upiti u petlji).
  • Prilikom dizajniranja arhitekture rješenja izbjegavajte korištenje akumulacijskih registara i računovodstvenih registara u "uskim grlima".
  • Prilikom izrade strukture podataka (registri akumulacije i/ili informacija) pridržavajte se pravila: „Najbrža tabela za pisanje i čitanje je tabela sa jednom kolonom“. O čemu je riječ bit će jasnije ako pogledate tipičan mehanizam RAUZ-a.
  • Za obradu velikih količina podataka koristite pomoćne klastere na koje je povezana ista baza podataka (ali to ni u kom slučaju ne radite tokom interaktivnog rada !!!). To će vam omogućiti da zaobiđete standardne 1C brave, što će omogućiti rad s bazom podataka gotovo istom brzinom kao kada radite direktno koristeći SQL.

Vrijedi napomenuti da je 1C optimizacija za holdinge i velike kompanije tema za poseban, veliki članak, pa pratite ažuriranja na našoj web stranici.

Kako ubrzati rad u 1C: Računovodstvo 8.3 (revizija 3.0) ili onemogućiti rutinske i pozadinske zadatke

2019-01-15T13: 28: 19 + 00: 00

Oni od vas koji su već uspjeli preći na novu verziju 1C: Accounting 8.3 (verzija 3.0) primijetili su da je postao sporiji u radu od ove dvije. Neka neshvatljiva usporavanja, beskrajni pozadinski zadaci po nekoliko puta dnevno, za koje niko od nje nije tražio da radi bez našeg znanja.

Odmah nakon tranzicije moji računovođe su mi rekli da nova verzija 1C: Accounting 3.0, u poređenju sa prethodnim, iskreno usporava! I jednostavno je nemoguće raditi.

Počeo sam da shvaćam i vrlo brzo saznao da su glavni razlog zamrzavanja i nezadovoljstva korisnika koji je uslijedio su zakazani i pozadinski poslovi, od kojih su mnogi uključeni po defaultu, iako za ogromnu većinu računovođa nema potrebe za njima. .

Pa, na primjer, zašto trebamo pokretati zadatak "Izdvoji tekst" sto puta dnevno ako ne izvršimo punu tekstualnu pretragu (računovođe, ne brinite) po svim objektima u našoj bazi podataka.

Ili zašto stalno preuzimati kurseve ako nemamo valutne transakcije ili ih radimo povremeno (a prije toga sami možemo kliknuti na dugme download rates).

Isto se odnosi i na stalne pokušaje 1C da se poveže sa sajtom i proveri i ažurira bankarske klasifikatore. Zašto? I sam ću pritisnuti dugme da ažuriram klasifikatore ako ne pronađem traženu banku po njenom BIC-u.

Kako to učiniti prema tačkama u nastavku.

1. Idite na odjeljak "Administracija" i odaberite stavku "Održavanje" na traci radnji ():

2. U prozoru koji se otvori pronađite i odaberite stavku "Planirani i pozadinski zadaci":

3. Otvorite svaki posao koji ima kolonu "Uključeno". tu je čavka.

4. Poništite izbor u polju za potvrdu Enabled i kliknite na dugme Sačuvaj i zatvori.

5. Uradite to sa svakim od uključenih zadataka i uživajte u novom izdanju. Generalno, po mom mišljenju, mnogo je bolji od dvojke.

Istovremeno, platforma će uključiti neke od zakazanih zadataka koje ste ionako onemogućili.

1C sistem zauzima dominantnu poziciju na tržištu automatizacije za mala i srednja preduzeća. Ako je kompanija odabrala 1C računovodstveni sistem, tada u njemu obično rade gotovo svi zaposlenici, od običnih stručnjaka do menadžmenta. Shodno tome, brzina poslovnih procesa kompanije zavisi od brzine 1C. Ako 1C radi nezadovoljavajućom brzinom, onda to direktno utiče na rad cijele kompanije i na ostvarivanje profita.

U stvari postoji tri metode ubrzanja 1C:

  • Povećani kapacitet hardvera.
  • Optimizacija postavki operativnog sistema i DBMS-a.
  • Optimizacija koda i algoritama u 1C.

Prvi način zahtijeva nabavku opreme i licenci, treći zahtijeva puno rada programera i kao rezultat toga oba načina rezultiraju značajnim finansijskim troškovima. Prije svega, trebate obratiti pažnju na programski kod, jer je nemoguće nadoknaditi pogrešan kod bilo kakvim povećanjem kapaciteta servera. Svaki programer zna da je sa samo nekoliko linija koda moguće kreirati proces koji će u potpunosti učitati resurse bilo kojeg servera.

Ako je kompanija sigurna u optimalnost programskog koda, a on i dalje sporo radi, obično menadžment odlučuje da poveća kapacitet servera. U ovom trenutku nameće se logično pitanje: šta nedostaje, koliko i šta na kraju treba dodati.

Kompanija 1C daje prilično nejasan odgovor na pitanje koliko sredstava je potrebno, o tome smo pisali ranije u našim objavama. Stoga morate samostalno provoditi eksperimente i shvatiti o čemu ovisi izvedba 1C. Eksperimenti sa performansama programa na EFSOL-u su opisani u nastavku.

Prilikom rada sa 1C 8.2, posebno sa konfiguracijama koje koriste upravljane forme, uočena je čudna činjenica: 1C radi brže na radnoj stanici nego na moćnom serveru. Štaviše, sve karakteristike radne stanice su lošije od karakteristika servera.



Tabela 1 – Konfiguracije na kojima je izvršeno početno testiranje

Radna stanica pokazuje performanse 155% više od 1C servera sa superiornim karakteristikama. Počeli smo da otkrivamo u čemu je stvar i sužavamo krug traženja.

Slika 1 – Mjerenja performansi na radnoj stanici Gilevovim testom

Prva sumnja je bila da je Gilevov test neadekvatan. Mjerenja otvaranja obrazaca, knjiženja dokumenata, generiranja izvještaja itd. instrumentacijskim alatima pokazala su da Gilev test daje procjenu proporcionalnu stvarnoj brzini rada u 1C.

Količina i frekvencija RAM-a

Analiza informacija dostupnih na Internetu pokazala je da mnogi pišu o ovisnosti performansi 1C o frekvenciji memorije. To je od frekvencije, a ne od jačine zvuka. Odlučili smo da testiramo ovu hipotezu, jer naš server ima RAM frekvenciju od 1066 Mhz naspram 1333 Mhz na radnoj stanici, a količina RAM-a na serveru je već mnogo veća. Odlučili smo da instaliramo ne 1066 Mhz odjednom, već 800 Mhz, tako da je efekat zavisnosti performansi od memorijske frekvencije bio jasniji. Kao rezultat toga, produktivnost je pala za 12% i iznosila je 39,37 jedinica. Server je opremljen memorijom sa frekvencijom od 1333 Mhz umjesto 1066 Mhz i dobio je neznatno povećanje performansi - oko 11%. Produktivnost je bila 19,53 jedinica. Shodno tome, tačka nije u memoriji, iako njena frekvencija daje blagi porast.

Slika 2 – Mjerenja performansi na radnoj stanici nakon smanjenja frekvencije RAM-a


Slika 3 – Mjerenja performansi na serveru nakon povećanja frekvencije RAM-a

Diskovni podsistem

Sljedeća hipoteza se odnosila na podsistem diska. Odmah su se pojavile dvije pretpostavke:

  • SSD diskovi su bolji od SAS diskova, čak i ako su u Raid 10.
  • iSCSI je spor ili ne radi ispravno.

Stoga je u radnu stanicu umjesto SSD-a instaliran običan SATA disk, a isto je urađeno i sa serverom - baza je postavljena na lokalni SATA disk. Kao rezultat toga, mjerenja performansi se ni na koji način nisu promijenila. Najvjerovatnije se to događa jer ima dovoljno RAM-a i diskovi praktički nisu uključeni u test.

CPU

Procesori na serveru su, naravno, moćniji i postoje dva, ali je frekvencija nešto niža nego na radnoj stanici. Odlučili smo da proverimo uticaj frekvencije procesora na performanse: za server nije bilo procesora sa višom frekvencijom pri ruci, pa smo smanjili frekvenciju procesora na radnoj stanici. Odmah smanjen na 1,6, tako da korelacija izgleda svetlija. Test je pokazao da su performanse značajno pale, ali i sa 1.6 procesorom radna stanica je proizvela skoro 28 jedinica, što je skoro 1,5 puta više nego na serveru.

Slika 4 – Mjerenja performansi na radnoj stanici sa procesorom od 1,6 Ghz

Video kartica

Na Internetu postoje informacije da video kartica može utjecati na performanse 1C. Isprobali smo integrisani video za radnu stanicu, Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5 profesionalni adapter, staru GeForce 16MbSDR grafičku karticu. Tokom Gilev testa nije uočena značajna razlika. Možda video kartica utiče, ali u stvarnim uslovima, kada treba da otvorite upravljane forme itd.

Trenutno postoje dvije sumnje zašto je radna stanica brža, čak i sa osjetno lošijim karakteristikama:

  1. CPU. Tip procesora na radnoj stanici je bolje prilagođen 1C.
  2. Čipset. Pod svim ostalim stvarima, naša radna stanica ima noviji čipset, možda je to razlog.

Planiramo nabavku potrebnih komponenti i nastavak testiranja kako bismo konačno saznali šta u većoj mjeri određuje performanse 1C. Dok je u toku proces odobravanja i nabavke, odlučili smo se za optimizaciju, pogotovo što ne košta ništa. Istaknute su sljedeće faze:

Faza 1. Podešavanje sistema

Prvo, napravimo sljedeće postavke u BIOS-u i operativnom sistemu:

  1. Onemogućite sve postavke da biste uštedjeli snagu procesora u BIOS-u servera.
  2. Odaberite plan "Maksimalne performanse" u operativnom sistemu.
  3. Takođe podešavamo procesor za maksimalne performanse. To se može učiniti pomoću uslužnog programa PowerSchemeEd.

Faza 2. Postavljanje SQL servera i 1C: Enterprise servera

Vršimo sljedeće promjene u postavkama DBMS servera i 1C: Enterprise.

  1. Konfiguriranje protokola dijeljene memorije:

    • Zajednička memorija će biti omogućena samo na platformi počevši od 1C 8.2.17, na ranijim izdanjima će biti omogućen Named Pipe, koji je nešto lošiji u brzini rada. Ova tehnologija radi samo ako su 1C i MSSQL servisi instalirani na istom fizičkom ili virtuelnom serveru.
  2. Preporučljivo je prebaciti uslugu 1C u način za otklanjanje grešaka, koliko god to bilo paradoksalno, to daje povećanje performansi. Otklanjanje grešaka na serveru je podrazumevano onemogućeno.
  3. Podešavanje SQL servera:

    • Potreban nam je samo server, ostali servisi koji se na njega odnose i, možda ih neko koristi, samo usporavaju rad. Zaustavljamo i onemogućavamo usluge kao što su: FullText Search (1C ima vlastiti mehanizam pretraživanja punog teksta), Integration Services, itd.
    • Postavljamo maksimalnu količinu memorije koja je dodijeljena serveru. Ovo je neophodno kako bi sql-server računao na ovu količinu i unaprijed očistio memoriju.
    • Postavljamo maksimalan broj niti (Maximum worker threads) i postavljamo povećani prioritet servera (Boost priority).

Faza 3. Postavljanje proizvodne baze podataka

Nakon što su DBMS server i 1C: Enterprise optimizirani, prijeđite na postavke baze podataka. Ako baza još nije proširena iz .dt datoteke, a znate njenu približnu veličinu, onda je bolje odmah navesti "> =" veličinu baze primarnoj datoteci, veličinu inicijalizacije, ali ovo je stvar ukusa, i dalje će rasti tokom širenja. Ali autoinkrement mora biti specificiran: oko 200 MB po bazi i 50 MB po logu, jer podrazumevane vrednosti su 1MB i rast od 10%, što u velikoj meri usporava rad servera, kada treba da povećava fajl sa svakom 3. transakcijom. Takođe, bolje je odrediti skladištenje datoteke baze podataka i datoteke dnevnika na različitim fizičkim diskovima ili RAID grupama, ako se koristi RAID niz, i ograničiti rast dnevnika. Preporučljivo je premjestiti Tempdb datoteku u niz velike brzine, jer mu DBMS često pristupa.

Faza 4. Postavljanje zakazanih poslova

Planirani zadaci se kreiraju prilično jednostavno pomoću Plana održavanja u sekciji Menadžment, koristeći grafičke alate, tako da nećemo detaljno opisivati ​​kako se to radi. Hajde da se zadržimo na tome koje operacije treba izvršiti da bismo poboljšali performanse.

  • Defragmentiranje indeksa i ažuriranje statistike treba raditi svakodnevno, jer ako je fragmentacija indeksa> 25%, to će dramatično smanjiti performanse servera.
  • Defragmentiranje i ažuriranje statistike se obavlja brzo i ne zahtijeva isključenje korisnika. Takođe se preporučuje da to radite svakodnevno.
  • Potpuno reindeksiranje - vrši se zaključavanjem baze podataka, preporučljivo je da se to radi najmanje jednom sedmično. Naravno, nakon potpunog ponovnog indeksiranja, odmah se vrši defragmentacija indeksa i ažuriranje statistike.

Kao rezultat toga, uz pomoć finog podešavanja sistema, SQL servera i radne baze, uspjeli smo povećati performanse za 46%. Mjerenja su obavljena pomoću 1C KIP alata i Gilev testa. Potonji je pokazao 25,6 jedinica naspram 17,53 koliko je prvobitno bilo.

Kratak zaključak

  1. Performanse 1C ne zavise mnogo od frekvencije RAM-a. Kada se postigne dovoljan volumen, dalje proširenje memorije nema smisla, jer ne dovodi do povećanja performansi.
  2. Performanse 1C ne zavise od video kartice.
  3. Performanse 1C ne zavise od podsistema diska, pod uslovom da red čitanja ili pisanja diskova nije prekoračen. Ako su SATA diskovi instalirani i nisu prekoračeni, onda instalacija SSD-a neće poboljšati performanse.
  4. Performanse dosta zavise od frekvencije procesora.
  5. Uz pravilno podešavanje operativnog sistema i MSSQL servera, moguće je povećati performanse 1C za 40-50% bez ikakvih materijalnih troškova.

PAŽNJA! Veoma važna tačka! Sva mjerenja su obavljena na testnoj bazi korištenjem Gilev testa i 1C instrumentacije. Ponašanje stvarne baze sa stvarnim korisnicima može se razlikovati od dobijenih rezultata. Na primjer, u bazi podataka testova nismo pronašli nikakvu ovisnost performansi o video kartici i količini RAM-a. Ovi zaključci su prilično sumnjivi i u realnim uslovima ovi faktori mogu imati značajan uticaj na performanse. Prilikom rada sa konfiguracijama koristeći upravljane forme, važna je video kartica, a moćan grafički procesor ubrzava rad u smislu crtanja programskog sučelja, što se vizualno manifestira u bržem 1C radu.

Radi li vaš 1C sporo? Naručite IT održavanje računara i servera od strane EFSOL stručnjaka sa dugogodišnjim iskustvom ili prenesite svoj 1C na moćan virtuelni 1C server otporan na greške.

Integracija sistema. Konsalting

Na mnogo načina, 1C optimizacija i brzina rada ovise o radu sa bravama, upitima i indeksima. Pokušat ćemo odgovoriti na pitanje "kako ubrzati rad 1C" (pitanje kako ubrzati pokretanje 1C razmotrit ćemo u drugom članku) i izbjeći pritužbe korisnika na "dugo čuvanje dokumenata", koje neizbežno utiče na poslovne procese.

Dio 3. Performanse 1C

Brave u 1C 8.3: pretraživanje i eliminacija u kodu, prijenos na upravljane brave

Brave su dio ACID mehanizma. Razmotrimo njegov koncept, predstavljen u obliku pojednostavljenog dijagrama, koristeći primjer SQL SERVER-a

U automatskom načinu rada, zaključavanjem upravlja sam DBMS. Istovremeno, na MS SQL serveru su se pojavile nuspojave kao što su zaključavanje praznih tabela i granični opseg podataka (Serializable level), što je stvaralo dodatne probleme u višekorisničkom radu. Da bi riješio ove probleme, 1C je kreirao upravljane brave.

1C Upravljane brave

Mehanizam zaključavanja je premješten na 1C server, a na nivou DBMS-a izolacija je svedena na minimum. Na MS SQL-u, nivo izolacije je degradiran na Read Committed sa zajedničkim mehanizmom zaključavanja platforme 8.2 i mehanizmom za verzioniranje redova platforme 8.3 (tzv. Read Committed Snapshot Isoliation). Tačnije, radi se o svojstvu baze podataka istog imena i dva Read Committed načina rada, ovisno o ovom parametru.

Na posljednjoj razini izolacije (RCSI), mehanizam je dozvolio da se ne preklapaju transakcije čitanja i pisanja čitanja i pisanja transakcija na DBMS serveru na istim resursima. Sav glavni posao preuzeo je servis 1C blokiranja, koji na osnovu izvornih metapodataka određuje da li će se ili ne pokrenuti transakcije na DBMS serveru kako ne bi došlo do kršenja poslovne logike. Zaključavanje praznih tabela i graničnih opsega su stvar prošlosti.

DBMS Tip brave Nivo izolacije transakcije Čitanje izvan transakcije
Automatske brave
File Database Od stolova Serializable Prljavo čitanje
MS SQL Server Records Prljavo čitanje
IBM DB2 Records Ponovljivo čitanje ili serijaliziranje Prljavo čitanje
PostgreSQL Od stolova Serializable Dosljedno čitanje
Oracle Database Od stolova Serializable Dosljedno čitanje
Upravljane brave
File Database Od stolova Serializable Prljavo čitanje
MS SQL Server 2000 Records Read Commited Prljavo čitanje
MS SQL Server 2005 i noviji Pročitajte posvećeni snimak Dosljedno čitanje
IBM DB2 prije verzije 9.7 Records Read Commited Prljavo čitanje
IBM DB2 verzija 9.7 i novije Records Read Commited Dosljedno čitanje
PostgreSQL Records Read Commited Dosljedno čitanje
Oracle Database Records Read Commited Dosljedno čitanje

Da biste saznali u kojem se načinu blokiranja nalazi baza programa 1C, potrebno je izvršiti sljedeći zahtjev od SSMS-a u kontekstu željene baze:


Brave 1C. Korisnik neće čekati na zaključavanje, 1C će se ubrzati ako se pridržavate određenih pravila:

  • Trajanje transakcija treba vremenski skratiti što je više moguće. Izvođenje dugoročnih kalkulacija u transakciji u 100% slučajeva će dovesti do blokade pri radu na OLTP sistemu.
  • Isključene su dugoročne eksterne operacije unutar transakcije, na primjer, slanje i prihvatanje potvrda putem e-pošte, rad sa sistemom datoteka i druge dodatne radnje. Sve operacije treba staviti u odložene kratke zadatke.
  • Upiti su maksimalno optimizirani.
  • Kreiranje indeksa treba raditi samo prema potrebi da se osigura optimalna izvedba upita unutar aplikacije.
  • Uključivanje često ažuriranih stupaca u klasterirani indeks je svedeno na minimum. Ažuriranje stupca(a) ključa grupiranog indeksa zahtijeva zaključavanje i klasteriziranog indeksa i svih neklasteriranih indeksa (pošto njihov niz lokatora sadrži klasterizirani indeksni ključ).
  • Kad god je to moguće, kreiran je indeks pokrivanja koji se koristi za smanjenje vremena preuzimanja podataka.
  • Korištenje najniže razine izolacije transakcije, koja će zahtijevati prijelaz na način upravljanja zaključavanjem.

Dijagnostički alati za blokiranje:

  • Tehnološki časopis;
  • Centar za kontrolu performansi iz 1C alata;
  • Usluge u oblaku Gilev;

Ispod je primjer praćenja sistema od strane Gilev servisa. Ukupno trajanje blokade je ~ 15 sati. Preko 400 aktivnih korisnika. Nakon donošenja odluka i optimizacije, vrijeme čekanja je manje od jedne minute, a broj zaključavanja je smanjen za ~670 puta.

Bilo je:



postao:


U situaciji kada "sve visi i traje dugo", a servisi za praćenje nisu konfigurisani ili se uopšte ne koriste, prisjećajući se Pareto principa, potrebno je fokusirati se na kod.

U automatskom načinu rada, prisustvo zaključavanja na serveru može se otkriti korištenjem sistemske procedure u kontekstu potrebne baze podataka. Ova pohranjena procedura vam omogućava da odredite u kojem načinu rada brave, njihov status, tip, itd.



Modifikacijom procedure za 1C, možete dobiti vizuelne informacije o tome šta se trenutno dešava na serveru, uzimajući u obzir specifičnosti 1C tabela:


Fragment 1

// Zaključavanje u smislu 1C SELECT * FROM dbo.ReturnLockName1C (DEFAULT, DEFAULT) kao t Gdje TableName1C NIJE NULL RED OD t.Resource

Upotreba ovog mehanizma vam omogućava da dobijete potpune informacije o postojećim bravama u trenutnom trenutku. Ako izvještaj sadrži samo S-brave, problem može biti dugačak upit ili upiti. Da biste utvrdili uzrok i mjesto njihovog pojavljivanja u kodu, možete ići na različite načine: koristiti DMO objekte SQL servera (ali uzmite u obzir da se podaci iz njih resetiraju nakon ponovnog pokretanja servera) ili konfigurirajte Data Collector, čuvanje podataka praćenja u tabelama za određeno vrijeme. Glavna stvar je dobiti tekstove problematičnih zahtjeva.

Korištenje SQL Server DMO-a

Prikazujemo datum početka servera da bismo razumjeli relevantnost podataka. Paket dijelimo po ocjeni čitanja (fizičko, logičko, opterećenje procesora). U ovom slučaju se koriste glavni podaci iz sys.dm_exec_query_stats. Tekst zahtjeva prevodimo u 1C pojmove. Ako možete razumjeti kontekst poziva iz teksta upita, onda ostaje pogledati plan upita, pronaći problematične operatore i razumjeti šta se može učiniti.

Fragment 2

// vrijeme početka SELECT sqlserver_start_time FROM sys.dm_os_sys_info; // Vrh upita za fizička čitanja SELECT TOP (50) (total_physical_reads) AS Total_physical_reads,

Identificiranje problematičnih upita iz zbirke sakupljača podataka

Koristeći ovaj alat, možete rangirati podatke prema potrebnim parametrima, kao što su CPU opterećenje, trajanje, logički I/O, fizička čitanja, što vam omogućava da sačuvate kompletnu statistiku za dalju analizu, uprkos ponovnom pokretanju SQL servera.


Nakon što server prikupi zahtjeve za problem bez nadzora treće strane, moguće je rangirati primljene podatke prema potrebnim parametrima.

Dalje, uključivanjem tehnološkog dnevnika i navođenjem u postavkama "pretraži po nizu" i dijela upita za koji se garantuje da će se pojaviti, možete saznati odakle je problemski upit. Ako server ima više baza podataka ili je korisničko ime poznato, vrijedi dodati dodatna polja za filter kako bi se smanjilo opterećenje servera prilikom prikupljanja tehnološkog dnevnika.

Primjer zahtjeva za problem i uzorak postavljanja tehnološkog dnevnika:



Optimizacija upita kao prilika za ubrzanje 1C 8.3


Posledice neoptimalnih zahteva mogu se manifestovati u vidu dugotrajnog izvršavanja dokumenata, bolno dugog izveštavanja, „zamrzavanja“ sistema i drugih neprijatnih događaja.

Kada radite sa upitima, NE:

  • Spoji tabele sa potupitima;
  • Spojite obične stolove sa virtuelnim;
  • Koristite logičko "ILI" u uslovima;
  • Koristite podupite u uslovima pridruživanja;
  • Dobijte isprekidane podatke iz polja složenog tipa bez ključne riječi Express.

Prilikom rada sa upitima MOŽETE:

  • Kreirajte indekse u uslovima upita, pridruživanju, agregaciji i poljima sortiranja;
  • Filtriranje virtuelnih tabela mora se izvesti pomoću parametara filtriranja.

Upotreba indeksa i njihov uticaj na kvalitet performansi sistema

Mnogo je pisano o indeksima, potrebi njihove upotrebe i uticaju na kvalitet sistema. Pokušajmo razumjeti zamršenost "strukture" indeksa, slučajeva upotrebe i prednosti u odnosu na konvencionalne tablice.

Indeksiranje je važan dio motora baze podataka. Nedostaju indeksi, ili obrnuto, njihov prevelik broj, utiču na brzinu uzorkovanja, modifikacije, dodavanja i brisanja podataka. Pogledajmo indeksiranje na primjeru najčešćeg DBMS-a iz Microsofta.

Za opće razumijevanje kako ovo funkcionira, razmotrite detalje uređaja pomoću mehanizma za pohranu podataka, koji obično predstavljamo u obliku tabele (na primjer, Excel).

Jedinica za skladištenje fizičkih podataka je stranica - modul od 8KB koji pripada samo jednom objektu (na primjer, tablici ili indeksu). Stranica je najmanja jedinica za čitanje i pisanje. Stranice se prikupljaju u obimima. Opseg se sastoji od 8 uzastopnih stranica. Stranice opsega mogu pripadati jednom ili više objekata. Ako stranice pripadaju više od jednog objekta, opseg se naziva "mješoviti".

Njegov sadržaj možete pogledati u nastavku:





Sada kada imamo ideju o tome kako radi jedinica za pohranu na disku, razgovarajmo detaljnije o tablicama i indeksima.

Prema zadanim postavkama, ako se ne koriste posebni T-SQL izrazi, prazna tabela se kreira kao "gomila" - jednostavan skup stranica i ekstenata. Podaci u hrpi nemaju logičan redoslijed. Jezgro SQL Servera prati koje stranice i ekstenti pripadaju određenom objektu koristeći posebne sistemske stranice koje se nazivaju mape dodjeljivanja indeksa. Svaka tabela ili indeks ima najmanje jednu IAM stranicu, nazvanu "prva IAM stranica".


Dakle, nakon kreiranja regularne tabele, podrazumevano se dobija haotičan raspored podataka. Status tabele možete pogledati na sledeći način:


Glavni indeksi koje koristi 1C platforma

Fragment 3

Mitovi i stvarnost:

Mit prvi: grupirani indeksi i tabela podataka su dva različita entiteta pohranjena odvojeno jedan od drugog.

Drugi mit: u jednoj tabeli može biti mnogo grupisanih indeksa.

Skinuo sam program za optimizaciju DBMS-a. Kreirani preporučeni indeksi. Stopa uzorkovanja je povećana za 50%. Promjena i dodavanje podataka je usporilo 7 puta.

Grupirani (klasterirani) indeks

Grupirani indeksi su kolekcija stranica koje sortiraju i pohranjuju redove podataka u tabelama ili pogledima na osnovu njihovih ključnih vrijednosti - kolona uključenih u definiciju indeksa. Postoji ograničenje za ovu vrstu indeksa od 16 kolona i 900 bajtova. Za svaki sto postoji samo jedan grupirani indeks, jer se redovi podataka mogu sortirati samo jednim redoslijedom. Grupirani indeks se kreira reorganizacijom tabele, a ne kopiranjem podataka, što omogućava da se tabela zadrži kao B-stablo.

Fragment 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID ("TraceData")

Neklasterirani indeks

Neklasterirani indeksi su strukturirani odvojeno od redova podataka. Neklasterirani indeks sadrži vrijednosti klasteriziranog indeksnog ključa, a svaki zapis sadrži klasterizirani indeksni ključ (ne RID, budući da 1C tablice ne koriste hrpe, uz rijetke izuzetke).

Možete dodati stupce bez ključa na razinu lista neklasteriranog indeksa i zaobići postojeće ograničenje ključa indeksa od 900 bajtova i 16 ključnih stupaca pokretanjem potpuno indeksiranih upita.

Nakon dodavanja neklasteriranog indeksa, podaci su kopirani i pojavio se drugi objekt:



Fragment 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID ("TraceData")

Šema za klasterirani indeks nakon preuzimanja iz hrpe kao B-stabla:



Šema za neklasterizirani indeks dobiven iz klasterirane tablice (imajte na umu da kolona lokatora reda ima klasterizirani indeksni ključ):



Utjecaj indeksa na performanse upita

Optimizator upita koristi indeks da pretraži ključne stupce indeksa, locira tražene redove i odatle dohvati odgovarajuće redove. Pretraživanje indeksa je mnogo brže od pretraživanja u tablici jer, za razliku od tablice, indeks često sadrži manje kolona po redu, a redovi su sortirani po redu.

Kreiranje više indeksa dovodi do toga da se brzina uzorkovanja povećava, a brzina pisanja tokom modifikacije značajno smanjuje. Da biste riješili ovaj problem, prije svega, potrebno je obrisati nepotrebne indekse ili ih prethodno zaključati bez brisanja, što će vam omogućiti da ih jednostavno omogućite, ako se ukaže takva potreba.

Imajte na umu da se klasterirani indeks ne može zaključati ni u kom slučaju, jer ovo će zatvoriti pristup podacima tabele. Ovo se odnosi samo na indekse koje ste sami kreirali preko T-SQL-a. Razlog za kreiranje indeksa korišćenjem T-SQL-a, zaobilazeći 1C: Enterprise, prvenstveno je povezan sa ograničenim mogućnostima 1C platforme u smislu manipulisanja indeksima i uključivanja dodatnih polja u kreirani indeks.

T-SQL izraz koji izvodi radnju za zaključavanje indeksa:

// Zaključavanje zasebnog indeksa na tablici -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; // Uključi željeni indeks -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

Pored gornjih koraka, važno je kreirati grupu datoteka na fizičkom disku koji ne sadrži trenutne datoteke baze podataka i tamo premjestiti neklasterirane indekse. Ovo će ubrzati izmjenu podataka paralelizirajući njihovo pisanje.

Određivanje potrebnih ili suvišnih indeksa za ubrzavanje upita

Podrazumevano, 1C kreira određeni osnovni skup indeksa. Često ih jednostavno nema dovoljno. SQL Server ima mehanizme koji vam omogućavaju da shvatite, na osnovu radnog opterećenja, koliko su dostupni indeksi potrebni.

Database Engine Tuning Advisor analizira baze podataka i daje preporuke za optimizaciju performansi upita. Može se koristiti za odabir i kreiranje optimalnih skupova indeksa bez ekspertskog nivoa razumijevanja strukture baza podataka ili internih procesa SQL Servera. Database Engine Tuning Advisor vam omogućava da:

  • Rješavanje problema u izvedbi specifičnog problematičnog upita;
  • Postavljanje velikog skupa upita u jednoj ili više baza podataka.

Objekti dinamičkog upravljanja (DMO), koji uključuju dinamičke poglede upravljanja i funkcije dinamičkog upravljanja. Na primjer, T-SQL izraz može dohvatiti sve indekse koji nisu korišteni od posljednjeg pokretanja poslužitelja.



Fragment 6

SA vl kao (IZABIR OBJECT_NAME (I.object_id) AS objectname, I.name AS indexname, I.index_id AS indexid FROM sys.indexes KAO I INNER JOIN sys.objects KAO O ON O.object_id = I.object_id GDJE I.object_id > 100 I I.type_desc = "NONCLUSTERED" I I.index_id NIJE IN (IZABIR S.index_id FROM sys.dm_db_index_usage_stats KAO GDJE S.object_id = I.object_id I I.index_id = S.index_id I database_id" = DB_ID '))) SELECT objectname, T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C (objectname) kao T1 ORDER BY objectname, indexname;

Upute s kojima možete kreirati potrebne indekse koje preporučuje mehanizam baze podataka:



Fragment 7

SELECT T1.NameTable1C kao Table_Name_1C, "CREATE INDEX" + "ON"
Optimizator upita otkriva potrebu za kreiranjem indeksa koji nedostaje tokom generiranja plana izvršenja upita. Pohranjuje ove informacije u XML ShowPlan. Jer planovi upita se heširaju i upute se čuvaju (do sljedećeg ponovnog pokretanja servera), zatim se mogu preuzeti, obraditi i gotove upute za kreiranje potrebnih indeksa za bilo koji plan izvršenja u kešu. Vrijedno je obratiti pažnju na učestalost izvršavanja upita: što je veća, to su rezultati izvršenja upita relevantniji i, shodno tome, prikupljene metrike. Ako je upit izvršen samo jednom, njegovi rezultati nisu toliko indikativni.


Fragment 8

KRIŽNA PRIMJENA query_plan.nodes ('// StmtSimple ") KAO stmt (stmt_xml) GDJE stmt_xml.exist (" QueryPlan / Missinglndexes ") = 1) ODABERITE TOP 30 DatabaseName kao Database_Name, Tcool Column_Na_Name_Name, Tco_Colup_Name_Name. kao Uključi kolone,

Fragment 9

KORISTI [DatabaseName] IDI KREIRAJ NONCLUSTERED INDEX UKLJUČENO [_ Document497] ([_Fld12771_TYPE], [_ Fld12771_RTRef]) UKLJUČI ([_Date_Time], [_ Fld12771_RRGORef127] [8_2) Neke karakteristike indeksiranja po poljima agregata i sortiranja.

Kreiranje indeksa na stupcima navedenim u klauzuli ORDER BY pomaže optimizatoru upita da brzo organizira skup podataka rezultata jer su vrijednosti stupaca sortirane unaprijed u indeksu. Interna implementacija mehanizma GROUP BY također prvo sortira vrijednosti stupaca kako bi brzo grupirala potrebne podatke.

Kada koristite tipične preporuke, vrijedi provjeriti rezultat prije i nakon optimizacije. Navedimo primjer korištenja logičkog spoja "ILI" i njegove alternative (da bismo eliminirali problem sa tipičnim preporukama) - tehniku ​​za modificiranje upita koristeći sintaksu "COMBINE ALL".

Sam 1C zahtjev sa "ILI":

SELECT Code, Name, Link FROM Directory.Contractors AS Računi GDJE Računi. Šifra = "000000004" ILI Računi. Šifra = "0074853" ILI Računi. Šifra = "000000024" ILI Računi. Šifra = "009679294" OR. Šifra = "Računi 0074742 "OR Izvođači radova. Šifra =" 000000104 ";

Izmjena upita sa "KOMBINI SVE":

ODABERITE kod, naziv, vezu IZ imenika. Ugovarači KAO druge strane GDJE Supruge. Šifra = "000000004" JEDINICA SVE SELECT Šifra, naziv, veza IZ reference. Ugovarači KAO druge strane GDJE Counterparts. Šifra = "0074853" KOMBINIRAJ Kôd direktora SVE ODABIR Ugovora AS Contractors WHERE Contractors.Code = "000000024" UNIT ALL SELECT Kod, Naziv, Referenca IZ Imenika.Contractors AS Contractors WHERE

Stvarni plan upita (radi lakšeg prikaza i poređenja performansi, upiti se presreću i izvršavaju u SSMS-u):


U ovom slučaju, nakon optimizacije, performanse su pale za polovinu zbog ponovljene upotrebe Key Lookup operatora, koji je uvijek praćen operatorom Nested Loops. Stoga, koristeći šemu optimizacije upita, trebali biste izmjeriti ciljno vrijeme prije i nakon korištenja revizija. Ovaj primjer je prikazan u svrhu „vjeruj ali provjeri“, jer može postojati nedosljednost između tipičnih najboljih praksi i praktičnih zadataka.

Vrlo često nam se postavljaju pitanja poput:

  • zašto 1C server usporava?
  • kompjuter sa 1C radi veoma sporo
  • 1C klijent je užasno spor

Ponekad, kao rješenje problema, klijentima nudimo server za 1C za iznajmljivanje bez kočnica, uz izbor konfiguracije servera i operativnog sistema, server možete konfigurirati online na web stranici našeg partnera, putem linka https://1cloud.ru poglavlje Usluge, poglavlje Virtuelni server.

Šta učiniti i kako to pobijediti, i tako redom:

Klijenti rade vrlo sporo sa serverskom verzijom 1C

Osim sporog rada 1C, postoji i spor rad s mrežnim datotekama. Problem se javlja tokom normalnog rada i tokom RDP-a

da bih to riješio, nakon svake instalacije servera Seven ili 2008, uvijek pokrećem

netsh int tcp set globalno autotuning = onemogućeno

netsh int tcp set global autotuninglevel = onemogućen

netsh int tcp set global rss = isključen dimnjak = onemogućen

i mreža radi bez problema

ponekad je optimalno:

netsh interfejs tcp set global autotuning = Visoko ograničeno

ovako izgleda instalacija

Konfigurišite Antivirus ili Windows zaštitni zid

Kako da konfigurišete Anti-Virus ili Windows zaštitni zid za rad 1C servera (link sa 1C servera: Enterprise i MS SQL 2008, na primer).

Dodajte pravila:

  • Ako SQL server prihvata veze na standardnom TCP portu 1433, mi to dozvoljavamo.
  • Ako je SQL port dinamičan, tada je potrebno dozvoliti konekcije sa aplikacijom% ProgramFiles% \ Microsoft SQL Server \ MSSQL10_50.MSSQLSERVER \ MSSQL \ Binn \ sqlservr.exe.
  • Server 1C radi na portovima 1541, klasteru 1540 i opsegu 1560-1591. Iz potpuno mističnih razloga, ponekad takva lista otvorenih portova i dalje ne dozvoljava povezivanje sa serverom. Da bi sigurno radio, dozvolite raspon 1540-1591.

Podešavanje performansi servera/računara

Da bi računar radio sa maksimalnim performansama, potrebno je da ga konfigurišete za ovo:

1. BIOS postavke

  • Onemogućite sve postavke da biste uštedjeli snagu procesora u BIOS-u servera.
  • Ako postoji "C1E" i obavezno ODSKLJUČITE !!
  • Za neke ne baš paralelne zadatke, preporučuje se i onemogućavanje hipertrgovine u BIOS-u
  • U nekim slučajevima (posebno za HP!) morate ući u BIOS servera i ONEMOGUĆITI tamo stavke čiji su nazivi EIST, Intel SpeedStep i C1E.
  • Umjesto toga, potrebno je na istom mjestu pronaći stavke vezane za procesor u čijem nazivu stoji Turbo Boost i UKLJUČITI ih.
  • Ako BIOS ima opću indikaciju načina uštede energije i omogućite ga u režimu maksimalnih performansi (može se nazvati i "agresivnim")

2. Postavke šeme u operativnom sistemu - Visoke performanse

Serveri sa Intel Sandy Bridge arhitekturom mogu dinamički da menjaju frekvencije procesora.

Ponekad je rješenje problema sporog rada 1C servera zastarjela ili pokvarena oprema, u ovom slučaju klijentima nudimo server za 1C za iznajmljivanje bez kočnica, uz izbor konfiguracije servera i operativnog sistema, možete ga pronaći na web stranicu našeg partnera, putem linka https://1cloud.ru odeljak Usluge, odeljak Virtuelni server.

Ako imate bilo kakvih pitanja kontaktirajte:

  • pozovite + 7-812-385-55-66 u Sankt Peterburgu
  • pisite na adresu
  • ostavite zahtjev na našoj web stranici na stranici "Online prijava".

Top srodni članci