Përshpejtimi i punës 1s 8.3 file. Këshilla për automatizimin

03.11.2019 Në kontakt me

Fraza "1C ngadalësohet" duhet të jetë dëgjuar nga të gjithë që punojnë me produkte në platformën 1C:Enterprise. Dikush u ankua për këtë, dikush pranoi ankesat. Në këtë artikull, ne do të përpiqemi të shqyrtojmë shkaqet më të zakonshme të këtij problemi dhe opsionet për zgjidhjen e tij.

Le të kthehemi te metafora: para se të zbuloni pse një person nuk shkoi diku, ia vlen të siguroheni që ai ka këmbë për të ecur. Pra, le të fillojmë me kërkesat e harduerit dhe rrjetit.

Nëse Windows 7 është i instaluar:

Nëse Windows 8 ose 10 është i instaluar:

Mos harroni gjithashtu se duhet të ketë të paktën 2 GB hapësirë të lirë në disk, dhe një lidhje rrjeti duhet të ketë një shpejtësi prej të paktën 100 Mb / s.

Nuk ka shumë kuptim të merren parasysh karakteristikat e serverëve në versionin klient-server, sepse në këtë rast gjithçka varet nga numri i përdoruesve dhe specifikat e detyrave që ata zgjidhin në 1C.

Kur zgjidhni një konfigurim për një server, mbani parasysh sa vijon:

Një proces punonjës i serverit 1C konsumon mesatarisht 4 GB (të mos ngatërrohet me një lidhje përdoruesi, sepse një proces punonjësi mund të ketë aq lidhje sa specifikoni në cilësimet e serverit);
Përdorimi i 1C dhe DBMS (veçanërisht MS SQL) në një server fizik jep një fitim kur përpunohen grupe të mëdha të dhënash (për shembull, mbyllja e një muaji, llogaritja e një buxheti sipas një modeli, etj.), por ul ndjeshëm performancën gjatë operacioneve të shkarkuara (për shembull, krijimi dhe realizimi i dokumentit të zbatimit, etj.);
Mos harroni se serverët 1C dhe DBMS duhet të lidhen përmes një kanali "të trashë" nga 1 GB;
Përdorni disqe me performancë të lartë dhe mos kombinoni rolet e serverit 1C dhe DBMS me role të tjera (për shembull, skedari, AD, kontrolluesi i domenit, etj.).

Nëse, pas kontrollit të pajisjeve, 1C ende "ngadalësohet"

Ne kemi një kompani të vogël, 7 persona, dhe 1C "ngadalëson". Ne iu drejtuam specialistëve dhe ata thanë se vetëm opsioni klient-server do të na shpëtonte. Por për ne një zgjidhje e tillë nuk është e pranueshme, është shumë e shtrenjtë!

Kryeni mirëmbajtjen rutinë në bazën e të dhënave*:

1. Nisni bazën e të dhënave në modalitetin e konfiguruesit.

2. Zgjidhni artikullin "Administrimi" në menunë kryesore, dhe në të - "Testimi dhe rregullimi".

3. Vendosni të gjitha kutitë e kontrollit si në foto. Kliko Run.

*Kjo procedurë mund të zgjasë nga 15 minuta deri në një orë, në varësi të madhësisë së bazës dhe karakteristikave të kompjuterit tuaj.

Nëse kjo nuk ndihmon, atëherë ne bëjmë një lidhje klient-server, por pa investime shtesë në harduer dhe softuer:

1. Zgjidhni kompjuterin më pak të ngarkuar në zyrë nga kompjuterët e palëvizshëm (jo fletore): duhet të ketë të paktën 4 GB RAM dhe një lidhje rrjeti prej të paktën 100 Mb / s.

2. Aktivizoni IIS (Internet Information Server) në të. Për këtë:

3. Publikoni bazën tuaj të të dhënave në këtë kompjuter. Ka materiale të disponueshme për këtë temë në ITS, ose kontaktoni një specialist mbështetës.

4. Në kompjuterët e përdoruesve, konfiguroni aksesin në bazën e të dhënave përmes një klienti të hollë. Për këtë:

Hapni dritaren e nisjes 1C.

Zgjidhni bazën tuaj të punës. Kjo është baza juaj këtu. Klikoni Edit. Vendoseni çelësin në pozicionin "Në serverin në internet", specifikoni në rreshtin poshtë tij emrin ose adresën IP të serverit në të cilin është aktivizuar IIS dhe emrin me të cilin është publikuar baza e të dhënave. Shtypni "Next".

Vendosni çelësin "Main Startup Mode" në modalitetin "Thin Client". Klikoni "Finish".

Ne kemi një kompani mjaft të madhe, por jo edhe shumë të madhe, 50-60 persona.Ne përdorim opsionin klient-server, por 1C është tmerrësisht i ngadalshëm.

Në këtë rast, rekomandohet të ndani serverin 1C dhe serverin DBMS në dy serverë të ndryshëm. Kur ndani, sigurohuni që të mbani mend: nëse ata mbetën në të njëjtin server fizik, i cili thjesht u virtualizua, atëherë disqet e këtyre serverëve duhet të jenë të ndryshëm - fizikisht të ndryshëm! Gjithashtu, sigurohuni që të vendosni detyrat e planifikuara në serverin DBMS kur bëhet fjalë për MS SQL (më shumë për këtë përshkruhet në faqen e internetit të ITS)

Ne kemi një kompani mjaft të madhe, më shumë se 100 përdorues. Gjithçka është vendosur në përputhje me rekomandimet 1C për këtë opsion, por kur kryeni disa dokumente, 1C "ngadalësohet" shumë, dhe ndonjëherë ndodh një gabim bllokimi. Ndoshta bëni një konvolucion të bazës?

Një situatë e ngjashme lind për shkak të madhësisë së një regjistri shumë specifik akumulimi ose kontabiliteti (por më shpesh - akumulimi), për shkak të faktit se regjistri ose nuk është "i mbyllur" fare, d.m.th. ka lëvizje të të ardhurave, por nuk ka lëvizje shpenzimesh, ose numri i matjeve me të cilat llogariten bilancet e regjistrit është shumë i madh. Mund të ketë edhe një përzierje të dy arsyeve të mëparshme. Si të përcaktoni se cili regjistër prish gjithçka?

Ne rregullojmë kohën kur dokumentet përpunohen ngadalë, ose kohën dhe përdoruesin që ka një gabim bllokimi.

Hapni regjistrin e regjistrimit.

Ne gjejmë dokumentin që na nevojitet, në kohën e duhur, për përdoruesin e duhur me llojin e ngjarjes “Data.Conduct”.

Ne shikojmë të gjithë bllokun e transaksionit deri në momentin kur transaksioni është anuluar, nëse ka pasur një gabim bllokimi, ose kërkojmë ndryshimin më të gjatë (koha nga rekordi i mëparshëm është më shumë se një minutë).

Pas kësaj, ne marrim një vendim, duke pasur parasysh se është më e lirë të fshihet ky regjistër i veçantë në çdo rast sesa e gjithë baza e të dhënave.

Ne jemi një kompani shumë e madhe, më shumë se 1000 përdorues, mijëra dokumente në ditë, departamenti ynë i IT, një flotë e madhe serverësh, ne kemi optimizuar kërkesat disa herë, por 1C ngadalësohet. Ne, me sa duket, kemi tejkaluar 1C dhe na duhet diçka më e fuqishme.

Në shumicën dërrmuese të rasteve të tilla, nuk është 1C që "ngadalësohet", por arkitektura e zgjidhjes së përdorur. Kur zgjidhni një program të ri biznesi, mbani mend se është më e lirë dhe më e lehtë të shkruani proceset tuaja të biznesit në një program sesa t'i ribëni ato për disa, veçanërisht një program shumë të shtrenjtë. Vetëm 1C ofron një mundësi të tillë. Prandaj, është më mirë të pyesni veten: "Si ta rregulloni situatën? Si ta bëni 1C të "fluturojë" në vëllime të tilla? Le të hedhim një vështrim në disa opsione trajtimi:

Përdorni teknologjitë e programimit paralel dhe asinkron që mbështet 1C (detyrat në sfond dhe kërkesat në një lak).
Kur hartoni arkitekturën e zgjidhjes, refuzoni të përdorni regjistrat e grumbullimit dhe regjistrat e kontabilitetit në vendet më "të ngushta".
Kur zhvilloni një strukturë të dhënash (akumulim dhe / ose regjistra informacioni), ndiqni rregullin: "Tabela më e shpejtë për të shkruar dhe lexuar është një tabelë me një kolonë". Ajo që është në rrezik do të bëhet më e qartë nëse shohim një mekanizëm tipik RAUS.
Për të përpunuar sasi të mëdha të dhënash, përdorni grupe ndihmëse ku është e lidhur e njëjta bazë të dhënash (por në asnjë rast kjo nuk duhet të bëhet kur punoni në mënyrë interaktive !!!). Kjo do të anashkalojë bravat standarde 1C, të cilat do të bëjnë të mundur punën me bazën e të dhënave pothuajse me të njëjtën shpejtësi si kur punoni drejtpërdrejt me mjetet SQL.

Vlen të përmendet se optimizimi 1C për zotërimet dhe kompanitë e mëdha është një temë për një artikull të veçantë, të madh, kështu që qëndroni të sintonizuar për përditësimet e materialeve në faqen tonë të internetit.

Si të shpejtoni punën në 1C: Kontabiliteti 8.3 (versioni 3.0) ose çaktivizoni detyrat e planifikuara dhe në sfond

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

Ata prej jush që tashmë kanë arritur të kalojnë në edicionin e ri të 1C: Kontabiliteti 8.3 (versioni 3.0) kanë vënë re se ai është bërë më i ngadalshëm se ai. Disa ngadalësime të çuditshme, detyra të pafundme në sfond disa herë në ditë, të cilat askush nuk i kërkoi t'i kryente pa dijeninë tonë.

Menjëherë pas tranzicionit, kontabilistët e mi më thanë se edicioni i ri i 1C: Accounting 3.0 sinqerisht ngadalësohet në krahasim me ato të mëparshme! Dhe është e pamundur të punosh.

Fillova të kuptoja dhe shumë shpejt zbulova se shkaku kryesor i ngrirjeve dhe pakënaqësisë pasuese të përdoruesve janë detyrat rutinë dhe në sfond, shumë prej të cilave janë të aktivizuara si parazgjedhje, megjithëse për shumicën dërrmuese të kontabilistëve ato nuk janë të nevojshme.

Epo, për shembull, pse duhet të ekzekutojmë detyrën "Nxjerrja e tekstit" njëqind herë në ditë nëse nuk kryejmë një kërkim me tekst të plotë (kontabilistë, mos kini frikë) në të gjitha objektet në bazën tonë të të dhënave.

Ose pse të shkarkojmë vazhdimisht kurset e këmbimit nëse nuk kemi transaksione valutore ose i bëjmë ato herë pas here (dhe para kësaj ne vetë mund të klikojmë butonin e tarifave të shkarkimit).

E njëjta gjë vlen edhe për përpjekjen e vazhdueshme të 1C për t'u lidhur me sitin dhe për të kontrolluar dhe përditësuar klasifikuesit e bankës. Per cfare? Unë vetë do të shtyp butonin për të përditësuar klasifikuesit nëse nuk gjej bregun e duhur sipas BIC-së së tij.

Rreth asaj se si ta bëni atë në pikat e mëposhtme.

1. Shkoni te seksioni "Administrimi" dhe zgjidhni artikullin "Mirëmbajtja" në panelin e veprimit ():

2. Në dritaren që hapet, gjeni dhe zgjidhni artikullin "Detyrat e rregullta dhe në sfond":

3. Hapni çdo punë që ka kolonën On. ia vlen një xhaketë.

4. Hiq zgjedhjen "Enabled" dhe kliko butonin "Ruaj dhe Mbylle".

5. Bëni këtë me secilën nga detyrat e përfshira dhe shijoni botimin e ri. Në përgjithësi, për mendimin tim, është shumë më mirë se deuce.

Në të njëjtën kohë, platforma do të aktivizojë ende disa nga detyrat e planifikuara që keni çaktivizuar.

Sistemi 1C zë një pozicion dominues në tregun e automatizimit për bizneset e vogla dhe të mesme. Nëse një kompani ka zgjedhur një sistem të kontabilitetit 1C, atëherë zakonisht pothuajse të gjithë punonjësit punojnë në të, nga specialistët e zakonshëm tek menaxhmenti. Prandaj, shpejtësia e proceseve të biznesit të kompanisë varet nga shpejtësia 1C. Nëse 1C punon me një shpejtësi të pakënaqshme, atëherë kjo ndikon drejtpërdrejt në punën e të gjithë kompanisë dhe fitimin.

Në fakt ka tre metoda të përshpejtimit 1C:

Rritja e kapacitetit të harduerit.
Optimizimi i cilësimeve të sistemit operativ dhe DBMS.
Optimizimi i kodit dhe algoritmeve në 1C.

Metoda e parë kërkon blerjen e pajisjeve dhe licencave, e treta kërkon shumë punë për programuesit dhe, si rezultat, të dyja mënyrat rezultojnë në kosto të konsiderueshme financiare. Para së gjithash, duhet t'i kushtoni vëmendje kodit të programit, pasi asnjë rritje në kapacitetin e serverit nuk mund të kompensojë kodin e pasaktë. Çdo programues e di se me vetëm disa rreshta kodi është e mundur të krijohet një proces që do të ngarkojë plotësisht burimet e çdo serveri.

Nëse kompania ka besim në optimalitetin e kodit të programit dhe ai ende po funksionon ngadalë, zakonisht menaxhmenti vendos të rrisë kapacitetin e serverit. Në këtë pikë, lind një pyetje logjike: çfarë mungon, sa dhe çfarë duhet shtuar si rezultat.

Kompania 1C jep një përgjigje mjaft të paqartë në pyetjen se sa burime nevojiten, ne kemi shkruar për të më herët në postimet tona. Dhe kështu ju duhet të kryeni në mënyrë të pavarur eksperimente dhe të kuptoni se nga varet performanca e 1C. Eksperimentet e performancës në EFSOL janë përshkruar më poshtë.

Kur punoni me 1C 8.2, veçanërisht me konfigurimet që përdorin forma të menaxhuara, u vu re një fakt i çuditshëm: 1C funksionon më shpejt në një stacion pune sesa në një server të fuqishëm. Për më tepër, të gjitha karakteristikat e stacionit të punës janë më të këqija se ato të serverit.

Tabela 1 - Konfigurimet mbi të cilat është kryer testimi fillestar

Stacioni i punës tregon një performancë prej 155% më shumë se një server 1C me performancë superiore. Filluam të kuptonim se çfarë ishte çështja dhe të ngushtonim rrethin e kërkimeve.

Figura 1 - Matjet e performancës në stacionin e punës me testin Gilev

Dyshimi i parë ishte se testi i Gilev ishte i pamjaftueshëm. Matjet e hapjes së formularëve, postimi i dokumenteve, gjenerimi i raporteve, etj., duke përdorur mjete instrumentale, treguan se testi Gilev jep një vlerësim proporcional me shpejtësinë aktuale të punës në 1C.

Numri dhe frekuenca e RAM-it

Një analizë e informacionit të disponueshëm në internet tregoi se shumë shkruajnë për varësinë e performancës 1C nga frekuenca e kujtesës. Është nga frekuenca, dhe jo nga volumi. Ne vendosëm të testojmë këtë hipotezë, pasi kemi një frekuencë RAM prej 1066 Mhz në server kundrejt 1333 Mhz në stacionin e punës, dhe sasia e RAM në server është tashmë shumë më e lartë. Ne vendosëm të vendosim jo 1066 Mhz, por 800 Mhz menjëherë, në mënyrë që të bëjmë më të dukshëm efektin e varësisë së performancës nga frekuenca e kujtesës. Rezultati - produktiviteti ra me 12% dhe arriti në 39.37 njësi. Ne instaluam memorie me një frekuencë prej 1333 Mhz në vend të 1066 Mhz në server dhe morëm një rritje të lehtë të performancës - rreth 11%. Produktiviteti ishte 19.53 njësi. Prandaj, nuk bëhet fjalë për kujtesën, megjithëse frekuenca e saj jep një rritje të vogël.

Figura 2 - Matjet e performancës në stacionin e punës pas uljes së frekuencës së RAM-it

Figura 3 - Matjet e performancës në server pas rritjes së frekuencës së RAM-it

Nënsistemi i diskut

Hipoteza tjetër lidhej me nënsistemin e diskut. Dy hipoteza u ngritën menjëherë:

SSD-të janë më të mirë se disqet SAS, edhe nëse janë në raid 10.
iSCSI është i ngadalshëm ose nuk funksionon siç duhet.

Prandaj, në stacionin e punës u instalua një disk i rregullt SATA në vend të një SSD, dhe e njëjta gjë u bë me serverin - baza u vendos në një disk lokal SATA. Si rezultat, matjet e performancës nuk kanë ndryshuar në asnjë mënyrë. Me shumë mundësi, kjo po ndodh, pasi ka mjaft RAM dhe disqet praktikisht nuk përdoren në asnjë mënyrë gjatë provës.

CPU

Procesorët në server, natyrisht, janë më të fuqishëm dhe ka dy prej tyre, por frekuenca është pak më e ulët se në stacionin e punës. Ne vendosëm të kontrollonim efektin e frekuencës së procesorit në performancën: nuk kishte procesorë me një frekuencë më të lartë në dispozicion për serverin, kështu që ulëm frekuencën e procesorit në stacionin e punës. E ulëm menjëherë në 1.6 në mënyrë që korrelacioni të shfaqej më i ndritshëm. Testi tregoi se performanca ra ndjeshëm, por edhe me një procesor 1.6, stacioni i punës prodhoi pothuajse 28 njësi, që është pothuajse 1.5 herë më shumë se në server.

Figura 4 - Matjet e performancës në një stacion pune me një procesor 1.6 Ghz

kartë video

Ka informacione në internet që një kartë video mund të ndikojë në performancën e 1C. Provuam videon e integruar të stacionit të punës, një përshtatës profesional Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, një kartë grafike të vjetër GeForce 16MbSDR. Gjatë testit Gilev, nuk u vërejt ndonjë ndryshim domethënës. Ndoshta karta video ndikon akoma, por në kushte reale, kur duhet të hapni format e menaxhuara, etj.

Për momentin, ekzistojnë dy dyshime pse stacioni i punës funksionon më shpejt edhe me performancë dukshëm më të keqe:

CPU. Lloji i procesorit në stacionin e punës është më i përshtatshëm për 1C.
Çipset. Duke qenë të barabarta, stacioni ynë i punës ka një çip më të ri, gjë që mund të jetë arsyeja.

Ne planifikojmë të blejmë komponentët e nevojshëm dhe të vazhdojmë testet në mënyrë që më në fund të zbulojmë se nga varet në një masë më të madhe performanca e 1C. Ndërsa procesi i miratimit dhe prokurimit është duke u zhvilluar, ne vendosëm të kryejmë optimizimin, aq më tepër që nuk kushton asgjë. Hapat e mëposhtëm janë identifikuar:

Faza 1. Vendosja e sistemit

Së pari, le të bëjmë cilësimet e mëposhtme në BIOS dhe sistemin operativ:

Në BIOS të serverit, çaktivizoni të gjitha cilësimet për të kursyer fuqinë e procesorit.
Zgjidhni planin "Performanca maksimale" në sistemin operativ.
Procesori është gjithashtu i akorduar për performancë maksimale. Kjo mund të bëhet duke përdorur programin PowerSchemeEd.

Faza 2. Vendosja e serverit SQL dhe serverit 1C:Enterprise

Ne bëjmë ndryshimet e mëposhtme në cilësimet e serverit DBMS dhe 1C: Enterprise.

Konfigurimi i protokollit të memories së përbashkët:
- Memoria e përbashkët do të aktivizohet vetëm në platformë duke filluar nga 1C 8.2.17, në versionet e mëparshme Named Pipe do të aktivizohet - disi inferiore në shpejtësi. Kjo teknologji funksionon vetëm nëse shërbimet 1C dhe MSSQL janë instaluar në të njëjtin server fizik ose virtual.
Rekomandohet të vendosni shërbimin 1C në modalitetin e korrigjimit, paradoksalisht kjo jep një rritje të performancës. Si parazgjedhje, korrigjimi i gabimeve është i çaktivizuar në server.
Konfigurimi i serverit SQL:
- Na duhet vetëm një server, pjesa tjetër e shërbimeve që i përkasin dhe, ndoshta, dikush i përdor ato, vetëm ngadalëson punën. Ne ndalojmë dhe çaktivizojmë shërbime të tilla si: FullText Search (1C ka mekanizmin e vet të kërkimit me tekst të plotë), Shërbimet e Integrimit, etj.
- Vendosni sasinë maksimale të memories së caktuar për serverin. Kjo është e nevojshme në mënyrë që serveri sql të llogarisë në këtë shumë dhe të pastrojë kujtesën paraprakisht.
- Cakto numrin maksimal të threads (Maximum worker threads) dhe cakto prioritetin e rritur të serverit (Prioriteti Boost).

Faza 3. Krijimi i një baze të dhënash funksionale

Pasi serveri DBMS dhe 1C: Enterprise janë optimizuar, ne vazhdojmë te cilësimet e bazës së të dhënave. Nëse baza nuk është vendosur ende nga skedari .dt dhe ju e dini madhësinë e saj të përafërt, atëherë është më mirë të tregoni menjëherë madhësinë e inicializimit të skedarit primar me ">=" të madhësisë bazë, por kjo është një çështje me shije, do të rritet akoma kur të vendoset. Por Rritja automatike në madhësi duhet të specifikohet: afërsisht 200 MB për bazë të dhënash dhe 50 MB për regjistër, sepse. vlerat e paracaktuara - rritja me 1MB dhe me 10% ngadalëson shumë serverin, kur duhet të rrisë skedarin me çdo transaksion të tretë. Është gjithashtu më mirë të ruani skedarin bazë dhe skedarin e regjistrit në disqe të ndryshëm fizikë ose grupe RAID nëse përdoret një grup RAID dhe të kufizoni rritjen e regjistrit. Rekomandohet që skedari Tempdb të zhvendoset në një grup me shpejtësi të lartë, pasi DBMS e akseson atë mjaft shpesh.

Faza 4. Vendosja e detyrave të planifikuara

Detyrat e planifikuara krijohen thjesht duke përdorur Planin e Mirëmbajtjes në seksionin e Menaxhimit, duke përdorur mjete grafike, kështu që ne nuk do të përshkruajmë në detaje se si bëhet kjo. Le të ndalemi në atë se cilat operacione duhet të kryhen për të përmirësuar performancën.

Indekset duhet të defragmentohen dhe statistikat duhet të përditësohen çdo ditë. nëse fragmentimi i indeksit është > 25%, kjo do të reduktojë në mënyrë drastike performancën e serverit.
Defragmentimi dhe përditësimi i statistikave - bëhet shpejt dhe nuk kërkon shkëputjen e përdoruesve. Gjithashtu rekomandohet të bëhet çdo ditë.
Riindeksimi i plotë - i bërë me një bllokim të bazës së të dhënave, rekomandohet ta bëni atë të paktën një herë në javë. Natyrisht, pas një riindeksimi të plotë, indekset defragmentohen dhe statistikat përditësohen menjëherë.

Si rezultat, me ndihmën e rregullimit të mirë të sistemit, serverit SQL dhe bazës së punës, arritëm të rrisim produktivitetin me 46%. Matjet u kryen duke përdorur instrumentin 1C dhe duke përdorur testin Gilev. Ky i fundit tregoi 25.6 njësi kundrejt 17.53 që ishin fillimisht.

Përfundim i shkurtër

Performanca e 1C nuk varet shumë nga frekuenca e RAM-it. Kur arrihet një vëllim i mjaftueshëm, zgjerimi i mëtejshëm i kujtesës nuk ka kuptim, pasi nuk çon në një rritje të performancës.
Performanca e 1C nuk varet nga karta video.
Performanca e 1C nuk varet nga nënsistemi i diskut, me kusht që radha për leximin ose shkrimin e disqeve të mos tejkalohet. Nëse disqet SATA janë instaluar dhe nuk janë në radhë, atëherë instalimi i një SSD nuk do të përmirësojë performancën.
Performanca varet mjaft nga frekuenca e procesorit.
Me konfigurimin e duhur të sistemit operativ dhe serverit MSSQL, është e mundur të arrihet një rritje e performancës 1C me 40-50% pa asnjë kosto materiale.

KUJDES! Një pikë shumë e rëndësishme! Të gjitha matjet u kryen në një bazë testimi duke përdorur testin Gilev dhe instrumentet 1C. Sjellja e një baze të dhënash reale me përdorues të vërtetë mund të ndryshojë nga rezultatet e marra. Për shembull, në bazën e të dhënave të testit, ne nuk gjetëm ndonjë varësi të performancës nga karta video dhe sasia e RAM. Këto përfundime janë mjaft të dyshimta dhe në kushte reale këta faktorë mund të kenë një ndikim të rëndësishëm në performancën. Kur punoni me konfigurime që përdorin forma të menaxhuara, një kartë video është e rëndësishme dhe një procesor i fuqishëm grafik përshpejton punën për sa i përket vizatimit të ndërfaqes së programit, vizualisht kjo manifestohet në funksionimin më të shpejtë 1C.

A funksionon ngadalë 1C juaj? Porositni mirëmbajtjen e kompjuterëve dhe serverëve të IT nga specialistë të EFSOL me përvojë shumëvjeçare ose transferoni 1C tuaj në një server virtual 1C të fuqishëm dhe tolerant ndaj gabimeve.

Integrimi i sistemit. Konsulencë

Në shumë mënyra, optimizimi i 1C dhe shpejtësia e punës varet nga puna me bravë, pyetje dhe indekse. Ne do të përpiqemi t'i përgjigjemi pyetjes "si të shpejtojmë punën e 1C" (çështja se si të shpejtojmë fillimin e 1C, do ta shqyrtojmë në një artikull tjetër) dhe të shmangim ankesat e përdoruesve për "dokumentet e gjata", të cilat në mënyrë të pashmangshme ndikojnë proceset e biznesit.

Pjesa 3. Performanca 1C

Flokët në 1C 8.3: kërkimi dhe eliminimi në kod, transferimi në bravat e menaxhuara

Bravat janë pjesë e mekanizmit ACID. Konsideroni konceptin e tij, të paraqitur në formën e një diagrami të thjeshtuar, duke përdorur shembullin e SQL SERVER

Në modalitetin automatik, bravat menaxhohen nga vetë DBMS. Në të njëjtën kohë, në MS SQL Server u shfaqën efekte anësore, si bllokimi i tabelave boshe dhe diapazoni i të dhënave kufitare (niveli i serializueshëm), gjë që krijoi probleme shtesë në punën me shumë përdorues. Për të zgjidhur këto probleme, 1C ka krijuar bravë të menaxhuar.

1C Brava të menaxhuara

Mekanizmi i kyçjes u zhvendos në serverin 1C, dhe në nivelin DBMS, izolimi u reduktua në minimum. Në MS SQL, niveli i izolimit u ul në Read Committed me mekanizmin e kyçjes së përbashkët në platformën 8.2 dhe mekanizmin e versionimit të rreshtave në platformën 8.3 (i ashtuquajturi Read Committed Snapshot Isolation). Më saktësisht, kjo është vetia e bazës së të dhënave me të njëjtin emër dhe dy mënyra funksionimi Read Committed, në varësi të këtij parametri.

Me nivelin e fundit të izolimit (RCSI), mekanizmi lejoi që leximi dhe shkrimi i transaksioneve në të njëjtat burime të mos kryqëzoheshin në serverin DBMS. E gjithë puna kryesore u mor nga shërbimi i bllokimit 1C, i cili përcakton, bazuar në metadatat vendase, nëse do të fillojë ose jo transaksionet në serverin DBMS në mënyrë që të mos ketë shkelje të logjikës së biznesit. Problemet me bllokimin e tabelave boshe dhe kufijve janë një gjë e së kaluarës.

DBMS	Lloji i bllokimit	Niveli i izolimit të transaksionit	Leximi jashtë një transaksioni
Bllokimet automatike
Baza e të dhënave të skedarëve	tabelat	E serializueshme	Leximi i pistë
Serveri MS SQL	Regjistrimet		Leximi i pistë
IBM DB2	Regjistrimet	Lexim i përsëritur ose i serializueshëm	Leximi i pistë
PostgreSQL	tabelat	E serializueshme	Lexim i vazhdueshëm
Baza e të dhënave Oracle	tabelat	E serializueshme	Lexim i vazhdueshëm
Bllokimet e menaxhuara
Baza e të dhënave të skedarëve	tabelat	E serializueshme	Leximi i pistë
MS SQL Server 2000	Regjistrimet	Lexoni të përkushtuar	Leximi i pistë
MS SQL Server 2005 dhe më i lartë		Lexoni Fotot e Përkushtuara	Lexim i vazhdueshëm
IBM DB2 deri në versionin 9.7	Regjistrimet	Lexoni të përkushtuar	Leximi i pistë
IBM DB2 versioni 9.7 dhe më i lartë	Regjistrimet	Lexoni të përkushtuar	Lexim i vazhdueshëm
PostgreSQL	Regjistrimet	Lexoni të përkushtuar	Lexim i vazhdueshëm
Baza e të dhënave Oracle	Regjistrimet	Lexoni të përkushtuar	Lexim i vazhdueshëm

Për të zbuluar se në cilën mënyrë bllokimi është baza e të dhënave të programit 1C, duhet të ekzekutoni kërkesën e mëposhtme nga SSMS në kontekstin e bazës së të dhënave të dëshiruar:

Bllokimi 1C. Përdoruesi nuk do të presë në bravë, 1C do të përshpejtohet nëse ndiqen disa rregulla:

Kohëzgjatja e transaksioneve duhet të jetë sa më e shkurtër në kohë. Kryerja e llogaritjeve të gjata në një transaksion në 100% të rasteve do të çojë në bllokim kur punoni në një sistem OLTP.
Përjashtohen operacionet e gjata të jashtme brenda një transaksioni, të tilla si dërgimi dhe marrja e konfirmimeve me email, puna me sistemin e skedarëve dhe veprime të tjera shtesë. Të gjitha operacionet duhet të vendosen në detyra të shkurtra në pritje.
Kërkesat janë të optimizuara sa më shumë që të jetë e mundur.
Indekset duhet të krijohen vetëm sipas nevojës për të siguruar performancën optimale të pyetjeve brenda aplikacionit.
Përfshirjet e minimizuara në indeksin e grupuar të kolonave të përditësuara shpesh. Përditësimi i kolonës/ve të një çelësi indeksi të grupuar kërkon një kyçje, si në indeksin e grupuar ashtu edhe në të gjithë indekset jo të grupuara (sepse rreshti i tyre i lokalizimit përmban çelësin e indeksit të grupuar).
Aty ku është e mundur, krijohet një indeks mbulues dhe përdoret për të reduktuar kohën e rikthimit të të dhënave.
Përdorimi i nivelit më të ulët të izolimit nga transaksionet, të cilat do të kërkojnë një kalim në modalitetin e bllokimit të menaxhuar.

Mjetet e diagnostikimit të bllokimit:

Revista e Teknologjisë;
Qendra e menaxhimit të performancës nga paketa e veglave 1C;
Shërbimet cloud të Gilev;

Më poshtë është një shembull i monitorimit të sistemit nga shërbimi Gilev. Kohëzgjatja totale e bllokimit është ~15 orë. Mbi 400 përdorues aktivë. Pas vendimmarrjes dhe optimizimit, afatet janë më pak se një minutë dhe numri i blloqeve është reduktuar me ~ 670 herë.

Ishte:

U bë:

Në një situatë kur "gjithçka varet dhe kërkon shumë kohë", dhe shërbimet e monitorimit nuk janë konfiguruar ose nuk përdoren fare, duke kujtuar parimin Pareto, duhet të përqendroheni në kod.

Në modalitetin automatik, prania e bravave në server mund të zbulohet duke përdorur një procedurë të sistemit në kontekstin e bazës së të dhënave të kërkuar. Kjo procedurë e ruajtur ju lejon të përcaktoni mënyrën në të cilën funksionojnë bravat, statusin, llojin e tyre etj.

Pasi të keni përfunduar procedurën për 1C, mund të merrni informacion vizual për atë që po ndodh aktualisht në server, duke marrë parasysh specifikat e tabelave 1C:

Fragmenti 1

//Bllokohet në terma të 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) si t Ku TableName1C NUK ËSHTË NULL RENDIT NGA t.Burimet

Përdorimi i këtij mekanizmi ju lejon të merrni informacion të plotë në lidhje me bravat e disponueshme në momentin aktual. Nëse ka vetëm S-lock në raport, problemi mund të jetë një pyetje ose pyetje afatgjatë. Për të përcaktuar shkakun dhe vendin e paraqitjes së tyre në kod, mund të shkoni në mënyra të ndryshme: përdorni objektet DMO të serverit SQL (por mbani në mend se të dhënat prej tyre rivendosen pasi serveri të rindizet) ose konfiguroni Koleksionin e të Dhënave duke ruajtur monitorimi i të dhënave në tabela për një kohë të caktuar. Gjëja kryesore është të merrni tekstet e kërkesave me probleme.

Duke përdorur DMO të SQL Server

Ne shfaqim datën e fillimit të serverit për të kuptuar rëndësinë e të dhënave. Ne e thyejmë paketën duke lexuar vlerësimin (fizik, logjik, ngarkesa e procesorit). Në këtë rast, përdoren të dhënat kryesore nga sys.dm_exec_query_stats. Teksti i kërkesës përkthehet në terma 1C. Nëse mund ta kuptoni kontekstin e thirrjes nga teksti i kërkesës, atëherë mbetet të shikoni planin e pyetjes, të gjeni operatorë problematikë dhe të kuptoni se çfarë mund të bëhet.

Fragmenti 2

//koha e fillimit SELECT sqlserver_start_time FROM sys.dm_os_sys_info; //Kërkesat kryesore për lexime fizike SELECT TOP (50) (total_physical_reads) AS Total_physical_reads,

Identifikimi i pyetjeve problemore si rezultat i mbledhjes së të dhënave të koleksionistit

Me këtë mjet, ju mund të renditni të dhënat sipas parametrave të kërkuar, si përdorimi i CPU-së, kohëzgjatja, hyrje/dalja logjike, leximet fizike, gjë që ju lejon të ruani statistika të plota për analiza të mëtejshme, pavarësisht rinisjes së serverit SQL.

Pasi kërkesat e problemit të mblidhen nga serveri pa monitorim të palëve të treta, mund të renditni të dhënat e marra sipas parametrave të nevojshëm.

Më tej, duke aktivizuar regjistrin teknologjik dhe duke specifikuar në cilësimet "kërko sipas vargut" dhe pjesën e pyetjes që garantohet të ndodhë, mund të zbuloni se nga erdhi pyetja problematike. Nëse ka disa baza të të dhënave në server ose emri i përdoruesit është i njohur, ia vlen të shtoni fusha shtesë për filtrin në mënyrë që të zvogëloni ngarkesën në server gjatë mbledhjes së regjistrit teknologjik.

Një shembull i një kërkese problematike dhe një mostër e konfigurimit të një regjistri teknologjik:

Optimizimi i pyetjeve si një mundësi për të shpejtuar 1C 8.3

Pasojat e pyetjeve jo optimale mund të shfaqen në formën e postimit të gjatë të dokumenteve, gjenerimit të gjatë torturues të raporteve, ngrirjes së sistemit dhe ngjarjeve të tjera të pakëndshme.

Kur punoni me pyetje, MOS:

Bashkoni tabelat me nënpyetje;
Lidhni tabelat e zakonshme me ato virtuale;
Përdorni "OR" logjike në kushte;
Përdorni nënpyetjet në kushtet e bashkimit;
Merrni të dhëna përmes një pike nga fusha të një lloji të përbërë pa fjalën kyçe "Express".

Kur punoni me pyetje, ju MUND:

Krijoni indekse në kushtet e pyetjes, bashkoni, grumbulloni dhe renditni fushat;
Tabelat virtuale duhet të filtrohen duke përdorur opsionet e filtrit.

Përdorimi i indekseve dhe ndikimi i tyre në cilësinë e performancës së sistemit

Është shkruar shumë për indekset, për nevojën e përdorimit të tyre dhe ndikimin në cilësinë e sistemit. Le të përpiqemi të kuptojmë ndërlikimet e "pajisjes" së indekseve, aplikacioneve dhe avantazheve ndaj tabelave konvencionale.

Indeksimi është një pjesë e rëndësishme e bërthamës së DBMS. Mungojnë indekset, ose anasjelltas, numri i tepërt i tyre, ndikojnë në shkallën e kampionimit, modifikimin, shtimin dhe fshirjen e të dhënave. Le të shqyrtojmë indeksimin duke përdorur shembullin e DBMS-ve më të zakonshme nga Microsoft.

Për një kuptim të përgjithshëm se si funksionon kjo, le të shohim detajet e pajisjes nga mekanizmi i ruajtjes së të dhënave, të cilin zakonisht e përfaqësojmë në formën e një tabele (për shembull, Excel).

Njësia e ruajtjes fizike të të dhënave është një faqe - një modul 8 KB që i përket vetëm një objekti (për shembull, një tabelë ose indeks). Faqja është njësia më e vogël për lexim dhe shkrim. Faqet janë të organizuara në shtrirje. Shtrirja përbëhet nga 8 faqe të njëpasnjëshme. Faqet e shtrirjes mund t'i përkasin një ose më shumë objekteve. Nëse faqet i përkasin më shumë se një veçorie, shtrirja quhet shtrirje "e përzier".

Përmbajtja e tij mund të shihet më poshtë:

Tani që kemi një ide se si është organizuar një njësi e ruajtjes së diskut, le të flasim më shumë për tabelat dhe indekset.

Si parazgjedhje, nëse nuk përdoren deklarata speciale T-SQL, krijohet një tabelë bosh si "grumbull" - një grup i thjeshtë faqesh dhe shtrirjesh. Të dhënat mbi grumbullin nuk kanë rend logjik. Kerneli i SQL Server mban gjurmët se si faqet dhe shtrirjet i përkasin një objekti të caktuar duke përdorur faqe të veçanta të sistemit të quajtura Hartat e Shpërndarjes së Indeksit. Çdo tabelë ose indeks ka të paktën një faqe IAM, e quajtur "faqja e parë IAM".

Kështu, pas krijimit të një tabele të rregullt, si parazgjedhje, merret një rregullim kaotik i të dhënave. Ju mund të shikoni statusin e një tabele duke përdorur procedurën e mëposhtme:

Indekset kryesore të përdorura nga platforma 1C

Fragmenti 3

Mitet dhe realiteti:

Miti i parë: indekset e grupuara dhe një tabelë e të dhënave janë dy entitete të ndryshme të ruajtura veçmas nga njëra-tjetra.

Miti i dytë: mund të ketë shumë indekse të grumbulluara në një tabelë.

Shkarkuar programin për optimizimin e DBMS. Krijoi indekse të rekomanduara. Shpejtësia e kampionimit u rrit me 50%. Ndryshimi dhe shtimi i të dhënave u ngadalësua 7 herë.

Indeksi i grumbulluar (i grumbulluar).

Indekset e grupuara janë një grup faqesh që renditin dhe ruajnë rreshtat e të dhënave në tabela ose pamje bazuar në vlerat e tyre kryesore, kolonat e përfshira në përkufizimin e indeksit. Ekziston një kufi për këtë lloj indeksesh prej 16 kolonash dhe 900 bajte. Për çdo tryezë ka vetëm një indeks të grupuar, sepse rreshtat e të dhënave mund të renditen vetëm në një renditje. Krijimi i një indeksi të grupuar ndodh duke riorganizuar tabelën dhe jo duke kopjuar të dhënat, gjë që bën të mundur mbajtjen e tabelës si një pemë B.

Fragmenti 4

SELECT EMRI, TYPE, TYPE_DESC FROM sys.indexes WHERE objekt_id = OBJECT_ID("TraceData")

Indeksi jo i grupuar

Indekset jo të grumbulluara kanë një strukturë të ndarë nga rreshtat e të dhënave. Një indeks jo i grupuar përmban vlerat e çelësit të indeksit të grupuar dhe çdo hyrje përmban çelësin e indeksit të grupuar (jo RID, sepse tabelat 1C nuk përdorin grumbullime, me përjashtime të rralla).

Mund të shtoni kolona pa çelës në nivelin e fletës së një indeksi jo të grupuar dhe të anashkaloni kufirin ekzistues të çelësave të indeksit (900 bajt dhe 16 kolona kryesore) duke ekzekutuar pyetje të indeksuara plotësisht.

Pas shtimit të një indeksi jo të grupuar, të dhënat u kopjuan dhe u shfaq një objekt tjetër:

Fragmenti 5

SELECT EMRI, TYPE, TYPE_DESC FROM sys.indexes WHERE objekt_id = OBJECT_ID("TraceData")

Skema e indeksit të grumbulluar pas marrjes së tij nga grumbulli në formën e një peme të ekuilibruar:

Skema e një indeksi jo të grupuar të marrë nga një tabelë e grupuar (vini re se kolona e gjetësit të rreshtave ka një çelës indeksi të grupuar):

Ndikimi i indekseve në performancën e pyetjeve

Optimizuesi i pyetjeve përdor indeksin për të kërkuar kolonat kryesore të indeksit, gjen se ku janë ruajtur rreshtat e kërkuar dhe nxjerr nga atje rreshtat që përputhen. Një kërkim indeksi është shumë më i shpejtë se një kërkim tabele, sepse, ndryshe nga një tabelë, indeksi shpesh përmban më pak kolona për rresht dhe rreshtat renditen sipas renditjes.

Krijimi i shumë indekseve çon në faktin se shpejtësia e tërheqjes rritet, dhe shpejtësia e shkrimit gjatë modifikimit zvogëlohet ndjeshëm. Për të zgjidhur këtë problem, para së gjithash, duhet të fshini indekset e panevojshme ose t'i bllokoni ato pa i fshirë më parë, gjë që do t'ju lejojë thjesht t'i aktivizoni ato, nëse lind një nevojë e tillë.

Vini re se indeksi i grupuar nuk duhet të bllokohet kurrë, sepse kjo do të mbyllë aksesin në të dhënat e tabelës. Kjo vlen vetëm për indekset që keni krijuar vetë përmes T-SQL. Arsyeja e krijimit të indekseve duke përdorur T-SQL, duke anashkaluar 1C: Enterprise, është kryesisht për shkak të aftësive të kufizuara të platformës 1C në drejtim të manipulimit të indeksit dhe përfshirjes së fushave shtesë në indeksin e krijuar / marrë.

Deklarata T-SQL që kryen veprimin për të bllokuar indeksin:

//Blloko një indeks të vetëm në tabelë -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Përfshi indeksin e dëshiruar -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

Përveç hapave të mësipërm, është e rëndësishme të krijoni një grup skedarësh në një disk fizik që nuk përmban skedarët aktual të bazës së të dhënave dhe të zhvendosni indekset jo të grumbulluara atje. Kjo do të përshpejtojë modifikimin e të dhënave duke paralelizuar regjistrimin e tyre.

Përcaktimi i indekseve të kërkuara ose të tepërta për të shpejtuar ekzekutimin e pyetjeve

Si parazgjedhje, 1C krijon një grup të caktuar bazë indeksesh. Shpesh, ato thjesht nuk janë të mjaftueshme. SQL Server ka mekanizma që bëjnë të mundur të kuptohet, bazuar në ngarkesën e punës, se sa të nevojshme janë indekset ekzistuese.

Këshilltari i akordimit të motorit të bazës së të dhënave analizon bazat e të dhënave dhe bën rekomandime për të optimizuar performancën e pyetjeve. Mund të përdoret për të zgjedhur dhe krijuar grupe indeksi optimale pa pasur një kuptim të nivelit ekspert të strukturës së bazës së të dhënave ose proceseve të brendshme të SQL Server. Këshilltari i akordimit të motorit të bazës së të dhënave ju lejon të kryeni detyrat e mëposhtme:

Zgjidhja e problemeve të performancës së një pyetje të veçantë problematike;
Vendosja e një grupi të madh pyetjesh në një ose më shumë baza të dhënash.

DMO (objekte dinamike të menaxhimit), të cilat përfshijnë pamje dinamike të menaxhimit dhe funksione dinamike të menaxhimit. Për shembull, një deklaratë T-SQL mund të marrë të gjithë indekset që nuk janë përdorur që nga fillimi i fundit i serverit.

Fragmenti 6

ME vl si (SELECT OBJECT_NAME(I.object_id) AS emri i objektit, I.name AS indexname, I.index_id AS indexid FROM sys.indexes AS INNER JOIN sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 AND I.type_desc = "NONCLUSTERED" DHE I.index_id NUK IN (SELECT S.index_id FROM sys.dm_db_index_usage_stats AS S KU S.object_id=I.object_id AND I.index_id=S.index_id =S.index_id ANDbase_id_id" '))) SELECT emrin e objektit,T1.EmriTabela1C, indexid, emri i indeksit FROM vl OUTER APPLY dbo.ReturnTableEmri1C(emri i objektit) si T1 RENDIT SIPAS emrit të objektit, emrit të indeksit;

Një udhëzim me të cilin mund të krijoni indekset e nevojshme të rekomanduara nga motori DBMS:

Fragmenti 7

ZGJIDH T1.NameTable1C si Table_Name_1C, "CREATE INDEX " + " ON "
Optimizuesi i pyetjeve zbulon nevojën për të krijuar një indeks që mungon gjatë gjenerimit të planit të ekzekutimit të pyetjeve. Ai e ruan këtë informacion në XML ShowPlan. Sepse Nëse planet e pyetjeve janë hash dhe udhëzimet vazhdojnë (deri në rinisjen e serverit tjetër), ato mund të merren, përpunohen dhe përgatiten për të krijuar indekset e nevojshme për çdo plan ekzekutimi në cache. Vlen t'i kushtohet vëmendje frekuencës së ekzekutimit të pyetjes: sa më e lartë të jetë, aq më të rëndësishme janë rezultatet e ekzekutimit të pyetjes dhe, në përputhje me rrethanat, treguesit e mbledhur. Nëse kërkesa është ekzekutuar një herë, rezultatet e saj nuk janë aq indikative.

Fragmenti 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/MissingIndexes") = 1) ZGJIDH TOP 30 Emri i bazës së të dhënave si Emri i bazës së të dhënave si Emri_bazë e të dhënave, Tableable1_Name, Table1_Name, TableName, Table1_Name, TableName, Table1_Name, Table1_Name, Table1_Name, Table1_Name, Table1_Name, Table1_Na, si e barabartëTable1_Name, Table1_Na, si e barabartëTable1_Name. krahasoni_kolonat, përfshini_kolonat si kolona_për të_përfshirë,

Fragmenti 9

PËRDORË [Emri i bazës së të dhënave] SHKO KRIJO INDEKSI TË JOKLUSTERUAR .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) PËRFSHIJ ([_Date_Time],[_Fld12771_2_RRref],[_Fld12771_2_RRref]2,8 Disa veçori të indeksimit sipas fushave agregate dhe fushave të renditjes.

Krijimi i një indeksi në kolonat e specifikuara në klauzolën ORDER BY ndihmon optimizuesin e pyetjeve të organizojë shpejt grupin e rezultateve sepse vlerat e kolonës janë të renditura paraprakisht në indeks. Zbatimi i brendshëm i mekanizmit GROUP BY gjithashtu rendit vlerat e kolonës së pari për të grupuar shpejt të dhënat e kërkuara.

Kur përdorni rekomandime tipike, ia vlen të kontrolloni rezultatin para dhe pas optimizimit. Le të japim një shembull të përdorimit të bashkimit logjik "OR" dhe alternativës së tij (për të eliminuar problemin me rekomandimet standarde) - një teknikë për ndryshimin e një pyetjeje përmes sintaksës "JOIN ALL".

1C kërkon vetë me "OR":

SELECT Kodin, Emrin, Lidhjen FROM Directory.Contractors AS Contractors WHERE Contractors.Code = "000000004" OR Contractors.Code = "0074853" OR Contractors.Code = "000000024" OSE Contractors.Code = "29Code.97 0074742" OSE Kontraktorët.Kodi = "000000104";

Modifikimi i pyetjes me "JOIN ALL":

SELECT Code, Emri, Link FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000004" CONNECT ALL SELECT Code, Emri, Link FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Kodi LinkNE,3ALLme SELECT4 FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000024" UNITE ALL SELECT Kodi, Emri, Lidhja FROM Directory.Counterparties AS Kundërpalët WHERE

Plani aktual i pyetjeve (për lehtësinë e paraqitjes dhe krahasimit të performancës, pyetjet përgjohen dhe ekzekutohen në SSMS):

Në këtë rast, pas optimizimit, performanca ra përgjysmë për shkak të përdorimit të përsëritur të operatorit Key Lookup, i cili ndiqet gjithmonë nga operatori Nested Loops. Prandaj, duke përdorur një skemë të optimizimit të pyetjeve, duhet të matni kohën e synuar para dhe pas përdorimit të përmirësimeve. Ky shembull është paraqitur për qëllimin e "besimit, por verifikimit", pasi mund të ketë mospërputhje midis rekomandimeve tipike dhe detyrave praktike.

Shpesh na bëhen pyetje si:

për shkak të asaj që ngadalëson serveri 1C?
kompjuteri me 1C punon shumë ngadalë
klienti 1C është jashtëzakonisht i ngadalshëm

Ndonjëherë, si zgjidhje për këtë çështje, ne u ofrojmë klientëve tanë një server me qira 1C pa frena, me një zgjedhje të konfigurimit të serverit dhe sistemit operativ, ju mund ta konfiguroni serverin në internet në faqen e internetit të partnerit tonë, duke ndjekur lidhjen https://1cloud.ru kapitulli Shërbimet, kapitulli Server virtual.

Çfarë duhet të bëni dhe si ta fitoni atë, dhe kështu me radhë me radhë:

Klientët punojnë shumë ngadalë me versionin e serverit të 1C

Përveç punës së ngadaltë të 1C, ka edhe punë të ngadaltë me skedarët e rrjetit. Problemi ndodh gjatë funksionimit normal dhe me RDP

për ta zgjidhur këtë, pas çdo instalimi të serverit Seven ose 2008, unë gjithmonë drejtoj

netsh int tcp set automatizimi global = çaktivizohet

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=disabled oxhak=disabled

dhe rrjeti funksionon pa probleme

ndonjëherë më e mira është:

Ndërfaqja netsh tcp set automatizimi global = Shumë i kufizuar

ja se si duket konfigurimi

Konfiguro Antivirus ose Windows Firewall

Si të konfiguroni murin e zjarrit Anti-Virus ose Windows për funksionimin e serverit 1C (një paketë nga serveri 1C: Enterprise dhe MS SQL 2008, për shembull).

Shtoni rregullat:

Nëse serveri SQL pranon lidhje në portin standard TCP 1433, atëherë ne e lejojmë atë.
Nëse porta SQL është dinamike, duhet të lejoni lidhjet me aplikacionin %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
Serveri 1C punon në portet 1541, grupin 1540 dhe diapazonin 1560-1591. Për arsye krejtësisht mistike, ndonjëherë një listë e tillë e porteve të hapura ende nuk lejon lidhje me serverin. Për ta bërë atë të funksionojë me siguri, lejoni diapazonin 1540-1591.

Rregullimi i performancës së serverit / kompjuterit

Në mënyrë që kompjuteri të funksionojë me performancë maksimale, duhet ta konfiguroni atë për këtë:

1. Cilësimet e BIOS-it

Në BIOS të serverit, çaktivizoni të gjitha cilësimet për të kursyer fuqinë e procesorit.
Nëse ka "C1E" dhe sigurohuni që ta shkëputni!!
Për disa detyra jo shumë paralele, rekomandohet gjithashtu të çaktivizoni hiperthreading në bios
Në disa raste (veçanërisht për HP!) duhet të futeni në BIOS-in e serverit dhe të fikni artikujt atje, në emër të të cilëve janë EIST, Intel SpeedStep dhe C1E.
Në vend të kësaj, duhet të gjeni në të njëjtin vend artikujt që lidhen me procesorin, në emër të të cilit ka Turbo Boost dhe t'i AKTIVINI ato.
Nëse BIOS ka një tregues të përgjithshëm të modalitetit të kursimit të energjisë dhe aktivizoni atë në modalitetin maksimal të performancës (mund të quhet gjithashtu "agresiv")

2. Cilësimet e skemës në sistemin operativ - Performancë e lartë

Serverët me arkitekturë Intel Sandy Bridge mund të ndryshojnë në mënyrë dinamike frekuencat e procesorit.

Ndonjëherë zgjidhja e problemit të funksionimit të ngadaltë të serverit 1C është pajisje e vjetëruar ose e prishur, në këtë rast ne u ofrojmë klientëve një server për 1C me qira pa frena, me një zgjedhje të konfigurimit të serverit dhe sistemit operativ, mund ta gjeni në faqen tonë faqen e internetit të partnerit, nga lidhja https://1cloud.ru seksioni Shërbimet, seksioni Server virtual.

Nëse keni ndonjë pyetje, ju lutemi kontaktoni:

telefononi +7-812-385-55-66 në Shën Petersburg
shkruani ne adrese
Lini një aplikacion në faqen tonë të internetit në faqen "Aplikimi në internet"