Performance 1s 8.3 faila versija. Failu datubāzes vājās vietas – kā no tām izvairīties (pēc nesenās pieredzes). Norādījumi migrēšanai no failu datu bāzes uz SQL
Pēc pārejas no 1C: Accounting 2.0 uz izdevumu 3.0, jaunās versijas ātrums kļūst lēnāks. Mēs apskatīsim šo problēmu šajā rakstā un sniegsim soli pa solim norādījumus par darbībām programmā 1C: Accounting 3.0, kas palīdzēs paātrināt tās darbību.
Parasti programmas lēnas darbības iemesls ir fakts, ka sistēmā darbojas rutīnas un fona darbi. Versijas 3.0 konfigurācijas servera versijā tie ļauj automatizēt daudzas darbības, lai uzturētu programmu ārpus darba laika. Bet faila darbības režīmā fona darbi tiek palaisti, kamēr lietotājs strādā, un tāpēc sistēma palēninās.
Lai paātrinātu darbu 1C: Accounting 3.0 faila režīmā, ieteicams atspējot fona darbus. Lai to izdarītu, mums ir jāatsaucas uz sadaļu Administrācija. Šajā navigācijas paneļa sadaļā mēs atrodam Atbalsts un serviss.
Atveriet sadaļu Regulējošās darbības un pēc tam noklikšķiniet uz saites Rutīnas un fona uzdevumi.
Jūsu priekšā parādīsies saraksts, kurā ir atzīmēti aktīvie (iespējotie) uzdevumi. 
Lai atspējotu uzdevumu, tas ir jāatver un jānoņem izvēles rūtiņa "Iespējots", pēc tam nospiediet pogu Saglabājiet un aizveriet.
Strādājot programmas faila versijā, mēs iesakām atspējot visus sarakstā esošos ikdienas uzdevumus. Vēl viens iespējamais sistēmas zemā ātruma iemesls ir iespējotais mehānisms Pilna teksta meklēšana. Tā kā programmā 1C: Accounting 3.0 šis mehānisms nav obligāts, tas var būt atspējot. Lai to izdarītu, jums jāiet uz sadaļu Regulējošās darbības noņemiet atzīmi Pilna teksta datu meklēšana.
Mēs bieži saņemam jautājumus par to, kas palēnina 1c, it īpaši, pārejot uz versiju 1c 8.3, pateicoties mūsu kolēģiem no Interface LLC, mēs jums pastāstām sīkāk:
Iepriekšējās publikācijās mēs jau pieskārāmies diska apakšsistēmas veiktspējas ietekmei uz 1C ātrumu, taču šis pētījums attiecās uz lietojumprogrammas lokālu izmantošanu atsevišķā datorā vai termināļa serverī. Tajā pašā laikā lielākā daļa mazo implementāciju ietver darbu ar failu datu bāzi tīklā, kur viens no lietotāja datoriem tiek izmantots kā serveris, vai speciālu failu serveri, kura pamatā ir parasts, visbiežāk arī lēts dators.
Neliels pētījums par 1C krievu valodas resursiem parādīja, ka no šīs problēmas tiek rūpīgi izvairīties, ja rodas problēmas, parasti ieteicams pārslēgties uz klienta-servera vai termināļa režīmu. Gandrīz vispārpieņemts ir arī tas, ka pārvaldītās lietojumprogrammas konfigurācijas darbojas daudz lēnāk nekā parasti. Parasti norādītie argumenti ir “dzelzs”: “Grāmatvedība 2.0 tikko lidoja, bet “troika” tik tikko pakustējās”, protams, šajos vārdos ir daļa patiesības, tāpēc mēģināsim to izdomāt.
Resursu patēriņš, pirmais skatiens
Pirms šī pētījuma sākšanas mēs izvirzījām divus mērķus: noskaidrot, vai pārvaldītās lietojumprogrammu konfigurācijas patiešām ir lēnākas nekā parastās konfigurācijas un kuri konkrētie resursi galvenokārt ietekmē veiktspēju.
Testēšanai mēs paņēmām divas virtuālās mašīnas, kurās darbojas attiecīgi Windows Server 2012 R2 un Windows 8.1, piešķirot tām 2 resursdatora Core i5-4670 kodolus un 2 GB RAM, kas aptuveni atbilst vidējai biroja mašīnai. Serveris tika ievietots divu WD Se RAID 0 masīvā, un klients tika novietots līdzīgā vispārējas nozīmes disku masīvā.
Kā eksperimentālo pamatu mēs izvēlējāmies vairākas grāmatvedības 2.0 versijas konfigurācijas 2.0.64.12 , kas pēc tam tika atjaunināts uz 3.0.38.52 , visas konfigurācijas tika palaistas platformā 8.3.5.1443 .
Pirmā lieta, kas piesaista uzmanību, ir palielinātais Troikas informācijas bāzes apjoms, kas ir ievērojami pieaudzis, kā arī daudz lielāka apetīte pēc RAM:
Mēs esam gatavi dzirdēt ierasto: "kāpēc viņi to pievienoja šiem trim", bet nesteigsimies. Atšķirībā no klienta-servera versiju lietotājiem, kam nepieciešams vairāk vai mazāk kvalificēts administrators, failu versiju lietotāji reti domā par datu bāzu uzturēšanu. Arī specializēto uzņēmumu darbinieki, kas apkalpo (lasi atjaunina) šīs datu bāzes, par to aizdomājas reti.
Tikmēr 1C informācijas bāze ir pilnvērtīga sava formāta DBVS, kurai arī nepieciešama apkope, un tam ir pat rīks ar nosaukumu Informācijas bāzes pārbaude un labošana. Iespējams, nosaukums izspēlēja nežēlīgu joku, kas kaut kā nozīmē, ka tas ir problēmu novēršanas rīks, taču problēma ir arī zema veiktspēja, un pārstrukturēšana un pārindeksēšana, kā arī tabulu saspiešana ir labi zināmi rīki datu bāzu optimizēšanai jebkuram DBVS administratoram. . Pārbaudīsim?
Pēc izvēlēto darbību veikšanas datubāze strauji “zaudēja svaru”, kļūstot pat mazāka par “divām”, kuras neviens nekad nebija optimizējis, un arī RAM patēriņš nedaudz samazinājās.
Pēc tam pēc jaunu klasifikatoru un direktoriju ielādes, indeksu izveides utt. pamatnes izmērs palielināsies; kopumā “trīs” pamatnes ir lielākas nekā “divas” pamatnes. Taču tas nav svarīgāk, ja otrajā versijā pietika ar 150-200 MB operatīvo atmiņu, tad jaunajam izdevumam nepieciešams pusgigabaits un šī vērtība būtu jāņem vērā, plānojot darbam ar programmu nepieciešamos resursus.
Tīkls
Tīkla joslas platums ir viens no svarīgākajiem tīkla lietojumprogrammu parametriem, jo īpaši, piemēram, 1C faila režīmā, kas tīklā pārvieto ievērojamu datu apjomu. Lielākā daļa mazo uzņēmumu tīklu ir veidoti uz lētu 100 Mbit/s iekārtu bāzes, tāpēc mēs sākām testēšanu, salīdzinot 1C veiktspējas rādītājus 100 Mbit/s un 1 Gbit/s tīklos.
Kas notiek, kad tīklā palaižat 1C failu datu bāzi? Klients pagaidu mapēs lejupielādē diezgan lielu informācijas daudzumu, it īpaši, ja tas ir pirmais, “aukstais” sākums. Sagaidāms, ka pie 100 Mbit/s mēs sasniegsim kanāla platumu, un lejupielāde var aizņemt ievērojamu laiku, mūsu gadījumā apmēram 40 sekundes (grafikas sadalīšanas izmaksas ir 4 sekundes).
Otrā palaišana ir ātrāka, jo daži dati tiek saglabāti kešatmiņā un paliek tur līdz atsāknēšanai. Pārslēgšanās uz gigabitu tīklu var ievērojami paātrināt programmas ielādi gan “aukstā”, gan “karstā”, un vērtību attiecība tiek ievērota. Tāpēc mēs nolēmām rezultātu izteikt relatīvās vērtībās, katra mērījuma lielāko vērtību ņemot par 100%:
Kā redzams no grafikiem, Accounting 2.0 ielādējas jebkurā tīkla ātrumā divas reizes ātrāk, pāreja no 100 Mbit/s uz 1 Gbit/s ļauj četras reizes paātrināt lejupielādes laiku. Šajā režīmā nav nekādas atšķirības starp optimizētajām un neoptimizētajām "troikas" datu bāzēm.
Mēs pārbaudījām arī tīkla ātruma ietekmi uz darbību smagos režīmos, piemēram, grupu pārsūtīšanas laikā. Rezultātu izsaka arī relatīvās vērtībās:
Šeit ir interesantāk, optimizētā “trīs” bāze 100 Mbit/s tīklā darbojas ar tādu pašu ātrumu kā “divi”, un neoptimizētā uzrāda divreiz sliktākus rezultātus. Gigabitā attiecības paliek nemainīgas, arī neoptimizētais “trīs” ir uz pusi lēnāks nekā “divi”, bet optimizētais atpaliek par trešdaļu. Tāpat pāreja uz 1 Gbit/s ļauj samazināt izpildes laiku trīs reizes izdevumam 2.0 un uz pusi 3.0.
Lai novērtētu tīkla ātruma ietekmi uz ikdienas darbu, izmantojām Veiktspējas mērīšana, veicot iepriekš noteiktu darbību secību katrā datu bāzē.
Faktiski ikdienas uzdevumiem tīkla caurlaidspēja nav sašaurinājums, neoptimizēts "trīs" ir tikai par 20% lēnāks nekā "divi", un pēc optimizācijas tas izrādās tikpat ātrāks - priekšrocības strādājot plānā klienta režīmā ir acīmredzamas. Pāreja uz 1 Gbit/s optimizētajai bāzei nedod nekādas priekšrocības, un neoptimizētais un abi sāk darboties ātrāk, uzrādot nelielu atšķirību savā starpā.
Pēc veiktajām pārbaudēm kļūst skaidrs, ka tīkls nav šķērslis jaunajām konfigurācijām, un pārvaldītā aplikācija darbojas pat ātrāk nekā parasti. Varat arī ieteikt pārslēgties uz 1 Gbit/s, ja jums ir kritiski svarīgi uzdevumi un datu bāzes ielādes ātrums; citos gadījumos jaunas konfigurācijas ļauj efektīvi strādāt pat lēnos 100 Mbit/s tīklos.
Tātad, kāpēc 1C ir lēns? Mēs to izskatīsim sīkāk.
Servera diska apakšsistēma un SSD
Iepriekšējā rakstā mēs panācām 1C veiktspējas pieaugumu, ievietojot datu bāzes SSD. Varbūt servera diska apakšsistēmas veiktspēja ir nepietiekama? Diska servera veiktspēju mērījām grupas palaišanas laikā divās datu bāzēs uzreiz un saņēmām diezgan optimistisku rezultātu.
Neskatoties uz salīdzinoši lielo ievades/izvades operāciju skaitu sekundē (IOPS) – 913, rindas garums nepārsniedza 1,84, kas ir ļoti labs rezultāts divu disku masīvam. Pamatojoties uz to, mēs varam pieņemt, ka ar spoguli, kas izgatavots no parastajiem diskiem, pietiks normālai 8-10 tīkla klientu darbībai smagos režīmos.
Tātad, vai serverī ir nepieciešams SSD? Labākais veids, kā atbildēt uz šo jautājumu, būs testēšana, ko veicām ar līdzīgu metodi, tīkla savienojums visur ir 1 Gbit/s, rezultāts tiek izteikts arī relatīvās vērtībās.
Sāksim ar datu bāzes ielādes ātrumu.
Dažiem tas var šķist pārsteidzoši, taču serverī esošais SSD neietekmē datu bāzes ielādes ātrumu. Galvenais ierobežojošais faktors šeit, kā parādīja iepriekšējais tests, ir tīkla caurlaidspēja un klienta veiktspēja.
Pāriesim pie pārtaisīšanas:
Iepriekš jau atzīmējām, ka diska veiktspēja ir diezgan pietiekama pat darbam smagos režīmos, tāpēc arī SSD ātrums netiek ietekmēts, izņemot neoptimizēto bāzi, kas SSD ir panākusi optimizēto. Faktiski tas vēlreiz apstiprina, ka optimizācijas operācijas organizē informāciju datu bāzē, samazinot nejaušo I/O operāciju skaitu un palielinot piekļuves ātrumu tai.
Ikdienas uzdevumos attēls ir līdzīgs:
Tikai neoptimizētā datu bāze gūst labumu no SSD. Jūs, protams, varat iegādāties SSD, taču daudz labāk būtu padomāt par savlaicīgu datu bāzes uzturēšanu. Tāpat neaizmirstiet par sadaļas defragmentēšanu ar informācijas bāzēm serverī.
Klienta diska apakšsistēma un SSD
Iepriekšējā materiālā mēs apspriedām SSD ietekmi uz lokāli instalētā 1C darbības ātrumu; liela daļa no teiktā attiecas arī uz darbu tīkla režīmā. Patiešām, 1C diezgan aktīvi izmanto diska resursus, tostarp fona un ikdienas uzdevumiem. Zemāk esošajā attēlā varat redzēt, kā Accounting 3.0 diezgan aktīvi piekļūst diskam apmēram 40 sekundes pēc ielādes.
Taču tajā pašā laikā jāapzinās, ka darbstacijai, kurā notiek aktīvs darbs ar vienu vai divām informācijas datu bāzēm, parastā sērijveidā ražotā HDD veiktspējas resursi ir pilnīgi pietiekami. Iegādājoties SSD, dažus procesus var paātrināt, taču ikdienas darbā jūs nepamanīsiet radikālu paātrinājumu, jo, piemēram, lejupielādi ierobežos tīkla joslas platums.
Lēns cietais disks var palēnināt dažas darbības, bet pats par sevi nevar izraisīt programmas palēnināšanos.
RAM
Neskatoties uz to, ka operatīvā atmiņa tagad ir nepieklājīgi lēta, daudzas darbstacijas turpina strādāt ar tādu atmiņas apjomu, kāds tika instalēts iegādes brīdī. Šeit gaida pirmās problēmas. Pamatojoties uz to, ka vidējai “troikai” ir nepieciešami aptuveni 500 MB atmiņas, varam pieņemt, ka darbam ar programmu ar kopējo RAM apjomu 1 GB nepietiks.
Mēs samazinājām sistēmas atmiņu līdz 1 GB un palaidām divas informācijas datu bāzes.
No pirmā acu uzmetiena viss nav tik slikti, programma ir samazinājusi apetīti un labi iekļaujas pieejamajā atmiņā, taču neaizmirsīsim, ka nepieciešamība pēc operatīvajiem datiem nav mainījusies, kur tad tā palika? Izmesti diskā, kešatmiņā, mijmaiņā utt., šīs operācijas būtība ir tāda, ka šobrīd nevajadzīgie dati tiek nosūtīti no ātrās RAM, kuras apjoms nav pietiekams, uz lēnu diska atmiņu.
Kur tas ved? Apskatīsim, kā tiek izmantoti sistēmas resursi smagās operācijās, piemēram, uzsāksim grupas pārsūtīšanu uzreiz divās datu bāzēs. Vispirms sistēmā ar 2 GB RAM:
Kā redzam, sistēma aktīvi izmanto tīklu datu saņemšanai un procesoru to apstrādei, diska aktivitāte ir nenozīmīga, apstrādes laikā tā ik pa laikam palielinās, bet nav ierobežojošs faktors.
Tagad samazināsim atmiņu līdz 1 GB:
Situācija radikāli mainās, galvenā slodze tagad krīt uz cieto disku, procesors un tīkls ir dīkstāvē, gaidot, kad sistēma nolasīs nepieciešamos datus no diska atmiņā un nosūtīs tur nevajadzīgos datus.
Tajā pašā laikā pat subjektīvs darbs ar divām atvērtām datu bāzēm sistēmā ar 1 GB atmiņu izrādījās ārkārtīgi neērts; katalogi un žurnāli tika atvērti ar ievērojamu kavēšanos un aktīvu piekļuvi diskam. Piemēram, preču un pakalpojumu pārdošanas žurnāla atvēršana aizņēma apmēram 20 sekundes, un visu šo laiku to pavadīja liela diska aktivitāte (izcelta ar sarkanu līniju).
Lai objektīvi novērtētu RAM ietekmi uz konfigurāciju veiktspēju, pamatojoties uz pārvaldītu lietojumprogrammu, mēs veicām trīs mērījumus: pirmās datu bāzes ielādes ātrumu, otrās datu bāzes ielādes ātrumu un grupas atkārtotu palaišanu vienā no datu bāzēm. . Abas datu bāzes ir pilnīgi identiskas un tika izveidotas, kopējot optimizēto datu bāzi. Rezultātu izsaka relatīvās vienībās.
Rezultāts runā pats par sevi: ja ielādes laiks palielinās par aptuveni trešdaļu, kas joprojām ir diezgan pieļaujams, tad operāciju veikšanas laiks datu bāzē palielinās trīs reizes, nav jārunā par kaut kādu ērtu darbu šādos apstākļos. Starp citu, tas ir gadījums, kad SSD iegāde var uzlabot situāciju, taču daudz vienkāršāk (un lētāk) ir cīnīties ar cēloni, nevis ar sekām, un vienkārši iegādāties pareizo operatīvo atmiņu.
RAM trūkums ir galvenais iemesls, kāpēc darbs ar jaunām 1C konfigurācijām izrādās neērts. Konfigurācijas ar 2 GB atmiņu jāuzskata par minimāli piemērotām. Tajā pašā laikā paturiet prātā, ka mūsu gadījumā tika izveidoti “siltumnīcas” apstākļi: tīra sistēma, darbojās tikai 1C un uzdevumu pārvaldnieks. Reālajā dzīvē darba datorā parasti ir atvērta pārlūkprogramma, biroja komplekts, darbojas antivīruss utt. utt., Tāpēc ņemiet vērā, ka vienai datubāzei ir nepieciešami 500 MB, kā arī nedaudz rezerves, lai smagu operāciju laikā nesaskaras ar atmiņas trūkumu un strauju produktivitātes samazināšanos.
Procesors
Bez pārspīlējuma centrālo procesoru var saukt par datora sirdi, jo tas galu galā apstrādā visus aprēķinus. Lai novērtētu tā lomu, mēs veicām vēl vienu testu komplektu, tādu pašu kā RAM, samazinot virtuālajai mašīnai pieejamo kodolu skaitu no diviem līdz vienam, un tests tika veikts divas reizes ar atmiņas apjomu 1 GB un 2 GB.
Rezultāts izrādījās diezgan interesants un negaidīts: jaudīgāks procesors diezgan efektīvi uzņēmās slodzi, kad trūka resursu, pārējā laikā nedodot nekādas taustāmas priekšrocības. 1C Enterprise diez vai var saukt par lietojumprogrammu, kas aktīvi izmanto procesora resursus, tā ir diezgan mazprasīga. Un sarežģītos apstākļos procesoru noslogo ne tik daudz pašas aplikācijas datu aprēķināšana, bet pieskaitāmo izmaksu apkalpošana: papildu ievades/izvades operācijas utt.
secinājumus
Tātad, kāpēc 1C ir lēns? Pirmkārt, tas ir RAM trūkums, galvenā slodze šajā gadījumā krīt uz cieto disku un procesoru. Un, ja tie nespīd ar veiktspēju, kā tas parasti notiek biroja konfigurācijās, tad mēs iegūstam situāciju, kas aprakstīta raksta sākumā - “divi” strādāja labi, bet “trīs” ir bezdievīgi lēni.
Otrajā vietā ir tīkla veiktspēja, lēns 100 Mbit/s kanāls var kļūt par īstu sašaurinājumu, bet tajā pašā laikā plānā klienta režīms spēj uzturēt diezgan komfortablu darbības līmeni pat lēnos kanālos.
Tad jums vajadzētu pievērst uzmanību diskdzinim, maz ticams, ka SSD iegāde būs labs ieguldījums, taču diska nomaiņa pret modernāku būtu laba ideja. Atšķirību starp cieto disku paaudzēm var novērtēt no šāda materiāla: Pārskats par diviem lētiem Western Digital Blue sērijas diskdziņiem ar 500 GB un 1 TB.
Un visbeidzot procesors. Ātrāks modelis, protams, nebūs lieks, taču nav jēgas palielināt tā veiktspēju, ja vien šis dators netiek izmantots smagām darbībām: grupu apstrāde, smagas atskaites, mēneša beigu slēgšana utt.
Mēs ceram, ka šis materiāls palīdzēs jums ātri saprast jautājumu “kāpēc 1C ir lēns” un atrisināt to visefektīvāk un bez papildu izmaksām.
Pieaugot organizācijai un palielinoties 1C Enterprise informācijas bāzes lietotāju skaitam lokālajā datortīklā, palielinās slodze uz informācijas bāzes galveno krātuvi - serveri. Tāpēc agri vai vēlu uzņēmuma vadītājam un IT speciālistam var rasties jautājums: Kā nodrošināt ātru, drošu un efektīvu sistēmu ar viszemākajām finansiālajām izmaksām?
Pirmkārt, jums ir jāizvēlas korporatīvā automatizētā datoru kompleksa organizēšanas metode platformā 1C Enterprise 8. 1C platforma atbalsta divas darbības iespējas: failu un klients-serveris. Abos gadījumos visi lietojumprogrammu risinājumi darbojas tieši tāpat.
1C darba faila versija paredzēts vienam vai vairākiem lietotājiem darbam vietējā tīklā. Šajā gadījumā visi informācijas bāzes dati (konfigurācija, datubāze, administratīvā informācija) atrodas vienā failā - failu datu bāzē, kas izstrādāta īpaši 1C Enterprise 8 lietojumprogrammu risinājumiem.
Failu darbības režīma priekšrocības
- Optimāls nelielam lietotāju skaitam (līdz 5)
- Viegli uzstādīt un darbināt sistēmu
- Lai strādātu ar informācijas bāzi, nav nepieciešama papildu programmatūra, izņemot operētājsistēmu un 1C Enterprise 8
- Tiek samazināts datu integritātes pārkāpumu risks datora un lokālā tīkla kļūmju dēļ.
- Ērti izveidojiet dublējumus, vienkārši kopējot informācijas bāzes failu.
Darbs faila versijā ir iespējams gan tieši, tieši ar datu bāzes failu, gan caur tīmekļa serveri, ja klienta savienojumi tiek izmantoti caur HTTP vai HTTPS protokolu.
1C darba klienta-servera versija Paredzēts lietošanai dažādās nodaļās, darba grupās vai visā uzņēmumā. Tas ir ieviests, pamatojoties uz trīs līmeņu klienta-servera arhitektūru:
Klienta lietojumprogramma - 1C Enterprise serveru klasteris - Datu bāzes serveris
Klienta-servera versijā informācijas bāze tiek glabāta vienā no atbalstītajām DBVS: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. Klienta lietojumprogramma tai var piekļūt pēc vajadzības, izmantojot 1C Enterprise serveru kopu.
1C Enterprise 8 sistēmā ir trīs klientu lietojumprogrammas vai klients(programma, kas darbojas lietotājam) ar dažādām iespējām: biezais klients, plāns klients, tīmekļa klients.
Resnais klientsļauj realizēt visas 1C Enterprise 8 iespējas lietojumprogrammas koda izstrādes, administrēšanas un izpildes ziņā. Tomēr tas neatbalsta darbu ar informācijas datu bāzēm, izmantojot internetu, prasa iepriekšēju instalēšanu lietotāja datorā, un tam ir diezgan iespaidīgs izplatīšanas lielums.
Lietotāji bieži sūdzas, ka “1C 8.3 ir lēns”: dokumentu veidlapas atveras lēni, dokumentu apstrāde aizņem ilgu laiku, programma tiek startēta, pārskatu ģenerēšana prasa ilgu laiku utt.
Turklāt šādas "kļūmes" var rasties dažādās programmās:
Iemesli var būt dažādi. Tas nav atjaunoti dokumenti, vājš dators vai serveris, 1C serveris ir nepareizi konfigurēts.
Šajā rakstā es vēlos apskatīt vienu no vienkāršākajiem un visizplatītākajiem programmas lēnas darbības iemesliem - . Šī instrukcija būs aktuāla 1-2 lietotāju failu datu bāzu lietotājiem, kur nav konkurences par resursiem.
Ja jūs interesē nopietnāka klienta-servera opciju optimizācija sistēmas darbībai, apmeklējiet vietnes sadaļu.
Kur ir 1C 8.3 ieplānotie uzdevumi?
Pirms man bija laiks ielādēt programmu, daudzi fona uzdevumi tika pabeigti 1C. Tos var apskatīt, atverot izvēlni “Administrēšana” un pēc tam uz “Atbalsts un apkope”:
Saņemiet 267 video nodarbības 1C bez maksas:
Šādi izskatās logs ar pabeigtiem uzdevumiem:
Un šeit ir pilns saraksts ar visiem ieplānotajiem uzdevumiem, kas tiek palaisti:
Starp šiem uzdevumiem var redzēt, piemēram, “”, dažādu klasifikatoru ielādi, programmas versijas atbilstības pārbaudi utt. Piemēram, man nav jēgas gandrīz visiem šiem uzdevumiem. Es neveicu valūtu uzskaiti, es pats kontrolēju versijas un pēc vajadzības ielādēju klasifikatorus.
Attiecīgi manās (un vairumā gadījumu jūsu) interesēs ir atspējot nevajadzīgus uzdevumus.
Ikdienas un fona uzdevumu atspējošana 1C 8.3
Foto: Alena Tuļakova, ziņu aģentūra “Clerk.Ru”
Rakstā ir identificētas galvenās kļūdas, ko pieļauj iesācēju 1C administratori, un parādīts, kā tās atrisināt, izmantojot Gilev testu kā piemēru.
Galvenais šī raksta rakstīšanas mērķis ir izvairīties no acīmredzamu nianšu atkārtošanas tiem administratoriem (un programmētājiem), kuri vēl nav guvuši pieredzi ar 1C.
Sekundārais mērķis ir tāds, ka, ja man ir kādi trūkumi, Infostart man to visātrāk norādīs.
V. Gileva tests jau kļuvis par sava veida “de facto” standartu. Autors savā mājaslapā sniedza diezgan skaidrus ieteikumus, bet es vienkārši izklāstīš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 par to, kam vajadzētu būt un uz ko jūs varat tiekties. Uzreiz gribu atzīmēt, ka izmaiņas 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, ielikšu saites uz tiem attiecīgajās sadaļās (ja kaut ko palaidu garām, lūdzu, iesakiet komentāros, pievienošu). Tātad, pieņemsim, ka jūsu 1C ir lēns. 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ā jūrascūciņa: HP DL180G6, aprīkots ar 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Salīdzinājumam, Core i3-2100 uzrāda salīdzināmus rezultātus viena vītnes testā. Apzināti izvēlētais aprīkojums nebija jaunākais, ar modernu aprīkojumu rezultāti ir manāmi labāki.
Atsevišķu 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. (datubāze atrodas serverī koplietotā mapē, klienti savienojas caur tīklu, CIFS/SMB protokolu). Algoritms soli pa solim:
0. Pievienojiet Gilev testa datu bāzi failu serverim tajā pašā mapē, kurā atrodas galvenās datu bāzes. Mēs izveidojam savienojumu no klienta datora un izpildām testu. Mēs atceramies rezultātu.
Ir saprotams, ka pat veciem datoriem, kas ražoti pirms 10 gadiem (Pentium uz 775 ligzdas), laikam no 1C:Enterprise īsceļa noklikšķināšanas līdz datu bāzes loga parādīšanai vajadzētu aizņemt mazāk nekā minūti. (Celeron = lēns).
Ja jūsu dators ir sliktāks par Pentium uz 775 ligzdas 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ā. Padomājiet par jaunināšanu (pienācis laiks) vai pāreju uz termināļa (vai tīmekļa, ja tie ir plāni klienti un pārvaldītas formas) serveri.
Ja dators nav sliktāks, varat spert administratoru. Vismaz pārbaudiet tīkla, pretvīrusu un HASP aizsardzības draivera darbību.
Ja Gileva tests šajā posmā uzrādīja 30 “papagaiļus” vai vairāk, bet 1C darba bāze joprojām darbojas lēni, jautājumi jānosūta programmētājam.
1. Lai uzzinātu, cik daudz klienta dators var “izspiest”, mēs pārbaudām tikai šī datora darbību bez tīkla. Pārbaudes datubāzi instalējam lokālā datorā (ļoti ātrā diskā). Ja klienta datoram nav parastā SSD, tad tiek izveidots RAM disks. Pagaidām vienkāršākais un bezmaksas ir Ramdisk enterprise.
Lai pārbaudītu versiju 8.2, pietiek ar 256 MB RAM disku, un! Svarīgākā. Pēc datora pārstartēšanas, kad darbojas RAM disks, tajā jābūt brīvam 100–200 MB. Attiecīgi bez ramdiska normālai darbībai vajadzētu būt 300–400 MB brīvas atmiņas.
Lai pārbaudītu versiju 8.3, pietiek ar 256 MB RAM, taču jums 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 palaišanas laikā ielādē 1 procesora kodolu. Attiecīgi, ja testēšanas laikā procesora kodols nav pilnībā ielādēts, meklējiet vājās vietas. Nedaudz emocionāla, bet kopumā pareiza ir aprakstīta procesora ietekme uz 1C darbību. Tikai atsaucei, pat mūsdienu Core i3 ar augstām frekvencēm skaitļi 70-80 ir diezgan reāli.
Visbiežāk sastopamās kļūdas šajā posmā.
- Nepareizi konfigurēts antivīruss. Antivīrusu ir daudz, iestatījumi katram ir atšķirīgi, teikšu tikai to, ka ar pareizu konfigurāciju netraucē ne tīmeklis, ne Kaspersky 1C. Ar noklusējuma iestatījumiem var aizvest aptuveni 3-5 papagaiļus (10-15%).
- Izpildes režīms. Kādu iemeslu dēļ daži cilvēki tam pievērš uzmanību, taču efekts ir visnozīmīgākais. Ja jums ir nepieciešams ātrums, tas jādara gan klienta, gan servera datoros. (Gilev ir labs apraksts. Vienīgais brīdinājums ir tāds, ka dažās mātesplatēs, izslēdzot Intel SpeedStep, nevar ieslēgt TurboBoost).
Varat (un vēlams) iespējot veiktspējas režīmu divās vietās:
- caur BIOS. Atspējot režīmus C1, C1E, Intel C-state (C2, C3, C4). Dažādos bios tos sauc atšķirīgi, bet nozīme ir vienāda. Meklēšana prasa ilgu laiku, ir nepieciešama atsāknēšana, bet, ja jūs to darāt vienu reizi, varat to aizmirst. Ja visu izdarīsit pareizi BIOS, ātrums palielināsies. Dažās mātesplatēs varat konfigurēt BIOS iestatījumus, lai Windows veiktspējas režīmam nebūtu nozīmes. (BIOS iestatījumu piemēri no Gilev). Šie iestatījumi galvenokārt attiecas uz serveru procesoriem vai “uzlabotajām” BIOS, ja jūs to neesat atradis un jums NAV Xeon, tas ir labi.
- Vadības panelis - Barošanas avots - Augsta veiktspēja. Mīnuss - ja dators ilgstoši nav apkopts, tas radīs skaļāku ventilatora troksni, vairāk uzkarsīs un patērēs vairāk enerģijas. Šī ir maksa par sniegumu.
| Šie ir noklusējuma iestatījumi. BIOS C-state iespējots, līdzsvarots enerģijas patēriņa režīms |  |
| BIOS C-state iespējots, augstas veiktspējas režīms Attiecībā uz Pentium un Core varat apstāties pie tā, Jūs joprojām varat izspiest nedaudz "papagaiļus" no Xeon |  |
| BIOS C-stāvoklis ir atspējots, augstas veiktspējas režīms. Ja neizmantojat Turbo boost, tam vajadzētu izskatīties šādi 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, pēdējā - 49,5. Atšķirība ir gandrīz divkārša. Skaitļi var atšķirties, taču Intel Core attiecība būtībā paliek nemainīga.
Cienījamie administratori, jūs varat kritizēt 1C, cik vien vēlaties, taču, 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 atbalsta, jūs joprojām varat likumīgi iegūt kādu veiktspēju. (Es nevēlos pieskarties jautājumiem par frekvences pārspīlēšanu, 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 ievērojamu ā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 rodas, kad ir ieslēgts C-state. Un mēs iegūstam kaut ko līdzīgu:
Lūdzu, ņemiet vērā, ka reizinātājs ir maksimālais, kodola ātrums ir skaists un veiktspēja ir augsta. Bet kas notiks rezultātā ar 1s?
Bet beigās izrādās, ka pēc CPU veiktspējas testiem priekšā ir versija 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 klients-serveris versija - versija ar reizinātāju 23 ir šausmīgi briesmīga (pat ja C -state iestatīts uz 7 līmeni, tas joprojām ir lēnāks nekā ar C-state izslēgtu). Tāpēc ieteikums ir pašam pārbaudīt abas iespējas un izvēlēties labāko. Jebkurā gadījumā atšķirība starp 49,5 un 53 papagaiļiem ir diezgan ievērojama, īpaši bez lielas piepūles.
Secinājums - turbo boost ir jāieslēdz. 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šanas opcijas — Augsta veiktspēja) . Un es joprojām (pat faila versijai) izvēlētos opciju, kur c-state ir izslēgts, lai gan reizinātājs ir mazāks. Izrādīsies kaut kas līdzīgs šim...
Diezgan strīdīgs punkts ir atmiņas frekvence. Piemēram, ir pierādīts, ka atmiņas frekvencei ir ļoti spēcīga ietekme. 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 esam spiesti iestatīt 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 boost ir atspējots abās versijās. 8.3 parāda salīdzināmus rezultātus.
Atšķirība ir mērījumu kļūdas robežās. Es speciāli izvilku CPU-Z ekrānuzņēmumus, lai parādītu, ka, mainoties frekvencei, mainās arī citi parametri, tas pats CAS Latency un RAS uz CAS Delay, kas neitralizē frekvences izmaiņas. Atšķirība būs tad, kad fiziski tiks mainīti atmiņas moduļi, no lēnākiem uz ātrākiem, taču arī tur cipari nav īpaši būtiski.
2. Kad esam sakārtojuš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 sarakstīti daudzi grāmatu sējumi, ir raksti par Infostart (un citiem), taču šeit es nekoncentrēšos uz šo tēmu. Pirms 1C testēšanas, lūdzu, pārliecinieties, vai iperf starp diviem datoriem parāda visu joslas platumu (1 Gbit kartēm - vismaz 850 Mbit vai vēl labāk 950-980), ka Gileva padoms ir ievērots. Tad - visvienkāršākā darbības 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 1 Gbit tīklā būs vidējais kopēšanas ātrums 100 MB/sek, laba darbība - 120 MB/sek. Vēlos vērst jūsu uzmanību uz to, ka vājā vieta (ieskaitot) var būt procesora noslodze. SMB protokols operētājsistēmā Linux ir diezgan vāji paralēls, un darbības laikā tas var diezgan viegli “apēst” vienu procesora kodolu un 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 neskatījās uz pārējiem) darbojas labāk ar linux un NFS ( tas darbojas arī ar SMB, bet NFS papagaiļi ir garāki). Tas, ka lineārās kopēšanas laikā Windows Linux serveris uz NFS tiek ātrāk kopēts vienā straumē, neko nenozīmē. Debian tūnings priekš 1C ir atsevišķa raksta tēma, vēl neesmu tam gatavs, lai gan varu teikt, ka faila versijā dabūju pat nedaudz labāku sniegumu nekā Win versija uz tās pašas iekārtas, bet ar postgres ar over 50 lietotāji Man joprojām viss ir ļoti slikti.
Svarīgākais, ko zina “sadedzinājuši” administratori, bet iesācēji neņem vērā. Ir daudzi veidi, kā iestatīt ceļu uz 1c datu bāzi. Var veikt servershare, var 192.168.0.1share, var neto izmantot z: 192.168.0.1share (un dažos gadījumos šī metode arī derēs, bet ne vienmēr) un pēc tam norādīt disku Z. Šķiet, ka visi šie ceļi norāda uz vienu un to pašu lietu tajā pašā vietā, bet 1C ir tikai viena metode, kas nodrošina normālu veiktspēju diezgan uzticami. Tātad, tas ir jādara pareizi:
Komandrindā (vai politikās vai jebkurā jums ērtā veidā) izmantojiet DriveLetter: servershare. Piemērs: net use m: serverbase. Es īpaši uzsveru NE IP adresi, bet servera nosaukumu. Ja servera nosaukums nav redzams, pievienojiet to servera DNS vai lokāli hosts failam. Bet adresei jābūt pēc vārda. Attiecīgi pa ceļam uz datu bāzi piekļūstiet šim diskam (skat. attēlu).
Un tagad es parādīšu ar cipariem, kāpēc tas ir 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, izdevās izspiest tikai 7,2 Gbit, vēlāk redzēs kāpēc, testa serveris vēl nav pareizi konfigurēts). Diski ir dažādi, bet visur ir SSD (testēšanai speciāli ievietoju vienu disku, tur neko citu neielādē) 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 optisko Intel X520-DA2 (iegūts, ierobežojot adaptera ātrumu). Maksimālā veiktspēja, turbo boost ir izslēgts (tikai rezultātu salīdzināmības labad, turbo boost labiem rezultātiem pievieno nedaudz mazāk par 10%, sliktiem rezultātiem var nebūt nekādas ietekmes). Versijas 1C 8.2.19.86, 8.3.6.2076. Es nedodu visus skaitļus, bet tikai interesantākos, lai jums būtu ar ko salīdzināt.
| 100 Mbit CIFS Win 2008 - Win 2008 sazināties pēc ip adreses | 100 Mbit CIFS Win 2008 - Win 2008 sauc vārdā | 1 Gbit CIFS Win 2008 - Win 2008 sazināties pēc ip adreses | 1 Gbit CIFS Win 2008 - Win 2008 sauc vārdā | 1 Gbit CIFS Win 2008 — Win 7 sauc vārdā | 1 Gbit CIFS Win 2008 — Debian sauc vārdā | 10 Gbit CIFS Win 2008 - Win 2008 sazināties pēc ip adreses | 10 Gbit CIFS Win 2008 - Win 2008 sauc vārdā |
|
| 11,20 | 26,18 | 15,20 | 43,86 | 40,65 | 37,04 | 16,23 | 44,64 | |
| 1C 8.2 | 11,29 | 26,18 | 15,29 | 43,10 | 40,65 | 36,76 | 15,11 | 44,10 |
| 8.2.19.83 | 12,15 | 25,77 | 15,15 | 43,10 | 14,97 | 42,74 | ||
| 6,13 | 34,25 | 14,98 | 43,10 | 39,37 | 37,59 | 15,53 | 42,74 | |
| 1C 8.3 | 6,61 | 33,33 | 15,58 | 43,86 | 40,00 | 37,88 | 16,23 | 42,74 |
| 8.3.6.2076 | 33,78 | 15,53 | 43,48 | 39,37 | 37,59 | 42,74 |
Secinājumi (no tabulas un no personīgās pieredzes. Attiecas tikai uz faila versiju):
- Tīklā jūs varat iegūt diezgan normālus numurus darbam, ja šis tīkls ir pareizi konfigurēts un ceļš ir pareizi ievadīts 1C. Pat pirmais Core i3 var viegli saražot 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 pareizas tīkla konfigurācijas ziņā. Pamatiestatījumi - skatiet Gilevu, bet paturiet prātā, ka visu var ietekmēt. Es pamanīju paātrinājumu no antivīrusa atinstalēšanas (un ne tikai izslēgšanas), no protokolu, piemēram, 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 DLC), no otrās tīkla kartes noņemšanas. no servera. Ir daudz iespēju, rūpīgi iestatiet tīklu. Var būt situācija, ka platforma 8.2 dod pieņemamus skaitļus, bet 8.3 - divas vai pat vairāk reizes mazāk. Mēģiniet spēlēt 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) joprojām ir vieglāk konfigurējams tīklā nekā 8.3.7.2008. Normālu darbību pa tīklu no 8.3.2008. (salīdzināmos papagaiļos) varēju panākt tikai dažas reizes, vispārīgākam gadījumam nevarēju atkārtot. Neko daudz nesapratu, bet spriežot pēc pēdu aptinumiem no Process Explorer, ieraksts tur nav tik labs kā 8.3.6.
- Neskatoties uz to, ka, strādājot 100 Mbit tīklā, tā slodzes grafiks ir neliels (var teikt, ka tīkls ir bezmaksas), darbības ātrums joprojām ir daudz mazāks nekā 1 Gbit. Iemesls ir tīkla latentums.
- Ja visas pārējās lietas ir vienādas (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 jums ir nauda, labāk ir glabāt Intel tīkla kartes visur; ja jums nav naudas, instalējiet Intel tikai serverī (jūsu CO). Un Intel tīkla karšu noregulēšanai ir daudzkārt vairāk instrukciju.
- Noklusējuma pretvīrusu iestatījumi (kā piemēru izmantojot drweb versiju 10) aizņem apmēram 8–10% papagaiļu. Ja konfigurē tā, kā vajadzētu (ļauj 1cv8 procesam darīt visu, lai gan tas nav droši), ātrums ir tāds pats kā bez antivīrusa.
- NELASĪT Linux guru. Serveris ar samba ir lielisks un bezmaksas, bet, ja uz servera instalējat Win XP vai Win7 (vai vēl labāk - servera OS), tad 1c faila versija darbosies ātrāk. Jā, samba un protokolu steku un tīkla iestatījumus un daudz, daudz ko citu var labi noregulēt debian/ubuntu, 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.
- Diezgan laba ideja ir pārbaudīt disku darbību, kas savienotas, izmantojot tīklu, izmantojot fio . Vismaz būs skaidrs, vai tās ir problēmas ar 1C platformu, vai ar tīklu/disku.
- Viena lietotāja versijai es nevaru iedomāties testus (vai situāciju), kurā būtu redzama atšķirība starp 1 Gbit un 10 Gbit. Vienīgais, kur 10Gbit faila versijai deva labākus rezultātus, ir disku savienošana caur iSCSI, bet šī ir atsevišķa raksta tēma. Tomēr domāju, ka faila versijai pietiek ar 1 Gbit kartēm.
- Es nesaprotu, kāpēc ar 100 Mbit tīklu 8.3 darbojas ievērojami ātrāk nekā 8,2, bet tas bija fakts. Viss pārējais aprīkojums, visi pārējie iestatījumi ir absolūti vienādi, tikai vienā gadījumā tiek pārbaudīts 8.2, bet otrā - 8.3.
- Nenoskaņots NFS win-win vai win-lin dod 6 papagaiļus, es tos neiekļāvu tabulā. Pēc tūninga saņēmu 25, bet tas bija nestabils (mērījumu atšķirība bija vairāk nekā 2 vienības). Es vēl nevaru sniegt ieteikumus par Windows un NFS protokola lietošanu.
Termināļa serveris. (datubāze atrodas serverī, klienti savienojas caur tīklu, LAP protokolu). Algoritms soli pa solim:
- Mēs pievienojam Gilev testa datu bā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.
- Tieši tāpat kā faila versijā, mēs konfigurējam procesoru. Termināļa servera gadījumā galveno lomu parasti spēlē procesors (tiek pieņemts, ka nav acīmredzamu vājo vietu, piemēram, atmiņas trūkums vai milzīgs daudzums nevajadzīgas programmatūras).
- Tīkla karšu konfigurēšana termināļa servera gadījumā praktiski neietekmē 1c darbību. Lai nodrošinātu “īpašu” komfortu, ja jūsu serveris ražo vairāk nekā 50 papagaiļus, varat spēlēt ar jaunām RDP protokola versijām, tikai lietotāju ērtībām, ātrākai reakcijai un ritināšanai.
- Kad aktīvi strādā liels skaits lietotāju (un šeit jau var mēģināt pieslēgt vienai datubāzei 30 cilvēkus, ja pamēģini), ļ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. Testa bāze ir maza, diezgan labi iederas 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.
| Raid 10 4x SATA 7200 ATA ST31500341AS | Raids 10 4x SAS 10k | Raids 10 4x SAS 15k | Viens SSD | Ramdisks | Ramdisks | Kešatmiņa iespējota RAID kontrolieris |
|
| 21,74 | 28,09 | 32,47 | 49,02 | 50,51 | 53,76 | 49,02 | |
| 1C 8.2 | 21,65 | 28,57 | 32,05 | 48,54 | 49,02 | 53,19 | |
| 8.2.19.83 | 21,65 | 28,41 | 31,45 | 48,54 | 49,50 | 53,19 | |
| 33,33 | 42,74 | 45,05 | 51,55 | 52,08 | 55,56 | 51,55 | |
| 1C 8.3 | 33,46 | 42,02 | 45,05 | 51,02 | 52,08 | 54,95 | |
| 8.3.7.2008 | 35,46 | 43,01 | 44,64 | 51,55 | 52,08 | 56,18 |
- Iespējotā RAID kontrollera kešatmiņa novērš visas atšķirības starp diskiem; skaitļi ir vienādi gan sat, gan cas. Testēšana ar to ar nelielu datu apjomu ir bezjēdzīga, un tā neliecina par jebkādu veidu.
- Platformai 8.2 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 jūs varat skaidri redzēt “Aktīvā diska darbības laiks (%)” 80-95. Jā, ja ierakstīšanai iespējosit pašu disku kešatmiņu, ātrums palielināsies līdz 35, ja iespējosit reida kontrollera kešatmiņu - līdz 49 (neatkarīgi no tā, kuri diski šobrīd tiek pārbaudīti). Bet tie ir sintētiskie 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 pilnīgi pietiekams, lai palaistu faila versiju. Ierakstīšanas resurss ir cita lieta, jāskatās katrā konkrētajā gadījumā, skaidrs, ka Intel 3700 būs par kārtu augstāks, bet cena atbilstoša. Un jā, es saprotu, ka testējot SSD disku, testēju 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 spoguļraidā atvēlēt 2 SSD diskus failu datubāzei (vai vairākām failu datu bāzēm), nevis tur neko citu nelikt. Jā, ar spoguli SSD nolietojas vienādi, un tas ir mīnuss, bet vismaz kontroliera elektronika ir kaut kā pasargāta no kļūdām.
- Galvenās SSD diskdziņu priekšrocības faila versijai parādīsies, kad ir daudz datu bāzu, katrā no kurām ir vairāki lietotāji. Ja ir 1-2 datu bāzes un ir kādi 10 lietotāji, tad pietiks ar SAS diskiem. (bet jebkurā gadījumā apskatiet šo disku ielādi, vismaz caur perfmon).
- 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 K.O.).
Ja Gileva tests uzrāda mazus skaitļus un jums ir procesors ar augstu takts ātrumu un ātrie diski, tad administratoram ir jāpaņem vismaz perfmon, kaut kur ierakstot visus rezultātus un jāskatās, jānovēro un jāizdara secinājumi. Nebūs galīgu padomu.
Klienta-servera opcija.
Pārbaudes tika veiktas tikai 8.2, jo uz 8.3 viss 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.
| 1C: Xeon 5520 SQL: Xeon E5-2630 | 1C: Xeon 5520 SQL: Xeon E5-2630 Šķiedru kanāls - SSD | 1C: Xeon 5520 SQL: Xeon E5-2630 Fiber kanāls - SAS | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 SQL: Xeon E5-2630 Šķiedru kanāls - SSD | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | |
| 16,78 | 18,23 | 16,84 | 28,57 | 27,78 | 32,05 | 34,72 | 36,50 | 23,26 | 40,65 | 39.37 | |
| 1C 8.2 | 17,12 | 17,06 | 14,53 | 29,41 | 28,41 | 31,45 | 34,97 | 36,23 | 23,81 | 40,32 | 39.06 |
| 16,72 | 16,89 | 13,44 | 29,76 | 28,57 | 32,05 | 34,97 | 36,23 | 23,26 | 40,32 | 39.06 |
Šķiet, esmu izskatījusi visus interesantos variantus, ja vēl kas interesē, rakstiet komentāros, mēģināšu to izdarīt.
- SAS uzglabāšanas sistēmās darbojas lēnāk nekā vietējie SSD, lai gan uzglabāšanas sistēmām ir lielāki kešatmiņas izmēri. Gan lokālie, gan uzglabāšanas sistēmu SSD diski darbojas ar salīdzināmu ātrumu Gilev testam. Es nezinu nevienu standarta daudzpavedienu testu (ne tikai ierakstīšanu, bet visu aprīkojumu), izņemot 1C slodzes testu no KC.
- 1C servera maiņa no 5520 uz 5650 gandrīz divkāršoja veiktspēju. Jā, servera konfigurācijas pilnībā nesakrīt, taču tas liecina par tendenci (nav pārsteigums).
- Biežuma palielināšana SQL serverī noteikti dod efektu, bet ne tādu pašu kā 1C serverī; MS SQL serveris ir lielisks (ja to prasāt), lai izmantotu daudzkodolus un brīvu atmiņu.
- Mainot tīklu starp 1C un SQL no 1 Gbit uz 10 Gbit, tiek iegūti aptuveni 10% papagaiļu. Es gaidīju vairāk.
- Koplietojamās atmiņas iespējošana joprojām nodrošina efektu, lai gan ne 15%, kā aprakstīts rakstā. Noteikti dariet to, par laimi, tas ir ātri un vienkārši. Ja instalēšanas laikā kāds iedeva SQL serverim nosauktu instanci, tad, lai 1C darbotos, servera nosaukums ir jānorāda nevis ar FQDN (darbosies tcp/ip), nevis caur localhost vai tikai ServerName, bet caur ServerNameInstanceName, piemēram, zz- testzztest. (Pretējā gadījumā radīsies DBVS kļūda: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: koplietojamā atmiņas bibliotēka, kas tika izmantota savienojuma izveidei ar SQL Server 2000, netika atrasta. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQL Server : SQLSTATE=08001, stāvoklis=1, nopietnība=10, native=126, rinda=0).
- Lietotājiem, kas jaunāki par 100 gadiem, vienīgais punkts, kas jāsadala divos atsevišķos serveros, ir Win 2008 Std (un vecāka) licence, kas atbalsta tikai 32 GB RAM. Visos citos gadījumos 1C un SQL noteikti ir jāinstalē vienā serverī un jāpiešķir vairāk (vismaz 64 GB) atmiņas. Piešķirt 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ā darbojas 1C un SQL kombinācija, 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 diezgan atbilst faila versijai.
- Daudzi avoti saka, ka atkļūdošanas režīms (ragent.exe -debug) ievērojami samazina veiktspēju. Nu, tas samazina, jā, bet es nesauktu 2-3% par būtisku efektu.