1s 8.3 töötab väga aeglaselt, mida teha. Automatiseerimise näpunäited
Mulle esitatakse sageli selliseid küsimusi nagu:
- mille tõttu server 1C aeglustub?
- 1C-ga arvuti töötab väga aeglaselt
- klient 1C on kohutavalt aeglane
Mida teha ja kuidas see võita jne järjekorras:
Kliendid töötavad 1C serveriversiooniga väga aeglaselt
Lisaks 1C aeglasele tööle on ka aeglane töö võrgufailidega. Probleem ilmneb tavapärase töötamise ja RDP-ga
Selle lahendamiseks käivitan ma pärast iga Seven või 2008 serveri installimist alati
netsh int tcp seatud globaalne autotuning=disabled
netsh int tcp seab globaalse autotuninglevel=disabled
netsh int tcp set global rss=disabled chimney=disabled
ja võrk töötab probleemideta
mõnikord on parim:
netsh liides tcp set global autotuning= HighlyRestricted
siin näeb seadistus välja
Konfigureerige viirusetõrje või Windowsi tulemüür
Viirusetõrje või Windowsi tulemüüri konfigureerimine 1C-serveri tööks (näiteks pakett 1C serverist: Enterprise ja MS SQL 2008).
Lisa reeglid:
- Kui SQL-server aktsepteerib ühendusi standardse TCP-pordi 1433 kaudu, siis lubame seda.
- Kui SQL-port on dünaamiline, peate lubama ühendused rakendusega %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
- Server 1C töötab portides 1541, klastris 1540 ja vahemikus 1560–1591. Täiesti müstilistel põhjustel ei võimalda mõnikord selline avatud portide loend ikkagi serveriga ühendusi luua. Et see kindlasti töötaks, lubage vahemik 1540–1591.
Serveri / arvuti jõudluse häälestamine
Selleks, et arvuti töötaks maksimaalse jõudlusega, peate selle konfigureerima:
1. BIOS-i sätted
- Protsessori toite säästmiseks keelake serveri BIOS-is kõik sätted.
- Kui on "C1E" ja LÕIDU kindlasti LAHTI!!
- Mõnede mitte väga paralleelsete ülesannete puhul on soovitatav ka biosis hüperkeermestamine välja lülitada
- Mõnel juhul (eriti HP puhul!) tuleb minna serveri BIOS-i ja VÄLJA lülitada seal olevad elemendid, mille nimel on EIST, Intel SpeedStep ja C1E.
- Selle asemel tuleb samast kohast üles leida protsessoriga seotud esemed, mille nimel on Turbo Boost ja need LUBADA.
- Kui BIOS-il on energiasäästurežiimi üldine märge ja lubage see maksimaalse jõudluse režiimis (seda võib nimetada ka "agressiivseks")
2. Skeemi sätted operatsioonisüsteemis – suur jõudlus
Intel Sandy Bridge arhitektuuriga serverid saavad protsessorite sagedusi dünaamiliselt muuta.
AT viimastel aegadel kasutajad ja administraatorid hakkavad üha enam kurtma, et hallatava rakenduse baasil välja töötatud uued 1C konfiguratsioonid on aeglased, mõnel juhul lubamatult aeglased. On selge, et uued konfiguratsioonid sisaldavad uusi funktsioone ja võimalusi ning on seetõttu ressursside suhtes nõudlikumad, kuid enamik kasutajaid ei mõista, mis mõjutab peamiselt 1C toimimist failirežiimis. Proovime seda lünka parandada.
Oma puhul oleme jõudluse mõju juba puudutanud ketta alamsüsteem kiirusega 1C aga see uuring puudutas rakenduse kohalikku kasutamist eraldi arvutis või terminaliserveris. Samas on enamiku pisirakenduste puhul tegemist failibaasiga üle võrgu, kus serverina kasutatakse üht kasutaja arvutit või siis tavalisel, enamasti ka soodsal arvutil põhineva spetsiaalse failiserveriga.
Väike uuring 1C venekeelsete ressursside kohta näitas, et sellest probleemist püütakse usinalt mööda minna, probleemide korral soovitatakse tavaliselt lülituda klient-serveri või terminali režiimile. Samuti on peaaegu üldiselt aktsepteeritud, et hallatava rakenduse konfiguratsioonid töötavad palju aeglasemalt kui tavalised. Reeglina antakse argumentidele "raud": "siin Accounting 2.0 lihtsalt lendas ja" kolmik "vaevu liigub, muidugi on neis sõnades tõtt, nii et proovime selle välja mõelda.
Ressursitarbimine lühidalt
Enne selle uuringu alustamist seadsime endale kaks eesmärki: välja selgitada, kas hallatud rakendusepõhised konfiguratsioonid on tegelikult aeglasemad kui tavalised konfiguratsioonid ja millised ressursid mõjutavad jõudlust kõige rohkem.
Testimiseks võtsime kaks virtuaalmasinat, milles töötas vastavalt Windows Server 2012 R2 ja Windows 8.1, eraldades neile kaks Core i5-4670 tuuma ja 2 GB. muutmälu, mis on ligikaudu samaväärne keskmise kontorimasinaga. Server paigutati kahest RAID 0 massiivi ja klient paigutati sarnasele üldotstarbeliste ketaste massiivile.
Eksperimentaalseteks alusteks oleme valinud mitu raamatupidamise versiooni 2.0 versiooni konfiguratsiooni 2.0.64.12 , mida seejärel värskendati 3.0.38.52 , käivitati kõik konfiguratsioonid platvormil 8.3.5.1443 .
Esimese asjana tõmbab tähelepanu Troika infobaasi suurenenud maht, mis on oluliselt kasvanud, aga ka palju suurem isu RAM-i järele:
Oleme juba valmis kuulma tavalist: "mis nad sellele kolmikule juurde andsid", aga ärgem kiirustagem. Erinevalt klient-serveri versioonide kasutajatest, mis nõuavad enam-vähem kvalifitseeritud administraatorit, mõtlevad failiversioonide kasutajad andmebaasi hooldusele harva. Ka neid baase teenindavate (loe - värskendavate) spetsialiseerunud ettevõtete töötajad mõtlevad sellele harva.
Vahepeal on 1C teabebaas oma vormingus täieõiguslik DBMS, mis vajab ka hooldust ja selleks on isegi tööriist nn. Infobaasi testimine ja parandamine. Võib-olla tegi nimi julma nalja, mis justkui viitab, et see on tõrkeotsingu tööriist, kuid kesine sooritus on samuti probleem ning ümberstruktureerimine ja uuesti indekseerimine koos tabeli tihendamisega on iga DBMS-i administraatori jaoks hästi tuntud andmebaasi optimeerimise tööriistad. Kontrollime?
Pärast valitud toimingute rakendamist kaotas andmebaas dramaatiliselt kaalust, muutudes veelgi väiksemaks kui "kaks", mida keegi pole samuti kunagi optimeerinud, ja ka RAM-i tarbimine vähenes veidi.
Seejärel, pärast uute klassifikaatorite ja kataloogide laadimist, indeksite loomist jne. aluse suurus kasvab, üldiselt on "kolme" alused suuremad kui "kahe" alused. See pole aga olulisem, kui teine versioon jäi rahule 150-200 MB RAM-iga, siis uus väljaanne vajab juba pool gigabaiti ja seda väärtust tuleks programmiga töötamiseks vajalike ressursside planeerimisel arvestada. .
Net
Võrgu ribalaius on võrgurakenduste jaoks üks olulisemaid parameetreid, eriti failirežiimis 1C, mis liigutab võrgu kaudu märkimisväärseid andmemahtusid. Enamik väikeettevõtete võrke on ehitatud odavate 100 Mbps seadmete baasil, seetõttu alustasime testimist, võrreldes 1C jõudlusnäitajaid 100 Mbps ja 1 Gbps võrkudes.
Mis juhtub, kui käivitate 1C failibaasi võrgu kaudu? Klient laadib ajutistesse kaustadesse alla üsna suure hulga teavet, eriti kui see on esimene "külm" käivitamine. 100 Mbps juures jooksime eeldatavalt ribalaiusele ja allalaadimine võib võtta märkimisväärselt palju aega, meie puhul umbes 40 sekundit (graafiku jagamise hind on 4 sekundit).
Teine käivitamine on kiirem, kuna osa andmetest salvestatakse vahemällu ja jäävad sinna kuni taaskäivitamiseni. Gigabiti võrgule üleminek võib märkimisväärselt kiirendada programmi laadimist, nii "külma" kui ka "kuuma" ja väärtuste suhet jälgitakse. Seetõttu otsustasime tulemust väljendada suhtelistena, võttes iga mõõtmise suurimaks väärtuseks 100%.
Nagu graafikutelt näha, laadib Accounting 2.0 mistahes võrgukiirusel kaks korda kiiremini, üleminek 100 Mbps-lt 1 Gbps-le võimaldab allalaadimisaega neli korda kiirendada. Selles režiimis pole optimeeritud ja optimeerimata troika andmebaaside vahel vahet.
Samuti kontrollisime võrgu kiiruse mõju rasketele töödele, näiteks rühma ümberhostimise ajal. Tulemust väljendatakse ka suhtelistena:
Siin on huvitavam, "troika" optimeeritud baas 100 Mbps võrgus töötab sama kiirusega kui "kaks" ja optimeerimata näitab kaks korda halvimat tulemust. Gigabitil suhted säilivad, optimeerimata "kolm" on samuti kaks korda aeglasem kui "kaks" ja optimeeritud jääb kolmandiku võrra maha. Samuti võimaldab üleminek kiirusele 1 Gb / s vähendada täitmisaega versiooni 2.0 puhul kolm korda ja versiooni 3.0 puhul kaks korda.
Võrgu kiiruse mõju hindamiseks igapäevatööle kasutasime jõudluse mõõtmine tehes igas andmebaasis eelnevalt määratletud toimingute jada.
Tegelikult ei ole igapäevaste toimingute jaoks võrgu ribalaius kitsaskoht, optimeerimata "kolm" on ainult 20% aeglasem kui kaks ja pärast optimeerimist selgub, et see on umbes sama kiirem - õhukese kliendi režiimis töötamise eelised mõjutavad. Üleminek kiirusele 1 Gb / s ei anna optimeeritud baasile mingeid eeliseid ning optimeerimata baas ja kahekordne hakkavad kiiremini tööle, näidates nende vahel väikest erinevust.
Läbiviidud testidest selgub, et võrk ei ole uute seadistuste jaoks kitsaskoht ning hallatav rakendus töötab tavapärasest veelgi kiiremini. Samuti võite soovitada üleminekut kiirusele 1 Gb/s, kui rasked ülesanded ja andmebaasi laadimiskiirus on teie jaoks kriitilised, muul juhul võimaldavad uued konfiguratsioonid tõhusalt töötada ka aeglastes 100 Mb/s võrkudes.
Miks siis 1C aeglustub? Uurime edasi.
Serveri ketta alamsüsteem ja SSD
Eelmises artiklis saavutasime 1C jõudluse tõusu, paigutades andmebaasid SSD-le. Võib-olla ei piisa serveri ketta alamsüsteemi jõudlusest? Mõõtsime kettaserveri jõudlust grupitöö käigus kahes andmebaasis korraga ja saime üsna optimistliku tulemuse.
Vaatamata suhteliselt suurele sisend-/väljundtoimingute arvule sekundis (IOPS) – 913, ei ületanud järjekorra pikkus 1,84, mis on väga hea tulemus. Selle põhjal võime eeldada, et tavaliste ketaste peeglist piisab 8-10 võrgukliendi normaalseks tööks rasketes režiimides.
Nii et kas serveris on vaja SSD-d? Parim viis sellele küsimusele vastata on testimine, mille viisime läbi sarnase metoodika abil, võrguühendus on kõikjal 1 Gb / s, tulemust väljendatakse ka suhtelistes väärtustes.
Alustame andmebaasi laadimiskiirusest.
Kellelegi võib see üllatav tunduda, kuid serveris olev SSD andmebaas ei mõjuta andmebaasi allalaadimiskiirust. Peamine piirav tegur siin, nagu näitas eelmine test, on võrgu läbilaskevõime ja kliendi jõudlus.
Liigume edasi juhtmestiku ümberpaigutamise juurde:
Oleme juba eespool märkinud, et ketta jõudlus on täiesti piisav isegi suure koormusega tööks, seetõttu ei mõjuta see ka SSD kiirust, välja arvatud optimeerimata alus, mis jõudis järele SSD optimeeritud omale. Tegelikult kinnitab see veel kord, et optimeerimistoimingud korrastavad teavet andmebaasis, vähendades juhuslike I/O operatsioonide arvu ja suurendades sellele juurdepääsu kiirust.
Igapäevaste ülesannete puhul on pilt sarnane:
SSD-st saab kasu ainult optimeerimata baas. Muidugi saab osta SSD, kuid palju parem oleks mõelda aluste õigeaegsele hooldusele. Samuti ärge unustage teabebaasi partitsiooni defragmentimist serveris.
Kliendiketta alamsüsteem ja SSD
Analüüsisime SSD mõju lokaalselt installitud 1C kiirusele aastal, suur osa öeldust kehtib ka võrgurežiimis töötamise kohta. Tõepoolest, 1C kasutab üsna aktiivselt kettaressursse, sealhulgas tausta- ja ajastatud toimingute jaoks. Alloleval joonisel on näha, kuidas Accounting 3.0 pärast laadimist umbes 40 sekundi jooksul üsna aktiivselt kettale ligi pääseb.
Kuid samal ajal peaksite teadma, et tööjaama jaoks kus aktiivne töö on toodetud ühe või kahe tavalise massseeria kõvaketta jõudlusressursside teabebaasi abil. SSD ostmine võib küll mõningaid protsesse kiirendada, kuid igapäevatöös radikaalset kiirendust ei märka, kuna näiteks laadimine on piiratud läbilaskevõime võrgud.
Aeglane HDD võib aeglustada mõningaid toiminguid, kuid ei saa iseenesest põhjustada programmi aeglustumist.
RAM
Hoolimata asjaolust, et RAM on nüüd nilbe odav, töötavad paljud tööjaamad jätkuvalt ostu ajal installitud mälumahuga. Siin ootavad ees esimesed probleemid. Lähtudes asjaolust, et keskmine "troika" vajab umbes 500 MB mälu, võime eeldada, et RAM-i kogumahust 1 GB-s programmiga töötamiseks ei piisa.
Vähendasime süsteemimälu 1 GB-ni ja käivitasime kaks teabebaasi.
Esmapilgul pole kõik nii hull, programm on oma isud mõõdukaks muutnud ja täielikult vaba mälu piires hoidnud, kuid ärgem unustagem, et vajadus operatiivandmete järele pole muutunud, kuhu need siis kadusid? Kettale, vahemällu, vahetusse jne loputatuna on selle toimingu olemus selles, et kiirest RAM-ist, mille mahust ei piisa, saadetakse aeglasele kettale andmed, mida hetkel ei vajata.
Kuhu see viib? Vaatame, kuidas kasutatakse süsteemiressursse rasketes operatsioonides, näiteks alustame grupi uuesti postitamist kahes andmebaasis korraga. Esmalt 2 GB RAM-iga süsteemis:
Nagu näete, kasutab süsteem aktiivselt võrku andmete vastuvõtmiseks ja protsessorit nende töötlemiseks, ketta aktiivsus on ebaoluline, töötlemise käigus aeg-ajalt kasvab, kuid ei ole piirav tegur.
Nüüd vähendame mälu 1 GB-ni:
Olukord muutub radikaalselt, põhikoormus langeb nüüd kõvakettale, protsessor ja võrk on jõude, oodates, kuni süsteem loeb vajalikud andmed kettalt mällu ja saadab sinna mittevajalikud andmed.
Samal ajal osutus isegi subjektiivne töö kahe avatud andmebaasiga 1 GB mäluga süsteemis äärmiselt ebamugavaks, kataloogid ja ajakirjad avanesid olulise viivitusega ja aktiivse kettale juurdepääsuga. Näiteks kaupade ja teenuste müügi ajakirja avamine võttis aega umbes 20 sekundit ja sellega kaasnes kogu selle aja kettaaktiivsus (punase joonega esile tõstetud).
Selleks, et objektiivselt hinnata RAM-i mõju hallatud rakendusel põhinevate konfiguratsioonide jõudlusele, viisime läbi kolm mõõtmist: esimese baasi laadimiskiirus, teise aluse laadimiskiirus ja grupi ümberpostitus ühes baasist. Mõlemad alused on täiesti identsed ja loodud optimeeritud aluse kopeerimise teel. Tulemust väljendatakse suhtelistes ühikutes.
Tulemus räägib enda eest, kui laadimisaeg kasvab umbes kolmandiku võrra, mis on veel üsna talutav, siis andmebaasis toimingute sooritamise aeg kasvab kolm korda, mingist mugavast tööst sellistes tingimustes pole vaja rääkidagi. Muide, see on nii, kui SSD ostmine võib olukorda parandada, kuid palju lihtsam (ja odavam) on tegeleda põhjuse, mitte tagajärgedega, ja osta lihtsalt õige kogus RAM-i.
RAM-i puudumine on peamine põhjus, miks uute 1C konfiguratsioonidega töötamine on ebamugav. Kaaluda tuleks minimaalselt sobivaid konfiguratsioone, kui pardal on 2 GB mälu. Samal ajal pidage meeles, et meie puhul loodi "kasvuhoone" tingimused: puhas süsteem, käivitati ainult 1C ja tegumihaldur. Reaalses elus on töötavas arvutis tavaliselt avatud brauser, kontorikomplekt, viirusetõrje jne, seega lähtuge vajadusest 500 MB andmebaasi kohta pluss teatud varu, et raskete toimingute ajal puudust ei tekiks. mälu ja jõudluse drastiline halvenemine.
Protsessor
Keskprotsessorit võib liialdamata nimetada arvuti südameks, kuna see on see, kes lõppkokkuvõttes töötleb kõiki arvutusi. Selle rolli hindamiseks viisime läbi veel ühe testide komplekti, sama mis RAM-i puhul, vähendades virtuaalmasinale saadaolevate tuumade arvu kahelt ühele, samas kui testi viidi läbi kaks korda mälumahuga 1 GB ja 2 GB.
Tulemus osutus üsna huvitavaks ja ootamatuks, võimsam protsessor võttis ressursipuuduse tingimustes üsna tõhusalt koormuse üle, ülejäänud aja aga käegakatsutavat kasu andmata. 1C Enterprise (failirežiimis) ei saa vaevalt nimetada protsessoriressursse aktiivselt kasutavaks rakenduseks, mis on üsna vähenõudlik. Ja rasketes oludes langeb protsessorile koormus mitte niivõrd rakenduse enda andmete arvutamisel, kuivõrd üldkulude teenindamisel: täiendavad I/O toimingud jne.
järeldused
Niisiis, miks 1C aeglustub? Esiteks on see RAM-i puudumine, põhikoormus langeb sel juhul kõvakettale ja protsessorile. Ja kui need ei hiilga jõudlusega, nagu tavaliselt kontorikonfiguratsioonides, siis saame artikli alguses kirjeldatud olukorra - "kaks" töötas hästi ja "kolm" aeglustab häbematult kiirust.
Teisele kohale tuleks anda võrgu jõudlus, aeglane 100 Mbps kanal võib muutuda tõeliseks kitsaskohaks, kuid samas suudab õhuke kliendi režiim säilitada üsna mugava töötaseme ka aeglastel kanalitel.
Siis peaksite tähelepanu pöörama kettale, SSD ostmine pole tõenäoliselt hea investeering, kuid ketta asendamine kaasaegsema vastu pole üleliigne. Kõvaketaste põlvkondade erinevust saab hinnata järgmise materjali põhjal: .
Ja lõpuks protsessor. Kiirem mudel pole muidugi üleliigne, kuid selle jõudluse suurendamisel pole mõtet, välja arvatud juhul, kui seda arvutit kasutatakse rasketeks toiminguteks: partiitöötlus, rasked aruanded, kuu sulgemine jne.
Loodame, et see materjal aitab teil kiiresti mõista küsimust "miks 1C aeglustub" ja lahendada selle kõige tõhusamalt ja ilma lisatasuta.
Sildid:
1C-süsteemil on väikeste ja keskmise suurusega ettevõtete automatiseerimisturul turgu valitsev positsioon. Kui ettevõte on valinud 1C raamatupidamissüsteemi, siis tavaliselt töötavad selles peaaegu kõik töötajad tavaspetsialistidest juhtkonnani. Vastavalt sellele sõltub ettevõtte äriprotsesside kiirus 1C kiirusest. Kui 1C töötab ebarahuldava kiirusega, mõjutab see otseselt kogu ettevõtte tööd ja kasumit.
Tegelikult on kolm 1C kiirenduse meetodit:
- Riistvara mahu suurendamine.
- Operatsioonisüsteemi ja DBMS-i sätete optimeerimine.
- Koodi ja algoritmide optimeerimine 1C-s.
Esimene meetod eeldab seadmete ja litsentside ostmist, kolmas nõuab programmeerijatelt palju tööjõudu ning selle tulemusena toovad mõlemad teed märkimisväärseid rahalisi kulutusi. Kõigepealt peate tähelepanu pöörama programmi koodile, kuna serveri võimsuse suurendamine ei kompenseeri vale koodi. Iga programmeerija teab, et vaid mõne koodirea abil on võimalik luua protsess, mis laadib täielikult iga serveri ressursid.
Kui ettevõte on kindel programmikoodi optimaalsuses ja see töötab endiselt aeglaselt, otsustab juhtkond tavaliselt serveri võimsust suurendada. Siinkohal tekib loogiline küsimus: millest jääb puudu, kui palju ja mida tuleb selle tulemusena lisada.
1C ettevõte annab üsna ebamäärase vastuse küsimusele, kui palju ressursse on vaja, kirjutasime sellest varem oma postitustes. Ja nii peate iseseisvalt katseid läbi viima ja välja mõtlema, millest 1C jõudlus sõltub. EFSOLi jõudluskatseid kirjeldatakse allpool.
1C 8.2-ga töötades, eriti hallatud vorme kasutavate konfiguratsioonidega, märgati kummalist tõsiasja: 1C töötab tööjaamas kiiremini kui võimsas serveris. Pealegi on kõik tööjaama omadused halvemad kui serveril.
Tabel 1 – konfiguratsioonid, mille alusel esialgne testimine viidi läbi
Tööjaam näitab 155% paremat jõudlust kui suurepärase jõudlusega 1C-server. Hakkasime aru saama, milles asi ja ahendasime otsingute ringi.
Joonis 1 – tööjaama jõudlusmõõtmised Gilevi testiga
Esimene kahtlus oli, et Gilevi test oli ebapiisav. Ankeetide avamise, dokumentide postitamise, aruannete koostamise jms mõõtmised mõõteriistade abil näitasid, et Gilevi test annab hinnangu, mis on võrdeline tegeliku töökiirusega 1C-s.
RAM-i arv ja sagedus
Internetis saadaoleva teabe analüüs näitas, et paljud kirjutavad 1C jõudluse sõltuvusest mälusagedusest. See tuleneb sagedusest, mitte helitugevusest. Otsustasime seda hüpoteesi testida, kuna meil on RAM-i sagedus serveris 1066 Mhz versus 1333 Mhz tööjaamas ja RAM-i maht serveris on juba palju suurem. Otsustasime panna kohe mitte 1066 Mhz, vaid 800 Mhz, et jõudluse sõltuvuse mõju mälusagedusest paremini näha oleks. Tulemus - tootlikkus langes 12% ja ulatus 39,37 ühikuni. Paigaldasime serverisse mälu sagedusega 1333 Mhz 1066 Mhz asemel ja saime jõudluse pisut tõusu - umbes 11%. Tootlikkus oli 19,53 ühikut. Järelikult pole see mälus, kuigi selle sagedus annab väikese tõusu.
Joonis 2 – tööjaama jõudluse mõõtmised pärast RAM-i sageduse langetamist
Joonis 3 – jõudluse mõõtmised serveris pärast RAM-i sageduse suurendamist
Ketta alamsüsteem
Järgmine hüpotees oli seotud ketta alamsüsteemiga. Kohe tekkis kaks hüpoteesi:
- SSD-d on paremad kui SAS-draivid, isegi kui need on raid 10-s.
- iSCSI on aeglane või ei tööta korralikult.
Seetõttu paigaldati tööjaama SSD asemel tavaline SATA ketas ja sama tehti ka serveriga - alus pandi kohalikule SATA kettale. Selle tulemusena ei ole jõudlusnäitajad kuidagi muutunud. Tõenäoliselt see juhtub, kuna RAM-i on piisavalt ja kettaid testi ajal praktiliselt ei kasutata.
Protsessor
Protsessorid serveris on muidugi võimsamad ja neid on kaks, aga sagedus on veidi väiksem kui tööjaamal. Otsustasime kontrollida protsessori sageduse mõju jõudlusele: serveri jaoks polnud käepärast kõrgema sagedusega protsessoreid, mistõttu langetasime tööjaama protsessori sagedust. Vähendasime selle kohe 1,6-ni, nii et korrelatsioon avaldus eredamalt. Test näitas, et jõudlus langes oluliselt, kuid isegi 1,6 protsessoriga tootis tööjaam ligi 28 ühikut, mis on ligi 1,5 korda rohkem kui serveris.
Joonis 4 – 1,6 GHz protsessoriga tööjaama jõudluse mõõtmised
videokaart
Internetis on teavet selle kohta, et videokaart võib mõjutada 1C jõudlust. Proovisime kasutada integreeritud tööjaama videot, professionaalset adapterit Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, vana GeForce graafikakaart 16 MbSDR. Gilevi testi ajal olulist erinevust ei märgatud. Võib-olla mõjutab videokaart endiselt, kuid reaalsetes tingimustes, kui peate avama hallatud vormid jne.
Hetkel on kaks kahtlust, miks tööjaam ka märgatavalt kehvema jõudlusega kiiremini töötab:
- PROTSESSOR. Tööjaama protsessori tüüp sobib paremini 1C-ga.
- Kiibistik. Kui muud asjad on võrdsed, on meie tööjaamal uuem kiibistik, mis võib olla põhjuseks.
Plaanime soetada vajalikud komponendid ja jätkata testidega, et lõpuks välja selgitada, millest 1C jõudlus suuremal määral sõltub. Sel ajal, kui kooskõlastus- ja hankeprotsess on käimas, otsustasime optimeerida, seda enam, et see ei maksa midagi. On kindlaks tehtud järgmised sammud:
1. etapp. Süsteemi seadistamine
Esmalt teeme BIOS-is ja operatsioonisüsteemis järgmised sätted:
- Protsessori toite säästmiseks keelake serveri BIOS-is kõik sätted.
- Valige operatsioonisüsteemis plaan "Maksimaalne jõudlus".
- Protsessor on häälestatud ka maksimaalse jõudluse saavutamiseks. Seda saab teha utiliidi PowerSchemeEd abil.
2. etapp. SQL-serveri ja 1C:Enterprise-serveri seadistamine
Teeme DBMS-serveri ja 1C:Enterprise seadetes järgmised muudatused.
- Jagatud mälu protokolli konfigureerimine:
- Jagatud mälu on lubatud ainult platvormil alates versioonist 1C 8.2.17, varasematel väljaannetel on lubatud Named Pipe – kiirus on mõnevõrra väiksem. See tehnoloogia töötab ainult siis, kui 1C ja MSSQL teenused on installitud samasse füüsilisse või virtuaalserverisse.
- Soovitatav on panna teenus 1C silumisrežiimi, paradoksaalselt annab see jõudluse tõuke. Vaikimisi on silumine serveris keelatud.
- SQL-serveri seadistamine:
- Vajame ainult serverit, ülejäänud selle juurde kuuluvad teenused ja võib-olla keegi neid kasutab, ainult aeglustavad tööd. Peatame ja keelame sellised teenused nagu: FullText Search (1C-l on oma täistekstiotsingu mehhanism), integratsiooniteenused jne.
- Määrake serverile eraldatud maksimaalne mälumaht. See on vajalik selleks, et sql-server saaks selle summaga arvestada ja mälu eelnevalt puhastada.
- Määrake lõimede maksimaalne arv (Maximum worker threads) ja määrake serveri suurenenud prioriteet (Boost priority).
3. etapp. Töötava andmebaasi loomine
Pärast DBMS-serveri ja 1C:Enterprise'i optimeerimist jätkame andmebaasi sätetega. Kui baasi pole veel .dt-failist juurutatud ja teate selle ligikaudset suurust, on parem kohe näidata esmase faili lähtestamissuurus märkega ">=", mis on baasi suurus, kuid see on maitse asi, kasutuselevõtmisel see ikka kasvab. Kuid suuruse automaatne suurendamine tuleb määrata: ligikaudu 200 MB andmebaasi kohta ja 50 MB logi kohta, sest. vaikeväärtused - kasv 1 MB ja 10% aeglustab serverit väga palju, kui see peab iga 3. tehinguga faili suurendama. Samuti on RAID-massiivi kasutamisel parem salvestada põhifail ja logifail erinevatele füüsilistele ketastele või RAID-rühmadele ning piirata logi kasvu. Tempdb-fail on soovitatav teisaldada kiiresse massiivi, kuna DBMS pääseb sellele üsna sageli juurde.
4. etapp. Ajastatud ülesannete seadistamine
Ajastatud ülesanded luuakse üsna lihtsalt, kasutades jaotises Haldus olevat Hooldusplaani, kasutades graafilisi tööriistu, mistõttu me ei kirjelda üksikasjalikult, kuidas seda tehakse. Mõelgem pikemalt sellele, milliseid toiminguid tuleb jõudluse parandamiseks teha.
- Indekseid tuleks defragmentida ja statistikat uuendada iga päev. kui indeksi killustatus on > 25%, vähendab see drastiliselt serveri jõudlust.
- Statistika defragmentimine ja värskendamine – tehakse kiiresti ja ei nõua kasutajate lahtiühendamist. Samuti on soovitatav seda teha iga päev.
- Täielik uuesti indekseerimine – tehakse andmebaasi lukuga, soovitav on seda teha vähemalt kord nädalas. Loomulikult defragmenteeritakse indeksid pärast täielikku uuesti indekseerimist ja statistikat värskendatakse kohe.
Selle tulemusel õnnestus süsteemi, SQL-serveri ja tööbaasi peenhäälestuse abil tõsta tootlikkust 46%. Mõõtmised viidi läbi 1C instrumendi ja Gilevi testi abil. Viimane näitas 25,6 ühikut algselt 17,53 vastu.
Lühike järeldus
- 1C jõudlus ei sõltu palju RAM-i sagedusest. Piisava mahu saavutamisel pole mälu edasisel laiendamisel mõtet, kuna see ei too kaasa jõudluse suurenemist.
- 1C jõudlus ei sõltu videokaardist.
- 1C jõudlus ei sõltu ketta alamsüsteemist, eeldusel, et ketaste lugemise või kirjutamise järjekorda ei ületata. Kui SATA-draivid on installitud ja need pole järjekorda ületanud, ei paranda SSD-ketta installimine jõudlust.
- Jõudlus sõltub suuresti protsessori sagedusest.
- Operatsioonisüsteemi ja MSSQL-serveri õige konfigureerimisega on võimalik saavutada 1C jõudluse kasv 40-50% ilma materiaalsete kuludeta.
TÄHELEPANU! Väga oluline punkt! Kõik mõõtmised viidi läbi katsealusel, kasutades Gilevi testi ja 1C mõõteriistu. Reaalse andmebaasi käitumine tegelike kasutajatega võib erineda saadud tulemustest. Näiteks testide andmebaasis ei leidnud me jõudluse sõltuvust videokaardist ja RAM-i hulgast. Need järeldused on üsna kaheldavad ja reaalsetes tingimustes võivad need tegurid tulemuslikkust oluliselt mõjutada. Hallatud vorme kasutavate konfiguratsioonidega töötamisel on oluline videokaart ja võimas graafikaprotsessor kiirendab tööd programmiliidese joonistamise osas, visuaalselt väljendub see kiiremas 1C töös.
Kas teie 1C töötab aeglaselt? Tellige arvutite ja serverite IT-hooldus paljude aastate kogemusega EFSOL-i spetsialistidelt või viige oma 1C üle võimsasse ja tõrketaluvasse 1C virtuaalserverisse.
Süsteemi integreerimine. Konsulteerimine
Saame sageli küsimusi selle kohta, mis aeglustab 1-e, eriti versioonile 1s 8.3 üleminekul, tänu meie kolleegidele Interface LLC-st räägime üksikasjalikult:
Oma eelmistes väljaannetes oleme juba puudutanud ketta alamsüsteemi jõudluse mõju 1C kiirusele, kuid see uuring puudutas rakenduse kohalikku kasutamist eraldi arvutis või terminaliserveris. Samas on enamiku pisirakenduste puhul tegemist failibaasiga üle võrgu, kus serverina kasutatakse üht kasutaja arvutit või siis tavalisel, enamasti ka soodsal arvutil põhineva spetsiaalse failiserveriga.
Väike uuring 1C venekeelsete ressursside kohta näitas, et sellest probleemist püütakse usinalt mööda minna, probleemide korral soovitatakse tavaliselt lülituda klient-serveri või terminali režiimile. Samuti on peaaegu üldiselt aktsepteeritud, et hallatava rakenduse konfiguratsioonid töötavad palju aeglasemalt kui tavalised. Reeglina antakse argumentidele "raudne": "siin Accounting 2.0 lihtsalt lendas ja" kolmik "vaevu liigub", muidugi on neis sõnades tõtt, nii et proovime selle välja mõelda.
Ressursitarbimine lühidalt
Enne selle uuringu alustamist seadsime endale kaks eesmärki: välja selgitada, kas hallatud rakendusepõhised konfiguratsioonid on tegelikult aeglasemad kui tavalised konfiguratsioonid ja millised ressursid mõjutavad jõudlust kõige rohkem.
Testimiseks võtsime kaks virtuaalmasinat, millel töötab vastavalt Windows Server 2012 R2 ja Windows 8.1, eraldades neile 2 tuuma Core i5-4670 ja 2 GB muutmälu, mis vastab ligikaudu keskmisele kontorimasinale. Server paigutati kahe WD Se massiivi RAID 0 ja klient paigutati sarnasele üldotstarbeliste ketaste massiivile.
Eksperimentaalseteks alusteks oleme valinud mitu raamatupidamise versiooni 2.0 versiooni konfiguratsiooni 2.0.64.12 , mida seejärel värskendati 3.0.38.52 , käivitati kõik konfiguratsioonid platvormil 8.3.5.1443 .
Esimese asjana tõmbab tähelepanu Troika infobaasi suurenenud maht, mis on oluliselt kasvanud, aga ka palju suurem isu RAM-i järele:
Oleme juba valmis kuulma tavalist: "mis nad sellele kolmikule juurde andsid", aga ärgem kiirustagem. Erinevalt klient-serveri versioonide kasutajatest, mis nõuavad enam-vähem kvalifitseeritud administraatorit, mõtlevad failiversioonide kasutajad andmebaasi hooldusele harva. Ka neid baase teenindavate (loe - värskendavate) spetsialiseerunud ettevõtete töötajad mõtlevad sellele harva.
Vahepeal on 1C teabebaas oma vormingus täieõiguslik DBMS, mis vajab ka hooldust ja selleks on isegi tööriist nn. Infobaasi testimine ja parandamine. Võib-olla tegi nimi julma nalja, mis näib viitavat sellele, et see on tõrkeotsingu tööriist, kuid probleem on ka kehv jõudlus ning ümberstruktureerimine ja uuesti indekseerimine koos tabeli tihendamisega on kõigile RDBMS-i administraatoritele tuntud andmebaasi optimeerimise tööriistad. Kontrollime?
Pärast valitud toimingute rakendamist kaotas andmebaas dramaatiliselt kaalust, muutudes veelgi väiksemaks kui "kaks", mida keegi pole samuti kunagi optimeerinud, ja ka RAM-i tarbimine vähenes veidi.
Seejärel, pärast uute klassifikaatorite ja kataloogide laadimist, indeksite loomist jne. aluse suurus kasvab, üldiselt on "kolme" alused suuremad kui "kahe" alused. See pole aga olulisem, kui teine versioon jäi rahule 150-200 MB RAM-iga, siis uus väljaanne vajab juba pool gigabaiti ja seda väärtust tuleks programmiga töötamiseks vajalike ressursside planeerimisel arvestada. .
Net
Võrgu ribalaius on võrgurakenduste jaoks üks olulisemaid parameetreid, eriti failirežiimis 1C, mis liigutab võrgu kaudu märkimisväärseid andmemahtusid. Enamik väikeettevõtete võrke on ehitatud odavate 100 Mbps seadmete baasil, seetõttu alustasime testimist, võrreldes 1C jõudlusnäitajaid 100 Mbps ja 1 Gbps võrkudes.
Mis juhtub, kui käivitate 1C failibaasi võrgu kaudu? Klient laadib ajutistesse kaustadesse alla üsna suure hulga teavet, eriti kui see on esimene "külm" käivitamine. 100 Mbps juures jooksime eeldatavalt ribalaiusele ja allalaadimine võib võtta märkimisväärselt palju aega, meie puhul umbes 40 sekundit (graafiku jagamise hind on 4 sekundit).
Teine käivitamine on kiirem, kuna osa andmetest salvestatakse vahemällu ja jäävad sinna kuni taaskäivitamiseni. Gigabiti võrgule üleminek võib märkimisväärselt kiirendada programmi laadimist, nii "külma" kui ka "kuuma" ja väärtuste suhet jälgitakse. Seetõttu otsustasime tulemust väljendada suhtelistena, võttes iga mõõtmise suurimaks väärtuseks 100%.
Nagu graafikutelt näha, laadib Accounting 2.0 mistahes võrgukiirusel kaks korda kiiremini, üleminek 100 Mbps-lt 1 Gbps-le võimaldab allalaadimisaega neli korda kiirendada. Selles režiimis pole optimeeritud ja optimeerimata troika andmebaaside vahel vahet.
Samuti kontrollisime võrgu kiiruse mõju rasketele töödele, näiteks rühma ümberhostimise ajal. Tulemust väljendatakse ka suhtelistena:
Siin on huvitavam, "troika" optimeeritud baas 100 Mbps võrgus töötab sama kiirusega kui "kaks" ja optimeerimata näitab kaks korda halvimat tulemust. Gigabitil suhted säilivad, optimeerimata "kolm" on samuti kaks korda aeglasem kui "kaks" ja optimeeritud jääb kolmandiku võrra maha. Samuti võimaldab üleminek kiirusele 1 Gb / s vähendada täitmisaega versiooni 2.0 puhul kolm korda ja versiooni 3.0 puhul kaks korda.
Võrgu kiiruse mõju hindamiseks igapäevatööle kasutasime jõudluse mõõtmine tehes igas andmebaasis eelnevalt määratletud toimingute jada.
Tegelikult ei ole igapäevaste toimingute jaoks võrgu ribalaius kitsaskoht, optimeerimata "kolm" on ainult 20% aeglasem kui kaks ja pärast optimeerimist selgub, et see on umbes sama kiirem - õhukese kliendi režiimis töötamise eelised mõjutavad. Üleminek kiirusele 1 Gb / s ei anna optimeeritud baasile mingeid eeliseid ning optimeerimata baas ja kahekordne hakkavad kiiremini tööle, näidates nende vahel väikest erinevust.
Läbiviidud testidest selgub, et võrk ei ole uute seadistuste jaoks kitsaskoht ning hallatav rakendus töötab tavapärasest veelgi kiiremini. Samuti võite soovitada üleminekut kiirusele 1 Gb/s, kui rasked ülesanded ja andmebaasi laadimiskiirus on teie jaoks kriitilised, muul juhul võimaldavad uued konfiguratsioonid tõhusalt töötada ka aeglastes 100 Mb/s võrkudes.
Miks siis 1C aeglustub? Uurime edasi.
Serveri ketta alamsüsteem ja SSD
Eelmises artiklis saavutasime 1C jõudluse tõusu, paigutades andmebaasid SSD-le. Võib-olla ei piisa serveri ketta alamsüsteemi jõudlusest? Mõõtsime kettaserveri jõudlust grupitöö käigus kahes andmebaasis korraga ja saime üsna optimistliku tulemuse.
Vaatamata suhteliselt suurele sisend-/väljundoperatsioonide arvule sekundis (IOPS) – 913, ei ületanud järjekorra pikkus 1,84, mis on kahe kettaga massiivi puhul väga hea tulemus. Selle põhjal võime eeldada, et tavaliste ketaste peeglist piisab 8-10 võrgukliendi normaalseks tööks rasketes režiimides.
Nii et kas serveris on vaja SSD-d? Parim viis sellele küsimusele vastata on testimine, mille viisime läbi sarnase metoodika abil, võrguühendus on kõikjal 1 Gb / s, tulemust väljendatakse ka suhtelistes väärtustes.
Alustame andmebaasi laadimiskiirusest.
Kellelegi võib see üllatav tunduda, kuid serveris olev SSD andmebaas ei mõjuta andmebaasi allalaadimiskiirust. Peamine piirav tegur siin, nagu näitas eelmine test, on võrgu läbilaskevõime ja kliendi jõudlus.
Liigume edasi juhtmestiku ümberpaigutamise juurde:
Oleme juba eespool märkinud, et ketta jõudlus on täiesti piisav isegi suure koormusega tööks, seetõttu ei mõjuta see ka SSD kiirust, välja arvatud optimeerimata alus, mis jõudis järele SSD optimeeritud omale. Tegelikult kinnitab see veel kord, et optimeerimistoimingud korrastavad teavet andmebaasis, vähendades juhuslike I/O operatsioonide arvu ja suurendades sellele juurdepääsu kiirust.
Igapäevaste ülesannete puhul on pilt sarnane:
SSD-st saab kasu ainult optimeerimata baas. Muidugi saab osta SSD, kuid palju parem oleks mõelda aluste õigeaegsele hooldusele. Samuti ärge unustage teabebaasi partitsiooni defragmentimist serveris.
Kliendiketta alamsüsteem ja SSD
Eelmises artiklis analüüsisime SSD mõju kohapeal installitud 1C kiirusele, suur osa öeldust kehtib ka võrgurežiimis töötamise kohta. Tõepoolest, 1C kasutab üsna aktiivselt kettaressursse, sealhulgas tausta- ja ajastatud toimingute jaoks. Alloleval joonisel on näha, kuidas Accounting 3.0 pärast laadimist umbes 40 sekundi jooksul üsna aktiivselt kettale ligi pääseb.
Kuid samas tasub meeles pidada, et tööjaama jaoks, kus tehakse aktiivset tööd ühe või kahe infobaasiga, piisab tavalise massseeria HDD jõudlusressursist. SSD ostmine võib küll mõningaid protsesse kiirendada, kuid igapäevatöös radikaalset kiirendust ei märka, kuna näiteks allalaadimist piirab võrgu ribalaius.
Aeglane kõvaketas võib mõningaid toiminguid aeglustada, kuid see ei saa iseenesest põhjustada programmi aeglustumist.
RAM
Hoolimata asjaolust, et RAM on nüüd nilbe odav, töötavad paljud tööjaamad jätkuvalt ostu ajal installitud mälumahuga. Siin ootavad ees esimesed probleemid. Lähtudes asjaolust, et keskmine "troika" vajab umbes 500 MB mälu, võime eeldada, et RAM-i kogumahust 1 GB-s programmiga töötamiseks ei piisa.
Vähendasime süsteemimälu 1 GB-ni ja käivitasime kaks teabebaasi.
Esmapilgul pole kõik nii hull, programm on oma isud mõõdukaks muutnud ja täielikult vaba mälu piires hoidnud, kuid ärgem unustagem, et vajadus operatiivandmete järele pole muutunud, kuhu need siis kadusid? Kettale, vahemällu, vahetusse jne loputatuna on selle toimingu olemus selles, et kiirest RAM-ist, mille mahust ei piisa, saadetakse aeglasele kettale andmed, mida hetkel ei vajata.
Kuhu see viib? Vaatame, kuidas kasutatakse süsteemiressursse rasketes operatsioonides, näiteks alustame grupi uuesti postitamist kahes andmebaasis korraga. Esmalt 2 GB RAM-iga süsteemis:
Nagu näete, kasutab süsteem aktiivselt võrku andmete vastuvõtmiseks ja protsessorit nende töötlemiseks, ketta aktiivsus on ebaoluline, töötlemise käigus aeg-ajalt kasvab, kuid ei ole piirav tegur.
Nüüd vähendame mälu 1 GB-ni:
Olukord muutub radikaalselt, põhikoormus langeb nüüd kõvakettale, protsessor ja võrk on jõude, oodates, kuni süsteem loeb vajalikud andmed kettalt mällu ja saadab sinna mittevajalikud andmed.
Samal ajal osutus isegi subjektiivne töö kahe avatud andmebaasiga 1 GB mäluga süsteemis äärmiselt ebamugavaks, kataloogid ja ajakirjad avanesid olulise viivitusega ja aktiivse kettale juurdepääsuga. Näiteks kaupade ja teenuste müügi ajakirja avamine võttis aega umbes 20 sekundit ja sellega kaasnes kogu selle aja kettaaktiivsus (punase joonega esile tõstetud).
Selleks, et objektiivselt hinnata RAM-i mõju hallatud rakendusel põhinevate konfiguratsioonide jõudlusele, viisime läbi kolm mõõtmist: esimese baasi laadimiskiirus, teise aluse laadimiskiirus ja grupi ümberpostitus ühes baasist. Mõlemad alused on täiesti identsed ja loodud optimeeritud aluse kopeerimise teel. Tulemust väljendatakse suhtelistes ühikutes.
Tulemus räägib enda eest, kui laadimisaeg kasvab umbes kolmandiku võrra, mis on veel üsna talutav, siis andmebaasis toimingute sooritamise aeg kasvab kolm korda, mingist mugavast tööst sellistes tingimustes pole vaja rääkidagi. Muide, see on nii, kui SSD ostmine võib olukorda parandada, kuid palju lihtsam (ja odavam) on tegeleda põhjuse, mitte tagajärgedega, ja osta lihtsalt õige kogus RAM-i.
RAM-i puudumine on peamine põhjus, miks uute 1C konfiguratsioonidega töötamine on ebamugav. Kaaluda tuleks minimaalselt sobivaid konfiguratsioone, kui pardal on 2 GB mälu. Samal ajal pidage meeles, et meie puhul loodi "kasvuhoone" tingimused: puhas süsteem, käivitati ainult 1C ja tegumihaldur. Reaalses elus on töötavas arvutis tavaliselt avatud brauser, kontorikomplekt, viirusetõrje jne, seega lähtuge vajadusest 500 MB andmebaasi kohta pluss teatud varu, et raskete toimingute ajal puudust ei tekiks. mälu ja jõudluse drastiline halvenemine.
Protsessor
Keskprotsessorit võib liialdamata nimetada arvuti südameks, kuna see on see, kes lõppkokkuvõttes töötleb kõiki arvutusi. Selle rolli hindamiseks viisime läbi veel ühe testide komplekti, sama mis RAM-i puhul, vähendades virtuaalmasinale saadaolevate tuumade arvu kahelt ühele, samas kui testi viidi läbi kaks korda mälumahuga 1 GB ja 2 GB.
Tulemus osutus üsna huvitavaks ja ootamatuks, võimsam protsessor võttis ressursipuuduse tingimustes üsna tõhusalt koormuse üle, ülejäänud aja aga käegakatsutavat kasu andmata. Vaevalt saab 1C Enterprise'i nimetada aktiivselt protsessoriressursse kasutavaks rakenduseks, mis on üsna vähenõudlik. Ja rasketes oludes langeb protsessorile koormus mitte niivõrd rakenduse enda andmete arvutamisel, kuivõrd üldkulude teenindamisel: täiendavad I/O toimingud jne.
järeldused
Niisiis, miks 1C aeglustub? Esiteks on see RAM-i puudumine, põhikoormus langeb sel juhul kõvakettale ja protsessorile. Ja kui need ei hiilga jõudlusega, nagu tavaliselt kontorikonfiguratsioonides, siis saame artikli alguses kirjeldatud olukorra - "kaks" töötas hästi ja "kolm" aeglustab häbematult kiirust.
Teisele kohale tuleks anda võrgu jõudlus, aeglane 100 Mbps kanal võib muutuda tõeliseks kitsaskohaks, kuid samas suudab õhuke kliendi režiim säilitada üsna mugava töötaseme ka aeglastel kanalitel.
Siis peaksite tähelepanu pöörama kettale, SSD ostmine pole tõenäoliselt hea investeering, kuid ketta asendamine kaasaegsema vastu pole üleliigne. Kõvaketaste põlvkondade erinevust saab hinnata järgmise materjali põhjal: Ülevaade kahest odavast Western Digital Blue seeria draivist 500 GB ja 1 TB.
Ja lõpuks protsessor. Kiirem mudel pole muidugi üleliigne, kuid selle jõudluse suurendamisel pole mõtet, välja arvatud juhul, kui seda arvutit kasutatakse rasketeks toiminguteks: partiitöötlus, rasked aruanded, kuu sulgemine jne.
Loodame, et see materjal aitab teil kiiresti mõista küsimust "miks 1C aeglustub" ja lahendada selle kõige tõhusamalt ja ilma lisatasuta.
Fraasi "1C aeglustab" pidid kuulma kõik, kes töötavad platvormil 1C: Enterprise toodetega. Keegi kaebas selle üle, keegi võttis kaebused vastu. Selles artiklis püüame kaaluda selle probleemi levinumaid põhjuseid ja selle lahendamise võimalusi.
Pöördume metafoori juurde: enne kui välja selgitada, miks inimene kuhugi ei läinud, tasub veenduda, et tal on jalad, mida käia. Niisiis, alustame riistvara- ja võrgunõuetega.
Kui installitud on Windows 7:
Kui installitud on Windows 8 või 10:
Samuti pidage meeles, et vaba kettaruumi peab olema vähemalt 2 GB ja võrguühenduse kiirus peab olema vähemalt 100 Mb / s.
Serverite omadustega klient-serveri versioonis pole palju mõtet arvestada, sest sel juhul sõltub kõik kasutajate arvust ja nende ülesannete spetsiifikast, mida nad 1C-s lahendavad.
Serveri konfiguratsiooni valimisel pidage meeles järgmist.
- 1C serveri üks tööprotsess tarbib keskmiselt 4 GB (mitte segi ajada kasutajaühendusega, sest ühel tööprotsessil võib olla nii palju ühendusi, kui serveri seadetes määrate);
- 1C ja DBMS-i (eriti MS SQL) kasutamine samas füüsilises serveris annab kasu suurte andmemassiivide töötlemisel (näiteks kuu sulgemine, eelarve arvutamine mudeli järgi jne), kuid vähendab oluliselt jõudlust mahalaadimise ajal. toimingud (näiteks rakendusdokumendi loomine ja läbiviimine jne);
- Pidage meeles, et 1C-serverid ja DBMS-id peavad olema ühendatud 1 GB paksuse kanali kaudu;
- Kasutage suure jõudlusega kettaid ja ärge ühendage 1C-serveri ja DBMS-i rolle teiste rollidega (näiteks fail, AD, domeenikontroller jne).
Kui pärast seadmete kontrollimist 1C ikkagi "aeglustab"
Meil on väike firma, 7 inimest ja 1C "aeglustab". Pöördusime spetsialistide poole ja nad ütlesid, et ainult klient-server valik päästab meid. Kuid meie jaoks pole selline lahendus vastuvõetav, see on liiga kallis!
Tehke andmebaasis rutiinset hooldust*:
1. Käivitage andmebaas konfiguraatori režiimis.
2. Valige peamenüüs üksus "Haldus" ja selles - "Testimine ja parandamine".
3. Määrake kõik märkeruudud nagu pildil. Klõpsake käsul Käivita.
*See protseduur võib sõltuvalt aluse suurusest ja arvuti omadustest võtta aega 15 minutist kuni tunnini.
Kui see ei aita, siis loome kliendi-serveri ühenduse, kuid ilma täiendavate investeeringuteta riist- ja tarkvarasse:
1. Valige statsionaarse (mitte sülearvuti) hulgast kontoris kõige vähem koormatud arvuti: sellel peab olema vähemalt 4 GB muutmälu ja võrguühendus vähemalt 100 Mb/s.
2. Aktiveerige sellel IIS (Internet Information Server). Selle jaoks:
3. Avaldage oma andmebaas selles arvutis. Selle teema kohta on saadaval materjal ITS-is või võtke ühendust tugispetsialistiga.
4. Kasutajaarvutites konfigureerige juurdepääs andmebaasile õhukese kliendi kaudu. Selle jaoks:
Avage käivitusaken 1C.
Valige oma tööbaas. See on teie baas siin. Klõpsake nuppu Redigeeri. Seadke lüliti asendisse "Veebiserveris", määrake selle all olevale reale selle serveri nimi või IP-aadress, millel IIS aktiveeriti, ja nimi, mille all andmebaas avaldati. Vajutage "Järgmine".
Seadke lüliti "Põhikäivitusrežiim" režiimile "Õhuke klient". Klõpsake nuppu "Lõpeta".
Meil on suht suur firma aga mitte väga suur ka, 50-60 inimest.Kasutame klient-server varianti, aga 1C on jube aeglane.
Sel juhul on soovitatav eraldada 1C-server ja DBMS-server kaheks erinevaks serveriks. Eraldamisel pidage kindlasti meeles: kui need jäid samasse füüsilist serverisse, mis lihtsalt virtualiseeriti, siis peavad nende serverite kettad olema erinevad - füüsiliselt erinevad! Samuti määrake kindlasti rutiinsed ülesanded DBMS-i serveris, kui tegemist on MS SQL-iga (selle kohta on täpsemalt kirjeldatud ITS-i veebisaidil)
Meil on üsna suur ettevõte, rohkem kui 100 kasutajat. Kõik on seadistatud vastavalt selle valiku 1C soovitustele, kuid mõne dokumendi läbiviimisel "aeglustab" 1C väga palju ja mõnikord ilmneb blokeerimisviga. Äkki teeks aluse keerdumise?
Sarnane olukord tekib väga spetsiifilise akumulatsiooniregistri või raamatupidamise (aga sagedamini - akumulatsiooni) suuruse tõttu, kuna register kas pole üldse “suletud”, s.t. on sissetulekute liikumisi, kuid kulude liikumist ei ole või on mõõtmiste arv, millega registri saldosid arvutatakse, väga suur. Võib esineda isegi kahe eelneva põhjuse segu. Kuidas teha kindlaks, milline register kõik ära rikub?
Fikseerime aja, millal dokumente töödeldakse aeglaselt või kellaaega ja kasutajat, kellel on blokeerimisviga.
Avage registreerimislogi.
Leiame vajaliku dokumendi õigel ajal õigele kasutajale sündmusetüübiga „Data.Conduct”.
Vaatame kogu tehinguplokki kuni tehingu tühistamise hetkeni, kui ilmnes blokeerimisviga, või otsime kõige pikemat muudatust (aeg eelmisest kirjest on üle minuti).
Pärast seda langetame otsuse, pidades silmas, et seda konkreetset registrit on igal juhul odavam kokku tõmmata kui kogu andmebaasi.
Oleme väga suur ettevõte, rohkem kui 1000 kasutajat, tuhandeid dokumente päevas, oma IT-osakond, tohutu serveripark, oleme mitu korda taotlusi optimeerinud, kuid 1C aeglustub. Ilmselt oleme 1C-st välja kasvanud ja vajame midagi võimsamat.
Valdav enamus sellistel juhtudel ei "aeglusta" mitte 1C, vaid kasutatud lahenduse arhitektuur. Tehes valikut uue äriprogrammi kasuks, pea meeles, et odavam ja lihtsam on oma äriprotsesse programmi kirjutada, kui mõne, eriti väga kalli programmi jaoks ümber teha. Ainult 1C annab sellise võimaluse. Seetõttu on parem endalt küsida: “Kuidas olukorda parandada? Kuidas panna 1C sellistel mahtudel "lendama"? Vaatame mõningaid ravivõimalusi:
- Kasutage paralleelse ja asünkroonse programmeerimise tehnoloogiaid, mida 1C toetab (taustaülesanded ja päringud tsüklis).
- Lahenduse arhitektuuri kujundamisel keelduda akumulatsiooniregistrite ja raamatupidamisregistrite kasutamisest kõige „pudelikaela“ kohtades.
- Andmestruktuuri (akumulatsiooni- ja/või inforegistrite) väljatöötamisel järgi reeglit: "Kõige kiiremini saab kirjutada ja lugeda ühe veeruga tabeli." Mis on kaalul, saab selgemaks, kui vaatame tüüpilist RAUS-i mehhanismi.
- Suurte andmemahtude töötlemiseks kasutage abiklastreid, kus on ühendatud sama andmebaas (kuid interaktiivselt töötades ei tohiks seda mingil juhul teha !!!). See möödub standardsetest 1C lukkudest, mis võimaldab töötada andmebaasiga peaaegu sama kiirusega kui otse SQL-tööriistadega töötades.
Väärib märkimist, et 1C optimeerimine osaluste ja suurettevõtete jaoks on eraldi suure artikli teema, nii et jääge meie veebisaidil olevate materjalide värskendustega kursis.