Automatizācijas padomi. Padomi automatizēšanai 1s 8 ir lēns

Š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 liela skaita lietotāju vienlaicīgai darbībai, ko aktīvi atbalsta foruma lietotāji, kuri šajās ziņās atrod mierinājumu un iemeslu atstāt visu, kā tas ir. Ar pietiekamu pacietību un zināšanu līmeni 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: visvieglāk ir optimizēt 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). Tā iegūšana līdz 400 vienlaicīgiem lietotājiem ir diezgan tipisks projekts. Līdz 1500 jau ir grūti, 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ī atjaunojot nenozīmīgu aprīkojuma daļu, piemēram, pievienojot RAM. Tajā pašā laikā jāņem vērā, ka iekārtai 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 vairāku lietotāju darbā 1C ir bloķēšanas mehānisms. Tieši 1C slēdzenes, nevis servera aprīkojums, parasti neļauj lielam skaitam cilvēku strādāt datu bāzē. Lai pārvarētu šo problēmu, jums ir smagi jāstrādā un jāmaina slēdzeņu loģika 1C - pazeminiet tās no tabulas uz rindiņu pa rindiņai. Tad, piemēram, turot rokās 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 rindiņu šajā modulī.

1C bloķēšanas mehānisma maiņa ir ļoti sarežģīta tehnoloģija. Ne visi spēj realizē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 laiks, kas nepieciešams darbību pabeigšanai, ir ļoti savstarpēji saistīti rādītāji. Piemēram, ja dokumenta grāmatošana aizņem 15 sekundes, tad ar lielu lietotāju skaitu pastāv liela iespējamība, ka grāmatošanas laikā kāds cits mēģinās ievietot dokumentu un gaidīs slēdzenē. Ja izpildes laiks tiek palielināts vismaz līdz 1 sekundei, 1C bloķēšana šai darbībai tiks ievērojami samazināta.

Bīstamāka bloķēšanas ziņā ir grupu apstrāde, kas var būt ilga izpildes laikā un vienlaikus izraisīt 1C bloķēšanu. Jebkura apstrāde, kas maina datus, piemēram, dokumentu atkārtota secība vai pakešu apstrāde, bloķē tabulas un neļauj citiem lietotājiem publicēt dokumentus. Protams, jo ātrāk šie procesi tiek veikti, jo īsāks ir bloķēšanas laiks un lietotājiem ir vieglāk strādāt.

Smagie pārskati, kas veic tikai lasīšanas 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 pārskats 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 izpildes tika veiktas 1 sekundi, bet pārskata izpildes laikā 15 sekundes. Protams, palielinoties operāciju izpildes laikam, palielināsies arī bloķēšanas intensitāte.

2. attēls. Slodze uz darba servera konfigurācijas moduļu kontekstā no visiem lietotājiem. Katram modulim ir sava krāsa. No 1C radītā slodze ir skaidra nelīdzsvarotība.

Galvenais optimizācijas noteikums ir tāds, ka dokumenta laiks aizņem minimālu laiku un jāveic 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ā reģistriem ir jānorāda 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 ir sastopama 95% klientu. Jāatzīmē, ka tie ir nopietnu organizāciju serveri, un to atbalstīšanā un konfigurēšanā ir iesaistītas veselas augsti kvalificētu administratoru nodaļas.

Galvenais iemesls, kāpēc serveris nav pareizi konfigurēts, 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 nolaidīgo administratoru. Tāpēc viņam izdevīgāk ir atstāt visu, kā ir, un nespert ne soli bez priekšnieku pavēles, 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īgā pretrunā viens otram. Katram optimizācijai veltītajam viedoklim ir savi pretinieki un fanātiķi, kas to aizstāvēs. Rezultātā internets un forumi jauc servera iestatījumus, nevis palīdz. Šādas nenoteiktības situācijā administratoram vēl mazāk ir vēlme kaut ko mainīt serverī, kas vismaz 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 SCP 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 paskatāmies, kas notiek serverī – pēkšņi ir kaut kāds neatkarīgs antivīruss, kas veic pilnu sistēmas skenēšanu. Pārbaude liecina, ka viss ir pienācīgi - serveris ir noslogots zem 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 tika priecīgi atjaunināti, un pēc atjaunināšanas sākās masveida 1C lietotāju darba palēnināšanās vai 1C vienkārši sasalst. .

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

No prakses: programma, kas ātri atjaunina datus vietnē, iestrēga, un tā vietā, lai atjauninātu ik pēc 4 stundām, tā to darīja bez apstājas, bez pauzēm, spēcīgi 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ā saprast, ko tieši lietotāji dara? Vai vismaz kas viņi ir. Nu, ja organizācijā ir 10 1C lietotāji, tad varat vienkārši izstaigāt viņiem 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. Un iedomājieties, ka palēninājums nebija šodien, bet vakar. Šodien situācija neatkārtojas, viss kārtībā, bet jāizdomā, kāpēc vakar nevarēja strādāt operatori (protams, ka sūdzējās tikai pirms iziešanas no mājām, jo patīk visu dienu pļāpāt, jo nekas nestrādā, patīk vairāk nekā strādājot). Šis gadījums uzsver nepieciešamību pēc servera reģistrēšanas sistēmas, kas vienmēr saglabās servera galveno parametru vēsturi un no kuras var atjaunot notikumu secību.

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

Uzsākot darbu optimizācijas jomā, izmēģinājām daudzas serveru uzraudzības sistēmas, diemžēl 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, kas uzrakstīja konfigurāciju", programmētāji atbild - "Mums viss ir labi uzrakstīts - serveris 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 vadības lēmumu un ietaupīt naudu. Produkts piemērots gan maziem IS 1C:Enterprise - līdz 50 lietotājiem, gan sistēmām - no 1000 lietotājiem. No 2015. gada jūlija izpildes monitorings PerfExpert saņēma sertifikātu 1C: Saderīgs, tika pārbaudīts 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 tālāk norādītās darbības.

- Ja vēlaties patstāvīgi risināt 1C tehniskās darbības problēmas (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) un citas informācijas sistēmas, tad jums unikāls tehnisko rakstu saraksts mūsu Almanahā (Slēdzenes un strupceļi, liela CPU un diska 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.

Dažādu iemeslu dēļ programmas 1C lietotāji laiku pa laikam saskaras ar 1C veiktspējas problēmām. Piemēram: dokuments tiek apstrādāts ilgu laiku, atskaite tiek ģenerēta ilgu laiku, transakciju kļūdas, programma sastingst, lēna reakcija uz lietotāja darbībām utt. Ievērojot mūsu norādījumus, jūs varat sasniegt ievērojamus panākumus programmas ātrumā, novērst sistēmas limita pārsniegšanu. Tā nav panaceja pret visām slimībām, taču lielākā daļa 1C bremžu iemeslu ir tieši šajos jautājumos.

1. Neveiciet plānotos un fona uzdevumus, kamēr lietotāji strādā

Pirmais un galvenais sistēmas administratoru noteikums ir likt visiem fona uzdevumiem darboties ārpus darba laika. Sistēmai jābūt maksimāli izlādētai, lai veiktu rutīnas uzdevumus (indeksēšana, dokumentu ievietošana, datu augšupielāde) un tajā pašā laikā netraucētu lietotāju darbam. Ne sistēma, ne lietotāji netraucēs viens otram, ja viņi strādās dažādos laikos.

2. Neapmainīties ar RIB datiem lietotāju darba dienas laikā

Lai gan uzņēmumi pēdējā laikā ir atteikušies no RIB datu apmaiņas sistēmas par labu tiešsaistes režīmam un termināla piekļuvei, nebūs nevietā atcerēties, ka apmaiņas datu augšupielādes un lejupielādes laikā nav iespējams veikt dokumentus un pabeigt darbu programmā. Ja iespējams, šī procedūra, ja tāda ir, jāveic, izmantojot fona uzdevumus naktī.

3. Savlaicīgi uzlabojiet datora veiktspēju, saskaņojiet tā jaudu ar reālajām vajadzībām

Neaizmirstiet, ka 30 un 100 lietotāju vienlaicīga darbība sistēmā rada atšķirīgu slodzi. Attiecīgi, ja tiek plānots kvantitatīvs lietotāju pieaugums, IT dienestam būtu savlaicīgi jāizskata jautājums ar uzņēmuma vadību par mašīnu parka paplašināšanu, papildu atmiņas vai serveru iegādi.

4. Programmatūra, kurā darbojas 1C

Programma 1C ir tāda, ka operētājsistēmās tā darbojas atšķirīgi. Nav precīzi zināms, kāpēc, bet tā ir. Piemēram, 1C datu bāzes servera versija operētājsistēmā Linux OS kopā ar SQL Postgre ir daudz lēnāka nekā tā pati 1C datubāze, bet operētājsistēmā Windows OS kopā ar MS SQL. Precīzi šī fakta iemesli nav zināmi, taču acīmredzot kaut kur dziļi 1C platformā ir saderības problēmas ar operētājsistēmām un ne-Microsoft DBVS. Sistēmu ir vērts izvietot arī 64 bitu serverī, ja tiek plānota ievērojama datu bāzes noslodze.

5. Datu bāzes indeksēšana

1C programmas iekšējā procedūra, kas "ķemmē" sistēmu no iekšpuses. Iestatiet, lai tas darbotos kā fonā ieplānots uzdevums naktī, un esiet mierīgs.

6. Operatīvās partijas uzskaites atspējošana

Fakts ir tāds, ka dokumentu operatīvās apstrādes laikā kustības tiek reģistrētas reģistros, tostarp partiju uzskaites reģistros. Sērijveida uzskaites reģistru ierakstīšanu, grāmatojot dokumentus, var atspējot programmas iestatījumos. Reizi mēnesī būs jāsāk apstrādāt dokumentu grāmatošanu pa partijām, piemēram, laikā, kad datubāze ir vismazākā noslodze vai strādā vismazāk lietotāju.

7. RAM

Izmantojiet šādu formulu:

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

Apmēram 70% no kopējā datu bāzu fiziskā apjoma. 1C bāzēm patīk labi paēst ar RAM. Neaizmirstiet par to.

8. Ja iespējams, optimizējiet pašrakstītās atskaites un apstrādi ar nepilnīgiem un novecojušiem kodiem

Uzņēmuma dzīves gaitā rodas nepieciešamība pēc atskaišu rakstīšanas un apstrādes, kā arī uzlabojumi biznesa procesu vadīšanā un specifiskas informācijas ieguvē. Tikai visi šie uzlabojumi var būt buggy, palēnināt darbu, jo. a) daži kulibini reiz varētu sabojāt smagu nepareizu kodu, kuru programmai ir grūti izpildīt un kura izpilde prasa ievērojamas pūles; b) kods, uz kura tiek rakstīts apstrāde vai ziņojums, var kļūt morāli novecojis un prasa pārskatīšanu, pārprogrammēšanu. Izmantojiet noteikumu – jo mazāk kaut ko mainīsim programmā, jo labāk.

9. Kešatmiņas tīrīšana

Parasta servera restartēšana dažreiz atrisina problēmas ar novecojušu 1C kešatmiņu. Vienkārši pamēģini. Var palīdzēt arī izkraušana - informācijas bāzes ielāde caur konfiguratoru. Un pēdējā konkrēta lietotāja kešatmiņas tīrīšana ir mapju dzēšana veidlapas 1C sistēmas direktorijā: kexifzghjuhfv8j33hbdgk0. Bet lietotāja kešatmiņā saglabāto mapju dzēšana ir pēdējā lieta, jo. papildus atkritumu noņemšanai kešatmiņas tīrīšanai ir nepatīkamas sekas saglabāto atskaites iestatījumu, lietotāja izvēlnes saskarnes dzēšanas veidā.

10. Datu bāzu fiziskā apjoma samazināšana

Vairāk bāzes nozīmē vairāk resursu. Dabiski. Izmantojiet standarta 1C instrumentus, lai sarullētu pamatni. Padomājiet par to, jūs varat pēkšņi atteikties no datiem pirms pieciem gadiem, lai palielinātu produktivitāti. Un, ja jums joprojām ir nepieciešami pēdējo piecu gadu dati, jūs vienmēr varat izmantot datu bāzes kopiju.

11. Pareiza arhitektūras organizācija

Kopumā korporatīvās informācijas sistēmas arhitektūrai jābūt pareizai. Ko mēs saprotam ar pareizu sistēmu? Sistēmai noteikto uzdevumu salīdzināmība ar pieejamo aprīkojumu un programmatūru. Plānojiet sistēmu kopā ar: sistēmas administratoru (jo viņš pārzina mašīnu parku), 1C programmētāju (jo viņš zina 1C resursu vajadzības) un uzņēmuma vadītāju (jo viņš zina par uzņēmuma turpmāko izaugsmi vai samazināšanu). uzņēmums).

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 ir prasīgākas pret resursiem, taču lielākajai daļai lietotāju nav izpratnes par to, kas galvenokārt ietekmē 1C darbību faila režīmā. Mēģināsim novērst š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šķā personālajā datorā vai termināļa serverī. Tajā pašā laikā lielākā daļa mazo implementāciju ietver darbu ar failu 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 1C krievu valodas resursu pētījums parādīja, ka šī problēma tiek rūpīgi apieta, problēmu gadījumā parasti tiek ieteikts pārslēgties uz klienta-servera vai termināļa režīmu. Un gandrīz vispārpieņemts ir arī tas, ka pārvaldītās lietojumprogrammas konfigurācijas darbojas daudz lēnāk nekā parasti. Parasti argumentiem tiek dots "dzelzs": "šeit Accounting 2.0 tikko lidoja, un" trijotne "knapi kustas, protams, šajos vārdos ir daļa patiesības, tāpēc mēģināsim to izdomāt.

Resursu patēriņš īsumā

Pirms šī pētījuma uzsā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 resursi visvairāk 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, ar diviem resursdatora Core i5-4670 kodoliem un 2 GB RAM, kas 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ā.

Kā eksperimentālās bāzes esam izvēlējušies vairākas Accounting 2.0, laidiena konfigurācijas 2.0.64.12 , kas pēc tam tika atjaunināts uz 3.0.38.52 , visas konfigurācijas tika darbinātas platformā 8.3.5.1443 .

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

Esam jau gatavi dzirdēt ierasto: "ko viņi pievienoja šim trijotnei", bet nesteigsimies. Atšķirībā no klienta-servera versiju lietotājiem, kuriem nepieciešams vairāk vai mazāk kvalificēts administrators, failu versiju lietotāji reti domā par datu bāzes uzturēšanu. Arī specializēto firmu darbinieki, kas apkalpo (lasi - atjaunina) šīs 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, šķiet, nozīmē, ka šis ir problēmu novēršanas rīks, taču slikta veiktspēja ir arī problēma, un pārstrukturēšana un pārindeksēšana, kā arī tabulas saspiešana ir labi zināmi datu bāzes optimizācijas rīki jebkuram RDBMS administratoram. Pārbaudīsim?

Pēc izvēlēto darbību pielietošanas datu bāze dramatiski "zaudēja svaru", kļūstot pat mazāka par "divām", kuras arī neviens nekad nav 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 pieaugs, kopumā "trīs" pamatnes ir lielākas nekā "divu" pamatnes. Tomēr tas nav svarīgāk, ja otrā versija bija apmierināta ar 150-200 MB RAM, tad jaunajam izdevumam jau ir nepieciešams pusgigabaits, un šī vērtība ir jāņem vērā, plānojot nepieciešamos resursus darbam ar programmu. .

Tīkls

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

Kas notiek, palaižot 1C failu bāzi tīklā? Klients pagaidu mapēs lejupielādē diezgan lielu informācijas daudzumu, it īpaši, ja šī ir pirmā "aukstā" palaišana. Paredzams, ka pie 100 Mb/s mēs saskaramies ar joslas platumu, un lejupielāde var aizņemt ievērojamu laiku, mūsu gadījumā apmēram 40 sekundes (grafikas dalīšanas cena 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āreja uz gigabitu tīklu var ievērojami paātrināt programmas ielādi gan "aukstā", gan "karstā", un tiek novērota vērtību attiecība. Tāpēc mēs nolēmām rezultātu izteikt relatīvā izteiksmē, katra mērījuma lielāko vērtību ņemot par 100%:

Kā redzams no grafikiem, Accounting 2.0 ielādējas divreiz ātrāk jebkurā tīkla ātrumā, pāreja no 100 Mb/s uz 1 Gb/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 trijotnes datu bāzēm.

Mēs arī pārbaudījām tīkla ātruma ietekmi uz lieljaudas darbību, piemēram, grupas atkārtotas mitināšanas laikā. Rezultātu izsaka arī relatīvā izteiksmē:

Šeit jau ir interesantāk, optimizētā "troikas" bāze 100 Mbit/s tīklā strādā ar tādu pašu ātrumu kā "diviem", un neoptimizētā uzrāda divreiz sliktāku rezultātu. Gigabitā attiecības tiek saglabātas, arī neoptimizētais "trīs" ir divreiz lēnāks par "divi", un optimizētais atpaliek par trešdaļu. Arī pāreja uz 1 Gb / s ļauj samazināt izpildes laiku trīs reizes 2.0 versijai un divas reizes versijai 3.0.

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

Faktiski ikdienas darbiem tīkla joslas platums 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 - ietekmē priekšrocības, strādājot plānā klienta režīmā. Pāreja uz 1 Gb / s optimizētajai bāzei nedod nekādas priekšrocības, un neoptimizētā bāze un deuce sāk darboties ātrāk, parādot nelielu atšķirību starp tām.

No veiktajiem testiem kļūst skaidrs, ka tīkls nav šķērslis jaunām konfigurācijām, un pārvaldītā lietojumprogramma darbojas pat ātrāk nekā parasti. Varat arī ieteikt pārslēgties uz 1 Gb/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 Mb/s tīklos.

Tātad, kāpēc 1C palēninās? Mēs turpināsim izmeklēšanu.

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 ar servera diska apakšsistēmas veiktspēju nepietiek? 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 izdarīt pieņēmumu, ka 8-10 tīkla klientu normālai darbībai smagos režīmos pietiks ar spoguli no parastajiem diskiem.

Tātad, vai serverī ir nepieciešams SSD? Labākā atbilde uz šo jautājumu palīdzēs testēšanai, ko veicām, izmantojot līdzīgu metodiku, tīkla savienojums visur ir 1 Gb / s, rezultāts tiek izteikts arī relatīvās vērtībās.

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

Kādam tas var šķist pārsteidzoši, taču SSD bāze serverī neietekmē datu bāzes lejupielādes ātrumu. Galvenais ierobežojošais faktors šeit, kā parādīts iepriekšējā testā, ir tīkla caurlaidspēja un klienta veiktspēja.

Pāriesim pie vadu pārslēgšanas:

Iepriekš jau atzīmējām, ka diska veiktspēja ir diezgan pietiekama pat lielas slodzes darbam, tāpēc arī SSD ātrums netiek ietekmēts, izņemot neoptimizēto bāzi, kas panāca SSD 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ā bāze saņem labumu no SSD. Protams, var iegādāties SSD, taču daudz labāk būtu padomāt par savlaicīgu bāzu apkopi. Tāpat neaizmirstiet par informācijas bāzes nodalījuma defragmentēšanu serverī.

Klienta diska apakšsistēma un SSD

Mēs analizējām SSD ietekmi uz lokāli instalētā 1C ā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 plānotajiem 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.

Bet tajā pašā laikā jāapzinās, ka darbstacijai, kurā tiek veikts aktīvs darbs ar vienu vai divām informācijas bāzēm, parastā lielapjoma 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īsit 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, taču tas pats 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 to 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 ar kopējo RAM apjomu 1 GB darbam ar programmu nepietiks.

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

No pirmā acu uzmetiena viss nav tik slikti, programma ir mērenējusi apetīti un pilnībā turējusies pieejamās atmiņas robežās, taču neaizmirsīsim, ka nepieciešamība pēc operatīvajiem datiem nav mainījusies, kur tad tie palika? Izskalots diskā, kešatmiņā, mijmaiņā utt., šīs operācijas būtība ir tāda, ka no ātrās RAM, kuras apjoms nav pietiekams, uz lēno disku tiek nosūtīti dati, kas šobrīd nav nepieciešami.

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

Kā redzams, sistēma aktīvi izmanto tīklu datu saņemšanai un procesoru to apstrādei, diska aktivitāte ir niecīga, apstrādes procesā ik pa laikam pieaug, 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, katalogi un žurnāli tika atvērti ar ievērojamu kavēšanos un aktīvu piekļuvi diskam. Piemēram, žurnāla Preču un pakalpojumu pārdošanas 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 bāzes ielādes ātrumu, otrās bāzes ielādes ātrumu un grupas pārpublicēšanu vienā no bāzēm. Abas bāzes ir pilnīgi identiskas un izveidotas, kopējot optimizēto bāzi. Rezultātu izsaka relatīvās vienībās.

Rezultāts runā pats par sevi, ja ielādes laiks pieaug par aptuveni trešdaļu, kas vēl ir diezgan pieļaujami, tad datu bāzē operāciju veikšanas laiks pieaug trīs reizes, par kaut kādu komfortablu darbu šādos apstākļos nav jārunā. 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 strādāt ar jaunām 1C konfigurācijām ir neērti. Jāapsver minimālās piemērotās konfigurācijas ar 2 GB atmiņu. Tajā pašā laikā paturiet prātā, ka mūsu gadījumā tika izveidoti "siltumnīcas" apstākļi: tika palaista tīra sistēma, tika palaists tikai 1C un uzdevumu pārvaldnieks. Reālajā dzīvē pārlūkprogramma, biroja komplekts, antivīruss utt. parasti ir atvērti strādājošā datorā, tāpēc ņemiet vērā nepieciešamību pēc 500 MB vienai datu bāzei plus neliela rezerve, lai smagas darbības laikā nesaskartos ar trūkumu. atmiņas un krasas veiktspējas pasliktināšanās.

Procesors

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

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

secinājumus

Tātad, kāpēc 1C palēninās? 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 ir biroja konfigurācijās, tad mēs iegūstam situāciju, kas aprakstīta raksta sākumā - "divi" strādāja labi, un "trīs" nekaunīgi bremzē.

Otrā vieta jāatvēl tīkla veiktspējai, lēns 100 Mbps 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 darba līmeni pat lēnos kanālos.

Tad jāpievērš uzmanība diskam, SSD pirkšana diez vai būs labs ieguldījums, taču diska nomaiņa pret modernāku nebūs lieka. Atšķirību starp cieto disku paaudzēm var noteikt 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: pakešu apstrāde, smagas atskaites, mēneša slēgšana utt.

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

Tagi:

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

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

Iepriekšējās publikācijās mēs jau esam pieskārušies diska apakšsistēmas veiktspējas ietekmei uz 1C ātrumu, tomēr š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 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 1C krievu valodas resursu pētījums parādīja, ka šī problēma tiek rūpīgi apieta, problēmu gadījumā parasti tiek ieteikts pārslēgties uz klienta-servera vai termināļa režīmu. Un gandrīz vispārpieņemts ir arī tas, ka pārvaldītās lietojumprogrammas konfigurācijas darbojas daudz lēnāk nekā parasti. Parasti argumentiem tiek dots "dzelzs": "šeit Accounting 2.0 tikko lidoja, un" trijotne "knapi kustas", protams, šajos vārdos ir patiesība, tāpēc mēģināsim to izdomāt.

Resursu patēriņš īsumā

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, ar diviem resursdatora Core i5-4670 kodoliem un 2 GB RAM, kas 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ā.

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

Tīkls

Mēs arī pārbaudījām tīkla ātruma ietekmi uz lieljaudas darbību, piemēram, grupas atkārtotas mitināšanas laikā. Rezultātu izsaka arī relatīvā izteiksmē:

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

Tātad, kāpēc 1C palēninās? Mēs turpināsim izmeklēšanu.

Servera diska apakšsistēma un SSD

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

Pāriesim pie vadu pārslēgšanas:

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

Klienta diska apakšsistēma un SSD

Iepriekšējā rakstā mēs analizējām SSD ietekmi uz lokāli instalētā 1C ā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 plānotajiem 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.

Lēns cietais disks var palēnināt dažas darbības, taču tas 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 palaidām divas informācijas bāzes.

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

Kā redzams, sistēma aktīvi izmanto tīklu datu saņemšanai un procesoru to apstrādei, diska aktivitāte ir niecīga, apstrādes procesā ik pa laikam pieaug, bet nav ierobežojošs faktors.

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

Procesors

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

secinājumus

Tad jāpievērš uzmanība diskam, SSD pirkšana diez vai būs labs ieguldījums, taču diska nomaiņa pret modernāku nebūs lieka. Atšķirību starp cieto disku paaudzēm var novērtēt pēc šāda materiāla: Pārskats par diviem lētiem Western Digital Blue sērijas diskdziņiem ar 500 GB un 1 TB.

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

Raksta rakstīšanas galvenais mērķis nav atkārtot acīmredzamās nianses tiem administratoriem (un programmētājiem), kuri vēl nav guvuši pieredzi ar 1C.

Sekundārais mērķis, ja man ir kādi trūkumi, Infostart to man norādīs visātrāk.

V. Gileva tests jau kļuvis par sava veida "de facto" standartu. Autors savā mājaslapā sniedza visai saprotamus ieteikumus, bet es vienkārši sniegšu dažus rezultātus un komentēšu iespējamās kļūdas. Protams, jūsu aprīkojuma pārbaudes rezultāti var atšķirties, tas ir tikai norādījums, kādam jābūt un uz ko jūs varat tiekties. Uzreiz gribu atzīmēt, ka izmaiņas ir jāveic soli pa solim, un pēc katra soļa pārbaudiet, kādu rezultātu tas deva.

Infostartā ir līdzīgi raksti, attiecīgajās sadaļās ielikšu saites uz tiem (ja kaut ko palaidu garām, lūdzu, pastāstiet komentāros, pievienošu). Tātad, pieņemsim, ka jūs palēnināt 1C. Kā noteikt problēmu un kā saprast, kurš ir vainīgs, administrators vai programmētājs?

Sākotnējie dati:

Pārbaudīts dators, galvenā izmēģinājuma cūciņa: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Salīdzinājumam, salīdzināmus rezultātus viena vītnes testā parāda Core i3-2100. Iekārta tika speciāli paņemta ne jaunākā, uz modernām iekārtām rezultāti ir manāmi labāki.

Attālināto 1C un SQL serveru testēšanai SQL serveris: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Lai pārbaudītu 10 Gbit tīklu, tika izmantoti Intel 520-DA2 adapteri.

Faila versija. (bāze atrodas serverī koplietotajā mapē, klienti ir savienoti tīklā, CIFS/SMB protokols). Soli pa solim algoritms:

0. Pievienojiet Gilev testa datu bāzi failu serverim tajā pašā mapē, kurā atrodas galvenās datu bāzes. Savienojamies no klienta datora, palaižam testu. Mēs atceramies rezultātu.

Saprotams, ka pat veciem datoriem pirms 10 gadiem (Pentium uz 775 ligzdas ) laikam no noklikšķināšanas uz etiķetes 1C:Enterprise līdz datu bāzes loga parādīšanai vajadzētu būt mazākam par minūti. ( Celeron = lēns darbs).

Ja jūsu dators ir sliktāks nekā ieslēgts Pentium 775 ligzda ar 1 GB RAM, tad es jums jūtu līdzi, un jums būs grūti panākt ērtu darbu ar 1C 8.2 faila versijā. Apsveriet iespēju jaunināt (ilgi nokavēts) vai pāriet uz termināļa (vai tīmekļa, ja tie ir plāni klienti un pārvaldītas veidlapas) serveri.

Ja dators nav sliktāks, tad varat nosist administratoru. Pārbaudiet vismaz tīkla, pretvīrusu un HASP aizsardzības draivera darbību.

Ja Gileva tests šajā posmā uzrādīja 30 "papagaiļus" un vairāk, bet 1C darba bāze joprojām darbojas lēni - jautājumi jau ir programmētājam.

1. Lai orientētu, cik daudz klienta dators var "izspiest", mēs pārbaudām tikai šī datora darbību, bez tīkla. Testa bāzi ievietojām lokālajā datorā (ļoti ātrā diskā). Ja klienta datoram nav parastā SSD, tad tiek izveidots RAM disks. Līdz šim vienkāršākais un bezmaksas ir Ramdisk uzņēmums.

Lai pārbaudītu versiju 8.2, pietiek ar 256 MB RAM diska, un! Svarīgākā. Pēc datora restartēšanas ar strādājošu RAM disku tam vajadzētu būt brīvam 100–200 MB. Attiecīgi bez ramdiska normālai brīvās atmiņas darbībai vajadzētu būt 300–400 MB.

8.3 versijas testēšanai pietiek ar 256 MB RAM, bet ir nepieciešams vairāk brīvas RAM.

Pārbaudot, jāskatās procesora slodze. Gadījumā, kas ir tuvu ideālam (RAM disks), lokālais fails 1c darbības laikā ielādē 1 procesora kodolu. Attiecīgi, ja testēšanas laikā procesora kodols nav pilnībā ielādēts, meklējiet trūkumus. Nedaudz emocionāla, bet kopumā pareiza ir aprakstīta procesora ietekme uz 1C darbību. Tikai atsaucei, pat mūsdienu Core i3 ar augstu frekvenci skaitļi 70-80 ir diezgan reāli.

Biežākās kļūdas šajā posmā.

a) Nepareizi konfigurēts antivīruss. Antivīrusu ir daudz, iestatījumi katram ir atšķirīgi, varu tikai teikt, ka ar pareizu konfigurāciju netraucē ne tīmeklis, ne Kaspersky 1C. Ar "noklusējuma" iestatījumiem - apmēram 3-5 papagaiļus (10-15%) var aizvest.

b) Izpildes režīms. Kādu iemeslu dēļ daži cilvēki tam pievērš uzmanību, un efekts ir visnozīmīgākais. Ja nepieciešams ātrums, tad tas jādara gan klienta, gan servera datoros. (Gilev ir labs apraksts. Vienīgais brīdinājums ir tāds, ka uz dažām mātesplatēm, ja Intel SpeedStep ir izslēgts, tad TurboBoost nevar ieslēgt).

Īsāk sakot, 1C darbības laikā ir daudz jāgaida atbilde no citām ierīcēm (diska, tīkla utt.). Gaidot atbildi, ja veiktspējas režīms ir līdzsvarots, procesors samazina frekvenci. No ierīces nāk atbilde, 1C (procesoram) ir jādarbojas, bet pirmie cikli notiek ar samazinātu frekvenci, pēc tam frekvence palielinās - un 1C atkal gaida atbildi no ierīces. Un tā - daudzus simtus reižu sekundē.

Varat (un vēlams) iespējot veiktspējas režīmu divās vietās:

Caur BIOS. Atspējot C1, C1E, Intel C-state (C2, C3, C4) režīmus. Dažādos bios tos sauc atšķirīgi, bet nozīme ir vienāda. Meklējiet ilgu laiku, ir nepieciešama atsāknēšana, bet, ja jūs to izdarījāt vienu reizi, varat aizmirst. Ja BIOS viss ir izdarīts pareizi, ātrums tiks pievienots. Dažās mātesplatēs BIOS iestatījumus var iestatīt tā, lai Windows veiktspējas režīmam nebūtu nozīmes. (Gileva BIOS iestatīšanas piemēri). Šie iestatījumi galvenokārt attiecas uz servera procesoriem vai "uzlabotajām" BIOS, ja jūs to neesat atradis savā sistēmā un jums nav Xeon - tas ir labi.

Vadības panelis — jauda — augsta veiktspēja. Mīnuss - ja dators ilgstoši nav ticis apkopts, tad ar ventilatoru tas zumēs spēcīgāk, vairāk uzkarsīs un patērēs vairāk enerģijas. Tā ir veiktspējas cena.

Kā pārbaudīt, vai režīms ir iespējots. Palaidiet uzdevumu pārvaldnieku — veiktspēja — resursu monitors — centrālais procesors. Mēs gaidām, līdz procesors ir aizņemts ar neko.

Šie ir noklusējuma iestatījumi.

BIOS C stāvoklis iekļauts,

līdzsvarotas jaudas režīms

BIOS C stāvoklis iekļauts, augstas veiktspējas režīms

Attiecībā uz Pentium un Core varat apstāties pie tā,

jūs joprojām varat izspiest dažus "papagaiļus" no Xeon

BIOS C stāvoklis izslēgts, augstas veiktspējas režīms.

Ja neizmantojat Turbo boost - šādi tam vajadzētu izskatīties

serveris ir pielāgots veiktspējai

Un tagad skaitļi. Atgādināšu: Intel Xeon 5650, RAM disks. Pirmajā gadījumā tests uzrāda 23,26, otrajā - 49,5. Atšķirība ir gandrīz divkārša. Skaitļi var atšķirties, taču attiecība Intel Core paliek gandrīz tāda pati.

Cienījamie administratori, jūs varat lamāt 1C, kā vēlaties, bet, ja lietotājiem ir nepieciešams ātrums, jums ir jāiespējo augstas veiktspējas režīms.

c) Turbo Boost. Vispirms jums ir jāsaprot, vai, piemēram, jūsu procesors atbalsta šo funkciju. Ja tas tā notiek, jūs joprojām varat likumīgi iegūt kādu sniegumu. (Es nevēlos pieskarties pārtaktēšanas problēmām, it īpaši serveriem, dariet to uz savu risku un risku. Taču piekrītu, ka autobusa ātruma palielināšana no 133 uz 166 dod ļoti jūtamu ātruma un siltuma izkliedes pieaugumu)

Kā ieslēgt turbo boost ir rakstīts, piemēram,. Bet! 1C ir dažas nianses (nav acīmredzamākās). Grūtības ir tādas, ka maksimālais turbo pastiprinājuma efekts izpaužas, kad ir ieslēgts C stāvoklis. Un izrādās kaut kas līdzīgs šim attēlam:

Lūdzu, ņemiet vērā, ka reizinātājs ir maksimālais, kodola ātrums ir visskaistākais, veiktspēja ir augsta. Bet kas notiks 1s rezultātā?

	Faktors	Kodola ātrums (frekvence), GHz	CPU-Z viens pavediens	Gileva Ramdiska tests faila versija	Gileva Ramdiska tests klients-serveris
bez turbo pastiprinājuma
C-stāvoklis izslēgts, turbo pastiprinājums				53.19	40,32
C-stāvoklis ieslēgts, turbo pastiprinājums			1080	53,13	23,04

Bet beigās izrādās, ka pēc CPU veiktspējas testiem priekšā ir variants ar reizinātāju 23, pēc Gileva testiem faila versijā veiktspēja ar reizinātāju 22 un 23 ir tāda pati, bet klienta-servera versija, variants ar reizinātāju 23 horror horror horror (pat ja C -state ir iestatīts uz 7 līmeni, tas joprojām ir lēnāks nekā ar C-state izslēgtu). Tāpēc ieteikums, pārbaudiet paši abas iespējas un izvēlieties no tām labāko. Jebkurā gadījumā atšķirība starp 49,5 un 53 papagaiļiem ir diezgan ievērojama, jo īpaši tāpēc, ka tas ir bez lielas piepūles.

Secinājums - turbo boost ir jāiekļauj. Atgādināšu, ka nepietiek tikai ar Turbo boost vienuma iespējošanu BIOS, jums ir jāapskata arī citi iestatījumi (BIOS: QPI L0s, L1 - atspējot, pieprasīt skrāpēšanu - atspējot, Intel SpeedStep - iespējot, Turbo boost - Iespējot. Vadības panelis — barošana — augsta veiktspēja) . Un es joprojām (pat faila versijai) apstātos pie opcijas, kur c-state ir izslēgts, lai gan reizinātājs tur ir mazāks. Iegūstiet kaut ko līdzīgu...

Diezgan strīdīgs punkts ir atmiņas frekvence. Piemēram, atmiņas frekvence tiek parādīta kā ļoti ietekmīga. Mani testi neatklāja šādu atkarību. Es nesalīdzināšu DDR 2/3/4, es parādīšu frekvences maiņas rezultātus vienas līnijas ietvaros. Atmiņa ir tāda pati, bet BIOS mēs piespiežam zemākas frekvences.

Un testa rezultāti. 1C 8.2.19.83, faila versijai vietējais RAM disks, klienta-servera 1C un SQL vienā datorā, koplietojamā atmiņa. Turbo pastiprināšana ir atspējota abās opcijās. 8.3 parāda salīdzināmus rezultātus.

Atšķirība ir mērījumu kļūdas robežās. Es īpaši izvilku CPU-Z ekrānuzņēmumus, lai parādītu, ka citi parametri mainās līdz ar frekvences maiņu, tas pats CAS latentums un RAS uz CAS aizkavi, kas izlīdzina frekvences izmaiņas. Atšķirība būs tad, kad atmiņas moduļi fiziski mainīsies, no lēnāka uz ātrāku, taču arī tur skaitļi nav īpaši būtiski.

2. Kad esam izdomājuši klienta datora procesoru un atmiņu, pārejam uz nākamo ļoti svarīgo vietu - tīklu. Par tīkla skaņošanu ir uzrakstīts daudz grāmatu, ir raksti par Infostart (un citi), šeit es nekoncentrēšos uz šo tēmu. Pirms sākat testēt 1C, lūdzu, pārliecinieties, vai iperf starp diviem datoriem parāda visu joslu (1 Gbit kartēm - nu, vismaz 850 Mbit, bet labāk 950-980), ka tiek ievērots Gilev padoms. Tad - visvienkāršākā darba pārbaude, dīvainā kārtā, būs viena liela faila (5-10 gigabaiti) kopēšana tīklā. Netieša normālas darbības pazīme tīklā 1 Gb / s būs vidējais kopēšanas ātrums 100 Mb / s, labs darbs - 120 Mb / s. Es gribu vērst jūsu uzmanību uz to, ka procesora slodze var būt arī vājā vieta (ieskaitot). MVU Linux protokols ir diezgan vāji paralēls, un darbības laikā tas var diezgan viegli “apēst” vienu procesora kodolu un to vairs nepatērēt.

Un tālāk. Ar noklusējuma iestatījumiem Windows klients vislabāk darbojas ar Windows serveri (vai pat Windows darbstaciju) un SMB / CIFS protokolu, linux klients (debian, ubuntu neapskatīja pārējos) vislabāk darbojas ar linux un NFS (tas darbojas arī ar SMB, bet par NFS papagaiļiem iepriekš). Tas, ka lineāri kopējot win-linux serveri uz nfs ātrāk tiek kopēts vienā straumē, neko nenozīmē. Debian skaņošana priekš 1C ir atsevišķa raksta tēma, vēl neesmu tam gatavs, lai gan varu teikt, ka faila versijā pat ieguvu nedaudz labāku veiktspēju nekā Win versija uz tās pašas iekārtas, bet ar postgres ar lietotāji virs 50 Man joprojām viss ir ļoti slikti.

Svarīgākā , kas zināms "sadedzinātajiem" administratoriem, bet iesācēji neņem vērā. Ir daudzi veidi, kā iestatīt ceļu uz 1c datu bāzi. Varat veikt \\serveris\share, varat \\192.168.0.1\share, varat neto izmantot z: \\192.168.0.1\share (un dažos gadījumos šī metode arī darbosies, bet ne vienmēr) un pēc tam norādīt Z disks. Šķiet, ka visi šie ceļi norāda uz vienu un to pašu vietu, bet 1C ir tikai viens veids, kas nodrošina diezgan stabilu veiktspēju. Tātad, lūk, kas jums jādara pareizi:

Komandrindā (vai politikās vai jebkurā jums piemērotā veidā) izmantojiet DriveLetter: \\serveris\share. Piemērs: neto izmantošana m:\\serveris\bāzes. Es īpaši uzsveru NE IP adresi, proti Vārds serveris. Ja serveris nav redzams pēc nosaukuma, pievienojiet to servera dns vai lokāli hosts failam. Bet apelācijai jābūt ar nosaukumu. Attiecīgi pa ceļam uz datu bāzi piekļūstiet šim diskam (skat. attēlu).

Un tagad es parādīšu skaitļos, kāpēc šāds padoms. Sākotnējie dati: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kartes.OS Win 2008 R2, Win 7, Debian 8. Jaunākie draiveri, lietoti atjauninājumi. Pirms testēšanas pārliecinājos, ka Iperf dod pilnu joslas platumu (izņemot 10 Gbit kartes, izrādījās, ka izspiež tikai 7,2 Gbit, vēlāk paskatīšos kāpēc, testa serveris vēl nav pareizi nokonfigurēts). Diski ir dažādi, bet visur ir SSD (speciāli ievietots viens disks testēšanai, nekas cits netiek ielādēts) vai reids no SSD. Ātrums 100 Mbit tika iegūts, ierobežojot adaptera Intel 362 iestatījumus.Nebija atšķirības starp 1 Gbit vara Intel 350 un 1 Gbit optiku Intel X520-DA2 (iegūta, ierobežojot adaptera ātrumu). Maksimālā veiktspēja, turbo boost ir atspējots (tikai rezultātu salīdzināmības labad, turbo boost pievieno nedaudz mazāk par 10%, lai iegūtu labus rezultātus, sliktiem rezultātiem tas var neietekmēt vispār). Versijas 1C 8.2.19.86, 8.3.6.2076. Nedodu visus skaitļus, bet tikai interesantākos, lai ir ar ko salīdzināt.

	Win 2008 - Win 2008 zvanot pēc ip adreses	Win 2008 - Win 2008 Adrese pēc vārda	Win 2008 - Win 2008 Zvanu pēc ip adreses	Win 2008 - Win 2008 Adrese pēc vārda	Win 2008 — Win 7 Adrese pēc vārda	Windows 2008 — Debian Adrese pēc vārda	Win 2008 - Win 2008 Zvanu pēc ip adreses	Win 2008 - Win 2008 Adrese pēc vārda
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Secinājumi (no tabulas un no personīgās pieredzes. Attiecas tikai uz faila versiju):

Tīklā jūs varat iegūt diezgan parastus skaitļus darbam, ja šis tīkls ir normāli konfigurēts un ceļš ir pareizi uzrakstīts 1C. Pat pirmie Core i3 var dot 40+ papagaiļus, kas ir diezgan labi, un tie nav tikai papagaiļi, reālajā darbā atšķirība ir arī manāma. Bet! ierobežojums strādājot ar vairākiem (vairāk nekā 10) lietotājiem vairs nebūs tīkls, šeit joprojām pietiek ar 1 Gbit, bet bloķēšana vairāku lietotāju darba laikā (Gilev).

1C 8.3 platforma ir daudzkārt prasīgāka kompetentai tīkla iestatīšanai. Pamatiestatījumi - skatiet Gilevu, taču paturiet prātā, ka viss var ietekmēt. Es redzēju paātrinājumu no tā, ka viņi atinstalēja (un ne tikai izslēdza) pretvīrusu, sākot no tādu protokolu kā FCoE noņemšanas, no draiveru maiņas uz vecāku, bet Microsoft sertificētu versiju (īpaši lētām kartēm, piemēram, asus un longs), un noņemot otrā tīkla karte no servera. Daudz iespēju, pārdomāti konfigurējiet tīklu. Var būt situācija, kad platforma 8.2 dod pieņemamus skaitļus, bet 8.3 - divas vai pat vairāk reizes mazāk. Mēģiniet paspēlēties ar platformas versijām 8.3, dažreiz jūs iegūstat ļoti lielu efektu.

1C 8.3.6.2076 (varbūt vēlāk, es vēl neesmu meklējis precīzu versiju) tīklā joprojām ir vieglāk iestatīt nekā 8.3.7.2008. No 8.3.2008., lai panāktu normālu tīkla darbību (salīdzināmos papagaiļos) tas izdevās tikai dažas reizes, nevarēju atkārtot vispārīgākam gadījumam. Neko daudz nesapratu, bet, spriežot pēc Process Explorer kāju lupatām, ieraksts tur nenotiek tā, kā 8.3.6.

Neskatoties uz to, ka, strādājot 100Mbps tīklā, tā slodzes grafiks ir neliels (var teikt, ka tīkls ir bezmaksas), darba ātrums joprojām ir daudz mazāks nekā 1 Gbps. Iemesls ir tīkla latentums.

Ceteris paribus (labi funkcionējošs tīkls) 1C 8.2, Intel-Realtek savienojums ir par 10% lēnāks nekā Intel-Intel. Bet realtek-realtek parasti var dot strauju iegrimšanu no zila gaisa. Tāpēc, ja ir nauda, labāk turēt Intel tīkla kartes visur, ja nav naudas, tad liec Intel tikai uz servera (savu KO). Jā, un instrukciju intel tīkla karšu noregulēšanai ir daudzkārt vairāk.

Antivīrusu noklusējuma iestatījumi (piemēram, drweb 10 versija) atņem apmēram 8-10% papagaiļu. Ja pareizi konfigurē (ļauj 1cv8 procesam darīt visu, lai gan tas nav droši) - ātrums ir tāds pats kā bez antivīrusa.

NElasiet Linux guru. Serveris ar samba ir lielisks un bezmaksas, bet ja uzliksi uz servera Win XP vai Win7 (vai vēl labāk - servera OS), tad failā 1c versija darbosies ātrāk. Jā, gan samba, gan protokolu steks, tīkla iestatījumi un daudz kas cits debian / ubuntu ir labi noregulēts, taču tas ir ieteicams speciālistiem. Nav jēgas instalēt Linux ar noklusējuma iestatījumiem un pēc tam teikt, ka tas ir lēns.

Ieteicams pārbaudīt diskus, kas savienoti, izmantojot tīklu, izmantojot fio . Vismaz būs skaidrs, vai tās ir problēmas ar 1C platformu vai tīklu / disku.

Viena lietotāja variantam es nevaru iedomāties testus (vai situāciju), kurā būtu redzama atšķirība starp 1 Gb un 10 Gb. Vienīgā vieta, kur 10Gbps faila versijai sniedza labākus rezultātus, bija disku savienošana, izmantojot iSCSI, taču šī ir atsevišķa raksta tēma. Tomēr domāju, ka faila versijai pietiek ar 1 Gbit kartēm.

Kāpēc ar 100 Mbit tīklu 8.3 darbojas ievērojami ātrāk nekā 8,2 - es nesaprotu, bet fakts notika. Visas pārējās iekārtas, visi pārējie iestatījumi ir tieši tādi paši, tikai vienā gadījumā tiek pārbaudīts 8.2, bet otrā - 8.3.

Nav noregulēts NFS win - win vai win-lin dod 6 papagaiļus, neiekļāva tabulā. Pēc noregulēšanas saņēmu 25, bet tas ir nestabils (uzskriešanās mērījumos ir vairāk nekā 2 vienības). Pagaidām nevaru sniegt ieteikumus par windows un NFS protokola lietošanu.

Pēc visiem iestatījumiem un pārbaudēm vēlreiz palaižam testu no klienta datora, priecājamies par uzlaboto rezultātu (ja izdevās). Ja rezultāts ir uzlabojies, ir vairāk nekā 30 papagaiļu (un jo īpaši vairāk nekā 40), vienlaikus strādā mazāk par 10 lietotājiem, un darba datubāze joprojām palēninās - gandrīz noteikti programmētāja problēma (vai arī jūs jau esat sasniedza faila versijas iespēju maksimumu).

termināļa serveris. (bāze atrodas serverī, klienti ir savienoti tīklā, RDP protokols). Soli pa solim algoritms:

0. Pievienojiet Gilev testa datubāzi serverim tajā pašā mapē, kurā atrodas galvenās datu bāzes. Mēs izveidojam savienojumu no tā paša servera un izpildām testu. Mēs atceramies rezultātu.

1. Tādā pašā veidā kā faila versijā mēs uzstādām darbu. Termināļa servera gadījumā galveno lomu parasti spēlē procesors (saprotams, ka nav acīmredzamu trūkumu, piemēram, atmiņas trūkums vai milzīgs daudzums nevajadzīgas programmatūras).

2. Tīkla karšu iestatīšana termināļa servera gadījumā praktiski neietekmē 1s darbību. Lai nodrošinātu "īpašu" komfortu, ja jūsu serveris izdod vairāk nekā 50 papagaiļus, varat spēlēt ar jaunām RDP protokola versijām, lai nodrošinātu lietotāju ērtības, ātrāku reakciju un ritināšanu.

3. Lielam lietotāju skaitam aktīvi darbojoties (un te jau var mēģināt pieslēgt vienai bāzei 30 cilvēkus, ja pamēģinās), ļoti vēlams uzstādīt SSD disku. Kādu iemeslu dēļ tiek uzskatīts, ka disks īpaši neietekmē 1C darbību, taču visi testi tiek veikti ar kontroliera kešatmiņu, kas ir iespējota rakstīšanai, kas ir nepareizi. Pārbaudes bāze ir maza, tā iekļaujas kešatmiņā, līdz ar to augstie skaitļi. Reālās (lielās) datu bāzēs viss būs pavisam savādāk, tāpēc kešatmiņa testiem ir atspējota.

Piemēram, es pārbaudīju Gilev testa darbu ar dažādām diska opcijām. Ieliku diskus no tā, kas bija pa rokai, lai tikai parādītu tendenci. Atšķirība starp 8.3.6.2076 un 8.3.7.2008 ir neliela (Ramdisk Turbo boost versijā 8.3.6 dod 56.18 un 8.3.7.2008 dod 55.56, citos testos atšķirība ir vēl mazāka). Enerģijas patēriņš - maksimāla veiktspēja, turbo pastiprināšana atspējota (ja nav norādīts citādi).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raids 10 4x SAS 10k	Raids 10 4x SAS 15k	Viens SSD	RAM disks		Kešatmiņa iespējota RAID kontrolieris
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Iekļautā RAID kontrollera kešatmiņa novērš visas atšķirības starp diskiem, cipari ir vienādi gan sat, gan sas. Pārbaude ar to nelielam datu apjomam ir bezjēdzīga un nav rādītājs.

8.2 platformai veiktspējas atšķirība starp SATA un SSD opcijām ir vairāk nekā divas reizes. Tā nav drukas kļūda. Ja paskatās uz veiktspējas monitoru SATA disku pārbaudes laikā. tad ir skaidri redzams "Aktīvā diska laiks (%)" 80-95. Jā, ja iespējosit pašu disku rakstīšanas kešatmiņu, ātrums palielināsies līdz 35, ja iespējosit raid kontrollera kešatmiņu - līdz 49 (neatkarīgi no tā, kuri diski šobrīd tiek pārbaudīti). Bet tie ir sintētiski kešatmiņas papagaiļi, reālā darbā ar lielām datu bāzēm nekad nebūs 100% rakstīšanas kešatmiņas trāpījumu attiecība.

Pat lēto SSD (es testēju uz Agility 3) ātrums ir pietiekams, lai faila versija darbotos. Rakstīšanas resurss ir cita lieta, te jāskatās katrā konkrētajā gadījumā, skaidrs, ka Intel 3700 būs par kārtu augstāks, bet tur cena ir atbilstoša. Un jā, es saprotu, ka testējot SSD disku, es pārbaudu arī šī diska kešatmiņu lielākā mērā, reālie rezultāti būs mazāki.

Pareizākais (no mana viedokļa) risinājums būtu atvēlēt spoguļreidam 2 SSD diskus failu bāzei (vai vairākām failu bāzēm), nevis neko citu tur likt. Jā, ar spoguli SSD nolietojas tāpat, un tas ir mīnuss, bet vismaz tie ir kaut kā apdrošināti pret kļūdām kontroliera elektronikā.

Galvenās SSD disku priekšrocības faila versijai parādīsies, ja datu bāzu ir daudz, un katrā no tām ir vairāki lietotāji. Ja ir 1-2 bāzes un lietotāji aptuveni 10, tad pietiks ar SAS diskiem. (bet jebkurā gadījumā - paskaties uz šo disku ielādi, vismaz caur perfmonu).

Galvenās termināļa servera priekšrocības ir tādas, ka tam var būt ļoti vāji klienti, un tīkla iestatījumi termināļa serveri ietekmē daudz mazāk (atkal jūsu KO).

Secinājumi: ja palaižat Gilev testu termināļa serverī (no tā paša diska, kur atrodas darba datu bāzes) un tajos brīžos, kad darba datubāze palēninās, un Gilev tests uzrāda labu rezultātu (virs 30), tad lēns pie vainas galvenās darba datu bāzes darbība, visticamāk programmētājs.

Ja Gilev tests rāda mazus skaitļus, un tev ir gan procesors ar augstu frekvenci, gan ātrie diski, tad šeit administratoram vajag paņemt vismaz perfmon, un kaut kur ierakstīt visus rezultātus, un skatīties, novērot, izdarīt secinājumus. Nebūs galīgu padomu.

Klienta-servera opcija.

Pārbaudes tika veiktas tikai uz 8.2, tk. 8.3 versijā viss ir diezgan nopietni atkarīgs no versijas.

Testēšanai izvēlējos dažādas serveru iespējas un tīklus starp tiem, lai parādītu galvenās tendences.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Šķiedras kanāls-SSD	SQL: Xeon E5-2630 Fiber kanāls - SAS	SQL: Xeon E5-2630 Vietējais SSD	SQL: Xeon E5-2630 Šķiedras kanāls-SSD	SQL: Xeon E5-2630 Vietējais SSD	1C: Xeon 5650 =	1C: Xeon 5650 = koplietojamo atmiņu	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1С 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Šķiet, esmu izskatījusi visus interesantos variantus, ja interesē vēl kas - rakstiet komentāros, mēģināšu to izdarīt.

SAS krātuvē darbojas lēnāk nekā vietējie SSD, lai gan krātuvē ir lieli kešatmiņas izmēri. SSD, kā arī vietējās un uzglabāšanas sistēmas Gilev testam darbojas ar salīdzināmu ātrumu. Es nezinu nevienu standarta vairāku vītņu testu (ne tikai ierakstus, bet visu aprīkojumu), izņemot slodzi 1C no KC.

1C servera maiņa no 5520 uz 5650 nodrošināja gandrīz divkāršu veiktspēju. Jā, serveru konfigurācijas pilnībā nesakrīt, bet tas parāda tendenci (nekas pārsteidzošs).

Biežuma palielināšana SQL serverī, protams, dod efektu, bet ne tādu pašu kā 1C serverī, MS SQL Server lieliski spēj (ja tā prasāt) izmantot daudzkodolu un brīvu atmiņu.

Mainot tīklu starp 1C un SQL no 1 Gbps uz 10 Gbps, tiek iegūti aptuveni 10% papagaiļu. Gaidīts vairāk.

Koplietotās atmiņas iespējošana joprojām nodrošina efektu, lai gan ne 15%, kā aprakstīts. Noteikti dariet to, tas ir ātri un vienkārši. Ja instalēšanas laikā kāds SQL serverim iedeva nosauktu gadījumu, tad, lai 1C darbotos, servera nosaukums ir jānorāda nevis ar FQDN (darbosies tcp / ip), nevis caur lokālo resursdatoru vai tikai serveranosaukums, bet gan caur ServerName\InstanceName, lai piemērs zz-test\zztest. (Pretējā gadījumā tiks parādīta šāda DBVS kļūda: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: koplietojamā atmiņas bibliotēka, kas tika izmantota, lai izveidotu savienojumu ar SQL Server 2000, netika atrasta. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005:, SQLSTATE=08001, stāvoklis=1, nopietnība=10, native=126, rinda=0).

Lietotājiem, kas jaunāki par 100, vienīgais veids, kā sadalīt divos atsevišķos serveros, ir Win 2008 Std (un vecāku versiju) licence, kas atbalsta tikai 32 GB RAM. Visos citos gadījumos 1C un SQL noteikti jāinstalē vienā serverī un jāpiešķir vairāk (vismaz 64 GB) atmiņas. Atdot MS SQL mazāk par 24-28 GB RAM ir nepamatota alkatība (ja uzskatāt, ka jums tai ir pietiekami daudz atmiņas un viss darbojas labi, varbūt jums pietiktu ar 1C faila versiju?)

Par to, cik sliktāk virtuālajā mašīnā strādā 1C un SQL gūzma, ir atsevišķa raksta tēma (mājiens - manāmi sliktāk). Pat Hyper-V viss nav tik skaidrs...

Līdzsvarotās veiktspējas režīms ir slikts. Rezultāti labi saskan ar faila versiju.

Daudzi avoti saka, ka atkļūdošanas režīms (ragent.exe -debug) ievērojami samazina veiktspēju. Nu, pazemina, jā, bet es nesauktu 2-3% par būtisku efektu.