1s ir lēnāks jaunajā serverī kāpēc. Automatizācijas padomi

Šajā rakstā ir apskatīti galvenie faktori: kad 1C palēninās, 1C sasalst un 1C darbojas lēni. Dati tika sagatavoti, pamatojoties uz SoftPoint daudzu gadu pieredzi lielu IT sistēmu optimizēšanā, kas balstītas uz 1C + MS SQL kombināciju.

Sākumā ir vērts atzīmēt mītu, ka 1C nav paredzēts vienlaicīgam lielam lietotāju skaitam, ko aktīvi atbalsta foruma lietotāji, kuri šajos ierakstos atrod pārliecību un iemeslu atstāt visu, kā tas ir. Ar pietiekamu pacietību un zināšanām jūs varat nodrošināt sistēmu jebkuram lietotāju skaitam. Lēna darbība un 1C sasalšana vairs nebūs problēma.

No prakses: Vienkāršākais optimizācijas veids ir 1C v7.7 (1C 8.1, 1C 8.2, 1C 8.3 optimizēšana ir grūtāks uzdevums, jo lietojumprogramma sastāv no 3 saitēm). 400 vienlaicīgu lietotāju nodrošināšana ir diezgan tipisks projekts. Līdz 1500 jau ir grūti un prasa smagu darbu.

Otrais mīts: lai uzlabotu 1C veiktspēju un atbrīvotos no 1C sasalšanas, ir jāinstalē jaudīgāks serveris. Parasti optimizācijas projektos 95% gadījumu ir iespējams sasniegt pieņemamu veiktspēju vai nu bez jaunināšanas, vai arī atjauninot nelielu aprīkojuma daļu, piemēram, pievienojot RAM. Jāpiebilst, ka aprīkojumam joprojām ir jābūt servera bāzētai, jo īpaši diska apakšsistēmai. Novecojusi diska apakšsistēma ir tikai viens no iemesliem, kāpēc 1C darbojas lēni.

Galvenais ierobežojums, strādājot ar vairākiem lietotājiem 1C, ir bloķēšanas mehānisms. Tā ir bloķēšana 1C, nevis servera aprīkojums, kas parasti neļauj lielam skaitam cilvēku strādāt datu bāzē. Lai novērstu šo problēmu, jums ir smagi jāstrādā un jāmaina bloķēšanas loģika 1C — samaziniet tos no tabulas uz rindām. Tad, piemēram, ievietojot dokumentu, tiks bloķēts tikai viens, nevis visi sistēmas dokumenti.

1. attēls. 1C bloķēšanas rinda PerfExpert uzraudzības sistēmā ar informāciju par 1C lietotājiem, konfigurācijas moduli un īpašu koda rindu šajā modulī.

1C bloķēšanas mehānisma maiņa ir ļoti sarežģīta tehnoloģija. Ne katrs var izdomāt šādu triku, un viņiem atliek tikai viens ceļš - optimizēt struktūru un paātrināt operāciju izpildes laiku. Fakts ir tāds, ka bloķēšana 1C un darbību izpildes laiks ir ļoti savstarpēji saistīti rādītāji. Piemēram, ja dokumenta grāmatošanas darbība aizņem 15 sekundes, tad, ja ir liels lietotāju skaits, pastāv liela varbūtība, ka pārsūtīšanas laikā kāds cits mēģinās ievietot dokumentu un gaidīs bloķēšanā. Ja pagarināsiet izpildes laiku vismaz līdz 1 sekundei, 1C bloķēšana šai darbībai tiks ievērojami samazināta.

Bīstamāka no bloķēšanas viedokļa ir grupu apstrāde, kuras pabeigšana var aizņemt ilgu laiku un vienlaikus izraisīt 1C bloķēšanu. Jebkura apstrāde, kas maina datus, piemēram, dokumentu secības atjaunošana vai pakešu apstrāde, bloķē tabulas un neļauj citiem lietotājiem ievietot dokumentus. Protams, jo ātrāk šīs apstrādes tiek veiktas, jo mazāk laika bloķēšanu un lietotājiem atvieglo darbu.

Smagie pārskati, kas veic tikai lasāmas darbības, var būt bīstami arī bloķēšanas ziņā, lai gan šķiet, ka tie nebloķē datus. Šādi ziņojumi ietekmē 1C bloķēšanas intensitāti, palēninot citas sistēmas darbības. Tas ir, ja ziņojums ir ļoti smags un aizņem lielāko daļu servera resursu, var izrādīties, ka pirms atskaites palaišanas vienas un tās pašas darbības tika veiktas 1 sekundi, bet atskaites izpildes laikā tās tika veiktas 15 sekundes. . Protams, palielinoties operāciju izpildes laikam, palielināsies arī bloķēšanas intensitāte.

2. attēls. Slodze uz strādājošā servera konfigurācijas moduļu izteiksmē no visiem lietotājiem. Katram modulim ir sava krāsa. No 1C radītajā slodzē ir skaidra nelīdzsvarotība.

Optimizācijas pamatnoteikums ir tāds, ka dokumentu apstrādei vajadzētu aizņemt minimālu laiku un veikt tikai nepieciešamās darbības. Piemēram, reģistru aprēķini bieži tiek izmantoti grāmatošanas apstrādē, nenorādot filtrēšanas nosacījumus. Šajā gadījumā ir jānorāda reģistru filtri, kas ļauj iegūt vislabāko selektivitāti, neaizmirstot, ka atbilstoši filtrēšanas nosacījumiem reģistrā jābūt atbilstošiem indeksiem.

Papildus smagu pārskatu palaišanai, MS SQL un MS Windows neoptimālie iestatījumi var palēnināt darbību izpildes laiku un tādējādi palielināt 1C bloķēšanas intensitāti. Šī problēma rodas 95% klientu. Jāatzīmē, ka tie ir nopietnu organizāciju serveri, kuru nodrošināšanā un konfigurēšanā ir iesaistīti veseli augsti kvalificētu administratoru departamenti.

Galvenais iemesls nav pareizi iestatījumi serveris ir administratoru bailes kaut ko mainīt strādājošā serverī un noteikums “Labākais ir labā ienaidnieks”. Ja administrators mainīs servera iestatījumus un sāksies problēmas, tad visas varas dusmas izgāzīsies uz neuzmanīgo administratoru. Tāpēc viņam izdevīgāk ir atstāt visu, kā ir, un nespert ne soli bez priekšnieku pavēlēm, nekā eksperimentēt uz savu atbildību.

Otrs iemesls ir skaidras informācijas trūkums par tīkla optimizācijas problēmām. Ir daudz viedokļu, kas bieži vien ir pilnīgi pretrunā viens otram. Katram optimizācijai veltītajam viedoklim ir savi pretinieki un fanātiķi, kas to aizstāvēs. Tā rezultātā internets un forumi, visticamāk, sajauks servera iestatījumus, nevis palīdzēs. Šādas nenoteiktības situācijā administratoram ir vēl mazāka vēlme kaut ko mainīt serverī, kas kaut kā darbojas.

No pirmā acu uzmetiena attēls ir skaidrs - jums ir jāoptimizē viss, kas palēnina 1C servera darbību. Bet iedomāsimies sevi šāda optimizētāja vietā – pieņemsim, ka mums ir 1C 8.1 8.2 8.3 UPP un vienlaikus strādā 50 lietotāji. Kādā briesmīgā dienā lietotāji sāk sūdzēties, ka 1C ir lēns, un mums šī problēma ir jāatrisina.

Vispirms aplūkojam, kas notiek serverī – ja nu kāds īpaši neatkarīgs antivīruss veic pilnu sistēmas skenēšanu. Pārbaude parāda, ka viss ir kārtībā - serveris ir noslogots uz 100%, un tikai ar sqlservr procesu.

No prakses: viens no jaunākajiem administratoriem pēc savas iniciatīvas serverī ieslēdza automātisko atjaunināšanu, Windows un SQL laimīgi tika atjaunināti, un pēc atjaunināšanas sākās masveida 1C lietotāju darba palēnināšanās vai 1C vienkārši iesaldēja.

Nākamais solis ir pārbaudīt, kuras programmas ielādē MS SQL. Pārbaude liecina, ka slodzi ģenerē aptuveni 20 lietojumprogrammu servera savienojumi.

No prakses: programma, kas nekavējoties atjaunina datus vietnē, iegāja cilpā, un tā vietā, lai atjauninātu reizi 4 stundās, tā to darīja nepārtraukti, bez pauzēm, smagi noslogojot serveri un bloķējot datus.

Turpmāka situācijas analīze saskaras ar lielām grūtībām. Mēs jau esam noskaidrojuši, ka slodze nāk tieši no 1C, bet kā mēs varam saprast, ko tieši lietotāji dara? Vai vismaz kas viņi ir. Ir labi, ja organizācijā ir 10 1C lietotāji, tad varat vienkārši iziet cauri tiem un uzzināt, ko viņi dara tagad, bet mūsu gadījumā viņu ir piecdesmit, un tie ir izkaisīti pa vairākām ēkām.

Mūsu aplūkotajā piemērā situācija vēl nav sarežģīta. Iedomājieties, ka palēninājums nebija šodien, bet vakar. Šodien situācija neatkārtojas, viss ir kārtībā, bet jāizdomā, kāpēc vakar nevarēja strādāt operatori (protams, sūdzējās tikai pirms iziešanas no mājām, jo patīk pļāpāt visas dienas garumā, jo nekas nav strādā, vairāk nekā strādā). Šis gadījums uzsver nepieciešamību pēc servera reģistrēšanas sistēmas, kas vienmēr saglabās galveno servera darbības parametru vēsturi un no kuras var atjaunot notikumu secību.

Mežizstrādes sistēma ir vienkārši neaizstājams sistēmas optimizācijas rīks. Ja pievienosit tam iespēju tiešsaistē skatīt pašreizējo statusu, jūs iegūsit servera statusa uzraudzības sistēmu. Katrs optimizācijas projekts sākas ar servera stāvokļa statistikas apkopošanu, lai noteiktu vājās vietas.

Uzsākot darbu optimizācijas jomā, mēs izmēģinājām daudzas serveru uzraudzības sistēmas, diemžēl mums neizdevās atrast kaut ko, kas šo problēmu atrisinātu atbilstošā līmenī, tāpēc nācās izveidot sistēmu saviem spēkiem. Rezultātā tika izveidots unikāls produkts PerfExpert, kas ļāva automatizēt un racionalizēt IT sistēmu optimizācijas procesus. Programma izceļas ar ciešu integrāciju ar 1C, pamanāmas papildu slodzes neesamību un vairākkārt pierādītu piemērotību praktiskai lietošanai kaujas situācijās.

Atgriežoties pie mūsu piemēra, visticamākais iznākums ir šāds: administrators saka: "Vainīgi ir programmētāji, kuri uzrakstīja konfigurāciju. Programmētāji atbild: "Mums viss ir labi uzrakstīts, tas ir serveris, kas nedarbojas labi." Bet rati, kā saka, joprojām ir. Rezultātā 1C palēninās, sasalst vai darbojas lēni.

Jebkurā gadījumā, lai atrisinātu 1C veiktspējas problēmas, mēs iesakām vispirms iegādāties un izmantot veiktspējas uzraudzību PerfExpert , tas ļaus jums pieņemt pareizo lēmumu vadības lēmums un ietaupīt naudu. Produkts piemērots gan mazām 1C:Uzņēmuma informācijas sistēmām - līdz 50 lietotājiem, gan sistēmām - no 1000 lietotājiem. Kopš 2015. gada jūlija izpildes monitorings PerfExpert saņēma 1C:Compatible sertifikātu, izturēja testēšanu Microsoft un palīdz atrisināt veiktspējas problēmas ne tikai 1C sistēmām, bet arī citām informācijas sistēmām, kuru pamatā ir MS SQL Server (Axapta, CRM Dynamics, Doc Vision un citi).

Ja jums patika informācija, ieteicamās turpmākās darbības:

- Ja vēlaties patstāvīgi risināt 1C veiktspējas tehniskās problēmas (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) un citas informācijas sistēmas, tad jums ir unikāls tehnisko rakstu saraksts mūsu Almanahā (Bloķēšana un strupceļi, liela CPU un disku slodze, datu bāzes uzturēšana un indeksu regulēšana ir tikai neliela daļa no tehniskajiem materiāliem, ko jūs tur atradīsit).
.
- Ja vēlaties apspriest veiktspējas problēmas ar mūsu ekspertu vai pasūtīt PerfExpert veiktspējas uzraudzības risinājumu, tad atstājiet pieprasījumu, un mēs ar jums sazināsimies pēc iespējas ātrāk.

Mēs bieži saņemam jautājumus par to, kas palēnina 1c, it īpaši, pārejot uz versiju 1c 8.3, pateicoties mūsu kolēģiem no Interface LLC, mēs jums pastāstām sīkāk:

Iepriekšējās publikācijās mēs jau esam pieskārušies produktivitātes ietekmei diska apakšsistēma tomēr ar ātrumu 1C šis pētījums attiecās uz lietojumprogrammas lokālu izmantošanu atsevišķā datorā vai termināļa serveris. Tajā pašā laikā lielākā daļa mazo implementāciju ietver darbu ar failu datu bāzi tīklā, kur viens no lietotāja datoriem tiek izmantots kā serveris, vai speciālu failu serveri, kura pamatā ir parasts, visbiežāk arī lēts dators.

Neliels pētījums par krievu valodas 1C resursiem to parādīja šo jautājumu cītīgi no tā izvairās, ja rodas problēmas, parasti tiek ieteikts pārslēgties uz klienta-servera vai termināļa režīmu. Gandrīz vispārpieņemts ir arī tas, ka pārvaldītās lietojumprogrammas konfigurācijas darbojas daudz lēnāk nekā parasti. Parasti norādītie argumenti ir “dzelzs”: “Grāmatvedība 2.0 tikko lidoja, bet “troika” tik tikko pakustējās”, protams, šajos vārdos ir daļa patiesības, tāpēc mēģināsim to izdomāt.

Resursu patēriņš, pirmais skatiens

Pirms šī pētījuma sākšanas mēs izvirzījām divus mērķus: noskaidrot, vai pārvaldītās lietojumprogrammu konfigurācijas patiešām ir lēnākas nekā parastās konfigurācijas un kuri konkrētie resursi galvenokārt ietekmē veiktspēju.

Testēšanai mēs paņēmām divas virtuālās mašīnas, kurās darbojas attiecīgi Windows Server 2012 R2 un Windows 8.1, piešķirot tām 2 resursdatora Core i5-4670 kodolus un 2 GB. brīvpiekļuves atmiņa, kas aptuveni atbilst vidējai biroja mašīnai. Serveris tika ievietots divu WD Se RAID 0 masīvā, un klients tika novietots līdzīgā vispārējas nozīmes disku masīvā.

Kā eksperimentālo pamatu mēs izvēlējāmies vairākas grāmatvedības 2.0 versijas konfigurācijas 2.0.64.12 , kas pēc tam tika atjaunināts uz 3.0.38.52 , visas konfigurācijas tika palaistas platformā 8.3.5.1443 .

Pirmā lieta, kas piesaista uzmanību, ir palielinātais Troikas informācijas bāzes apjoms, kas ir ievērojami pieaudzis, kā arī daudz lielāka apetīte pēc RAM:

Mēs esam gatavi dzirdēt ierasto: "kāpēc viņi to pievienoja šiem trim", bet nesteigsimies. Atšķirībā no klienta-servera versiju lietotājiem, kam nepieciešams vairāk vai mazāk kvalificēts administrators, failu versiju lietotāji reti domā par datu bāzu uzturēšanu. Arī specializēto uzņēmumu darbinieki, kas apkalpo (lasi atjaunina) šīs datu bāzes, par to aizdomājas reti.

Tikmēr 1C informācijas bāze ir pilnvērtīga sava formāta DBVS, kurai arī nepieciešama apkope, un tam ir pat rīks ar nosaukumu Informācijas bāzes pārbaude un labošana. Iespējams, nosaukums izspēlēja nežēlīgu joku, kas kaut kā nozīmē, ka tas ir problēmu novēršanas rīks, taču problēma ir arī zema veiktspēja, un pārstrukturēšana un pārindeksēšana, kā arī tabulu saspiešana ir labi zināmi rīki datu bāzu optimizēšanai. Pārbaudīsim?

Pēc izvēlēto darbību veikšanas datubāze strauji “zaudēja svaru”, kļūstot pat mazāka par “divām”, kuras neviens nekad nebija optimizējis, un arī RAM patēriņš nedaudz samazinājās.

Pēc tam pēc jaunu klasifikatoru un direktoriju ielādes, indeksu izveides utt. pamatnes izmērs kopumā palielināsies, "trīs" pamatnes ir lielākas nekā "divas" pamatnes. Taču tas nav svarīgāk, ja otrajā versijā pietika ar 150-200 MB operatīvo atmiņu, tad jaunajam izdevumam nepieciešams pusgigabaits un šī vērtība būtu jāņem vērā, plānojot darbam ar programmu nepieciešamos resursus.

Tīkls

Tīkla joslas platums ir viens no svarīgākajiem tīkla lietojumprogrammu parametriem, jo īpaši, piemēram, 1C faila režīmā, kas tīklā pārvieto ievērojamu datu apjomu. Lielākā daļa mazo uzņēmumu tīklu ir veidoti uz lētu 100 Mbit/s iekārtu bāzes, tāpēc mēs sākām testēšanu, salīdzinot 1C veiktspējas rādītājus 100 Mbit/s un 1 Gbit/s tīklos.

Kas notiek palaišanas laikā failu datu bāze 1C tīklā? Klients lejupielādē pietiekami daudz pagaidu mapēs liels skaits informāciju, it īpaši, ja šis ir pirmais, “aukstais” starts. Paredzams, ka pie 100 Mbit/s mēs darbosimies pret kanāla platumu, un lejupielāde var aizņemt ievērojamu laiku, mūsu gadījumā apmēram 40 sekundes (grafikas dalīšanas izmaksas ir 4 sekundes).

Otrā palaišana ir ātrāka, jo daži dati tiek saglabāti kešatmiņā un paliek tur līdz atsāknēšanai. Pārslēgšanās uz gigabitu tīklu var ievērojami paātrināt programmas ielādi gan “aukstā”, gan “karstā”, un vērtību attiecība tiek ievērota. Tāpēc mēs nolēmām rezultātu izteikt relatīvās vērtībās, ņemot visvairāk liela nozīme katrs mērījums:

Kā redzams no grafikiem, Accounting 2.0 ielādējas jebkurā tīkla ātrumā divas reizes ātrāk, pāreja no 100 Mbit/s uz 1 Gbit/s ļauj četras reizes paātrināt lejupielādes laiku. Šajā režīmā nav nekādas atšķirības starp optimizētajām un neoptimizētajām "troikas" datu bāzēm.

Mēs pārbaudījām arī tīkla ātruma ietekmi uz darbību smagos režīmos, piemēram, grupu pārsūtīšanas laikā. Rezultātu izsaka arī relatīvās vērtībās:

Šeit ir interesantāk, optimizētā “trīs” bāze 100 Mbit/s tīklā darbojas ar tādu pašu ātrumu kā “divi”, un neoptimizētā uzrāda divreiz sliktākus rezultātus. Gigabitā attiecības paliek nemainīgas, arī neoptimizētais “trīs” ir uz pusi lēnāks nekā “divi”, bet optimizētais atpaliek par trešdaļu. Tāpat pāreja uz 1 Gbit/s ļauj samazināt izpildes laiku trīs reizes izdevumam 2.0 un uz pusi 3.0.

Lai novērtētu tīkla ātruma ietekmi uz ikdienas darbu, izmantojām Veiktspējas mērīšana, veicot iepriekš noteiktu darbību secību katrā datu bāzē.

Faktiski ikdienas uzdevumiem tīkla caurlaidspēja nav sašaurinājums, neoptimizēts "trīs" ir tikai par 20% lēnāks nekā "divi", un pēc optimizācijas tas izrādās tikpat ātrāks - priekšrocības strādājot plānā klienta režīmā ir acīmredzamas. Pāreja uz 1 Gbit/s optimizētajai bāzei nedod nekādas priekšrocības, un neoptimizētais un abi sāk darboties ātrāk, uzrādot nelielu atšķirību savā starpā.

No veiktajiem testiem kļūst skaidrs, ka tīkls nav šķērslis jaunām konfigurācijām, un pārvaldītā aplikācija darbojas pat ātrāk nekā parasti. Varat arī ieteikt pārslēgties uz 1 Gbit/s, ja jums ir kritiski svarīgi uzdevumi un datu bāzes ielādes ātrums, citos gadījumos jaunas konfigurācijas ļauj efektīvi strādāt pat lēnos 100 Mbit/s tīklos.

Tātad, kāpēc 1C ir lēns? Mēs to izskatīsim sīkāk.

Servera diska apakšsistēma un SSD

Iepriekšējā rakstā mēs panācām 1C veiktspējas pieaugumu, ievietojot datu bāzes SSD. Varbūt servera diska apakšsistēmas veiktspēja ir nepietiekama? Diska servera veiktspēju mērījām grupas palaišanas laikā divās datu bāzēs uzreiz un saņēmām diezgan optimistisku rezultātu.

Neskatoties uz salīdzinoši lielo ievades/izvades operāciju skaitu sekundē (IOPS) – 913, rindas garums nepārsniedza 1,84, kas ir ļoti labs rezultāts divu disku masīvam. Pamatojoties uz to, mēs varam pieņemt, ka ar spoguli, kas izgatavots no parastajiem diskiem, pietiks normālai 8-10 tīkla klientu darbībai smagos režīmos.

Tātad, vai serverī ir nepieciešams SSD? Labākais veids, kā atbildēt uz šo jautājumu, būs testēšana, ko veicām ar līdzīgu metodi, tīkla savienojums visur ir 1 Gbit/s, rezultāts tiek izteikts arī relatīvās vērtībās.

Sāksim ar datu bāzes ielādes ātrumu.

Dažiem tas var šķist pārsteidzoši, taču serverī esošais SSD neietekmē datu bāzes ielādes ātrumu. Galvenais ierobežojošais faktors šeit, kā parādīja iepriekšējais tests, ir tīkla caurlaidspēja un klienta veiktspēja.

Pāriesim pie pārtaisīšanas:

Iepriekš jau atzīmējām, ka diska veiktspēja ir diezgan pietiekama pat darbam smagos režīmos, tāpēc arī SSD ātrums netiek ietekmēts, izņemot neoptimizēto bāzi, kas SSD ir panākusi optimizēto. Faktiski tas vēlreiz apstiprina, ka optimizācijas operācijas organizē informāciju datu bāzē, samazinot nejaušo I/O operāciju skaitu un palielinot piekļuves ātrumu tai.

Ikdienas uzdevumos attēls ir līdzīgs:

Tikai neoptimizētā datu bāze gūst labumu no SSD. Jūs, protams, varat iegādāties SSD, taču daudz labāk būtu padomāt par savlaicīgu datu bāzes uzturēšanu. Tāpat neaizmirstiet par sadaļas defragmentēšanu ar informācijas bāzēm serverī.

Klienta diska apakšsistēma un SSD

Iepriekšējā materiālā mēs apspriedām SSD ietekmi uz lokāli instalētā 1C darbības ātrumu. Liela daļa no teiktā attiecas arī uz darbu tīkla režīmā. Patiešām, 1C diezgan aktīvi izmanto diska resursus, tostarp fona un ikdienas uzdevumiem. Zemāk esošajā attēlā varat redzēt, kā Accounting 3.0 diezgan aktīvi piekļūst diskam apmēram 40 sekundes pēc ielādes.

Taču tajā pašā laikā jāapzinās, ka darbstacijai, kurā notiek aktīvs darbs ar vienu vai divām informācijas datu bāzēm, parastā sērijveidā ražotā HDD veiktspējas resursi ir pilnīgi pietiekami. SSD iegāde var paātrināt dažus procesus, taču ikdienas darbā jūs nepamanīsiet radikālu paātrinājumu, jo, piemēram, ielāde būs ierobežota caurlaidspēja tīkliem.

Lēns HDD var palēnināt dažas darbības, bet pati par sevi nevar izraisīt programmas palēnināšanos.

RAM

Neskatoties uz to, ka operatīvā atmiņa tagad ir nepieklājīgi lēta, daudzas darbstacijas turpina strādāt ar tādu atmiņas apjomu, kāds tika instalēts iegādes brīdī. Šeit gaida pirmās problēmas. Pamatojoties uz to, ka vidējai “troikai” ir nepieciešami aptuveni 500 MB atmiņas, varam pieņemt, ka darbam ar programmu ar kopējo RAM apjomu 1 GB nepietiks.

Mēs samazinājām sistēmas atmiņu līdz 1 GB un iedarbinājām divas informācijas datu bāzes.

No pirmā acu uzmetiena viss nav tik slikti, programma ir samazinājusi apetīti un labi iekļaujas pieejamajā atmiņā, taču neaizmirsīsim, ka nepieciešamība pēc operatīvajiem datiem nav mainījusies, kur tad tā palika? Atiestatīt uz diska, kešatmiņas, mijmaiņas u.c., šīs darbības būtība ir tāda, ka tas nav nepieciešams Šis brīdis dati tiek nosūtīti no ātras RAM, kuras apjoms nav pietiekams, lai palēninātu diska atmiņu.

Kur tas ved? Apskatīsim, kā tiek izmantoti sistēmas resursi smagās operācijās, piemēram, uzsāksim grupas pārsūtīšanu uzreiz divās datu bāzēs. Vispirms sistēmā ar 2 GB RAM:

Kā redzam, sistēma aktīvi izmanto tīklu datu saņemšanai, un procesors to apstrādei ir niecīgs, tas ik pa laikam palielinās, bet nav ierobežojošs faktors;

Tagad samazināsim atmiņu līdz 1 GB:

Situācija radikāli mainās, galvenā slodze tagad krīt uz cieto disku, procesors un tīkls ir dīkstāvē, gaidot, kad sistēma nolasīs nepieciešamos datus no diska atmiņā un nosūtīs tur nevajadzīgos datus.

Tajā pašā laikā pat subjektīvs darbs ar divām atvērtām datu bāzēm sistēmā ar 1 GB atmiņu izrādījās ārkārtīgi neērts, un direktori un žurnāli tika atvērti ar ievērojamu kavēšanos un aktīvu piekļuvi diskam. Piemēram, preču un pakalpojumu pārdošanas žurnāla atvēršana aizņēma apmēram 20 sekundes, un visu šo laiku to pavadīja liela diska aktivitāte (izcelta ar sarkanu līniju).

Lai objektīvi novērtētu RAM ietekmi uz konfigurāciju veiktspēju, pamatojoties uz pārvaldītu lietojumprogrammu, mēs veicām trīs mērījumus: pirmās datu bāzes ielādes ātrumu, otrās datu bāzes ielādes ātrumu un grupas atkārtotu palaišanu vienā no datu bāzēm. . Abas datu bāzes ir pilnīgi identiskas un tika izveidotas, kopējot optimizēto datu bāzi. Rezultātu izsaka relatīvās vienībās.

Rezultāts runā pats par sevi: ja ielādes laiks palielinās par aptuveni trešdaļu, kas joprojām ir diezgan pieļaujams, tad operāciju veikšanas laiks datu bāzē palielinās trīs reizes, nav jārunā par kaut kādu ērtu darbu šādos apstākļos. Starp citu, tas ir gadījums, kad SSD iegāde var uzlabot situāciju, taču daudz vienkāršāk (un lētāk) ir cīnīties ar cēloni, nevis ar sekām, un vienkārši iegādāties pareizo operatīvo atmiņu.

RAM trūkums ir galvenais iemesls, kāpēc darbs ar jaunām 1C konfigurācijām izrādās neērts. Konfigurācijas ar 2 GB atmiņu jāuzskata par minimāli piemērotām. Tajā pašā laikā paturiet prātā, ka mūsu gadījumā tika izveidoti “siltumnīcas” apstākļi: tīra sistēma, darbojās tikai 1C un uzdevumu pārvaldnieks. IN īsta dzīve darba datorā parasti ir atvērta pārlūkprogramma, biroja komplekts, darbojas antivīruss utt. utt., tāpēc ņemiet vērā nepieciešamību pēc 500 MB vienai datu bāzei plus neliela rezerve, lai smagu darbību laikā jūs to darītu nesastopas ar atmiņas trūkumu un strauju produktivitātes samazināšanos.

Procesors

Bez pārspīlējuma centrālo procesoru var saukt par datora sirdi, jo tas galu galā apstrādā visus aprēķinus. Lai novērtētu tā lomu, mēs veicām vēl vienu testu komplektu, tādu pašu kā RAM, samazinot virtuālajai mašīnai pieejamo kodolu skaitu no diviem līdz vienam, un tests tika veikts divas reizes ar atmiņas apjomu 1 GB un 2 GB.

Rezultāts izrādījās diezgan interesants un negaidīts: jaudīgāks procesors diezgan efektīvi uzņēmās slodzi, kad trūka resursu, pārējā laikā nedodot nekādu taustāmu labumu. 1C Enterprise diez vai var saukt par lietojumprogrammu, kas aktīvi izmanto procesora resursus, tā ir diezgan mazprasīga. Un sarežģītos apstākļos procesoru noslogo ne tik daudz pašas aplikācijas datu aprēķināšana, bet pieskaitāmo izmaksu apkalpošana: papildu ievades/izvades operācijas utt.

secinājumus

Tātad, kāpēc 1C ir lēns? Pirmkārt, tas ir RAM trūkums, galvenā slodze šajā gadījumā krīt uz cieto disku un procesoru. Un, ja tie nespīd ar veiktspēju, kā tas parasti notiek biroja konfigurācijās, tad mēs iegūstam situāciju, kas aprakstīta raksta sākumā - “divi” strādāja labi, bet “trīs” ir bezdievīgi lēni.

Otrajā vietā ir tīkla veiktspēja, lēns 100 Mbit/s kanāls var kļūt par īstu sašaurinājumu, bet tajā pašā laikā plānā klienta režīms spēj uzturēt diezgan komfortablu darbības līmeni pat lēnos kanālos.

Tad jums vajadzētu pievērst uzmanību diskdzinim, visticamāk, ka SSD iegāde nebūs labs ieguldījums, taču diska nomaiņa pret modernāku būtu laba ideja. Atšķirība starp paaudzēm cietie diski var novērtēt pēc uz šādu materiālu: Pārskats par diviem lētiem Western Digital Blue sērijas diskdziņiem ar 500 GB un 1 TB.

Un visbeidzot procesors. Ātrāks modelis noteikti nebūs lieks, bet tam ir liela jēga Nav iespējams palielināt tā veiktspēju, ja vien šis dators netiek izmantots smagām darbībām: grupu apstrāde, smagas atskaites, mēneša slēgšana utt.

Mēs ceram šo materiālu palīdzēs ātri saprast jautājumu “kāpēc 1C ir lēns” un atrisināt to visefektīvāk un bez papildu izmaksām.

Ikviens, kurš strādā ar produktiem platformā 1C:Enterprise, droši vien ir dzirdējis frāzi “1C ir lēns”. Daži cilvēki par to sūdzējās, citi pieņēma sūdzības. Šajā rakstā mēs centīsimies aplūkot visbiežāk sastopamos šīs problēmas cēloņus un tās risināšanas iespējas.

Pievērsīsimies metaforai: pirms noskaidrot, kāpēc cilvēks kaut kur nav ieradies, jāpārliecinās, vai viņam ir kājas, lai staigātu. Tātad, sāksim ar aparatūras un tīkla prasībām.

Ja ir instalēta Windows 7:

Ja jums ir instalēta operētājsistēma Windows 8 vai 10:

Atcerieties arī to brīva vieta Diskam jābūt vismaz 2 GB, un tīkla savienojuma ātrumam jābūt vismaz 100 MB/sek.

Nav jēgas apsvērt serveru īpašības klienta-servera versijā, jo šajā gadījumā viss ir atkarīgs no lietotāju skaita un to uzdevumu specifikas, ko viņi risina 1C.

Izvēloties servera konfigurāciju, ņemiet vērā tālāk norādīto.

Viens 1C servera darbinieka process patērē vidēji 4 GB (nejaukt ar lietotāja savienojumu, jo vienam darbinieka procesam var būt tik daudz savienojumu, cik norādāt servera iestatījumos);
1C un DBVS (īpaši MS SQL) izmantošana vienā fiziskajā serverī sniedz priekšrocības, apstrādājot lielu datu apjomu (piemēram, slēdzot mēnesi, aprēķina budžetu, pamatojoties uz modeli utt.), bet ievērojami samazina veiktspēju izkraušanas operāciju laikā ( piemēram, ieviešanas dokumenta izveide un vadīšana utt.);
Atcerieties, ka 1C serveri un DBVS ir jāsavieno pa kanālu, kura biezums ir 1 GB;
Izmantojiet augstas veiktspējas diskus un neapvienojiet 1C un DBMS servera lomas ar citām lomām (piemēram, fails, AD, domēna kontrolleris utt.).

Ja pēc aprīkojuma pārbaudes 1C joprojām palēninās

Mums ir mazs uzņēmums, 7 cilvēki, un 1C ir lēns. Sazinājāmies ar speciālistiem, un viņi teica, ka mūs glābs tikai klienta-servera opcija. Bet mums šāds risinājums nav pieņemams, tas ir pārāk dārgi!

Veiciet regulāro apkopi datu bāzē*:

1. Palaidiet datu bāzi konfiguratora režīmā.

2. Galvenajā izvēlnē atlasiet "Administrēšana" un tajā - "Pārbaude un korekcija".

3. Atzīmējiet visas rūtiņas, kā parādīts attēlā. Noklikšķiniet uz Palaist.

*Šī procedūra var ilgt no 15 minūtēm līdz stundai atkarībā no datu bāzes lieluma un datora īpašībām.

Ja tas nepalīdz, mēs izveidojam klienta-servera savienojumu, taču bez papildu ieguldījumiem aparatūrā un programmatūrā:

1. Izvēlieties vismazāk noslogoto stacionāro datoru birojā (nevis piezīmjdatoru): tam jābūt vismaz 4 GB RAM un tīkla savienojumam vismaz 100 MB/sek.

2. Aktivizējiet tajā IIS (interneta informācijas serveri). Priekš šī:

3. Publicējiet savu datu bāzi šajā datorā. ITS ir pieejams materiāls par šo tēmu vai sazinieties ar atbalsta speciālistu.

4. Lietotāju datoros konfigurējiet piekļuvi datubāzei, izmantojot plāno klientu. Priekš šī:

Atveriet 1C palaišanas logu.

Izvēlieties savu darba bāzi. Šeit tā ir “Jūsu bāze”. Noklikšķiniet uz "Rediģēt". Iestatiet slēdzi pozīcijā “Tīmekļa serverī”, zem tā esošajā rindā norādiet tā servera nosaukumu vai IP adresi, kurā tika aktivizēts IIS, un nosaukumu, ar kuru datubāze tika publicēta. Noklikšķiniet uz "Tālāk".

Iestatiet slēdzi "Pamata starta režīms" uz režīmu "Thin Client". Noklikšķiniet uz "Gatavs".

Mums ir diezgan liels uzņēmums, bet ne pārāk liels, apmēram 50–60 cilvēki Mēs izmantojam klienta-servera iespēju, bet 1C ir šausmīgi lēns.

Šajā gadījumā ir ieteicams sadalīt 1C serveri un DBVS serveri divos dažādos serveros. Atdalot noteikti atceries: ja tie palika tajā pašā fiziskajā serverī, kurš tika vienkārši virtualizēts, tad šo serveru diskiem ir jābūt atšķirīgiem – fiziski atšķirīgiem! Noteikti iestatiet arī ikdienas uzdevumus DBVS serverī, kad runa ir par MS SQL (sīkāka informācija par to ir aprakstīta ITS vietnē)

Mums ir diezgan liels uzņēmums, vairāk nekā 100 lietotāju. Viss ir konfigurēts saskaņā ar 1C ieteikumiem šai opcijai, taču, apstrādājot dažus dokumentus, 1C darbojas ļoti lēni, un dažreiz rodas bloķēšanas kļūda. Varbūt veikt bāzes apkopojumu?

Līdzīga situācija veidojas ļoti specifiska uzkrāšanas vai uzskaites reģistra (bet biežāk - uzkrāšanas) lieluma dēļ, sakarā ar to, ka reģistrs vai nu “aizveras” pavisam, t.i. ir ienākošās kustības, bet plūsmas kustības nav, vai arī mērījumu skaits, pēc kuriem aprēķina reģistra atlikumus, ir ļoti liels. Var būt pat divu iepriekšējo iemeslu kombinācija. Kā noteikt, kurš reģistrs visu sabojā?

Mēs ierakstām laiku, kad dokumenti tiek apstrādāti lēni, vai laiku un lietotāju, kuram ir bloķēšanas kļūda.

Atveriet reģistrācijas žurnālu.

Mēs atrodam mums vajadzīgo dokumentu īstajā laikā pareizajam lietotājam ar notikuma veidu “Data.Post”.

Mēs skatāmies uz visu izpildes bloku, līdz darījums tiek atcelts, ja ir bijusi bloķēšanas kļūda, vai meklējam visilgākās izmaiņas (laiks no iepriekšējā ieraksta ir vairāk nekā minūte).

Pēc tam mēs pieņemam lēmumu, paturot prātā, ka šī konkrētā reģistra sabrukšana jebkurā gadījumā ir lētāka nekā visa datubāze.

Mēs esam ļoti liels uzņēmums, vairāk nekā 1000 lietotāju, tūkstošiem dokumentu dienā, savs IT departaments, milzīgs serveru parks, vairākkārt esam optimizējuši vaicājumus, bet 1C ir lēns. Acīmredzot esam pārauguši 1C, un mums vajag kaut ko jaudīgāku.

Lielākajā daļā šādu gadījumu palēninās nevis 1C, bet gan izmantotā risinājuma arhitektūra. Izdarot izvēli par labu jauna programma biznesam atcerieties, ka biznesa procesu ierakstīšana programmā ir lētāka un vienkāršāka nekā to konvertēšana uz dažām, īpaši ļoti dārgām programmām. Tikai 1C nodrošina šo iespēju. Tāpēc labāk ir uzdot jautājumu: “Kā labot situāciju? Kā var likt 1C “lidot” šādos apjomos?” Īsi apskatīsim vairākas ārstēšanas iespējas:

Izmantojiet paralēlās un asinhronās programmēšanas tehnoloģijas, ko atbalsta 1C ( fona darbi un vaicājumi cilpā).
Izstrādājot risinājuma arhitektūru, izvairieties no uzkrāšanas reģistru un uzskaites reģistru izmantošanas visvairāk vājajās vietās.
Veidojot datu struktūru (akumulācijas un/vai informācijas reģistrus), ievērojiet noteikumu: "Ātrākā rakstīšanas un lasīšanas tabula ir tabula ar vienu kolonnu." Par ko mēs runājam par, tas kļūs skaidrāks, ja paskatīsities uz tipisko RAUZ mehānismu.
Lai apstrādātu lielus datu apjomus, izmantojiet papildu klasterus, kur ir savienota viena un tā pati datu bāze (bet nekādā gadījumā to nevajadzētu darīt interaktīvā darba laikā!!!). Tas ļaus jums apiet standarta 1C slēdzenes, kas ļaus strādāt ar datu bāzi gandrīz tādā pašā ātrumā kā strādājot tieši ar SQL rīkiem.

Ir vērts atzīmēt, ka 1C optimizācija holdingiem un lieliem uzņēmumiem ir atsevišķa tēma lielisks raksts, tāpēc sekojiet līdzi atjauninātajiem materiāliem mūsu vietnē.

2. Programmas iespējas. Bieži vien pat ar optimāliem iestatījumiem 1C darbojas ļoti lēni. Īpaši strauji veiktspēja krītas, ja vienlaikus ar datu bāzi strādājošo skaits pārsniedz 4-5 lietotājus.

Kas jūs esat uzņēmumā?

Risinājums lēns darbs 1C ir atkarīgs no tā, kas jūs esat uzņēmumā. Ja esat tehniķis, lasiet tālāk. Ja esat direktors vai grāmatvedis, izmantojiet īpašo saiti ↓

Tīkla joslas platums

Ar vienu informācijas bāzi (IS) parasti strādā nevis viens, bet vairāki lietotāji. Tajā pašā laikā notiek pastāvīga datu apmaiņa starp datoru, kurā ir instalēts 1C klients, un datoru, kurā atrodas informācijas drošība. Šo datu apjoms ir diezgan ievērojams. Bieži rodas situācija, kad vietējais tīkls, kas darbojas ar ātrumu 100 Mbit/s, kas ir visizplatītākais ātrums, vienkārši nevar tikt galā ar slodzi. Un atkal lietotājs sūdzas par programmas lēnu darbību.

Katrs no šiem faktoriem atsevišķi jau būtiski samazina programmas ātrumu, bet nepatīkamākais ir tas, ka parasti šīs lietas summējas.

Tagad, izmantojot piemēru, aplūkosim vairākus zema 1C darbības ātruma problēmas un to izmaksu risinājumus lokālais tīkls no 10 vidējiem datoriem.

Risinājums viens. Infrastruktūras modernizācija

Tas, iespējams, ir visredzamākais risinājums. Aprēķināsim tā minimālās izmaksas.

Katram datoram ir nepieciešams vismaz 2 GB RAM, kas vidēji maksā 1500 rubļu, LAN karte ar atbalstu ātrumam 1 Gbit/s, maksā apmēram 700 rubļu. Turklāt jums būs nepieciešams vismaz 1 maršrutētājs, kas atbalsta ātrumu 1 Gbit/s, kas maksās aptuveni 4000 rubļu. Kopējās izmaksas - 26 000 rubļu par aprīkojumu, neskaitot darbu.

Principā ātrums var ievērojami palielināties, tomēr tagad vairs nav iespējams iegādāties lētus datorus birojam. Turklāt, šo lēmumu nav piemērojams tiem, kas izmanto Wi-Fi vai vēlas strādāt, izmantojot internetu - viņu gadījumā tīkla ātrums var būt desmitiem reižu mazāks. Rodas doma: "Vai nav iespējams visu programmu ieviest vienā jaudīgā serverī, lai lietotāja dators nepiedalītos sarežģītos aprēķinos, bet vienkārši kalpotu attēla pārsūtīšanai?" Tad jūs varat strādāt pat ļoti vājos datoros, pat tīklos ar mazu joslas platumu. Protams, šādi risinājumi pastāv.

Otrais risinājums. Termināļa serveris

Ieguva lielu popularitāti 1C 7 laikos. Ieviests serverī Windows versijas un lieliski tiek galā ar mūsu uzdevumu. Tomēr tam ir savas nepilnības, proti, licenču izmaksas.

Viņa pati operētājsistēma maksās aptuveni 40 000 rubļu. Papildus tam mums visiem, kas plāno strādāt 1C, būs nepieciešama Windows Server CAL licence, kas maksā aptuveni 1700 rubļu, un Windows Remote Desktop Services CAL licence, kas maksā aptuveni 5900 rubļu.

Aprēķinot izmaksas 10 datoru tīklam, mēs iegūstam 116 000 rubļu. tikai par vienu licenci. Pievienojiet tam paša servera izmaksas (vismaz 40 000 rubļu) un ieviešanas darbu izmaksas, taču pat bez tā licenču cena izrādījās iespaidīga.

Trešais risinājums. Pakalpojums 1C Enterprise

1C šai problēmai ir izstrādājis savu risinājumu, kas var ievērojami palielināt programmas ātrumu. Bet šeit ir arī nianse.

Fakts ir tāds, ka šāda risinājuma izmaksas svārstās no 50 000 līdz 80 000 rubļu atkarībā no izdevuma. Uzņēmumam ar līdz 15 lietotājiem tas izrādās diezgan dārgi. Lielas cerības tika liktas uz “1C uzņēmuma miniserveri”, kas, pēc 1C uzņēmuma domām, ir paredzēts maziem uzņēmumiem un maksā aptuveni 10 000 - 15 000 rubļu.

Taču, kad tas nonāca pārdošanā, šis produkts sagādāja lielu vilšanos. Fakts ir tāds maksimālā summa Bija tikai 5 lietotāji, ar kuriem varēja izmantot mini serveri.

Kā forumā rakstīja viens 1C programmētājs: “Joprojām nav skaidrs, kāpēc 1C izvēlējās tieši 5 savienojumus! Problēmas sākas tikai ar 4 lietotājiem, bet ar pieciem tas viss beidzas. Ja gribi pieslēgt kādu sesto, maksā vēl 50 tūkstošus Mēs varētu veikt vismaz 10 pieslēgumus...”

Protams, savu patērētāju atrada arī miniserveris. Taču uzņēmumiem, kuros ar 1C strādā 5 un vairāk cilvēku, vienkāršs un lēts risinājums nav parādījies.

Papildus iepriekš aprakstītajām programmas paātrināšanas metodēm ir vēl viena, kas ir ideāli piemērota segmentam no 5 līdz 15 lietotājiem, proti, tīmekļa piekļuve 1C faila režīmā.

Ceturtais risinājums. Tīmekļa piekļuve 1C faila režīmā

Darbības princips ir šāds: datorā tiek instalēta papildu tīmekļa servera loma, kurā tiek publicēta informācijas drošība.

Protams, tam jābūt vai nu visvairāk jaudīgs dators tīklā vai atsevišķā šai lomai paredzētajā mašīnā. Pēc tam jūs varat strādāt ar 1C tīmekļa servera režīmā. Visas smagās darbības tiks veiktas servera pusē, un tīklā pārraidītā trafika, kā arī klienta datora slodze tiks samazināta līdz minimumam.

Tādējādi pat ļoti vājas mašīnas var izmantot darbam 1C, un tīkla joslas platums nekļūst kritisks. Mūsu testi ir parādījuši, ka varat strādāt ērti Mobilais internets lētā planšetdatorā, neizjūtot nekādu diskomfortu.

Šī opcija darbības ātruma ziņā ir zemāka par uzņēmuma 1C serveri, taču šī atšķirība ir praktiski neredzama līdz 15-20 lietotājiem. Starp citu, tīmekļa servera ieviešanai varat izmantot IIS (operētājsistēmai Windows) un Apache (operētājsistēmai Linux), un abi šie risinājumi ir bezmaksas!

Neskatoties uz acīmredzamajām priekšrocībām, šī metode 1C darbības optimizācija nav guvusi lielu popularitāti.

Es nevaru droši pateikt, bet, visticamāk, tas ir divu iemeslu dēļ:

Diezgan vājš apraksts tehnisko dokumentāciju
Atrodas sistēmas administratora un 1C programmētāja atbildības krustpunktā

Parasti, ja pie sistēmas administratora vēršas ar maza ātruma problēmu, viņš iesaka jaunināt infrastruktūru vai termināļa serveri, ja tiek sazināties ar 1C speciālistu, viņam tiek piedāvāts 1C uzņēmuma serveris. Tātad, ja jūsu uzņēmumā par infrastruktūru atbildīgais speciālists un speciālists, kas atbildīgs par 1C, strādā “roku rokā”, tad varat droši izmantot risinājumu, kura pamatā ir tīmekļa serveris.

Paātrināsim 1C. Attālināti, ātri un bez jūsu līdzdalības

Mēs zinām, kā paātrināt 1Ski, netraucējot klientu. Mēs iedziļināmies problēmā, izdarām savu darbu un dodamies prom. Ja vēlaties, lai programma darbotos normāli, sazinieties ar mums. Mēs to izdomāsim.

Atstājiet pieprasījumu un saņemiet bezmaksas konsultāciju par programmas paātrināšanu.

IN Nesen Lietotāji un administratori arvien biežāk sāk sūdzēties, ka jaunās 1C konfigurācijas, kas izstrādātas, pamatojoties uz pārvaldītu lietojumprogrammu, ir lēnas, dažos gadījumos nepieņemami lēnas. Ir skaidrs, ka jaunās konfigurācijas satur jaunas funkcijas un iespējas, un tāpēc tās prasa vairāk resursu, taču lielākā daļa lietotāju nesaprot, kas galvenokārt ietekmē 1C darbību faila režīmā. Mēģināsim labot šo plaisu.

Mēs jau esam pieskārušies diska apakšsistēmas veiktspējas ietekmei uz 1C ātrumu, taču šis pētījums attiecās uz lietojumprogrammas lokālu izmantošanu atsevišķā datorā vai termināļa serverī. Tajā pašā laikā lielākā daļa mazo implementāciju ietver darbu ar failu datu bāzi tīklā, kur viens no lietotāja datoriem tiek izmantots kā serveris, vai speciālu failu serveri, kura pamatā ir parasts, visbiežāk arī lēts dators.

Neliels pētījums par 1C krievu valodas resursiem parādīja, ka no šīs problēmas tiek cītīgi izvairīties, ja rodas problēmas, parasti ieteicams pārslēgties uz klienta-servera vai termināļa režīmu. Gandrīz vispārpieņemts ir arī tas, ka pārvaldītās lietojumprogrammas konfigurācijas darbojas daudz lēnāk nekā parasti. Parasti argumenti ir “dzelzs”: “Grāmatvedība 2.0 tikko lidoja, un “troika” tik tikko kustējās, protams, šajos vārdos ir daļa patiesības, tāpēc mēģināsim to izdomāt.

Resursu patēriņš, pirmais skatiens

Testēšanai mēs paņēmām divas virtuālās mašīnas, kurās darbojas attiecīgi Windows Server 2012 R2 un Windows 8.1, piešķirot tām 2 resursdatora Core i5-4670 kodolus un 2 GB RAM, kas aptuveni atbilst vidējai biroja mašīnai. Serveris tika ievietots RAID 0 masīvā no diviem, un klients tika novietots līdzīgā vispārējas nozīmes disku masīvā.

Pirmā lieta, kas piesaista uzmanību, ir palielinātais Troikas informācijas bāzes apjoms, kas ir ievērojami pieaudzis, kā arī daudz lielāka apetīte pēc RAM:

Tīkls

Kas notiek, kad tīklā palaižat 1C failu datu bāzi? Klients pagaidu mapēs lejupielādē diezgan lielu informācijas daudzumu, it īpaši, ja tas ir pirmais, “aukstais” sākums. Paredzams, ka pie 100 Mbit/s mēs darbosimies pret kanāla platumu, un lejupielāde var aizņemt ievērojamu laiku, mūsu gadījumā apmēram 40 sekundes (grafikas dalīšanas izmaksas ir 4 sekundes).

Mēs pārbaudījām arī tīkla ātruma ietekmi uz darbību smagos režīmos, piemēram, grupu pārsūtīšanas laikā. Rezultātu izsaka arī relatīvās vērtībās:

Lai novērtētu tīkla ātruma ietekmi uz ikdienas darbu, izmantojām Veiktspējas mērīšana, veicot iepriekš noteiktu darbību secību katrā datu bāzē.

Tātad, kāpēc 1C ir lēns? Mēs to izskatīsim sīkāk.

Servera diska apakšsistēma un SSD

Sāksim ar datu bāzes ielādes ātrumu.

Pāriesim pie pārtaisīšanas:

Ikdienas uzdevumos attēls ir līdzīgs:

Klienta diska apakšsistēma un SSD

Mēs analizējām SSD ietekmi uz lokāli instalētā 1C darbības ātrumu, liela daļa no teiktā attiecas arī uz darbu tīkla režīmā. Patiešām, 1C diezgan aktīvi izmanto diska resursus, tostarp fona un ikdienas uzdevumiem. Zemāk esošajā attēlā varat redzēt, kā Accounting 3.0 diezgan aktīvi piekļūst diskam apmēram 40 sekundes pēc ielādes.

Taču tajā pašā laikā jāapzinās, ka darbstacijai, kurā notiek aktīvs darbs ar vienu vai divām informācijas datu bāzēm, parastā sērijveidā ražotā HDD veiktspējas resursi ir pilnīgi pietiekami. Iegādājoties SSD, dažus procesus var paātrināt, taču ikdienas darbā jūs nepamanīsiet radikālu paātrinājumu, jo, piemēram, lejupielādi ierobežos tīkla joslas platums.

Lēns cietais disks var palēnināt dažas darbības, bet pats par sevi nevar izraisīt programmas palēnināšanos.

RAM

Mēs samazinājām sistēmas atmiņu līdz 1 GB un iedarbinājām divas informācijas datu bāzes.

No pirmā acu uzmetiena viss nav tik slikti, programma ir samazinājusi apetīti un labi iekļaujas pieejamajā atmiņā, taču neaizmirsīsim, ka nepieciešamība pēc operatīvajiem datiem nav mainījusies, kur tad tā palika? Izmesti diskā, kešatmiņā, mijmaiņā utt., šīs operācijas būtība ir tāda, ka šobrīd nevajadzīgie dati tiek nosūtīti no ātrās RAM, kuras apjoms nav pietiekams, uz lēnu diska atmiņu.

Kur tas ved? Apskatīsim, kā tiek izmantoti sistēmas resursi smagās operācijās, piemēram, uzsāksim grupas pārsūtīšanu uzreiz divās datu bāzēs. Vispirms sistēmā ar 2 GB RAM:

Kā redzam, sistēma aktīvi izmanto tīklu datu saņemšanai, un procesors to apstrādei ir niecīgs, tas ik pa laikam palielinās, bet nav ierobežojošs faktors;

Tagad samazināsim atmiņu līdz 1 GB:

RAM trūkums ir galvenais iemesls, kāpēc darbs ar jaunām 1C konfigurācijām izrādās neērts. Konfigurācijas ar 2 GB atmiņu jāuzskata par minimāli piemērotām. Tajā pašā laikā paturiet prātā, ka mūsu gadījumā tika izveidoti “siltumnīcas” apstākļi: tīra sistēma, darbojās tikai 1C un uzdevumu pārvaldnieks. Reālajā dzīvē darba datorā parasti ir atvērta pārlūkprogramma, biroja komplekts, darbojas antivīruss utt. utt., tāpēc ņemiet vērā, ka vienai datubāzei ir nepieciešami 500 MB, kā arī nedaudz rezerves, lai smagu operāciju laikā nesaskaras ar atmiņas trūkumu un strauju produktivitātes samazināšanos.

Procesors

Rezultāts izrādījās diezgan interesants un negaidīts: jaudīgāks procesors diezgan efektīvi uzņēmās slodzi, kad trūka resursu, pārējā laikā nedodot nekādu taustāmu labumu. 1C Enterprise (faila režīmā) diez vai var saukt par lietojumprogrammu, kas aktīvi izmanto procesora resursus, tā ir diezgan mazprasīga. Un sarežģītos apstākļos procesoru noslogo ne tik daudz pašas aplikācijas datu aprēķināšana, bet pieskaitāmo izmaksu apkalpošana: papildu ievades/izvades operācijas utt.

secinājumus

Tad jums vajadzētu pievērst uzmanību diskdzinim, visticamāk, ka SSD iegāde nebūs labs ieguldījums, taču diska nomaiņa pret modernāku būtu laba ideja. Atšķirību starp cieto disku paaudzēm var novērtēt pēc šāda materiāla: .

Un visbeidzot procesors. Ātrāks modelis, protams, nebūs lieks, taču nav jēgas palielināt tā veiktspēju, ja vien šis dators netiek izmantots smagām darbībām: grupu apstrāde, smagas atskaites, mēneša beigu slēgšana utt.

Mēs ceram, ka šis materiāls palīdzēs jums ātri saprast jautājumu “kāpēc 1C ir lēns” un atrisināt to visefektīvāk un bez papildu izmaksām.