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

Gilev komanda jau daudzus gadus ir strādājusi pie veiktspējas jautājumiem un 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 subd ilgtermiņa darbību esamību.

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 - patiesībā jums 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. vaicājuma pārrakstīšana (ā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 produktivitātes 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 pienākumos 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āmeklē: varbūt ir iespējams optimizēt daļu bloķēšanas un samazināt resursu bloķēšanas laiku.

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

Gaidām 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 tiks pabeigta pirmā lietotāja transakcija.

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 noliktavas 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ķēšanas 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ā bāzē.

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 kopsummas 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 “atliekas” maksimāli detalizēti.

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— slēdzenes ir iespējamas indeksa diapazonu robežās, slēdzenes uz tukšas tabulas un slēdzenes eskalācijas.

Šī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ītajā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 kļūmes 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

Ilga palaišana smaga konfigurācija vienam lietotājam pirmo reizi pēc informācijas drošības pievienošanas datu bāzu sarakstam datorā 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 veidlapas 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 režīmu;
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 realizāciju. 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 atvērtās veidlapas apstrādei, 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 skaļumam RAM un, ja nepieciešams, palieliniet to - tam principā vajadzētu palīdzēt atrisināt problēmu “1C sasalst, atjauninot konfigurāciju”.

Ilgs objektu ierakstīšanas/dokumentu noformēšanas 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 “Veiktspējas mērīšanas” rīku.

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 laiks, kas nepieciešams objektu rakstīšanai, ir atkarīgs no lietotāju skaita, problēma, visticamāk, ir kodā (iespējams, gaidot bloķēšanu) vai joslas platums iekārtas. 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.

Š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ēns darbs 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). Palielināt to līdz 400 vienlaicīgiem lietotājiem 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āatzīmē, ka aprīkojumam joprojām ir jābūt serverī, jo īpaši diska apakšsistēma. 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 kad lielos daudzumos lietotājiem, pastāv liela varbūtība, ka darījuma laikā kāds cits mēģinās pārsūtīt 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ītā slodze 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, kas nodarbojas ar to atbalstu un konfigurēšanu.

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 atkārtoti 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." Un 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 ir piemērots gan maziem 1C:Enterprise IS - 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 pārbaudi 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.

Šis raksts palīdzēs jums atbrīvoties no iesaldēšanas programmām. Tajā es aprakstīšu metodi, kas palīdzēs beigt iesaldētu programmu Pareizi. Galu galā, bieži vien, lai pabeigtu programmu, cilvēki izmanto viņiem zināmas metodes - tas ir drudžains taustiņu nospiešana alt + f4 vai tikai poga esc un vairumā gadījumu tas nedarbojas. Tad jums ir jānospiež vienīgā poga, kas noteikti palīdzēs - šī ir poga ieslēgta sistēmas vienība vai klēpjdators, lai izslēgtu vai restartētu. Šajā gadījumā jūs riskējat zaudēt datus ne tikai no iesaldētās programmas, bet arī no citām, kas ir atvērtas.

Programmas sasalšanas iemesli var būt vairāki:

Ja jums ir 64x bitu sistēma(), un jūs izmantojat programmu, kas paredzēta 32 bitu sistēmām, tad labākajā gadījumā programma vienkārši nesāksies, sliktākajā gadījumā tā iesaldēsies. Lai gan šeit ir nianse - gadās, ka šādas programmas darbojas, bet vai nu nepareizi, vai arī laika gaitā sasalst.

Jums ir pārāk maz RAM, lai palaistu.

Jums darbojas pārāk daudz programmu un procesu, kas jau ielādē sistēmu.

Jums ir programmas, kas darbojas fonā, kas aizņem daudz sistēmas resursu

Vīrusi

Tehniskas problēmas (termiskā pasta uz procesora ir izžuvusi, ir aizsērējusi daudz putekļu, “vāja” aparatūra utt.)

Un tagad jūs esat palaidis programmu un gaidāt tās palaišanu. Un viņa apstājās pie iekraušanas procesa un "klusēja". Ir labi, ja tiek atskaņota fona mūzika (galvenokārt spēlēm), tas var sniegt mājienu cilpas veidā. Jūs, protams, varat pagaidīt dažas minūtes (ne vairāk kā 5), gaidot “brīnumu” un to, ka programma uzkaras, bet, ja nevēlaties gaidīt un noteikti zināt, ka programma ir iesaldējusi, tad jums jāsāk aizverot iesaldētas programmas.

Lai pārtraukt programmu, kas nereaģē(to sauc arī par iesaldēšanu) jums jāzvana uzdevumu pārvaldniekam. Jūs, protams, varat izmantot ctrl+maiņa+esc, taču iesaku izmantot pazīstamāku un efektīvāku īsinājumtaustiņu ctrl+alt+del.

Operētājsistēmā Windows 7, nospiežot šos taustiņus, tiks atvērts piecu opciju logs, kurā jāizvēlas pēdējā.

Cilnē Lietojumprogrammas Mēs meklējam iesaldētu programmu (parasti tās statuss ir Neatbild), ar peles labo pogu noklikšķiniet uz tās un izvēlnē atlasiet Dodieties uz apstrādi:

Tiks atvērta cilne Procesi ar īpašu piekarināšanas procesu. Šeit mēs vienkārši noklikšķiniet uz Pabeidziet procesu

un piekrītu sistēmas brīdinājumam

Piezīme:
Protams, izvēlnē Task Manager var izvēlēties ne Dodieties uz apstrādi, A Atcelt uzdevumu un šī būs “maigāka” metode, taču dažreiz tā nepalīdz. Un es kaut kā esmu pieradis šādas problēmas efektīvi risināt.

Tādā veidā jūs varat “noņemt” iesaldētu programmu, nerestartējot datoru, un saglabāt citas darbojošās programmas neskartas.

Gadās, ka Explorer nereaģē. Ar to es domāju, ka, piemēram, jūs atvērāt mapi savā datorā vai pat vienkārši Mans dators un sistēma sastinga (tā sāk ilgi domāt). Man pašam tā ir gadījies.
Šajā gadījumā var palīdzēt arī Task Manager un iepriekš aprakstītā metode.

Bet šeit svarīgi atcerēties Viena detaļa: Explorer procesu sauc explorer.exe, un, kad tas beidzas, visas datora mapes tiks aizvērtas. Bet tā ir puse no nepatikšanām. Pēc pētnieka “nogalināšanas” pazudīs arī vadības panelis ar izvēlni Sākt. Tieši tāpēc Neaizveriet uzdevumu pārvaldnieku uzreiz! Lai atgrieztu trūkstošo (izņemot atvērtās mapes), noklikšķiniet uz Fails -> Palaist

un rindā ievadiet explorer.exe

Protams, noklikšķiniet uz Labi, un viss atgriezīsies savās vietās.

Tāpat kā šis vienkāršs veids lai atrisinātu problēmu Ko darīt, ja programma nereaģē vai sasalst.

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ēta 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 REINDEKS
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 aizvērt 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.