Lietotāji bieži sūdzas, ka “1C 8.3 ir lēns”: dokumentu veidlapas atveras lēni, dokumentu apstrāde aizņem ilgu laiku, programma tiek startēta, pārskatu ģenerēšana prasa ilgu laiku utt.

Turklāt šādas "kļūmes" var rasties dažādās programmās:

Iemesli var būt dažādi. Tas nav atjaunoti dokumenti, vājš dators vai serveris, 1C serveris ir nepareizi konfigurēts.

Šajā rakstā es vēlos aplūkot vienu no vienkāršākajiem un visizplatītākajiem iemesliem lēns darbs programmas – . Šī instrukcija būs aktuāla 1-2 lietotāju failu datu bāzu lietotājiem, kur nav konkurences par resursiem.

Ja jūs interesē nopietnāka klienta-servera opciju optimizācija sistēmas darbībai, apmeklējiet vietnes sadaļu.

Kur ir 1C 8.3 ieplānotie uzdevumi?

Pirms man bija laiks ielādēt programmu, 1C izpildīja daudzas fona darbi. Tos var apskatīt, atverot izvēlni “Administrēšana” un pēc tam uz “Atbalsts un apkope”:

Saņemiet 267 video nodarbības 1C bez maksas:

Šādi izskatās logs ar pabeigtiem uzdevumiem:

Un tā pilns saraksts visiem rutīnas uzdevumi, kas tiek palaistas:

Starp šiem uzdevumiem ir, piemēram, ““, dažādu klasifikatoru ielāde, programmas versijas atbilstības pārbaude utt. Piemēram, man nav jēgas gandrīz visiem šiem uzdevumiem. Es neveicu valūtu uzskaiti, es pats kontrolēju versijas un ielādēju klasifikatorus pēc vajadzības.

Attiecīgi manās (un vairumā gadījumu jūsu) interesēs ir atspējot nevajadzīgus uzdevumus.

Plānoto un fona uzdevumu atspējošana 1C 8.3

1) apskatiet atmiņas apjomu, ko rphost atvēl 1C serverī. Ja jums ir servera x32 versija, process var izmantot ne vairāk kā 1,75 GB RAM
Ja nav pietiekami daudz atmiņas, serveris nevar pieņemt jaunus savienojumus vai uzkaras, kad pašreizējā sesija prasa papildu atmiņu
www.viva64.com/ru/k/0036
2) Apskatiet “Darba servera iestatījumus” iestatījumi var būt nepareizi. Man bija šī problēma, un serveris turpināja sastingt. Mani iestatījumi ir pievienoti. Serverim ir atvēlēti 11 GB.
3) Var rasties problēmas ar Postgressql iestatīšanu.

Norādiet sava servera raksturlielumus, datu bāzes izmērus, Postgressql konfigurācijas. Grūti pateikt bez informācijas.

Mana PostgreSQL konfigurācija: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Šī konfigurācija ir atlasīta pieejamajam RAM apjomam.
PostgreSQL instalēta operētājsistēmā Linux, 3 GB RAM, 3 CPU kodoli.
Serveris 1C8: 11 GB RAM, 5 CPU kodoli
4 datu bāzes, katra aptuveni 1 GB (augšupielādētas dt)

Norādiet visas sava servera īpašības: 1C8 serveris un datu bāze, fiziskais vai virtuālais, operētājsistēma, RAM apjoms katrā serverī, kāds CPU, cik daudz RAM aizņem rphost procesi, cik to ir? Vai izmantojat RAID masīvu?

Iepriekš pats izmantoju PostgreSQL, taču procesa gaitā saskāros ar dažām problēmām, palaistot datubāzi uz PostgreSQL, un nesen pārgāju uz MS SQL.

Jūsu serveris nav slikts šīm datu bāzēm. Lai izmantotu PostgreSQL, jums ir ļoti labi jāizprot tā konfigurācija. Ja datu bāzes ir mazas, daudzas konfigurācijas kļūdas tiek piedotas. Kad mēs tikko sākām ieviest 1C + PostgreSQL, mums arī bija ļoti bieži problēmas ar datu bāzes darbību (bieži bija sasalšanas, tā strādāja lēni). PostgreSQL labāk izmantot operētājsistēmā Linux, nevis Windows. Es pats neesmu datu bāzes speciālists, lai izveidotu datu bāzes serveri, mēs nolīgām speciālistu no 1Sbit un viņš to uzstādīja un pēc tam nebija nekādu problēmu.

Padoms:
Jums ir lielas datu bāzes, neskopojieties, nolīgt datu bāzes speciālistu, kas to var iestatīt jūsu vietā. Viens cilvēks nevar būt eksperts visā.

1) cik sen tu esi pārbaudījis pašu datubāzi un pārindeksējis to? VAKUUMS un REINDEKSS
2) cik sen jūs testējāt un labojāt datubāzi, izmantojot 1C rīkus?
3) vai datu bāzes žurnālfails ir ievietots atsevišķā HDD?
4) vai cietais disks ir ļoti noslogots?

Apsveriet iespēju pārslēgties uz MS SQL, lai to izmantotu praktiski bez konfigurācijas. Atšķirībā no PostgreSQL, MS Sql ir gatavs darbam, taču PostgreSQL ir jākonfigurē.

Ja ir kādi jautājumi, rakstiet, varbūt varu kaut ko palīdzēt Skype: tisartisar

Nolīgstiet datu bāzes iestatīšanas speciālistu

Kāpēc mēs pārgājām uz MS SQL:
Mēs izmantojam UT konfigurāciju un, slēdzot mēnesi, dažkārt radās kļūdas, kuras nevarēja novērst. Ja pārsūtījāt datu bāzi uz failu režīmu un sākāt slēgt mēnesi, tad viss aizvērās normāli, tā pati datu bāze tika ielādēta PostgreSQL serveris Aprēķinot izmaksas, radās kļūdas. Toreiz peldošo kļūdu dēļ slēgšanas mēnešos atpalikām par pusgadu. Mēs izveidojām testa datubāzi MS SQL, un mēnesis, kuru nevarēja aizvērt PostgreSQL uz MS SQL, tika slēgts. Tāpat PostgreSQL nedarbojas pareizi cenu noapaļošana cenrādī. Faktiski 1C palaišana uz PostgreSQL tiek atbalstīta, taču joprojām ir ieteicams izmantot MS SQL.
Sakarā ar to tika nolemts pāriet uz MS SQL, jo... darbības stabilitāte 1C ir dārgāka.

Es priecājos, ka varu palīdzēt, lūdzu, sazinieties ar mani, ja jums ir kādi jautājumi vai problēmas.

1) cik daudz atmiņas ir atvēlēts MS SQL serverim? tas ir konfigurēts pašā MS SQL serverī.
2) Regulāri pārbaudiet datu bāzi, izmantojot 1C
3) raksts par dublēšanas un apkopes iestatīšanu. Tas ir svarīgi, un tas jādara regulāri. Es to daru katru dienu. Apskatiet visas 3 rokasgrāmatas daļas.

IN pēdējā laikā 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 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 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

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. RAM, kas aptuveni atbilst vidējai biroja mašīnai. Serveris tika novietots uz RAID 0 divu masīvu, un klients tika novietots līdzīgā universālo 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.

Net

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, pamatojoties uz lētu 100 Mbit/s aprīkojumu, 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 startēš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. Sagaidāms, ka pie 100 Mbit/s mēs sasniegsim kanāla platumu, un lejupielāde var aizņemt ievērojamu laiku, mūsu gadījumā apmēram 40 sekundes (grafikas sadalīš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 vērtība 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ā.

Pēc veiktajām pārbaudēm kļūst skaidrs, ka tīkls nav šķērslis jaunajā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, izmantojot līdzīgu metodi, tīkla savienojums visur 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

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ēni cietais disks 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. Jau 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 palaidā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 šobrīd dati tiek nosūtīti no ātras RAM, kuras apjoms nav pietiekams, lai palēninātu diska atmiņu.

Pie kā tas novedīs? 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 radīti “siltumnīcas” apstākļi: tīra sistēma, darbojās tikai 1C un uzdevumu pārvaldnieks. IN īstā 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.

CPU

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ādas taustāmas priekšrocības. 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ājumi

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 vajadzētu pievērst uzmanību diskdzinim, visticamāk, ka SSD iegāde nebūs laba investīcija, 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: .

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.

• Tagi:

Lūdzu, iespējojiet JavaScript, lai skatītu

Bloķēšanas ietekme uz 1C:Enterprise 8 veiktspēju

Gilev komanda jau daudzus gadus nodarbojas ar veiktspējas problēmām un ir veiksmīgi atrisinājusi, cita starpā, jautājumus par gaidīšanas novēršanu uz slēdzenēm un strupceļiem.

Tālāk mēs aprakstīsim savu pieredzi šo problēmu risināšanā.

Bloķēšanas problēmu noteikšana 1C

Veiktspējas problēmas vairāku spēlētāju režīmā ne vienmēr ir saistītas ar sliktu kodu vai sliktu aparatūru. Pirmkārt, mums ir jāatbild uz jautājumu – kādas darbības problēmas pastāv un kas tās izraisa?

Nav iespējams manuāli izsekot simtiem lietotāju darbībām, jums ir nepieciešams rīks, kas automatizē šādas informācijas vākšanu.

Instrumentu ir daudz, taču gandrīz visiem tiem ir viens ļoti būtisks trūkums – cena.

Bet ir izeja - mēs izvēlamies

Mēs izmeklēsim problēmu MS SQL Server, tāpēc mums būs nepieciešami šādi pakalpojumi no šīs kopas:

1. Garo pieprasījumu uzraudzība un analīze(vairāk par iestatīšanu lasiet šeit) – nepieciešams, lai novērtētu, vai apakšd. ir ilgstošas ​​darbības.

Faktiski viņu klātbūtnes fakts ļauj teikt, ka pastāv veiktspējas problēmas, un problēmas slēpjas 1C konfigurācijas koda rindās, kuras pakalpojums sarindos pēc svarīguma. Vispirms ir jārisina problēmas, kas atrodas saraksta augšgalā. Šādi problemātisko līniju risinājumi dos vislielāko efektu, t.i. būs vislielākais ieguvums un ieguvums sistēmas lietotājiem.

(vairāk lasiet šeit) ļaus izvērtēt, vai ilgo (ilgo) pieprasījumu laiku tiešām izraisa gaidīšana uz slēdzenēm vai ir kādi citi iemesli (neoptimāls kods, pārslogota aparatūra utt.) Pakalpojums parādīs iemeslu pieprasījuma gaidīšana, proti, resurss, kas tika bloķēts un kurš viņu bloķēja. Tie. mēs sapratīsim bloķēšanas problēmu klātbūtni un to cēloņus.

3. Savstarpējo slēdzeņu analīze 1C un MS SQL serverī(vairāk par uzstādīšanu lasiet šeit) - ļaus mums novērtēt vairāk sarežģītas situācijas ar resursu gaidīšanu, kad vairāki dalībnieki jau ir paspējuši “noķert” kādus resursus bloķējot un tagad ir spiesti gaidīt viens otru tādēļ, ka nevar atbrīvot aizņemtos resursus, kamēr nav pabeigta citu kaimiņu bloķēto resursu uztveršana.

Kopumā šādu sarežģītu situāciju nevar atrisināt manuāli, šāds pakalpojums ir vajadzīgs.

4. Iekārtas slodzes kontrole(vairāk par uzstādīšanu lasiet šeit) palīdz mums atbildēt uz jautājumiem – cik lietotāju ir sistēmā, vai tiem ir slēdzenes, cik ir slēdzenes, vai aparatūra var tikt galā ar slodzi?

Pakalpojumu iestatīšana ir ļoti vienkārša, taču pat tad, ja jums joprojām ir jautājumi, tie ir!

Izmantojot iepriekš uzskaitītos rīkus, mums ir objektīva informācija par sistēmas veiktspēju. Tas ļauj pareizi novērtēt situāciju un ierosināt atbilstošus pasākumus.

Faktiski mēs saņemam informāciju par visām veiktspējas problēmām un varam precīzi atbildēt uz tādiem jautājumiem kā "cik problēmu ir sistēmā", "kur tieši tās rodas", "katra problēma ar kādu precīzu biežumu rodas", "kuras problēmas ir nozīmīgi un maznozīmīgi”. Tie. mēs redzam visus priekšnoteikumus, kas veidoja problēmas cēloni.

Pakalpojumi ļauj būtiski uzlabot izpratni par apstākļiem, kādos rodas problēmas, neliekot manuāli iedziļināties tādās lietās kā informācijas bāzes datu uzglabāšanas struktūra DBVS līmenī, bloķēšanas mehānisms u.c.

Rezultātā mēs iegūstam priekšstatu par veiktspēju, kas tiek izmērīta

— pieprasījuma laiks (protams, problemātiskos pieprasījumus sarindojot pēc svara (pieprasījuma laiks pēc šī pieprasījuma zvanu skaita);

— slēdzeņu gaidīšanas laiks;

Tātad, mēs uzsākām pakalpojumu Analīze par cerībām uz bloķēšanu

Augšējā tabulā pakalpojums parāda bloķēšanas “upuru” sarakstu, ņemot vērā “cerību smaguma” kopējo svaru.

Apakšējā tabulā katram upurim ir apskatīts viens vai vairāki dalībnieki “cīņā par ļoti konkurētspējīgu resursu”, kur radās bloķēšanas gaidīšana.

Apakšējā tabulā atveriet informāciju par kādu no noildzes notikumiem. Piemēram, kā attēlā.

Izceļot līniju ar “vaininieku”, mēs redzēsim, ka sašaurinājums bija tabula _Reference64, un radās problēma klasterizētajā indeksā ar “nezināmo” apgabalu. Iespējams, nākotnē mēs to pārdēvēsim par “tabulu”, jo patiesībā šī uzvedība ir raksturīga bloķēšanas zonas palielināšanai/paplašināšanai.

Līnija ar “upuri” parāda, kurš kods bija situācijas ķīlnieks un nevarēja bloķēt visu, tikai rindu “pēc atslēgas” (minimālais datu bloķēšanas apgabals šajā tabulā).

Šo problēmu var atrisināt “pareizi” un “viegli”.

Autors pareizais ceļš to ir grūtāk izdarīt - jums faktiski ir jāpārraksta kods, samazinot šādu situāciju rašanās iespējamību.

Viens no faktoriem, lai cik dīvaini tas neizklausītos, ir ilguma samazināšanās.

Jūs varat samazināt darījuma ilgumu:

1. algoritma pārrakstīšana

2. pārrakstot vaicājumu (ātrāks vaicājums samazina bloķēšanas iespējamību sarežģītās transakcijās tabulās, kuras dažkārt pat var nebūt vaicājumā!)

2.1 pievienojot trūkstošo pārklājuma indeksu (dažreiz indekss ne tikai paātrina vaicājumu, bet arī samazina datu lasīšanas apgabalu, kas samazina bloķēšanas iespējamību)

3. Darījumā apstrādāto datu apjoma samazināšana (papildus lineārajam ātrumam atceramies arī bloķēšanas eskalāciju)

4. iekārtu veiktspējas palielināšana katrā plūsmā

Pieprasīt izpildes laiku

1) dažādi lietotāji var strādāt paralēli ar dažādiem datiem
2) dažādiem lietotājiem ir jāstrādā stingri secīgi ar vieniem un tiem pašiem datiem

Tomēr ir iespējams optimizēt slēdzeņu izmantošanu, tādējādi samazinot kopējo gaidīšanas laiku.

Kā darbojas bloķēšana (jums nav jāizlasa šī rindkopa)

Slēdzenes apstrādā īpašs SQL Server modulis — Lock Manager. Viņa uzdevumos ietilpst:

• slēdzeņu izveidošana un uzstādīšana;
• atbloķēšana;
• bloķēšanas eskalācija;
• slēdzenes saderības noteikšana;
• strupceļu novēršana un daudz kas cits.

Kad lietotājs pieprasa atjaunināt vai nolasīt datus, DBVS transakciju pārvaldnieks nodod kontroli DBVS bloķēšanas pārvaldniekam, lai noteiktu, vai pieprasītie resursi ir bloķēti un, ja jā, vai pieprasītā bloķēšana ir saderīga ar pašreizējo. Ja slēdzenes nav saderīgas, pašreizējā darījuma izpilde tiek aizkavēta līdz datu atbloķēšanai. Kad dati ir pieejami, slēdzenes pārvaldnieks iegūst pieprasīto slēdzeni un atdod kontroli transakciju pārvaldniekam.

Galvenais iemesls, kas samazina veiktspēju, ir bloķēšana

Bloķēšanas gaidīšana ir liela veiktspējas problēma vairāku spēlētāju režīmā. Un tas ir saprotams, jo tie palielina operāciju gaidīšanas laiku un līdz ar to arī reakcijas laiku. Vai var teikt, ka gaidīšana uz slēdzenēm nav pareiza un kļūda daudzlietotāju sistēmā? To nevar teikt, jo pats resursu bloķēšanas mehānisms nodrošina datu integritāti. Izmantojot bloķēšanas mehānismu, vienlaicīgi dati tiek RAKSTĪTI SEKCĪGI.

Atšķirība starp nepieciešamajām un nevajadzīgajām slēdzenēm

Ja lietotājs ziņo par kļūdu, kas gaida slēdzeni, tad no viņa viedokļa tā vienmēr ir kļūda, jo, piemēram, tas traucē viņa darbam - palielinās laiks, kas nepieciešams viņa darba pabeigšanai.

Pieredze liecina par vienkāršu noteikumu: ja vairāk nekā puse pieprasījuma izpildes laika patiešām gaida bloķētu resursu, tad jums ir jāskatās: varbūt kādu bloķēšanu var optimizēt un samazināt resursu bloķēšanas laiku.

Šeit, it kā nejauši, es ieviešu definīciju:

Gaidu uz bloka ir situācija, kas rodas, kad divi lietotāji vienlaikus mēģina iegūt vienus un tos pašus datus. Šajā gadījumā viens no šiem lietotājiem tiek bloķēts, tas ir, tam jāgaida līdz pirmā lietotāja darījuma beigām.

Darījums ir aprēķinu un operāciju kopums ar datiem (lielākā daļa spilgts piemērs— veicot dokumentu) veic kā vienotu veselumu. Ja netiek pabeigta kāda no darījuma darbībām, viss darījums tiek atcelts.

Tātad lietotāji vairāku lietotāju informācijas bāzēs bieži var sūdzēties, ka šo slēdzeņu dēļ nav iespējams strādāt, savukārt kodā patiesībā var būt slēdzenes, kas šajā vietā nav vajadzīgas (liekas).
Un arī konfigurācijas kodā tās pašas var nebūt, par tām var palasīt, piemēram, šeit http://kb.1c.ru/articleView.jsp?id=30 (raksts ir grāmatas fragments; P.S. Belousovs, A.V.Ostroverh "1C: Enterprise: no 8.0 līdz 8.1."). Es piedāvāju vienkāršotu veidu, kā izskaidrot atšķirības starp ieslēgtām slēdzenēm vienkāršs piemērs Tātad:

Savā konfigurācijā režīmā 1C:Uzņēmums izveidojiet divus identiskus rēķinus ar vienādu preču sastāvu. Taču noteikti norādiet dažādas saņemšanas noliktavas.
Publicēšanas apstrādes kodā jāpievieno rinda ar ekrānā redzamu ziņojumu (vai cits kods, kas var aizkavēt grāmatošanas apstrādes izpildi par 21 sekundi (bloķēšanas taimauts notiek pēc 20 sekundēm, ja parametri ir pēc noklusējuma)) .
Ievietojiet divus dokumentus.
Ja iestājas taimauts un loģiski, ka preces nonāk dažādās noliktavās, aplikācijā ir liekas slēdzenes. Biznesa loģikai (apsveriet veselo saprātu) šeit nevajadzētu būt nekādai bloķēšanai.
Ja tagad šajos divos rēķinos taisām identiskas noliktavas. Tad vienlaicīgas izpildes mēģinājuma rezultātā izveidotā bloķēšana novedīs pie NEPIECIEŠAMAS bloķēšanas un tas ir LABI!

Tie. Kamēr rēķins veic izmaiņas krājumu atlikumos, otram ir jāgaida.

Protams, pat šis vienkāršais piemērs rada daudz jautājumu. Piemēram, ja dokumenti ir no viena piegādātāja un parāds uz to “pārvietojas”. Un ja pārvietojas ne tikai atlikumi noliktavā, bet vairāki reģistri un dažāda veida dokumenti.
Bet vissvarīgākais jautājums ir: PĒC KĀDAS BIZNESA LOĢIKAS NEDRĪKST BLOĶĒT. Kurš un kur bloķēšanas kontekstā nosaka šo biznesa loģiku? Bet parunāsim par visu pēc kārtas.

Pārmērīgas slēdzenes ir nevajadzīgas slēdzenes, kas nav vajadzīgas no datu integritātes nodrošināšanas viedokļa un vienlaikus samazina sistēmas kopējo veiktspēju, palielinot kopējo dīkstāvi – gaidīšanu uz slēdzenēm.
Nepieciešamā bloķēšana notiek, kad divi lietotāji iegūst vienus un tos pašus resursus (datu objektus). Ja lietotāji strādā ar resursiem, kas nepārklājas, bet gaida bloķēšanu, bloķēšana tiek uzskatīta par lieku.

Saprotamākie atlaišanas bloķēšanas kritēriji ir:

1. Savstarpējās slēdzenes;

2. Bloķēšanas līmenis (laukums) ir augstāks nekā nepieciešams (kā īpašs gadījums palielinot bloķēšanas līmeni, tā saukto. eskalācija);

3. Bloķēšanas laiks ir garāks par bloķējošā objekta “reālās” lietošanas laiku.

Saņemot informāciju par problēmu grupējumiem 1C:Enterprise metadatu kontekstā, iesaku vispirms pievērst uzmanību šādiem objektiem:

• Konstantes
• Secība
• Grāmatvedības reģistri
• Uzkrāšanas reģistri
• Informācijas reģistri
• Aprēķinu reģistri

1) Vēl nesen bija labi zināms ieteikums neko nerakstīt konstantēs. Ārkārtējos gadījumos dariet to no viena lietotāja un tad atcerieties, ka, kamēr lietotājs “raksta” vienu konstanti, ne tikai šo, bet arī jebkuru citu konstanti, citi lietotāji “gaidīs”. Tāpēc darījumu apstrādē ir īpaši bīstami izmantot konstantes. Visu konstantu vērtības tiek saglabātas V viens resurss.

Attēlā parādīts SCP konfigurācijas konstantu fiziskais izvietojums MS SQL Server 2005 datu bāzes tabulā.

Tas nozīmē, ka vienas konstantes bloķēšana bloķēs visas konstantes. DBVS uzliek bloķēšanu VISAI vienai tabulas RINDAI, t.i. visām konstantēm.

Tomēr jaunākajos platformas izlaidumos konstantu glabāšana ir mainīta. Tagad katra konstante ir atsevišķa tabula. Neaizraujieties, taču, izveidojot tūkstošiem tabulu, jūs varat iegūt bloķēšanu galvenajā pamatnē.

Uzmanību, ja jūsu konfigurācija pastāv jau ilgu laiku, varat mainīt krātuves formātu, "pārstrukturējot" to sadaļā Konfiguratora pārbaude un labošana.

2) Atteikties izmantot Sequence metadatu objektu. Vismaz no kustībām operatīvā īstenošana, veikt neoperatīvu (papildu) procedūru laikā. Skatiet, kā tas tiek ieviests jaunākās versijas UPP.

3) Ja sistēma veic tiešsaistes kustību reģistrēšanu grāmatvedības reģistrā vairāku lietotāju režīmā, tad ieteicams:

• iespējot kopējo summu atdalīšanas režīmu šim reģistram;
• Operatīvā darba laikā neizmantojiet reģistra bilances kontroli.

4) Uzkrāšanas reģistrā gadījumos, kad nav nepieciešams iegūt “operatīvos” datus, var iespējot kopsummu dalīšanu, kas palielinās datu ierakstīšanas paralēlismu un kopumā paātrinās darbu. Uzmanīgi uzraugiet mērījumus, lai mērījumos varētu iegūt maksimāli detalizētus “atlikumus”.

5) Jūs varat atbrīvoties no dažām platformas radītajām liekajām slēdzenēm tikai ar . Konfigurāciju automātiskajā darbības režīmā platforma “uzņemas” bloķējošos resursus. Cena bez raizēm automātiskais režīms— bloķēšana ir iespējama indeksa diapazonu robežās, tukšas tabulas slēdzenes un slēdzenes eskalācija.

Šīs slēdzenes pilnībā pazūd no darījuma datiem. Tas ir, šī bloķēšana nebūs iespējama, darbojoties kontrolētā režīmā.

Jau vairākas reizes esmu teicis “pārvaldītās slēdzenes” un “pārvaldītais režīms”. Jums jāsaprot, ka ir divu veidu slēdzenes:
DBVS slēdzenes tiek automātiski instalētas DBVS līmenī, izpildot vaicājumus.
1C: Uzņēmuma slēdzenes tiek instalētas automātiski, rakstot (pārveidojot) datus, un vienmēr manuāli, lasot datus.

Rūpīgs lasītājs teiks, ka 1C iedalās arī objektu un neobjektu slēdzenēs, taču tagad mēs šai pieejai nepieskaramies.

Bet es atzīmēju, ka tas izvirza lielākas prasības 1C speciālista kvalifikācijai un pieredzei.

6) Trūkstošie indeksi (īpaši sarežģītos vaicājumos) parasti ir galvenais faktors, kas izraisa augstāku bloķēšanas līmeni, nekā nepieciešams. Tie. paradokss, no vienas puses, es teicu, ka pirms vaicājuma optimizēšanas es teicu, ka vispirms ir jāskatās slēdzenes, bet tagad es saku, ka, lai optimizētu slēdzenes, jums ir jāoptimizē vaicājums. Man ir attaisnojums, konfigurācijas pārslēgšana uz pārvaldītām slēdzenēm samazina nevajadzīgu bloķēšanu pat neoptimālā vaicājumā. Tas notiek darījumu izolācijas līmeņa samazināšanās dēļ, kas savukārt dod DBVS bloķēšanas pārvaldniekam mazāk iemeslu, lai uzliktu pārmērīgu bloķēšanu.

Galvenie pārmērīgas bloķēšanas iemesli (apkopojot iepriekš minēto)

— projektēšanas kļūdas
(paralēlitātes pakāpi nosaka “cik smalki sagriezti dati”: iespējams paralēls darbs ar divām tabulas rindām, darbs ar vienu rindu notiks tikai secīgi)
(kļūdas metadatu lietošanā: konstantu, secību ierakstīšana, operatīvā uzskaite grāmatvedības reģistros)
— pārmērīga bloķēšana automātiskā režīma vainas dēļ (platformas-DBVS kombinācija).
- neoptimāla vaicājuma veiktspēja
(piemēram, skenējot tabulu, visa tabula tiek bloķēta - liekā zona
un bloķēšanas laiks palielinās - pārmērīgs laiks, papildu bloķēšanas skaits palielina bloķēšanas eskalācijas iespējamību)

Kā redzat, slēdzeņu optimizēšanas uzdevums ir “daudzšķautņains”. Jums ir jābūt pēc iespējas skaidrākam par “kontekstu”, kas izraisīja problēmu. Uz kādiem resursiem, kādu kodu. Cik šī bloķēšana patiešām ir nepieciešama, vai arī tā ir lieka?

Bērnam un pieaugušajam ir iekaisis kakls. Kad ārsts uzdod jautājumu “Kas par vainu?”, bērns skatīsies uz ārstu un kliedz (ticiet man, es zinu), bet pieaugušais norādīs uz slimības simptomiem. Šīs acīmredzamās atšķirības novirza ārstu uz dažādām problēmas identificēšanas metodēm.
Ar bērnu ārstam jāveic daudzi testus, apkopo datus, apvieno tos, veic analīzi un tikai tad sniedz ieteikumus. Savukārt pieaugušajam viņš uzdos vairākus jautājumus, un, tā kā sākotnējo datu skaits ir mazs, analīzes un problēmas noteikšanas laiks būs ievērojami mazāks. Līdz ar to ieteikumi tiks izdoti daudz agrāk.

Izmantojiet mūsu pakalpojumus, un jums būs vairāk iespēju bez maksas analizēt problēmu un atrast risinājumu!

IT speciālistiem labi zināmajai lietotāja sūdzībai “1C uzkaras” ir daudz iemeslu. Lai veiktu pareizu “diagnozi” - identificētu un analizētu problēmu, ir nepieciešams to reproducēt, jo problēmu, kuru nevar reproducēt, parasti ir gandrīz neiespējami atrisināt. Izpratuši 1C sasalšanas simptomus, mēs spersim pirmo soli ceļā uz efektīvi strādājošu sistēmu.

Ļoti ilga sistēmas palaišana

Smagas konfigurācijas ilgstoša palaišana vienam lietotājam pirmo reizi pēc informācijas drošības pievienošanas datora datu bāzu sarakstam ir normāla parādība. Pirmās palaišanas laikā konfigurācija tiek saglabāta kešatmiņā. Otrajam un nākamajiem braucieniem jābūt ātrākiem.

Sistēmas palaišana, kas aizņem ilgu laiku, var norādīt uz problēmām ar konfigurācijas arhitektonisko ieviešanu. Lielāko daļu konfigurācijas platforma nolasa tikai tad, kad pirmo reizi piekļūst vajadzīgajam metadatu objektam. Ilga palaišana norāda uz izmantošanas iespējamību liels skaits metadatu objekti (daudzi izsaukumi uz dažādiem izplatītiem moduļiem, apstrāde utt.).

Jāņem vērā, ka pirmo reizi piekļūstot jebkura moduļa tekstam, tas tiek kompilēts. Šis process arī prasa laiku, kas ir īpaši pamanāms, ja ir daudz moduļu. Tādējādi lēnas palaišanas problēma tiek atrisināta, pārveidojot (optimizējot) konfigurāciju, kuras mērķis ir atspējot visu izvēles algoritmu izpildi, kas tiek izpildīti sistēmas startēšanas laikā.

Pastāv iespēja, ka konfigurācija mēģina nolasīt datus no interneta, kad tā sākas. Tas arī palielina sistēmas palaišanas laiku.

Ļoti gara veidlapu atvēršana

Veidlapu ilgstoša atvēršana var būt saistīta ar:

1. Liels skaits formas vadīklu - laiks tiek tērēts formas izveidei un formas elementu izkārtojuma savstarpējai savienošanai;
2. Algoritmu izpilde formas inicializācijas laikā. Iespējams, ka, veidojot formu, tiek pārbaudīti daži nosacījumi un/vai saistītie objekti tiek nolasīti no datu bāzes.

Pirmā problēma tiek “apstrādāta”, vienkāršojot veidlapu. Piemēram, dažas vadīklas var ievietot atsevišķās formās, kas lietotājam var būt pat ērtāk. Piemēram, ja veidlapā ir adreses lauks “Pilsēta”, “Iela”, “Māja” utt., tad adresi labāk rediģēt atsevišķā formā.

Otra problēma tiek atrisināta, analizējot darbības, kas veiktas, veidojot un atverot veidlapu, un optimizējot šos algoritmus. Iespējams, daži no algoritmiem jau ir novecojuši, bet citus var vienkāršot un optimizēt, piemēram, likvidējot vai minimizējot piekļuvi datiem datubāzē.

Kā interaktīvu darbību apsveriet, ka lietotājs mēģina atlasīt vērtību veidlapas elementā. Reaģējot uz to, sistēma "par kaut ko domā". Tas var notikt šādu iemeslu dēļ:

1. Algoritmi, kas darbojas šajā darbībā, pārbauda vai aprēķina saistītos datus, kas ietekmē vērtību atlases darbību;
2. Atlasīšanas forma, kas tiek atvērta, lai atlasītu šo vērtību, inicializācijas laikā nolasa visus objektus no datu bāzes.

Lai atrisinātu pirmo problēmu, jāizmanto “Veiktspējas mērīšana”, jāatrod resursietilpīgi algoritmi un jāoptimizē tie.

Otro problēmu bieži var atrisināt, vienkārši analizējot izvēles formas īstenošanu. Piemēram, jums jāpārliecinās, vai dinamiskam sarakstam ir iestatīts rekvizīts “Dinamiskā datu lasīšana”, vai rekvizīts “Galvenā tabula” ir iestatīts pareizi un saraksta ieviešanā netiek izmantoti acīmredzami resursietilpīgi algoritmi.

Ir arī situācijas, kad, atverot atlases veidlapu, no datu bāzes tiek nolasīti daži saistītie dati (piemēram, atverot atlases formu “Prece”, tiek nolasīti preču atlikumi noliktavās). Parasti tā nav labākais risinājums. Saistītos datus labāk lasīt asinhroni, pēc formas atvēršanas. Tas lietotājam radīs mazāku diskomfortu, jo Pēc veidlapas parādīšanas lietotājs kādu laiku pavadīs veidlapas apguvei, un šo laiku var pavadīt saistīto datu ielādei.

Ļoti ilga reakcija uz atjauninājumiem

Tomēr viens no triviālajiem simptomiem var pastāstīt par dažām sistēmas problēmām: 1C atjauninājums sasalst, uzsākot dublēšanu. Tas galvenokārt notiek, veicot atjaunināšanu, izmantojot internetu, un, visticamāk, norāda, ka konfigurācija nav tikusi atjaunināta ilgu laiku un laidieni, kas ritēja viens pēc otra, izraisīja iesaldēšanu. Jūs varat novērst šādu problēmu, savlaicīgi instalējot atjauninājumus, un, ja ar to saskaraties, varat vienkārši pārtraukt dublēšanas procesu. Pēc konfiguratora palaišanas datu bāze sāksies ar parastajā režīmā veiktajām izmaiņām.

Jāpiebilst, ka 1C 8.3 atjaunināšanas laikā sasalst visbiežāk arī tāpēc, ka tai nepieciešama resursietilpīgāka aparatūra nekā iepriekšējās versijas platformas. Ir vērts pievērst uzmanību RAM apjomam un, ja nepieciešams, to palielināt - tam principā vajadzētu palīdzēt atrisināt problēmu “1C sasalst, atjauninot konfigurāciju”.

Ilgs objektu ierakstīšanas/dokumentu izpildes process

Šajā gadījumā “ārstēšana, kas balstīta uz fotografēšanu” ir praktiski izslēgta, jo iemesli var būt ļoti dažādi, sākot no liela datu apjoma objektā līdz gaidīšanai pie slūžām.

Bet pat ŠAJĀ gadījumā ir iespējams iezīmēt analīzes virzienu.

Būtisku ieraksta laika izmaiņu neesamība diennakts laika vai lietotāju skaita dēļ (kā aptuvens, subjektīvs novērtējums) norāda uz problēmu kodā vai objekta datu apjomā. Analīzei ir lietderīgi izmantot rīku “Veiktspējas mērīšana”.

Dramatiskas izmaiņas ierakstīšanas laikā ar neskaidrām atkarībām prasa veikt problēmas rašanās statistisko analīzi, t.i. veiktspējas analīze. Vienkāršākais veids ir analizēt žurnāla izmantošanu. Papildu priekšrocība šeit ir tā, ka platforma 1C: Enterprise 8 atbalsta žurnāla datu saglabāšanu failā SQLite formātā. Tas ļaus jums izmantot SQL vaicājumus, lai analizētu žurnāla datus. Ir pilnīgi iespējams iegūt objekta rakstīšanas laiku no žurnāla datiem, ņemot vērā faktu, ka katra objekta rakstīšana tiek veikta darījumā, un katram darījumam ir savs identifikācijas numurs.

Ja statistiskās analīzes rezultāts parādīja, ka objekta ierakstīšanas laiks ir atkarīgs no diennakts laika, nevis no lietotāju skaita, ir jāanalizē 1C servera un datu bāzes servera slodze. Iespējams, ka serverī darbojas rutīnas procesi, kas aizņem nevajadzīgus resursus.

Ja objektu rakstīšanai nepieciešamais laiks ir atkarīgs no lietotāju skaita, problēma, visticamāk, ir kodā (iespējams, gaidot bloķēšanu) vai aparatūras caurlaidspēju. To risināšanai jāpiesaista speciālists ar kompetenci “1C: Expert in tehnoloģiskiem jautājumiem", jo nav vienotu noteikumu šādas problēmas risināšanai.