Imajte na umu da su postavke klastera odgovorne za postavke svih poslužitelja koji pripadaju prilagođenom klasteru. Klaster podrazumijeva rad nekoliko fizičkih ili virtualnih poslužitelja koji rade s istim bazama podataka.

Interval ponovnog pokretanja - odgovoran za učestalost ponovnog pokretanja radnih tokova klastera. Ovaj parametar mora se postaviti tijekom rada poslužitelja koji radi non-stop. Preporuča se da frekvencija ponovnog pokretanja bude povezana s tehnološkim ciklusom baza podataka klastera. Obično je to svaka 24 sata (86.400 sekundi). Kao što znate, radni procesi 1C poslužitelja obrađuju i pohranjuju radne podatke.

Automatsko ponovno pokretanje razvijeno je na platformi "kako bi se smanjili negativni efekti fragmentacije i curenja memorije u radnim tokovima." Postoje čak i informacije o ITS-u o tome kako organizirati ponovno pokretanje tijekova rada prema drugim parametrima (količini memorije, korištenim resursima itd.).

Dozvoljena memorija - štiti 1C server od prekoračenja memorije. Ako postupak premašuje ovaj volumen u višak raspona, proces se ponovo pokreće. Može se izračunati kao maksimalna veličina memorije koju zauzimaju rphost procesi tokom razdoblja najvećeg opterećenja servera. Također je vrijedno postaviti mali interval za prekoračenje dopuštene zapremine.

Tolerancija broja grešaka na poslužitelju. Platforma izračunava prosječni broj pogrešaka poslužitelja u odnosu na broj poslužiteljskih poziva u roku od 5 minuta. Ako ovaj omjer prelazi dopušteni, tada se tok rada smatra „problematičnim“ i sustav ga može dovršiti ako je postavljena zastava "Prisilno završeni problematični procesi."

Procesi gašenja mogu se zaustaviti. Ako je prekoračena dopuštena količina memorije, tijek rada ne završava se odmah, već se "isključuje" tako da ima vremena za "prijenos" radnih podataka bez gubitka u novi tekući tijek rada. Ako je naveden ovaj parametar, postupak "isključeno" u svakom slučaju će se završiti nakon tog vremena. Ako u radu 1C poslužitelja postoje "obješeni" tokovi rada, tada ovaj parametar može vrijediti 2-5 minuta.
Ove postavke su postavljene za svaki 1C poslužitelj pojedinačno.

Maksimalna memorija tokom rada Je li glasnoća agregat memorija koja radni tokovi (rphost) na trenutnom klasteru mogu zauzeti. Ako je parametar postavljen na "0", tada on zauzima 80% RAM-a servera. „-1“ - bez ograničenja. Kada se DBMS i 1C poslužitelj pokreću na istom poslužitelju, oni trebaju međusobno dijeliti RAM. Ako se tijekom rada otkrije da DBMS poslužitelj nema dovoljno memorije, pomoću ovog parametra možete ograničiti memoriju dodijeljenu 1C poslužitelju. Ako su DBMS i 1C razdijeljeni od poslužitelja, ima smisla izračunati ovaj parametar pomoću formule:

"Max volume" \u003d "General RAM" - "RAM memorija";

"OS RAM" se izračunava na osnovi 1 GB za svakih 16 GB RAM-a poslužitelja

Sigurno korištenje memorije po pozivu. U općenitom slučaju, posebni pozivi ne bi trebali zauzimati svu RAM-u dodijeljenu tijeku rada. Ako je parametar postavljen na "0", volumen sigurnog protoka bit će jednak 5% od " Maksimalna memorija tokom rada “. "-1" - bez ograničenja, što se toplo ne preporučuje. U većini slučajeva ovaj je parametar najbolje ostaviti na „0“.

Korištenje parametara „Broj informacijske sigurnosti po procesu“ i „Broj veza po procesu“ Možete kontrolirati distribuciju radnih tokova 1C poslužitelja. Na primjer, pokrenite zasebni "rphost" za svaku info bazu, tako da u slučaju "pada" procesa, isključit će se samo korisnici jedne baze podataka. Ove parametre treba odabrati pojedinačno za svaku konfiguraciju poslužitelja.

Ograničenje upotrebe RAM-a od strane DBMS poslužitelja - MS SQL DBMS poslužitelj ima jednu izvanrednu osobinu - voli učitati baze podataka s kojima se u potpunosti radi u RAM-u. Ako ga ne ograničite, oduzet će svu RAM memoriju koju može.

Ako je 1C: Enterprise poslužitelj instaliran zajedno s Microsoft SQL Serverom, tada se gornji prag memorije mora smanjiti za količinu dovoljnu da 1C poslužitelj radi.
Ako se samo DBMS izvodi na poslužitelju, tada za DBMS koristi formula:

„DBMS memorija“ \u003d „General RAM“ - „OS RAM“;

Zajednička memorija - Zna se mnogo o ovom parametru, ali i dalje se događa da oni zaborave na njega. Postavili smo ga na "1" ako 1C poslužitelj i DBMS rade na istom fizičkom ili virtualnom poslužitelju. Usput, djeluje počevši od platforme 8.2.17.

Maksimalni stepen paralelizma - određuje koliko se procesora koristi pri izvršavanju jednog zahtjeva. DBMS paralelizira pretraživanje podataka pri izvođenju složenih upita na više niti. Za 1C preporučuje se podešavanje na „1“, odnosno s jednim tokom.

Automatsko proširenje DB datoteke - određujemo korak u MB s kojim se datoteka baze podataka "proširuje". Ako je korak mali, tada će uz aktivni rast baze podataka česta proširenja dovesti do dodatnog opterećenja na diskovnom sustavu. Bolje je instalirati u 500 - 1000 MB.

Ponovno indeksiranje i defragmentiranje indeksa - Preporučuje se defragmentacija / ponovna deksidacija najmanje jednom sedmično. Ponovno postavljanje blokova tablice, tako da je bolje pokretati nakon sati ili tokom perioda minimalnog opterećenja. Nema smisla raditi defragmentaciju nakon ponovne izgradnje indeksa (ponovnog deksidiranja). Na preporuku Microsofta, defragmentacija se vrši ako fragmentacija indeksa ne prelazi 30%. Ako je viša, preporučuje se ponovno dexeksiranje.

Plan napajanja - u postavkama napajanja operativnog sistema postavljenih na visoke performanse.

sada malo detaljnije:

Klaster 1C 8.3

Prije svega, nakon instaliranja 1C klastera, prethodno je bilo potrebno stvoriti radne tokove. Kako se ispostavilo, procesi klastera počeli su se automatski stvarati ovisno o opterećenju baze podataka.

Probni rad pozadinskih zadataka glavne baze podataka učinio je 1C klaster beskrajno preopterećiti rphost.exe, a dodatni rphost.exe nije želio biti stvoren ni na koji način. Pretražujući postavke, sve je postalo jasno.

Maksimalna memorija tokom rada je količina memorije koju radni tokovi mogu koristiti zajedno. Morate biti vrlo oprezni prilikom postavljanja parametra, mjerenih u bajtovima. Ako postavite pogrešnu vrijednost (nedovoljnu za normalan rad korisnika), korisnici će dobiti pogrešku "Nema dovoljno slobodne memorije na 1C poslužitelju." Ovu grešku možete dobiti i kada je memorijska kvota završila na serveru 1C.

Sigurno korištenje memorije po pozivu - omogućava vam kontrolu potrošnje memorije tokom poziva poslužitelja, mjereno u bajtovima. Ako poziv koristi više memorije nego što se očekivalo, ovaj poziv bit će završen unutar 1C klastera bez ponovnog pokretanja tijeka rada (rphost.exe). Prema tome, "gubitnik" koji je uputio poslužiteljski poziv izgubit će sesiju s 1C bazom bez utjecaja na rad drugih korisnika.

u jednom GB - 1073741824 bajta, dakle u 2 GB - 2147483648 bajtova

Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom - ako se ovaj parametar premaši, poslužitelj u 1C klasteru će prestati prihvaćati nove veze.

Broj IB-a po postupku- omogućuje vam izoliranje baza podataka o tijekovima rada. Prema zadanim postavkama, trenutni klaster 1C bio je postavljen na "8", ali nekoliko sati sam poslužitelj je bio vrlo nestabilan, korisničke sesije su prekinule. Nakon izolacije svake baze podataka (vrijednost - „1“), problemi su nestali.

Broj veza po postupku - Zadana vrijednost je "128". Budući da trenutna baza ima veoma veliko opterećenje pozadinskih zadataka (izračunavanje logistike, analiza cijena, analiza konkurenata itd.), Odlučeno je da se broj smanji na "25".

Postavke samog 1C klastera su se takođe malo promijenile:

Nivo tolerancije greške- ovo je broj radnih poslužitelja koji istovremeno mogu uspjeti, a to neće dovesti do hitnog isključivanja korisnika. Usluge izrade sigurnosnih kopija pokreću se automatski u onoj mjeri koja je potrebna kako bi se osigurala zadana tolerancija greške. U stvarnom vremenu, aktivna usluga se replicira u pripravnosti.

Način dijeljenja opterećenja - postoje dvije opcije za parametar: "Prioritet u performansama" - memorija servera se troši više i performanse su veće, "Prioritet u memoriji" - klaster 1C štedi memoriju poslužitelja.

Server 8.3 karakterizira redizajnirani interni kod, mada može izgledati "izvana" da je modificirani 8.2.

Poslužitelj je postao više "automatski podesiv", dio parametara poput broja radnih procesa se više ne izrađuje ručno, već se izračunava na temelju opisa zahtjeva tolerancije kvarova i pouzdanosti.

To smanjuje vjerojatnost pogrešnih postavki poslužitelja i snižava zahtjeve za kvalifikaciju administratora.

Razvijen je mehanizam za uravnoteženje opterećenja, koji se može koristiti ili za poboljšanje performansi sistema u cjelini ili korištenja novog načina „uštede u memoriji“, koji omogućava rad sa „ograničenom memorijom“ u slučajevima kada korištena konfiguracija „voli jesti memoriju“.

Stabilnost pri korištenju velike količine memorije određuje se novim parametrima radnog servera.

Posebno je zanimljiva opcija „sigurne potrošnje memorije po pozivu“. Za one koji imaju lošu predstavu o tome šta je - bolje je ne trenirati „produktivno“. Parametar „Maksimalna količina memorije radnog toka“ omogućava da tokom „overflowa“ ne uruši čitav tok rada, već samo jedan „sa gubitnikom“. "Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom" omogućava vam blokiranje novih veza čim se prijeđe ovaj prag memorije.

Preporučujem izoliranje radnih tokova od info baza, na primjer, specificiranje parametra „Broj IS po procesu \u003d 1 ″. S nekoliko visoko opterećenih baza podataka, to će smanjiti međusobni utjecaj kako u pouzdanosti tako i u performansama.

Poseban doprinos stabilnosti sistema predstavlja „trošenje“ licenci / ključeva. U 8.3. Postalo je moguće koristiti „softverski menadžer licenci“ koji liči na „aladin“ menadžera. Cilj je mogućnost odvođenja ključa u zasebnu mašinu.

Provodi se kao još jedna "usluga" u cluster manageru. Možete koristiti, na primjer, „besplatni“ laptop. Dodajte ga u klaster 1c 8.3, kreirajte zasebnog upravitelja na njemu pomoću usluge "usluga licenciranja". Možete da ubacite hardverski hasp ključ u laptop ili aktivirate softverske licence.

Najveći interes za programere trebao bi predstavljati "Zahtjevi za imenovanje funkcionalnosti".

Uslovi za dodeljenu funkcionalnost 1s

Dakle, na laptopu sa sigurnosnim ključem, kako ne biste pokrenuli korisnike na cluster poslužitelju, morate dodati „zahtjeve“ za objekt zahtjeva „Povezivanje klijenta s IB“ - „Ne dodijeli“, tj. Sprečite radne procese ovog poslužitelja da obrađuju veze klijenta.

Od još većeg interesa je mogućnost pokretanja „samo pozadinskih poslova“ na radnom klaster poslužitelju bez korisničkih sesija. Tako se visoko opterećeni zadaci (kôd) mogu prenijeti u zasebni stroj. Štaviše, na jednom je računalu moguće pokrenuti jedan pozadinski zadatak „zatvaranje mjeseca“ putem „Vrijednosti dodatnog parametra“, a na drugom pozadinski zadatak „Ažuriranje indeksa punog teksta“. Dopunjavanje se ukazuje na „Vrijednost dodatnog parametra“. Na primjer, ako kao vrijednost navedete BackgroundJob.CommonModule, rad proizvodnog poslužitelja u klasteru možete ograničiti na samo pozadinske zadatke s bilo kojim sadržajem. Vrijednost BackgroundJob.CommonModule.<Имя модуля>.<Имя метода> - navesti određeni kod.

Klaster 1C 8.2

Sesije vam omogućavaju da uravnotežite radno opterećenje i toleranciju grešaka u upravljanoj aplikaciji.

Upravitelj klastera sada je složeniji. Neke se funkcije sada mogu odvojiti u zaseban proces i čak staviti na drugi radni server klastera. To vam omogućava da uravnotežite opterećenje servera.

Tolerancija greške poslužitelja 8.2 postiže se:

Spremanje podataka o sesiji korisnika.
Korisnik više nije vezan za tijek rada.
Rezervacija radnih procesa u klasteru.
Mora postojati nekoliko radnih tokova, uključujući suvišne
Rezervacija klastera

Rezervni klaster je označen, kada su spojeni, navedeni su u priključnom nizu

To osigurava kontinuirani rad!

Kada se prekine fizička veza klijenta s klasterom (čistač je izvukao kabel, mrežna oprema je isključena, provajder je imao problema), nije potrebno ponovno se povezati s bazom podataka i započeti sve radove ponovo. Nakon vraćanja fizičke veze, korisnik može nastaviti s radom od mjesta na kome je prekinuta.

Ako je potrebno održavanje klasterskih računala, oni se mogu isključiti ispravno tijekom rada bez sprečavanja korisnika da rade s bazom podataka.

Ako bilo koji poslužitelj u klasteru ne uspije, rad korisnika neće se zaustaviti, automatski će se prenijeti u sigurnosne kopije i / ili radne procese izrade sigurnosnih kopija. Za korisnike će ovaj prijelaz biti neupadljiv.

Ako se jedan od radnih tijekova klastera sruši, korisnici koji su spojeni na njega automatski će se prebaciti u druge ili u pripravnosti. Takav će prelaz biti nevidljiv i za korisnike.

Često druge usluge - terminalni poslužitelj, SQL server itd. - rade s 1C: Enterprise serverom na uređaju. I u nekom trenutku 1C: Enterprise poslužitelj, tačnije rphost radni tijek, pojede više memorije nego što je planirano ili svu memoriju. To dovodi do usporavanja drugih servisa i zombija na poslužitelju. Da bi se izbjegle takve situacije, potrebno je konfigurirati automatsko ponovno pokretanje radnih procesa 1C: Enterprise poslužitelja

Odluka

1. Otvorite administrativnu konzolu 1C Enterprise servera;
2. Proširite stablo centralnog poslužitelja na klastere i odaberite klaster koji nas zanima. U primjeru postoji samo jedan klaster;
3. Otvorite svojstva odabranog klastera i pogledajte sljedeći obrazac

Server 1C: Svojstva klastera poslužitelja 8.3

Analizirajmo primer prikazan na slici:

Interval ponovnog pokretanja - vrijeme nakon kojeg će se postupak rfosta prisilno pokrenuti. Prije nego što se proces zaustavi, pokreće se novi rphost proces na koji se prenose sve veze, a tek tada će stari proces biti dovršen. Ovo neće uticati na rad korisnika. Interval je naveden u sekundi, u primjeru 24 sata.

Dozvoljena memorija - količinu memorije u kojoj tijek rada može raditi bez problema. Glasnoća je navedena u kilobajtima, na primjeru je vrijednost 20 gigabajta (u stvari, cifra je prevelika i trebate započeti s određenog sustava, ali prosječna je vrijednost 4 GB). Čim memorija zauzeta tijekom rada premaši navedenu vrijednost, odbrojavanje započinje.

Interval prekoračenja memorije - nakon što se tajmer pokrene, nakon što prekorači dopuštenu količinu memorije, broji određeno vrijeme, započinje novi tijek rada na koji se prenose sve veze, stari postupak se označava isključenim. Interval je naveden u sekundi, u primjeru 30 sekundi.

Procesi gašenja mogu se zaustaviti - vrijeme nakon kojeg će se zaustaviti tijek rada koji je označen kao isključen; ako je navedena vrijednost 0, proces neće biti dovršen. Interval je naveden u sekundi, u primjeru 60 sekundi.

Nakon primjene postavki ne možete ponovo pokrenuti uslugu poslužitelja, oni se primjenjuju dinamički.

Ukupno

Tako smo postavili automatsko ponovno pokretanje radnih procesa 1C: Enterprise poslužitelja i dobili smo stabilniji sistem; ako dođe do curenja memorije, zaustavit će se specifična sesija.

U nekim se situacijama možete poigrati s postavkama i spriječiti mogući pad sustava ako se naprave greške.

Ispis (Ctrl + P)

U ovom članku pregledavam glavne aktivnosti koje je potrebno obaviti za povećanje performansi 1C u verziji 1C klijent-poslužitelj:

Povećanje hardverskih kapaciteta.
Konfiguriranje 1C: Enterprise Server
Podešavanje SQL servera
Optimizacija koda i algoritama u 1C.

1. Povećanje hardverskog kapaciteta

Minimalni zahtevi za računarima koji su dostavljeni na sertifikaciju kompaniji „C“ za dobijanje logotipa „Kompatibilno! Sistem programa 1C: Enterprise "su napisani

Performanse 1C poslužitelja: poduzeće u velikoj mjeri ovisi o frekvenciji procesora, a za poslužitelj baze podataka karakteristike računala moraju zadovoljiti zahtjeve Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Konfiguriranje 1C: Enterprise poslužitelja

Upute za postavljanje proizvodnih poslužitelja s tehnološkom platformom 1C: Enterprise mogu se pregledati na ITS disku

U verziji 8.3 dodano je nekoliko novih parametara u konfiguraciji proizvodnih poslužitelja:

Maksimalna memorija tokom rada. Postavka vam omogućava podešavanje količine memorije koja može biti zauzeta svim radnim procesima ovog klastera na ovom radnom poslužitelju.
Sigurno korištenje memorije po pozivu. Podešavanje vam omogućuje ograničenje količine memorije koja će biti zauzeta prilikom upućivanja poslužiteljskog poziva na ovom proizvodnom poslužitelju.
Broj sigurnosti informacija po procesu i broj veza po procesu. Ova podešavanja omogućuju vam neizravno upravljanje brojem radnih procesa na ovom proizvodnom poslužitelju.
Menadžer za svaku uslugu. Postavljanje vam omogućava pokretanje svake usluge upravljanja klasterima kao zaseban proces.

3. Podešavanje SQL servera

Značajka podešavanja Microsoft Sql servera u cilju povećanja performansi može se vidjeti na ITS disku

Koristeći Plan održavanja u odjeljku za upravljanje, morate izvršiti sljedeće planirane zadatke za povećanje produktivnosti:

Defragmentacija indeksa i ažuriranje statistika trebalo bi raditi svakodnevno, jer ako je fragmentacija indeksa\u003e 25%, to dramatično smanjuje performanse poslužitelja.
Defragmentacija i ažuriranje statistika - vrši se brzo i ne zahtijeva isključenje korisnika. Takođe se preporučuje raditi svakodnevno.
Potpuna ponovna deksidacija - vrši se s blokiranjem baze podataka, preporučuje se to raditi najmanje jednom sedmično. Naravno, nakon potpunog ponovnog dexeksiranja, odmah se vrši defragmentacija indeksa i ažuriranje statistika.

3.1 analiza stupnja fragmentacije indeksa

Prekomjerna fragmentacija indeksa stvara probleme velikim operacijama I / O. Nakon izvođenja intenzivnih operacija izmjene podataka u tablicama baze podataka, vrijeme izvršavanja upita i operacija izmjene podataka se povećava.

To je zbog činjenice da se tijekom takvih operacija indeksi modificiraju, što dovodi do njihove rascjepkanosti i povećanja broja operacija ulaza / izlaza prilikom korištenja indeksa u procesu čitanja i pisanja podataka.

Za efikasnu upotrebu indeksa Potreban je Microsoft SQL Server

Redovno reindeksirajte tablice baze podataka naredbom DBCC DBREINDEX ( table_name ) .
Redovno defragmentirajte indekse baze podataka pomoću naredbe DBCC INDEXDEFRAG (ime_ baze podataka, table_name index_name) .

Izbor načina za rješavanje ovog problema ovisi o intenzitetu operacija za izmjenu tablica baze podataka.

MS SQL Server 2005 predstavio je nove alate za kontrolu ovog parametra.

Funkcija dinamičke kontrolne tablice sys.dm_db_index_physical_stats vraća postotak fragmentacije u stupcu avg_fragmentation_in_percent. Ako vrijednost u ovom stupcu prelazi 25%, preporučuje se defragmentirati ovaj indeks radi vraćanja izvornih parametara performansi. Skeniranje velikih raspona podataka koji su uobičajeni u aplikacijama za skladištenje podataka i izvještavanje mogu imati koristi od smanjene fragmentacije indeksa.

Upotreba ovih podataka može značajno smanjiti opterećenje sustava i izbjeći nepotrebnu defragmentaciju onih indeksa za koje nije potreban.

3.2 Korištenje fizičke memorije veće od 2 GB u Microsoft SQL Serveru

Microsoft SQL Server 2000 Standardno izdanje i Microsoft SQL Server 2005 Workgroup Editionmogu koristiti do 2 GB fizičke memorije koja se dinamički raspoređuje i oslobađa ovisno o radnom opterećenju. Sa porastom volumena baze podataka, ova količina RAM-a postaje nedovoljna za učinkovito predmemoriranje podataka i održavanje performansi na prihvatljivoj razini.

3.3 Smanjenje veličine dnevnika transakcija Microsoft SQL Server

Izvođenje intenzivnih operacija radi izmjene podataka info baze dovodi do povećanja veličine datoteka s podacima i dnevnika transakcija. U nekom trenutku stari unosi u dnevnik transakcija postaju nepotrebni za oporavak baze podataka i mogu se izbrisati, čime se oslobađa prostor za nove unose. Ako ne blagovremeno izbrišete stare zapise dnevnika transakcija, nakon nekog vremena datoteka dnevnika transakcija može zauzeti sav slobodni prostor na disku i rad s bazom podataka postat će nemoguć.

Da biste smanjili veličinu datoteke dnevnika, prvo morate izbrisati neaktivne zapise dnevnika transakcija pomoću naredbe BACKUP LOG, a zatim pomoću naredbe DBCC SHRINKFILEsmanjite veličinu datoteke dnevnika transakcija. Slijed naredbi koje se izvršavaju u Upitni analizator, kao što slijedi:

BACKUP LOG Ime baze podataka SA TRUNCATE_ONLY

DBCC SHRINKFILE(Transaction_Journal_File_Name)

3.4 Premještanje TEMPDB baze podataka na drugi veći pogon.

TEMPDB je sistemska baza podataka Microsoft SQL Server, koja pohranjuje privremene tablice koje su kreirali i sam poslužitelj i korisnici. Ova se baza podataka rekreira svaki put kada ponovno pokrenete Microsoft SQL Server. Veličina ove baze podataka prema zadanim postavkama je neograničena i automatski se povećava, ako je potrebno, u dijelovima od 10% trenutne veličine TEMPDB. Međutim, korisnik ove parametre može nadjačati. Prema zadanim postavkama minimalna veličina ove baze podataka koja se postavlja kada se pokrene Microsoft SQL Server, određuje se veličinom baze podataka MODEL. Dnevnik transakcija automatski se briše u ovoj bazi podataka, a brišu se samo neaktivni unosi dnevnika transakcija.

Kada 1C: Enterprise 8 radi u režimu klijent-poslužitelj, privremene tablice se široko koriste . Pored toga, TEMPDB koristi Microsoft SQL Server prilikom postavljanja upita pomoću izraza. GRUPA PO, UNION, Različita itd.

U procesu 1C: Enterprise 8, moguće je značajno povećanje veličine TEMPDB baze podataka. Ako veličina diska na kojoj se nalazi TEMPDB baza podataka nije dovoljna, rad 1C: Enterprise 8 možda neće uspjeti.

Ako se ovaj problem javlja redovito, preporučuje se premještanje TEMPDB-a na drugi veći pogon.

Ova se operacija može izvesti na sljedeći način:

1. odrediti logička imena datoteka baze podataka TEMPDB (stupac "IME" rezultata postupka). Da biste to učinili, pokrenite sljedeću naredbu u Query Analyzeru:

UPORABI tempdb GO EXEC sp_helpfile GO 2. promijeni lokaciju datoteka TEMPDB baze podataka naredbom ALTER BATABASE. Da biste to učinili, pokrenite sljedeći niz naredbi u Analizatoru upita: UPORABITE master GO ALTER DATABASE tempdb MODIFY FILE (NAME \u003d tempdev, FILENAME \u003d "New_Disk: \\ New_Catalog \\ tempdb.mdf") PROMIJENITE DATABASU tempdb MODIFY FILE (NAME \u003d templog, FILENAME \u003d "New_Drive: \\ New_Directory \\ templog.ldf") GO 3. Ponovo pokrenite Microsoft SQL Server.

4. Optimizacija koda i algoritama u 1C

4.1 Optimizacija upita

Značajan dio problema koji vode do suboptimalnog rada s upitima može se otkriti analizom konfiguracijskog koda i strukture metapodataka. Postoji lista tipičnih pogrešaka u kodu i strukturi podataka, čije su posljedice prilično dobro proučene i lako predvidljive. Analiza koda pomoću ove liste omogućuje vam rješavanje većine problema s izvedbom upita bez uranjanja u detaljne tehničke informacije (tekst upita u SQL-u, plan upita itd.).

Glavni razlozi neaptimalnog rada upita dijagnosticiranih na razini konfiguracijskog koda i strukture metapodataka smatraju se na ITS disku:

podupitnica se pridružuje
veze na virtualne tablice
neusklađenost indeksa i upita za upite
koristeći logički ILI u uvjetima
koristeći podupite u stanju pridruživanja
primanje podataka putem tačke iz polja složene vrste
filtriranje virtualnih tablica bez korištenja parametara

4.2 Korišćenje merenja performansi

1C: Enterprise 8 omogućava vam uklanjanje pogrešaka i mjerenje performansi za kôd na ugrađenom jeziku koji se može izvršiti i na klijentu i na poslužitelju. Značajka rada mjerenja performansi za bazu podataka klijent-poslužitelj u 1C: Enterprise 8 je da su rezultati mjerenja performansi kombinirani u jednu datoteku. Oni uključuju podatke o napretku izvršavanja koda na ugrađenom jeziku kako na klijentu tako i na poslužitelju. Da biste dobili takvo mjerenje, dovoljno je pokrenuti poslužitelj 1C: Enterprise 8 u načinu uklanjanja pogrešaka (koristeći tipku naredbenog retka / debug ), a u Konfiguratoru u pravo vrijeme samo uključite način mjerenja performansi.

Način mjerenja performansi u 1C: Enterprise 8 omogućava vam uspješno optimiziranje performansi klijent-poslužiteljskih aplikacija. Da biste izvršili ovu optimizaciju, dovoljno je izvršiti samo nekoliko koraka, nakon čega analizirati rezultate mjerenja performansi i nastaviti poboljšavanje koda na ugrađenom jeziku.

Više informacija o korištenju mjerenja performansi može se pronaći na ITS disku.

Prije nego što započnete rad na optimizaciji sustava, uvijek je potrebno dobiti početnu procjenu performansi pomoću „integrirane procjene performansi sistema APDEX“.

4.3 Alat za preradu koda

Funkcije refaktoringa koda implementirane u konfiguratoru platforme 8.3.5, 1068. kao i funkcije automatske pretvorbe modalnih metoda i odjeljaka kodova prikazane su na slici 1.

Slika 1 Alat za preusmjeravanje koda u konfiguratoru

Programeri platforme objašnjavaju potrebu za tim alatima činjenicom da kôd aplikativnih rješenja treba biti jasan, pogotovo kada na konfiguraciji radi grupa od nekoliko programera. Tada se programski kod lako održava i mijenja.

Server 8.3 karakterizira redizajnirani interni kod, mada može izgledati "izvana" da je modificirani 8.2.

Poslužitelj je postao više "automatski podesiv", neki se parametri, poput broja radnih procesa, više ne stvaraju ručno, već se izračunavaju na temelju opisa zahtjeva zadataka za toleranciju grešaka i pouzdanost.

Razvijen je mehanizam za uravnoteženje opterećenja, koji se može koristiti ili za povećanje ukupnih performansi sistema ili korištenje novog načina „uštede u memoriji“, koji omogućava rad sa „ograničenom memorijom“ u slučajevima kada korištena konfiguracija „voli jesti memoriju“.

Stabilnost pri korištenju velike količine memorije određuje se novim parametrima radnog servera.

Posebno je zanimljiva opcija "sigurne potrošnje memorije po pozivu". Za one koji imaju lošu predstavu o tome šta je - bolje je ne trenirati „produktivno“. Parametar "Maksimalna količina memorije radnog tijeka" omogućava vam da "nadjačate" cijeli tijek rada tijekom "prelijevanja", ali samo jednu sesiju "s gubitnikom". "Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom" omogućava vam blokiranje novih veza čim se prijeđe ovaj prag memorije.

Najveći interes za programere trebao bi predstavljati "Zahtjevi za imenovanje funkcionalnosti".

Jasno je da nema smisla ponavljati dokumentaciju. Ali ako neko savjetuje razumno, proširit ću članak.