1s 8.3 windows xp veikia lėtai. Automatikos patarimai. Operatyvinės partijos apskaitos išjungimas

1s 8.3 windows xp veikia lėtai. Automatikos patarimai. Operatyvinės partijos apskaitos išjungimas

Pastaruoju metu vartotojai ir administratoriai vis dažniau ima skųstis, kad naujos 1C konfigūracijos, sukurtos remiantis valdoma programa, veikia lėtai, kai kuriais atvejais – nepriimtinai lėtai. Akivaizdu, kad naujose konfigūracijose yra naujų funkcijų ir galimybių, todėl jos reikalauja daugiau išteklių, tačiau dauguma vartotojų nesupranta, kas pirmiausia turi įtakos 1C veikimui failo režimu. Pabandykime ištaisyti šią spragą.

Savo darbe jau palietėme disko posistemio veikimo įtaką 1C greičiui, tačiau šis tyrimas buvo susijęs su vietiniu programos naudojimu atskirame kompiuteryje arba terminalo serveryje. Tuo pačiu metu dauguma mažų diegimų apima darbą su failų duomenų baze tinkle, kur vienas iš vartotojo kompiuterių naudojamas kaip serveris, arba specialiu failų serveriu, kurio pagrindas yra įprastas, dažniausiai taip pat nebrangus kompiuteris.

Nedidelis rusų kalbos išteklių tyrimas 1C parodė, kad iškilus problemoms šios problemos uoliai vengiama, dažniausiai rekomenduojama pereiti į kliento-serverio arba terminalo režimą. Taip pat beveik visuotinai pripažinta, kad valdomos programos konfigūracijos veikia daug lėčiau nei įprastai. Paprastai argumentai yra „geležiniai“: „Apskaita 2.0 tiesiog skrido, o „troika“ vos pajudėjo, žinoma, šiuose žodžiuose yra dalis tiesos, todėl pabandykime tai išsiaiškinti.

Išteklių suvartojimas, iš pirmo žvilgsnio

Prieš pradėdami šį tyrimą, išsikėlėme du tikslus: išsiaiškinti, ar valdomos taikomųjų programų konfigūracijos iš tikrųjų yra lėtesnės nei įprastos konfigūracijos ir kurie konkretūs ištekliai turi didžiausią įtaką našumui.

Bandymui paėmėme dvi virtualias mašinas, kuriose veikia atitinkamai „Windows Server 2012 R2“ ir „Windows 8.1“, suteikdami joms 2 pagrindinio „Core i5-4670“ branduolius ir 2 GB RAM, o tai maždaug atitinka vidutinį biuro įrenginį. Serveris buvo patalpintas į dviejų RAID 0 masyvą, o klientas – į panašų bendrosios paskirties diskų masyvą.

Kaip eksperimentinę bazę pasirinkome keletą apskaitos 2.0 versijos konfigūracijų 2.0.64.12 , kuris vėliau buvo atnaujintas į 3.0.38.52 , visos konfigūracijos buvo paleistos platformoje 8.3.5.1443 .

Pirmas dalykas, kuris patraukia dėmesį, yra padidėjęs trejeto informacinės bazės dydis, kuris gerokai išaugo, taip pat daug didesnis apetitas RAM:

Esame pasirengę išgirsti įprastą: „kodėl jie tai pridėjo prie šių trijų“, bet neskubėkime. Skirtingai nuo kliento-serverio versijų naudotojų, kuriems reikalingas daugiau ar mažiau kvalifikuotas administratorius, failų versijų vartotojai retai susimąsto apie duomenų bazių priežiūrą. Taip pat retai apie tai susimąsto specializuotų, šias duomenų bazes aptarnaujančių (skaitykite atnaujinančių) įmonių darbuotojai.

Tuo tarpu 1C informacijos bazė yra visavertė savo formato DBVS, kuriai taip pat reikia priežiūros, o tam yra net įrankis, vadinamas Informacinės bazės testavimas ir taisymas. Galbūt pavadinimas suvaidino žiaurų pokštą, o tai kažkaip reiškia, kad tai yra trikčių šalinimo įrankis, tačiau mažas našumas taip pat yra problema, o restruktūrizavimas ir pakartotinis indeksavimas kartu su lentelių glaudinimu yra gerai žinomi įrankiai, skirti optimizuoti duomenų bazes bet kuriam DBVS administratoriui. . Ar patikrinsime?

Pritaikius pasirinktus veiksmus, duomenų bazė smarkiai „numetė svorio“, tapo dar mažesnė už „du“, kurių niekas niekada neoptimizavo, o RAM sąnaudos taip pat šiek tiek sumažėjo.

Vėliau, įkėlus naujus klasifikatorius ir katalogus, sukūrus indeksus ir pan. pagrindo dydis padidės apskritai, „trys“ pagrindai yra didesni nei „dvi“ pagrindai. Tačiau tai nėra svarbiau, jei antroji versija pasitenkino 150-200 MB RAM, tai naujajam leidimui reikia pusės gigabaito ir į šią reikšmę reikėtų atsižvelgti planuojant reikalingus išteklius darbui su programa.

Grynasis

Tinklo pralaidumas yra vienas iš svarbiausių tinklo taikomųjų programų parametrų, ypač tokių kaip 1C failo režimu, kurie tinkle perkelia didelius duomenų kiekius. Dauguma mažų įmonių tinklų yra sukurti nebrangios 100 Mbit/s įrangos pagrindu, todėl bandymus pradėjome lygindami 1C našumo rodiklius 100 Mbit/s ir 1 Gbit/s tinkluose.

Kas nutinka, kai tinkle paleidžiate 1C failų duomenų bazę? Klientas į laikinus aplankus atsisiunčia gana daug informacijos, ypač jei tai pirmas, „šaltas“ paleidimas. Esant 100 Mbit/s greičiui, tikimasi, kad atsitrenksime į kanalo plotį, o atsisiuntimas gali užtrukti daug laiko, mūsų atveju apie 40 sekundžių (grafiko padalijimo kaina yra 4 sekundės).

Antrasis paleidimas yra greitesnis, nes kai kurie duomenys saugomi talpykloje ir lieka ten iki perkrovimo. Perjungimas į gigabitinį tinklą gali žymiai pagreitinti programos įkėlimą, tiek „šaltą“, tiek „karštą“, o reikšmių santykis yra laikomasi. Todėl nusprendėme rezultatą išreikšti santykinėmis reikšmėmis, didžiausią kiekvieno matavimo vertę laikant 100 %:

Kaip matote iš grafikų, Accounting 2.0 bet kokiu tinklo greičiu kraunasi dvigubai greičiau, perėjimas nuo 100 Mbit/s į 1 Gbit/s leidžia keturis kartus pagreitinti atsisiuntimo laiką. Šiuo režimu nėra jokio skirtumo tarp optimizuotų ir neoptimizuotų „troikos“ duomenų bazių.

Taip pat patikrinome tinklo greičio įtaką darbui sunkiais režimais, pavyzdžiui, grupinių perdavimų metu. Rezultatas taip pat išreiškiamas santykinėmis vertėmis:

Čia įdomiau, optimizuota „trijų“ bazė 100 Mbit/s tinkle veikia tokiu pat greičiu kaip ir „du“, o neoptimizuota – dvigubai prastesnius rezultatus. Gigabituose santykiai išlieka tie patys, neoptimizuotas „trys“ taip pat yra perpus lėtesnis nei „du“, o optimizuotas atsilieka trečdaliu. Be to, perėjimas prie 1 Gbit/s leidžia sutrumpinti vykdymo laiką tris kartus 2.0 leidimui ir perpus 3.0 leidimui.

Siekdami įvertinti tinklo greičio įtaką kasdieniam darbui, naudojome Našumo matavimas, atliekantys iš anksto nustatytų veiksmų seką kiekvienoje duomenų bazėje.

Tiesą sakant, atliekant kasdienes užduotis, tinklo pralaidumas nėra kliūtis, neoptimizuotas „trys“ yra tik 20% lėtesnis nei „du“, o po optimizavimo jis pasirodo maždaug tiek pat greičiau - darbo plonojo kliento režimu pranašumai yra akivaizdūs. Perėjimas prie 1 Gbit/s nesuteikia optimizuotai bazei jokių pranašumų, o neoptimizuotas ir du pradeda veikti greičiau, parodydami nedidelį skirtumą tarp savęs.

Iš atliktų testų tampa aišku, kad tinklas nėra kliūtis naujoms konfigūracijoms, o valdoma aplikacija veikia dar greičiau nei įprastai. Taip pat galite rekomenduoti pereiti prie 1 Gbit/s, jei sunkios užduotys ir duomenų bazės įkėlimo greitis jums yra labai svarbūs, kitais atvejais naujos konfigūracijos leidžia efektyviai dirbti net lėtuose 100 Mbit/s tinkluose.

Taigi kodėl 1C yra lėtas? Mes tai panagrinėsime toliau.

Serverio disko posistemis ir SSD

Ankstesniame straipsnyje mes pasiekėme 1C našumo padidėjimą įdėdami duomenų bazes į SSD. Galbūt serverio disko posistemio našumas yra nepakankamas? Diskinio serverio našumą išmatavome grupinio veikimo metu dviejose duomenų bazėse iš karto ir gavome gana optimistišką rezultatą.

Nepaisant gana didelio įvesties/išvesties operacijų skaičiaus per sekundę (IOPS) – 913, eilės ilgis neviršijo 1,84, o tai labai geras rezultatas dviejų diskų masyvei. Remdamiesi tuo, galime daryti prielaidą, kad veidrodžio, pagaminto iš įprastų diskų, užteks normaliam 8–10 tinklo klientų darbui sunkiais režimais.

Taigi ar serveryje reikalingas SSD? Geriausias būdas atsakyti į šį klausimą bus testavimas, kurį atlikome panašiu metodu, tinklo ryšys visur yra 1 Gbit/s, rezultatas taip pat išreiškiamas santykinėmis reikšmėmis.

Pradėkime nuo duomenų bazės įkėlimo greičio.

Kai kam tai gali pasirodyti netikėta, tačiau SSD, esantis serveryje, neturi įtakos duomenų bazės įkėlimo greičiui. Pagrindinis ribojantis veiksnys, kaip parodė ankstesnis testas, yra tinklo pralaidumas ir kliento našumas.

Pereikime prie perdarymo:

Aukščiau jau pažymėjome, kad disko našumo visiškai pakanka net dirbant sunkiais režimais, todėl SSD sparta taip pat neturi įtakos, išskyrus neoptimizuotą bazę, kuri SSD diske pasivijo optimizuotą. Tiesą sakant, tai dar kartą patvirtina, kad optimizavimo operacijos sutvarko informaciją duomenų bazėje, sumažindamos atsitiktinių I/O operacijų skaičių ir padidindamos prieigos prie jos greitį.

Kasdienėse užduotyse vaizdas panašus:

SSD turi naudos tik neoptimizuotai duomenų bazei. Žinoma, galite įsigyti SSD, tačiau daug geriau būtų pagalvoti apie savalaikę duomenų bazės priežiūrą. Taip pat nepamirškite defragmentuoti skyriaus su informacijos bazėmis serveryje.

Kliento disko posistemis ir SSD

Išanalizavome SSD įtaką lokaliai įdiegto 1C veikimo greičiui, dauguma to, kas buvo pasakyta, taip pat tinka darbui tinklo režimu. Iš tiesų, 1C gana aktyviai naudoja disko išteklius, įskaitant fonines ir įprastas užduotis. Žemiau esančiame paveikslėlyje galite pamatyti, kaip Apskaita 3.0 gana aktyviai pasiekia diską maždaug 40 sekundžių po įkėlimo.

Tačiau tuo pačiu reikia žinoti, kad darbo stočiai, kurioje aktyviai dirbama su viena ar dviem informacinėmis duomenų bazėmis, įprasto masinės gamybos HDD našumo resursų visiškai pakanka. Įsigijus SSD, kai kurie procesai gali paspartėti, tačiau kasdieniame darbe radikalaus pagreitėjimo nepastebėsite, nes, pavyzdžiui, atsisiuntimą ribos tinklo pralaidumas.

Lėtas standusis diskas gali sulėtinti kai kurias operacijas, tačiau pats savaime negali sulėtinti programos.

RAM

Nepaisant to, kad RAM dabar yra nepadoriai pigi, daugelis darbo stočių ir toliau dirba su tokia atmintimi, kokia buvo įdiegta perkant. Čia laukia pirmosios problemos. Remiantis tuo, kad vidutinei „troikai“ reikia apie 500 MB atminties, galime daryti prielaidą, kad bendrai 1 GB RAM darbui su programa nepakaks.

Sumažinome sistemos atmintį iki 1 GB ir paleidome dvi informacines duomenų bazes.

Iš pirmo žvilgsnio viskas nėra taip blogai, programa pažabojo apetitą ir puikiai telpa į turimą atmintį, tačiau nepamirškime, kad operatyvinių duomenų poreikis nepasikeitė, tai kur jis dingo? Išmesti į diską, talpyklą, apsikeitimą ir pan., šios operacijos esmė ta, kad iš greitosios RAM, kurios nepakanka, siunčiami šiuo metu nereikalingi duomenys į lėtą disko atmintį.

Kur tai veda? Pažiūrėkime, kaip sistemos resursai naudojami sunkiose operacijose, pavyzdžiui, paleiskime grupės perkėlimą iš karto dviejose duomenų bazėse. Pirmiausia sistemoje su 2 GB RAM:

Kaip matome, sistema aktyviai naudoja tinklą duomenims priimti, o procesoriaus aktyvumas apdorojimo metu retkarčiais didėja, bet nėra ribojantis veiksnys;

Dabar sumažinkime atmintį iki 1 GB:

Situacija kardinaliai keičiasi, pagrindinė apkrova dabar tenka kietajam diskui, procesorius ir tinklas neveikia, laukia, kol sistema nuskaitys reikiamus duomenis iš disko į atmintį ir ten išsiųs nereikalingus duomenis.

Tuo pačiu metu net subjektyvus darbas su dviem atviromis duomenų bazėmis sistemoje su 1 GB atminties pasirodė esąs itin nepatogus su dideliu vėlavimu ir aktyvia prieiga prie disko. Pavyzdžiui, prekių ir paslaugų pardavimo žurnalo atidarymas užtruko apie 20 sekundžių ir visą tą laiką buvo lydimas didelio disko aktyvumo (paryškintas raudona linija).

Norėdami objektyviai įvertinti RAM poveikį konfigūracijų, pagrįstų valdoma programa, našumui, atlikome tris matavimus: pirmosios duomenų bazės įkėlimo greitį, antrosios duomenų bazės įkėlimo greitį ir grupės pakartotinį paleidimą vienoje iš duomenų bazių. . Abi duomenų bazės yra visiškai identiškos ir buvo sukurtos nukopijuojant optimizuotą duomenų bazę. Rezultatas išreiškiamas santykiniais vienetais.

Rezultatas kalba pats už save: jei įkrovimo laikas pailgėja maždaug trečdaliu, o tai dar gana pakenčiama, tai operacijų atlikimo laikas duomenų bazėje pailgėja tris kartus, apie jokį patogų darbą tokiomis sąlygomis nereikia kalbėti. Beje, taip yra tada, kai SSD pirkimas gali pagerinti situaciją, tačiau daug lengviau (ir pigiau) susitvarkyti su priežastimi, o ne su pasekmėmis ir tiesiog nusipirkti reikiamą kiekį RAM.

RAM trūkumas yra pagrindinė priežastis, kodėl dirbti su naujomis 1C konfigūracijomis yra nepatogu. Konfigūracijos, kuriose yra 2 GB atminties, turėtų būti laikomos minimaliomis tinkamomis. Tuo pačiu atminkite, kad mūsų atveju buvo sukurtos „šiltnamio“ sąlygos: švari sistema, veikė tik 1C ir užduočių tvarkyklė. Realiame gyvenime darbo kompiuteryje, kaip taisyklė, yra atidaryta naršyklė, biuro paketas, veikia antivirusinė programa ir pan., ir t. t., todėl reikia 500 MB vienai duomenų bazei ir šiek tiek rezervo, kad sunkių operacijų metu nesusiduriate su atminties trūkumu ir staigiu produktyvumo sumažėjimu.

CPU

Be perdėto centrinį procesorių galima vadinti kompiuterio širdimi, nes būtent jis galiausiai apdoroja visus skaičiavimus. Norėdami įvertinti jo vaidmenį, atlikome dar vieną testų rinkinį, tą patį kaip ir RAM, sumažindami virtualiai mašinai prieinamų branduolių skaičių nuo dviejų iki vieno, o testas buvo atliktas du kartus su 1 GB ir 2 GB atminties kiekiais.

Rezultatas pasirodė gana įdomus ir netikėtas: galingesnis procesorius gana efektyviai priimdavo krūvį, kai pritrūkdavo resursų, likusį laiką nesuteikdamas apčiuopiamų pranašumų. 1C Enterprise (failo režimu) vargu ar galima pavadinti programa, kuri aktyviai naudoja procesoriaus išteklius, ji yra gana nereikli. O sudėtingomis sąlygomis procesorių apkrauna ne tiek pačios aplikacijos duomenų skaičiavimas, kiek pridėtinės priežiūros išlaidos: papildomos įvesties/išvesties operacijos ir pan.

išvadas

Taigi, kodėl 1C yra lėtas? Visų pirma, tai yra RAM trūkumas, šiuo atveju pagrindinė apkrova tenka kietajam diskui ir procesoriui. Ir jei jie neblizga našumu, kaip paprastai būna biuro konfigūracijose, tada gauname straipsnio pradžioje aprašytą situaciją - „du“ veikė gerai, bet „trys“ yra bedieviškai lėti.

Antroje vietoje yra tinklo našumas lėtas 100 Mbit/s kanalas gali tapti tikra kliūtimi, tačiau tuo pačiu plonojo kliento režimas sugeba išlaikyti gana patogų veikimo lygį net ir lėtuose kanaluose.

Tuomet turėtumėte atkreipti dėmesį į diskų įrenginį, kad SSD pirkimas nebūtų gera investicija, tačiau būtų gera mintis pakeisti diską modernesniu. Skirtumą tarp kietųjų diskų kartų galima įvertinti iš šios medžiagos: .

Ir galiausiai procesorius. Spartesnis modelis, žinoma, nebus nereikalingas, tačiau nėra prasmės didinti jo našumą, nebent šis kompiuteris naudojamas sunkioms operacijoms: grupiniam apdorojimui, sunkioms ataskaitoms, mėnesio pabaigos uždarymui ir pan.

Tikimės, kad ši medžiaga padės greitai suprasti klausimą „kodėl 1C yra lėtas“ ir jį išspręsti efektyviausiai bei be papildomų išlaidų.

  • Žymos:

Norėdami peržiūrėti, įgalinkite „JavaScript“.

Pagrindinis šio straipsnio rašymo tikslas – nekartoti akivaizdžių niuansų tiems administratoriams (ir programuotojams), kurie dar nėra įgiję patirties su 1C.

Antrinis tikslas – jei turėsiu kokių nors trūkumų, „Infostart“ man tai greičiausiai nurodys.

V. Gilevo testas jau tapo savotišku „de facto“ etalonu. Autorius savo svetainėje pateikė gana aiškias rekomendacijas, bet aš tiesiog pateiksiu keletą rezultatų ir pakomentuosiu labiausiai tikėtinas klaidas. Žinoma, jūsų įrangos bandymų rezultatai gali skirtis, tai tik vadovas, kas turėtų būti ir ko galite siekti. Iš karto noriu pastebėti, kad pakeitimus reikia atlikti žingsnis po žingsnio, o po kiekvieno žingsnio patikrinti, kokį rezultatą tai davė.

Infostart’e yra panašių straipsnių, nuorodas į juos įdėsiu į atitinkamas skiltis (jei ką praleidau, pasiūlykite komentaruose, pridėsiu). Taigi, tarkime, kad jūsų 1C yra lėtas. Kaip diagnozuoti problemą ir kaip suprasti, kas kaltas – administratorius ar programuotojas?

Pradiniai duomenys:

Išbandytas kompiuteris, pagrindinė jūrų kiaulytė: HP DL180G6, komplektuojama su 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Palyginimui, Core i3-2100 rodo palyginamus vieno sriegio testo rezultatus. Sąmoningai pasirinkta įranga nebuvo pati naujausia su modernia įranga rezultatai pastebimai geresni.

Atskiriems 1C ir SQL serveriams testuoti SQL serveris: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Norint išbandyti 10 Gbit tinklą, buvo naudojami Intel 520-DA2 adapteriai.

Failo versija. (duomenų bazė yra serveryje bendrame aplanke, klientai jungiasi per tinklą, CIFS/SMB protokolą). Algoritmas žingsnis po žingsnio:

0. Pridėkite Gilevo bandomąją duomenų bazę prie failų serverio tame pačiame aplanke kaip ir pagrindinės duomenų bazės. Prisijungiame iš kliento kompiuterio ir vykdome testą. Mes prisimename rezultatą.

Suprantama, kad net seniems kompiuteriams prieš 10 metų (Pentium ant 775 lizdo ) laikas nuo sparčiojo klavišo 1C:Enterprise paspaudimo iki duomenų bazės lango pasirodymo turėtų būti trumpesnis nei minutė. ( Celeronas = lėtas).

Jei turite prastesnį kompiuterį nei Pentium 775 lizdas su 1 GB RAM, užjaučiu jus ir jums bus sunku patogiai dirbti su 1C 8.2 failo versijoje. Pagalvokite apie atnaujinimą (jau pats laikas) arba perjungimą į terminalo (arba žiniatinklio, jei tai yra ploni klientai ir valdomos formos) serverį.

Jei kompiuteris ne blogesnis, galite paspardyti administratorių. Bent jau patikrinkite tinklo, antivirusinės ir HASP apsaugos tvarkyklės veikimą.

Jei Gilevo testas šiame etape parodė 30 ar daugiau „papūgų“, tačiau 1C darbo bazė vis tiek veikia lėtai, klausimus reikia nukreipti į programuotoją.

1. Kaip orientyrą, kiek gali „išspausti“ kliento kompiuteris, patikriname tik šio kompiuterio veikimą, be tinklo. Bandomąją duomenų bazę įdiegiame vietiniame kompiuteryje (labai sparčiame diske). Jei kliento kompiuteris neturi įprasto SSD, sukuriamas ramdiskas. Kol kas paprasčiausia ir nemokama yra „Ramdisk enterprise“.

Norint išbandyti 8.2 versiją, pakanka 256 MB ramdisko ir! Svarbiausias. Perkrovus kompiuterį, veikiant ramdiskui, jame turėtų būti 100-200 MB laisvos vietos. Atitinkamai, be ramdisko normaliam veikimui turėtų būti 300–400 MB laisvos atminties.

Norint išbandyti 8.3 versiją, pakanka 256 MB atminties disko, tačiau reikia daugiau laisvos RAM.

Bandydami turite pažvelgti į procesoriaus apkrovą. Esant artimam idealiam atvejui (RAM diskas), vietinis failas 1c paleidžiant įkelia 1 procesoriaus branduolį. Atitinkamai, jei bandymo metu jūsų procesoriaus branduolys nėra visiškai įkeltas, ieškokite silpnų vietų. Šiek tiek emocingas, bet apskritai teisingas, aprašoma procesoriaus įtaka 1C veikimui. Tiesiog nuoroda, net šiuolaikiniuose „Core i3“ su aukštais dažniais skaičiai 70–80 yra gana tikroviški.

Dažniausios klaidos šiame etape.

a) Neteisingai sukonfigūruota antivirusinė programa. Yra daug antivirusinių programų, kiekvieno parametrai yra skirtingi, pasakysiu tik tiek, kad tinkamai sukonfigūravus nei žiniatinklis, nei Kaspersky 1C netrukdo. Pagal numatytuosius nustatymus galima paimti maždaug 3-5 papūgas (10-15%).

b) Atlikimo režimas. Kažkodėl mažai žmonių į tai atkreipia dėmesį, tačiau poveikis yra pats reikšmingiausias. Jei jums reikia greičio, turite tai padaryti tiek klientų, tiek serverių kompiuteriuose. (Gilev turi gerą aprašymą. Vienintelis įspėjimas yra tas, kad kai kuriose pagrindinėse plokštėse išjungus „Intel SpeedStep“, negalėsite įjungti TurboBoost).

Trumpai tariant, kol veikia 1C, laukiama atsakymo iš kitų įrenginių (disko, tinklo ir pan.). Laukdamas atsakymo, jei įjungtas našumo režimas, procesorius sumažina savo dažnį. Atsakymas ateina iš įrenginio, 1C (procesorius) turi veikti, tačiau pirmieji laikrodžio ciklai yra mažesniu dažniu, tada dažnis didėja - ir 1C vėl laukia atsakymo iš įrenginio. Ir taip – ​​daug šimtų kartų per sekundę.

Galite (ir pageidautina) įjungti našumo režimą dviejose vietose:

Per BIOS. Išjungti režimus C1, C1E, Intel C-state (C2, C3, C4). Skirtinguose biosuose jie vadinami skirtingai, bet reikšmė ta pati. Ieškoti užtrunka ilgai, reikia paleisti iš naujo, bet jei tai padarysite vieną kartą, galite tai pamiršti. Jei BIOS viską padarysite teisingai, greitis padidės. Kai kuriose pagrindinėse plokštėse galite sukonfigūruoti BIOS nustatymus, kad „Windows“ veikimo režimas neveiktų. (BIOS nustatymų pavyzdžiai iš Gilev). Šie nustatymai daugiausia susiję su serverių procesoriais arba „išplėstinėmis“ BIOS, jei to neradote ir NEturite „Xeon“, tai gerai.

Valdymo skydelis - Maitinimas - Didelis našumas. Minusas – jei kompiuteris ilgą laiką nebuvo aptarnaujamas, jis skleis didesnį ventiliatoriaus triukšmą, labiau įkais ir sunaudos daugiau energijos. Tai yra spektaklio mokestis.

Kaip patikrinti, ar režimas įjungtas. Paleiskite užduočių tvarkyklę - našumas - išteklių monitorius - CPU. Laukiame, kol procesorius užsiims niekuo.

Tai yra numatytieji nustatymai.

BIOS C būsenoje įskaitant,

subalansuoto energijos suvartojimo režimas


BIOS C būsenoje įskaitant, didelio našumo režimas

Dėl Pentium ir Core galite sustoti,

Iš Xeon vis tiek galite išspausti šiek tiek „papūgos“.


BIOS C būsenoje išjungė, didelio našumo režimas.

Jei nenaudojate „Turbo boost“, jis turėtų atrodyti taip

serveris sureguliuotas našumui


O dabar skaičiai. Leiskite jums priminti: Intel Xeon 5650, ramdisk. Pirmuoju atveju testas rodo 23,26, paskutiniu - 49,5. Skirtumas yra beveik dvigubas. Skaičiai gali skirtis, tačiau „Intel Core“ santykis iš esmės išlieka toks pat.

Gerbiami administratoriai, galite kritikuoti 1C kiek tik norite, bet jei galutiniams vartotojams reikia greičio, turite įjungti didelio našumo režimą.

c) Turbo Boost. Pirmiausia turite suprasti, ar, pavyzdžiui, jūsų procesorius palaiko šią funkciją. Jei jis palaiko, vis tiek galite legaliai gauti tam tikrą našumą. (Nenoriu liesti dažnio įsijungimo klausimų, ypač serverių, darykite tai rizikuodami ir rizikuodami. Tačiau sutinku, kad padidinus magistralės greitį nuo 133 iki 166, labai pastebimai padidėja greitis ir šilumos išsklaidymas)

Kaip įjungti turbo boost parašyta, pavyzdžiui, . Bet! 1C yra keletas niuansų (ne patys akivaizdžiausi). Sunkumas yra tas, kad didžiausias turbo boost efektas atsiranda, kai įjungta C būsena. Ir mes gauname kažką panašaus:

Atkreipkite dėmesį, kad daugiklis yra didžiausias, pagrindinis greitis yra gražus, o našumas didelis. Bet kas atsitiks su 1s?

veiksnys

Šerdies greitis (dažnis), GHz

CPU-Z viena gija

Gilevo Ramdisko testas

failo versija

Gilevo Ramdisko testas

kliento serveris

Be Turbo Boost

C būsena išjungta, Turbo boost

53.19

40,32

C būsena įjungta, Turbo boost

1080

53,13

23,04

Bet galų gale paaiškėja, kad pagal procesoriaus našumo testus priekyje yra versija su daugikliu 23, pagal Gilevo testus failo versijoje našumas su daugikliu 22 ir 23 yra toks pat, bet kliento-serverio. versija - versija su daugikliu 23 yra baisi baisi baisi (net jei C -state nustatytas į 7 lygį, ji vis tiek yra lėtesnė nei su išjungta C būsena). Todėl rekomenduojama patiems patikrinti abu variantus ir pasirinkti geriausią. Bet kuriuo atveju skirtumas tarp 49,5 ir 53 papūgų yra gana didelis, ypač be didelių pastangų.

Išvada – turbo boost turi būti įjungtas. Leiskite jums priminti, kad neužtenka įjungti „Turbo boost“ elementą BIOS, reikia peržiūrėti ir kitus nustatymus (BIOS: QPI L0s, L1 - išjungti, reikalauti šveitimo - išjungti, Intel SpeedStep - įjungti, Turbo boost - įgalinti Valdymo skydas - Maitinimo parinktys - Didelis našumas) . Ir aš vis tiek (net ir failo versijai) pasirinkčiau variantą, kai c-state išjungtas, nors daugiklis mažesnis. Išeis kažkas tokio...

Gana prieštaringas klausimas yra atminties dažnis. Pavyzdžiui, įrodyta, kad atminties dažnis turi labai didelę įtaką. Mano tyrimai tokios priklausomybės neatskleidė. DDR 2/3/4 nelyginsiu, toje pačioje eilutėje parodysiu dažnio keitimo rezultatus. Atmintis ta pati, bet BIOS esame priversti nustatyti žemesnius dažnius.




Ir testo rezultatai. 1C 8.2.19.83, failo versijai vietinis ramdiskas, kliento-serverio 1C ir SQL viename kompiuteryje, bendra atmintis. Turbo boost išjungtas abiejose versijose. 8.3 rodo palyginamus rezultatus.

Skirtumas yra matavimo paklaidos ribose. Specialiai ištraukiau CPU-Z ekrano kopijas, kad parodyčiau, kad keičiantis dažniui, keičiasi ir kiti parametrai, tas pats CAS Latency ir RAS į CAS Delay, kuris neutralizuoja dažnio pokytį. Skirtumas bus, kai fiziškai bus keičiami atminties moduliai, iš lėtesnių į greitesnius, bet ir ten skaičiai nėra itin reikšmingi.

2. Sutvarkę kliento kompiuterio procesorių ir atmintį pereiname prie kitos labai svarbios vietos – tinklo. Apie tinklo derinimą parašyta daugybė knygų, yra straipsnių apie „Infostart“ (ir kt.), tačiau čia aš nesikoncentruosiu į šią temą. Prieš pradėdami testuoti 1C, įsitikinkite, kad iperf tarp dviejų kompiuterių rodo visą pralaidumą (1 Gbit kortelėms - na, bent 850 Mbit arba dar geriau 950-980), kad buvo laikomasi Gilevo patarimų. Tada – kaip bebūtų keista, paprasčiausias veikimo testas bus vieno didelio failo (5–10 gigabaitų) kopijavimas tinkle. Netiesioginis normalaus veikimo požymis 1 Gbit tinkle bus vidutinis 100 MB/sek kopijavimo greitis, geras veikimas – 120 MB/sek. Noriu atkreipti jūsų dėmesį į tai, kad silpnoji vieta (įskaitant) gali būti procesoriaus apkrova. SMB „Linux“ protokolas yra gana prastai lygiagretus, o veikimo metu jis gali gana lengvai „suvalgyti“ vieną procesoriaus branduolį ir nebevartoti.

Ir toliau. Pagal numatytuosius nustatymus Windows klientas geriausiai veikia su Windows serveriu (ar net Windows darbo stotimi) ir SMB/CIFS protokolu, linux klientas (debian, ubuntu nežiūrėjo į kitus) veikia geriau su linux ir NFS ( jis taip pat veikia su SMB, bet NFS papūgos yra aukštesnės). Tai, kad linijinio kopijavimo metu Windows Linux serveris į NFS greičiau nukopijuojamas į vieną srautą, nieko nereiškia. Debian derinimas 1C yra atskiro straipsnio tema, dar nesu tam pasiruošęs, nors galiu pasakyti, kad failo versijoje gavau net šiek tiek geresnį našumą nei Win versija ta pačia įranga, bet su postgres su over 50 vartotojų Aš vis dar turiu viską labai blogai.

Svarbiausias , kurį „sudegę“ administratoriai žino, bet pradedantieji neatsižvelgia. Yra daug būdų, kaip nustatyti kelią į 1c duomenų bazę. Galite atlikti \\server\share, galite \\192.168.0.1\share, galite tinkle naudoti z: \\192.168.0.1\share (ir kai kuriais atvejais šis metodas taip pat veiks, bet ne visada) ir tada Nurodykite Z diską. Atrodo, kad visi šie keliai nukreipia į tą pačią vietą, tačiau 1C yra tik vienas būdas, kuris gana patikimai užtikrina normalų veikimą. Taigi, ką reikia padaryti teisingai:

Komandinėje eilutėje (arba politikoje, ar bet kur, kas jums patogu) - naudokite „DriveLetter“: \\server\share. Pavyzdys: tinklo naudojimas m: \\serveris\bazės. Aš konkrečiai pabrėžiu NE IP adresą, būtent vardas serveris. Jei serverio pavadinimo nematote, pridėkite jį prie dns serveryje arba lokaliai prie hosts failo. Bet adresas turi būti vardu. Atitinkamai, pakeliui į duomenų bazę, pasiekite šį diską (žr. paveikslėlį).

O dabar skaičiais parodysiu, kodėl toks patarimas. Pradiniai duomenys: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kortelės OS Win 2008 R2, Win 7, Debian 8. Naujausios tvarkyklės, naujinimai. Prieš testavimą įsitikinau, kad Iperf duoda visą pralaidumą (išskyrus 10 Gbit korteles, pavyko išspausti tik 7,2 Gbit, vėliau pamatysiu kodėl, testo serveris dar nesukonfigūruotas tinkamai). Diskai skirtingi, bet visur yra SSD (specialiai testavimui įdėjau vieną diską, daugiau nieko nekrauna) arba reidas iš SSD. 100 Mbit greitis gautas apribojant Intel 362 adapterio nustatymus Nebuvo skirtumo tarp 1 Gbit vario Intel 350 ir 1 Gbit optinio Intel X520-DA2 (gaunamas ribojant adapterio greitį). Maksimalus našumas, „turbo boost“ išjungtas (tik dėl rezultatų palyginimo, „turbo boost“ geriems rezultatams prideda šiek tiek mažiau nei 10%, blogiems rezultatams tai gali neturėti jokio poveikio). 1C versijos 8.2.19.86, 8.3.6.2076. Pateikiu ne visus skaičius, o tik įdomiausius, kad būtų su kuo palyginti.

Win 2008 - Win 2008

susisiekti ip adresu

Win 2008 - Win 2008

Skambina vardu

Win 2008 - Win 2008

Susisiekite pagal IP adresą

Win 2008 - Win 2008

Skambina vardu

Win 2008 – Win 7

Skambina vardu

Win 2008 – Debian

Skambina vardu

Win 2008 - Win 2008

Susisiekite pagal IP adresą

Win 2008 - Win 2008

Skambina vardu

11,20 26,18 15,20 43,86 40,65 37,04 16,23 44,64
1C 8.2 11,29 26,18 15,29 43,10 40,65 36,76 15,11 44,10
8.2.19.83 12,15 25,77 15,15 43,10 14,97 42,74
6,13 34,25 14,98 43,10 39,37 37,59 15,53 42,74
1C 8.3 6,61 33,33 15,58 43,86 40,00 37,88 16,23 42,74
8.3.6.2076 33,78 15,53 43,48 39,37 37,59 42,74

Išvados (iš lentelės ir iš asmeninės patirties. Taikoma tik failo versijai):

Per tinklą galite gauti gana įprastus skaičius darbui, jei šis tinklas yra tinkamai sukonfigūruotas ir teisingai įvestas kelias 1C. Netgi pirmasis Core i3 gali nesunkiai išauginti 40+ papūgų, tai visai neblogai, ir tai ne tik papūgos, realiame darbe skirtumas irgi pastebimas. Bet! Apribojimas dirbant su keliais (daugiau nei 10) vartotojų nebebus tinklas, čia dar pakanka 1 Gbit, bet blokavimas kelių vartotojų darbo metu (Gilev).

1C 8.3 platforma yra daug kartų reiklesnė tinkamos tinklo konfigūracijos atžvilgiu. Pagrindiniai nustatymai – žr. Gilevą, tačiau atminkite, kad viską galima paveikti. Paspartėjo antivirusinės programos pašalinimas (o ne tik išjungimas), protokolų, pvz., FCoE, pašalinimas, tvarkyklių keitimas į senesnę, bet „Microsoft“ sertifikuotą versiją (ypač pigioms kortelėms, pvz., ASUS ir DLC), ir antrosios tinklo plokštės pašalinimas. iš serverio. Yra daug galimybių, atidžiai nustatykite tinklą. Gali būti, kad 8.2 platforma pateikia priimtinus skaičius, o 8.3 – du ar net daugiau kartų mažiau. Pabandykite žaisti su 8.3 platformos versijomis, kartais pasieksite labai didelį efektą.

1C 8.3.6.2076 (galbūt vėliau, tikslios versijos dar neieškojau) vis tiek lengviau konfigūruoti tinkle nei 2008-07-08. Man pavyko pasiekti normalų veikimą tinkle nuo 2008-07-08 (panašiose papūgose) tik kelis kartus, negalėjau to pakartoti bendresniam atvejui. Daug ko nesupratau, bet sprendžiant pagal pėdų apvyniojimus iš Process Explorer, įrašas ten nėra toks geras kaip 8.3.6.

Nepaisant to, kad dirbant 100 Mbit tinkle jo apkrovos grafikas mažas (galime sakyti, kad tinklas nemokamas), veikimo greitis vis tiek gerokai mažesnis nei 1 Gbit. Priežastis yra tinklo delsa.

Jei visi kiti dalykai yra vienodi (gerai veikiantis tinklas), 1C 8.2 „Intel-Realtek“ ryšys yra 10% lėtesnis nei „Intel-Intel“. Tačiau realtek-realtek paprastai gali staigiai nuslūgti netikėtai. Todėl, jei turite pinigų, „Intel“ tinklo plokštes geriau laikyti visur, jei neturite pinigų, įdiekite „Intel“ tik serveryje (savo CO). O „Intel“ tinklo plokščių derinimo instrukcijų yra daug kartų daugiau.

Numatytieji antivirusiniai nustatymai (naudojant 10 versijos drweb pavyzdį) užima apie 8-10% papūgų. Jei sukonfigūruosite taip, kaip turėtų (leisti 1cv8 procesui padaryti viską, nors tai nėra saugu), greitis yra toks pat, kaip be antivirusinės programos.

NEskaitykite Linux guru. Serveris su samba yra puikus ir nemokamas, bet jei serveryje įdiegsite Win XP arba Win7 (ar dar geriau - serverio OS), tada 1c failo versija veiks greičiau. Taip, samba ir protokolų dėklas bei tinklo parametrai ir daug, daug daugiau gali būti gerai suderinti debian/ubuntu, tačiau tai rekomenduojama specialistams. Nėra prasmės diegti Linux su numatytaisiais nustatymais ir tada sakyti, kad jis lėtas.

Visai gera idėja patikrinti diskų, prijungtų per tinklą, veikimą naudojant fio . Bent jau bus aišku, ar tai problemos su 1C platforma, ar su tinklu / disku.

Vieno vartotojo versijai neįsivaizduoju testų (ar situacijos), kai būtų matomas skirtumas tarp 1 Gbit ir 10 Gbit. Vienintelis dalykas, kur 10 Gbit failo versijai davė geresnių rezultatų, yra diskų prijungimas per iSCSI, tačiau tai yra atskiro straipsnio tema. Visgi manau, kad failo versijai pakanka 1 Gbit kortelių.

Nesuprantu, kodėl su 100 Mbit tinklu 8.3 veikia pastebimai greičiau nei 8.2, bet tai buvo faktas. Visa kita įranga, visi kiti nustatymai yra visiškai vienodi, tiesiog vienu atveju išbandytas 8.2, o kitu - 8.3.

Netiuninguotas NFS win-win arba win-lin duoda 6 papūgas, į lentelę jų neįtraukiau. Po derinimo gavau 25, bet jis buvo nestabilus (išmatavimų skirtumas buvo daugiau nei 2 vnt.). Dar negaliu pateikti rekomendacijų, kaip naudoti Windows ir NFS protokolą.

Atlikę visus nustatymus ir patikrinimus, iš kliento kompiuterio paleidžiame testą dar kartą ir džiaugiamės pagerėjusiu rezultatu (jei pavyks). Jei rezultatas pagerėjo, yra daugiau nei 30 papūgų (o ypač daugiau nei 40), tuo pačiu metu dirba mažiau nei 10 vartotojų, o veikianti duomenų bazė vis dar lėta – beveik neabejotinai problema su programuotoju (arba jūs turite jau pasiekė didžiausias failo versijos galimybes).

Terminalo serveris. (duomenų bazė yra serveryje, klientai jungiasi per tinklą, KPP protokolą). Algoritmas žingsnis po žingsnio:

0. Pridėkite Gilev bandomąją duomenų bazę prie serverio tame pačiame aplanke kaip ir pagrindinės duomenų bazės. Prisijungiame iš to paties serverio ir vykdome testą. Mes prisimename rezultatą.

1. Taip pat, kaip ir failo versijoje, nustatome darbą. Terminalo serverio atveju pagrindinį vaidmenį atlieka procesorius (manoma, kad nėra akivaizdžių silpnųjų vietų, tokių kaip atminties trūkumas arba didžiulis nereikalingos programinės įrangos kiekis).

2. Tinklo plokščių nustatymas terminalo serverio atveju praktiškai neturi įtakos 1c veikimui. Norėdami užtikrinti „ypatingą“ komfortą, jei jūsų serveris gamina daugiau nei 50 papūgų, galite žaisti su naujomis RDP protokolo versijomis, tik dėl vartotojų patogumo, greitesnio reagavimo ir slinkimo.

3. Jei aktyviai dirba daug vartotojų (o čia jau galima pabandyti prijungti prie vienos duomenų bazės 30 žmonių, jei bandysite), labai patartina įsidiegti SSD diską. Kažkodėl manoma, kad diskas ne itin veikia 1C veikimą, tačiau visi testai atliekami su valdiklio talpykla įjungta rašymui, o tai neteisinga. Bandymų bazė nedidelė, gana gerai telpa talpykloje, todėl ir dideli skaičiai. Realiose (didelėse) duomenų bazėse viskas bus visiškai kitaip, todėl talpykla testams išjungta.

Pavyzdžiui, aš patikrinau Gilevo testo veikimą su skirtingomis disko parinktimis. Įdėjau diskus iš to, kas buvo po ranka, kad parodyčiau tendenciją. Skirtumas tarp 8.3.6.2076 ir 8.3.7.2008 nedidelis (Ramdisk Turbo boost versijoje 8.3.6 gamina 56.18, o 8.3.7.2008 – 55.56, kituose testuose skirtumas dar mažesnis). Energijos suvartojimas – maksimalus našumas, turbo boost išjungtas (jei nenurodyta kitaip).

Raid 10 4x SATA 7200

ATA ST31500341AS

Raid 10 4x SAS 10k

Raid 10 4x SAS 15k

Vienas SSD

Ramdisk

Talpykla įjungta

RAID valdiklis

21,74 28,09 32,47 49,02 50,51 53,76 49,02
1C 8.2 21,65 28,57 32,05 48,54 49,02 53,19
8.2.19.83 21,65 28,41 31,45 48,54 49,50 53,19
33,33 42,74 45,05 51,55 52,08 55,56 51,55
1C 8.3 33,46 42,02 45,05 51,02 52,08 54,95
8.3.7.2008 35,46 43,01 44,64 51,55 52,08 56,18

Įjungta RAID valdiklio talpykla pašalina visus skirtumus tarp diskų numeriai yra vienodi ir sat, ir cas. Bandymas naudojant nedidelį duomenų kiekį yra nenaudingas ir jokiu būdu nerodo.

8.2 platformoje SATA ir SSD parinkčių našumas skiriasi daugiau nei dvigubai. Tai nėra rašybos klaida. Jei pažvelgsite į našumo monitorių bandydami SATA diskus. tada aiškiai matote „Aktyvaus disko veikimo laikas (%)“ 80–95. Taip, jei įjungsite pačių diskų talpyklą įrašymui, greitis padidės iki 35, jei įjungsite raidės valdiklio talpyklą - iki 49 (nepriklausomai nuo to, kurie diskai šiuo metu yra testuojami). Bet tai yra sintetinės talpyklos papūgos realiame darbe, naudojant dideles duomenų bazes, niekada nebus 100% rašymo talpyklos pataikymo koeficiento.

Net ir pigių SSD spartos (išbandžiau su Agility 3) pakanka paleisti failo versiją. Įrašymo resursas jau kitas reikalas, reikia žiūrėti kiekvienu konkrečiu atveju, aišku, kad Intel 3700 bus eilės tvarka didesnis, bet kaina atitinkama. Ir taip, aš suprantu, kad testuodamas SSD diską, aš taip pat daugiau testuoju šio disko talpyklą, realių rezultatų bus mažiau.

Pats teisingiausias (mano požiūriu) sprendimas būtų skirti 2 SSD diskus veidrodiniame reide failų duomenų bazei (ar kelioms failų duomenų bazėms), o daugiau nieko ten nedėti. Taip, su veidrodžiu SSD dėvisi vienodai, ir tai yra minusas, bet bent jau valdiklio elektronika kažkaip apsaugota nuo klaidų.

Pagrindiniai SSD diskų privalumai failo versijai išryškės, kai bus daug duomenų bazių, kurių kiekvienoje yra keli vartotojai. Jei yra 1-2 duomenų bazės, o vartotojų yra apie 10, tada užteks SAS diskų. (bet bet kuriuo atveju pažiūrėkite, kaip įkelti šiuos diskus, bent jau per perfmon).

Pagrindiniai terminalo serverio privalumai yra tai, kad jis gali turėti labai silpnus klientus, o tinklo nustatymai terminalo serverį veikia daug mažiau (vėlgi jūsų K.O.).

Išvados: jei paleidžiate Gilev testą terminalo serveryje (iš to paties disko, kuriame yra veikiančios duomenų bazės) ir tais momentais, kai veikianti duomenų bazė sulėtėja, o Gilev testas rodo gerą rezultatą (virš 30), tada lėtas pagrindinės darbo duomenų bazės veikimas greičiausiai kaltas programuotojas.

Jei Gilevo testas rodo mažus skaičius, o jūs turite aukšto dažnio procesorių ir greitus diskus, tada administratorius turi paimti bent perfmoną, kur nors įrašyti visus rezultatus ir žiūrėti, stebėti ir daryti išvadas. Nebus galutinio patarimo.

Kliento-serverio parinktis.

Bandymai buvo atlikti tik 8.2, nes 8.3 viskas labai priklauso nuo versijos.

Bandymui pasirinkau skirtingas serverio parinktis ir tinklus tarp jų, kad parodyčiau pagrindines tendencijas.

SQL: Xeon E5-2630

SQL: Xeon E5-2630

Šviesolaidinis kanalas – SSD

SQL: Xeon E5-2630

Šviesolaidinis kanalas – SAS

SQL: Xeon E5-2630

Vietinis SSD

SQL: Xeon E5-2630

Šviesolaidinis kanalas – SSD

SQL: Xeon E5-2630

Vietinis SSD

1C: Xeon 5650 =

1C: Xeon 5650 =

Bendra atmintis

1C: Xeon 5650 =

1C: Xeon 5650 =

1C: Xeon 5650 =

16,78 18,23 16,84 28,57 27,78 32,05 34,72 36,50 23,26 40,65 39.37
1C 8.2 17,12 17,06 14,53 29,41 28,41 31,45 34,97 36,23 23,81 40,32 39.06
16,72 16,89 13,44 29,76 28,57 32,05 34,97 36,23 23,26 40,32 39.06

Atrodo, visus įdomius variantus apsvarsčiau, jei dar kas domina, rašykite komentaruose, pasistengsiu padaryti.

SAS saugojimo sistemose veikia lėčiau nei vietiniai SSD, nors saugojimo sistemos turi didesnius talpyklos dydžius. SSD diskai, tiek vietiniai, tiek saugojimo sistemose, veikia panašiu greičiu Gilevo bandymo metu. Nežinau jokio standartinio kelių gijų testo (ne tik įrašymo, bet ir visos įrangos), išskyrus 1C apkrovos testą iš MKC.

Pakeitus 1C serverį iš 5520 į 5650, našumas padidėjo beveik dvigubai. Taip, serverio konfigūracijos nevisiškai sutampa, bet tai rodo tendenciją (nenuostabu).

Dažnio padidinimas SQL serveryje tikrai duoda efektą, bet ne tokį, kaip 1C serveryje, MS SQL serveryje puikiai tinka naudoti kelių branduolių ir laisvos atminties.

Pakeitus tinklą tarp 1C ir SQL nuo 1 Gbit iki 10 Gbit, gaunama maždaug 10 % papūgų. Tikėjausi daugiau.

Bendrosios atminties įjungimas vis tiek suteikia efektą, nors ir ne 15%, kaip aprašyta. Būtinai padarykite tai, laimei, tai greita ir paprasta. Jei diegimo metu kas nors davė SQL serveriui pavadintą egzempliorių, tada, kad 1C veiktų, serverio pavadinimas turi būti nurodytas ne pagal FQDN (veiks tcp/ip), ne per localhost arba tiesiog serverio pavadinimas, bet, pavyzdžiui, per ServerName\InstanceName. zz-testas\zztestas. (Priešingu atveju atsiras DBVS klaida: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Bendrai naudojamos atminties biblioteka, naudojama ryšiui su SQL Server 2000 užmegzti, nerasta. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQL : SQLSTATE=08001, būsena=1, sunkumas=10, gimtoji=126, eilutė=0).

Mažiau nei 100 vartotojų vienintelis dalykas, norint jį padalinti į du atskirus serverius, yra Win 2008 Std (ir senesnė) licencija, kuri palaiko tik 32 GB RAM. Visais kitais atvejais 1C ir SQL būtinai reikia įdiegti viename serveryje ir suteikti daugiau (bent 64 GB) atminties. Suteikti MS SQL mažiau nei 24-28 GB RAM yra nepateisinamas godumas (jei manote, kad turite pakankamai atminties ir viskas veikia gerai, gal jums užtektų 1C failo versijos?)

Kaip blogiau virtualioje mašinoje veikia 1C ir SQL derinys – atskiro straipsnio tema (užuomina – pastebimai blogiau). Net Hyper-V viskas nėra taip aišku...

Subalansuoto veikimo režimas yra blogas. Rezultatai visiškai atitinka failo versiją.

Daugelis šaltinių teigia, kad derinimo režimas (ragent.exe -debug) žymiai sumažina našumą. Na, sumažina, taip, bet 2-3% reikšmingu efektu nepavadinčiau.

Dėl įvairių priežasčių 1C programos vartotojai retkarčiais susiduria su 1C veikimo problemomis. Pvz.: dokumentas apdorojamas ilgai, ataskaita sugeneruojama ilgai, operacijų klaidos, programa užstringa, lėta reakcija į vartotojo veiksmus ir pan. Vykdydami mūsų instrukcijas, galite pasiekti didelę sėkmę vykdydami programą ir neleisti viršyti sistemos limito. Tai nėra panacėja nuo visų ligų, tačiau dauguma 1C sulėtėjimo priežasčių slypi būtent šiose problemose.

1. Neatlikite įprastinių ar foninių užduočių, kol naudotojai dirba

Pirmoji ir pagrindinė sistemos administratorių taisyklė – planuoti visas fonines užduotis atlikti ne darbo valandomis. Sistema turi būti kiek įmanoma iškraunama, kad būtų galima atlikti įprastines užduotis (indeksavimas, dokumentų apdorojimas, duomenų įkėlimas) ir tuo pačiu netrukdyti vartotojų darbui. Nei sistema, nei vartotojai netrukdys vieni kitiems, jei dirbs skirtingu laiku.

2. Nekeiskite RIB duomenų vartotojų darbo valandomis

Nors įmonės pastaruoju metu atsisako RIB duomenų apsikeitimo sistemos ir pasirenka internetinį režimą ir prieigą prie terminalo, tačiau neverta prisiminti, kad įkeliant ir atsisiunčiant mainų duomenis neįmanoma atlikti dokumentų ir pilnai dirbti programoje. Jei įmanoma, šią procedūrą, jei ji yra, reikia atlikti naktį, naudojant fonines užduotis.

3. Laiku padidinkite kompiuterio našumą, suderindami jo galią su realiais poreikiais

Nepamirškite, kad 30 ir 100 vartotojų vienu metu veikiant sistemoje susidaro skirtingos apkrovos. Atitinkamai, jei planuojamas kiekybinis vartotojų skaičiaus padidėjimas, IT tarnyba su įmonės vadovybe turėtų skubiai apsvarstyti mašinų parko išplėtimo, papildomos atminties ar serverių įsigijimo klausimą.

4. Programinė įranga, kurioje veikia 1C

1C programa yra tokia, kad operacinėse sistemose ji veikia skirtingai. Tiksliai nežinoma kodėl, bet taip yra. Pavyzdžiui, 1C duomenų bazės serverio versija Linux OS kartu su SQL Postgre yra daug lėtesnė nei ta pati 1C duomenų bazė Windows OS kartu su MS SQL. Tikslios šio fakto priežastys nėra žinomos, tačiau, matyt, kažkur giliai 1C platformoje yra suderinamumo problemų su operacinėmis sistemomis ir ne „Microsoft“ DBVS. Taip pat verta įdiegti sistemą 64 bitų serveryje, jei planuojate reikšmingai apkrauti duomenų bazę.

5. Duomenų bazės indeksavimas

Vidinė 1C programos procedūra, kuri „šukuoja“ sistemą iš vidaus. Nustatykite, kad jis veiktų kaip foninė įprasta užduotis naktį ir būkite ramūs.

6. Operatyvinės partijos apskaitos išjungimas

Faktas yra tas, kad operatyvaus dokumentų tvarkymo metu judėjimai registruojami registruose, įskaitant partijų apskaitos registrus. Programos nustatymuose galima išjungti partijos apskaitos registrų registravimą, kai registruojami dokumentai. Kartą per mėnesį reikės pradėti tvarkyti dokumentų siuntimą paketais, pavyzdžiui, tuo metu, kai duomenų bazės apkrova yra mažiausia arba kai dirba mažiausiai vartotojų.

7. RAM

Naudokite šią formulę:

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

Apie 70% visos fizinės duomenų bazių apimties. 1C duomenų bazės mėgsta gerai tiekti RAM. Nepamiršk šito.

8. Jei įmanoma, optimizuokite savarankiškai rašytas ataskaitas ir apdorojimą naudodami netobulus ir pasenusius kodus

Įmonės gyvavimo metu atsiranda poreikis rašyti ataskaitas ir apdoroti, taip pat modifikuoti verslo procesus ir išgauti specifinę informaciją. Visi šie patobulinimai gali sukelti trikdžių ir sulėtinti darbą, nes... a) kai kurie Kulibinai kažkada parašė sunkų, neteisingą kodą, kurį programai sunku vykdyti ir reikia didelių pastangų; b) kodas, kuriame rašomas apdorojimas arba ataskaita, gali būti pasenęs ir jį reikia peržiūrėti bei perprogramuoti. Naudokite taisyklę: kuo mažiau ką nors pakeisime programoje, tuo geriau.

9. Išvalykite talpyklą

Įprastas serverio perkrovimas kartais išsprendžia pasenusios 1C talpyklos problemas. Tiesiog išbandyk tai. Gali padėti ir iškrovimas – informacinės bazės įkėlimas per konfigūratorių. Ir paskutinis konkretaus vartotojo talpyklos valymas yra aplankų ištrynimas formos 1C sistemos kataloge: kexifzghjuhfv8j33hbdgk0. Tačiau talpykloje esančių vartotojų aplankų ištrynimas yra paskutinis dalykas, nes... Be šiukšlių pašalinimo, talpyklos išvalymas turi nemalonių pasekmių, nes ištrinami išsaugoti ataskaitos nustatymai ir vartotojo meniu sąsaja.

10. Fizinės duomenų bazių apimties mažinimas

Daugiau bazės reiškia daugiau išteklių. Natūralu. Norėdami sutraukti duomenų bazę, naudokite standartinius 1C įrankius. Pagalvokite apie galimybę atsisakyti penkerių metų duomenų, kad pagerintumėte našumą. Ir jei jums vis dar reikia paskutinių penkerių metų duomenų, visada galite naudoti duomenų bazės kopiją.

11. Teisingas architektūros organizavimas

Apskritai įmonės informacinės sistemos architektūra turi būti teisinga. Ką turime omenyje sakydami teisingą sistemą? Sistemai priskirtų užduočių palyginamumas su turima įranga ir programine įranga. Planuokite sistemą kartu su: sistemos administratoriumi (nes žino mašinų parką), 1C programuotoju (nes žino 1C resursų poreikius) ir įmonės vadovu (nes žino apie būsimą įmonės augimą ar susitraukimą). ).

Ar 1C prasideda po dviejų minučių? Ar dokumentų žurnalas atidaromas per 40 sekundžių? Ar dokumentas laikomas beveik minutę?

Tai pažįstama situacija, jei naudojate failo versiją su prieiga prie tinklo.
Galima, žinoma, įsidiegti serverį ir pamiršti stabdžius, bet jei 1C dirba tik 2-3 žmonės ir leisti pinigus serverio licencijoms įsigyti nėra praktiška.

Simptomai:
Kelių vartotojų darbas tinkle su ta pačia byla (duomenų baze) apima tinklo blokavimo mechanizmą. Tai verčia sistemą gaišti brangų laiką nustatant atviras įrašymo sesijas ir atitinkamai sprendžiant konfliktus. Pagrindiniai blokavimo veikimo požymiai:

  • greitas vartotojų darbas su duomenų baze tinkle išskirtiniu režimu ir itin lėtas, kai vienu metu dirba keli vartotojai.
  • greitas vartotojo darbas su vietine duomenų baze serveryje ir lėtas darbas tinkle.
  • Serverio procesorius beveik neveikia.
  • Gigabito tinklo plokštės apkrova yra mažesnė nei 5%.
  • prieiga prie failų sistemos yra šiek tiek mažesnė nei 10 MB/sek.
  • Bandant vienu metu paskelbti dokumentus, vienas kompiuteris sustoja maždaug minutę, o antrasis sugenda nuo 1C su klaidos tekstu „nepavyko užrakinti lentelės“.
  • Paleidimas 1C trunka apie 3 minutes.

Patarimai, kurie gali padėti pagreitinti failų duomenų bazę:

  • Eikite į darbą naudodami terminalo prieigą. Deja, „Windows 7“ neleidžia paversti terminalo serveriu naudojant standartinius įrankius – yra daugiausia vienas aktyvus ryšys. Tokiu atveju likę seansai nenutrūksta, galite prisijungti prie kito vartotojo – „išmesti“ ankstesnį vartotoją, bet nenutraukdami jo seanso. Todėl turėtumėte perkelti 1C į serverio OS, kur tokių apribojimų nėra, arba išspręsti problemą naudodami trečiosios šalies įrankį.
  • Išjunkite IPv6 tinklo protokolo naudojimą, sukonfigūruokite adresavimą „senajame“ IPv4.
  • Pridėkite 1C procesus prie „Windows“ ugniasienės išimčių, taip pat prie antivirusinių išimčių arba visiškai jas išjunkite (rizikingiau, tačiau paprastas testas parodė, kad dokumentų pakartotinio persiuntimo greitis žymiai padidėjo, kai „Avast“ antivirusinė programa buvo išjungta!)
  • Pradėkite indeksuoti viso teksto paiešką 1C arba visiškai ją išjunkite
  • Vykdykite duomenų bazės testavimą ir taisymą, patikrinkite su ChDbfl programa (programa yra įdiegtos technologijos platformos aplanke „bin“).
  • Paleiskite konfigūracijos elementą „Patikrinti konfigūraciją“ (jei konfigūracija nėra standartinė, tai gali būti naudinga).
  • Išjunkite nereikalingas funkcines parinktis (kuo mažiau nereikalingų valdomoje sąsajoje, tuo greičiau ji veikia, kaip taisyklė).
  • Nustatykite vartotojo teises (kuo mažiau nereikalingų valdomoje sąsajoje, tuo greičiau ji veikia, kaip taisyklė).
  • Pradėkite perskaičiuoti sumas ir atkurti seką (žymus padidėjimas gali įvykti tik tuo atveju, jei sumos nebuvo atkurtos ilgą laiką).
  • Duomenų bazės sąrašo nustatymuose nurodykite „Ryšio greitis – mažas“.
  • Disko defragmentavimas su failų duomenų baze.
  • Duomenų bazės konvoliucija (gali būti naudinga, jei duomenų bazė didelė, pavyzdžiui, kelerius metus).
  • Techninės įrangos atnaujinimas – greitesnis kietasis diskas (SSD), naujas jungiklis, procesorius, atmintis ir kt.
  • Įdiekite žiniatinklio serveryje, pasiekite naudodami ploną klientą.

Atlikus visus šiuos veiksmus, 1C failų duomenų bazė gali veikti daug greičiau. Kai kuriais atvejais paleidimas užtruko 10 sekundžių, o dokumentų apdorojimo greitis padidėjo 12 kartų.

P.S. UT 11.1 konfigūracijoje nerealu paleisti failą 1C naudojant tinklo prieigą prie bendrinamo aplanko, nes Net greičiausias kietojo kūno diskas, RAM ir procesorius užblokuoja tinklą, o daugiau nei vieno vartotojo darbas tampa praktiškai neįmanomas.
Savarankiškai parašytos mažos konfigūracijos gali veikti gana greitai net ir failo versijoje.

Labai dažnai žmonės kreipiasi į mus su tokiais klausimais kaip:

  • Kodėl 1C serveris sulėtėja?
  • kompiuteris, kuriame veikia 1C, yra labai lėtas
  • 1C klientas siaubingai lėtas

Kartais, kaip problemos sprendimą, klientams siūlome išsinuomoti 1C serverį be stabdžių, pasirenkant serverio konfigūraciją ir operacinę sistemą, serverį galite konfigūruoti internetu mūsų partnerio svetainėje, naudodami nuorodą https://1cloud.ru skyrių Paslaugos, skyrius Virtualus serveris.

Ką daryti ir kaip tai įveikti, ir taip toliau eilės tvarka:

Su 1C serverio versija klientai dirba labai lėtai

Be lėto 1C darbo, taip pat lėtas darbas su tinklo failais. Problema kyla normaliai veikiant ir naudojant KPP

Kad tai išspręsčiau, po kiekvieno „Seven“ arba „2008“ serverio įdiegimo aš visada pradedu

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=išjungtas kaminas=išjungtas

ir tinklas veikia be problemų

kartais geriausias pasirinkimas yra:

netsh sąsaja tcp set global autotuning= HighlyRestricted

taip atrodo instaliacija

Konfigūruokite antivirusinę arba Windows ugniasienę

Kaip sukonfigūruoti antivirusinę arba „Windows“ užkardą, kad būtų paleistas 1C serveris (pavyzdžiui, „1C Server: Enterprise“ ir „MS SQL 2008“ derinys).

Pridėti taisykles:

  • Jei SQL serveris priima ryšius per standartinį TCP prievadą 1433, tai leidžiame.
  • Jei SQL prievadas yra dinaminis, turite leisti prisijungti prie programos %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
  • Serveris 1C veikia 1541 prievaduose, 1540 klasteryje ir 1560–1591 diapazone. Dėl visiškai mistinių priežasčių kartais toks atvirų prievadų sąrašas vis tiek neleidžia prisijungti prie serverio. Kad įsitikintumėte, jog jis veikia, leiskite diapazoną 1540–1591.

Serverio/kompiuterio našumo derinimas

Kad jūsų kompiuteris veiktų maksimaliai efektyviai, turite jį sukonfigūruoti taip:

1. BIOS nustatymai

  • Serverio BIOS išjungiame visus nustatymus, kad taupytume procesoriaus energiją.
  • Jei yra „C1E“ ir būtinai ATJUNKITE!!
  • Kai kurioms ne itin lygiagrečioms užduotims taip pat rekomenduojama išjungti hiperprekybą BIOS
  • Kai kuriais atvejais (ypač HP!) reikia įeiti į serverio BIOS ir IŠJUNGTI ten esančius elementus, kurių pavadinimuose yra EIST, Intel SpeedStep ir C1E.
  • Vietoj to turite rasti elementus, susijusius su procesoriumi, kurių pavadinimuose yra Turbo Boost, ir juos Įjungti.
  • Jei BIOS yra bendras energijos taupymo režimo nurodymas ir įtraukite jį į maksimalaus našumo režimą (tai taip pat gali būti vadinama „agresyviu“)

2. Schemos nustatymai operacinėje sistemoje – Didelis našumas

Serveriai su Intel Sandy Bridge architektūra gali dinamiškai keisti procesoriaus dažnius.

Kartais lėto 1C serverio veikimo problemos sprendimas yra pasenusi arba sugedusi įranga, tokiu atveju klientams siūlome išsinuomoti serverį 1C be stabdžių, pasirenkant serverio konfigūraciją ir operacinę sistemą, tai galite padaryti mūsų svetainėje. partnerio svetainėje, nuorodoje https://1cloud.ru Paslaugų skyrius, Virtualus serveris.

Jei turite klausimų, susisiekite:

  • skambinti +7-812-385-55-66 Sankt Peterburge
  • rašykite adresu
  • palikite paraišką mūsų svetainės puslapyje „Paraiška internetu“.
Peržiūros