Versiunea fișierului Performance 1s 8.3. Blocajele bazei de date de fișiere - cum să evitați (din experiența recentă). Instrucțiuni pentru migrarea de la o bază de date de fișiere la SQL

După trecerea de la 1C: Accounting 2.0 la ediția 3.0, viteza noii versiuni devine mai mică. Ne vom uita la această problemă în acest articol și vom oferi instrucțiuni pas cu pas pentru acțiunile din programul 1C: Contabilitate 3.0, care va ajuta să funcționeze mai rapid.

De regulă, motivul funcționării lente a programului constă în faptul că în sistem rulează joburi de rutină și de fundal. În versiunea de server a configurației versiunii 3.0, acestea vă permit să automatizați multe operațiuni de întreținere a programului în timpul orelor de lucru. Dar în modul de funcționare fișier, lucrările de fundal sunt lansate în timp ce utilizatorul lucrează și, prin urmare, sistemul încetinește.

Pentru a accelera munca în modul fișier 1C: Accounting 3.0, se recomandă dezactivarea lucrărilor de fundal. Pentru a face acest lucru, trebuie să ne referim la secțiune Administrare. În această secțiune din panoul de navigare găsim Suport și service.

Deschideți secțiunea Operațiuni de reglementareși apoi faceți clic pe link Sarcini de rutină și de fundal.

În fața dvs. va apărea o listă, în care sunt bifate sarcinile active (activate).

Pentru a dezactiva o sarcină, trebuie să o deschideți și să debifați opțiunea "Activat", apoi apăsați butonul Salveaza si inchide.

Când lucrați în versiunea de fișier a programului, vă recomandăm să dezactivați toate sarcinile de rutină prezente în listă. Un alt motiv posibil pentru viteza scăzută a sistemului este mecanismul activat Căutare text integral. Deoarece în programul 1C: Contabilitate 3.0 acest mecanism este opțional, poate fi dezactivați. Pentru a face acest lucru, trebuie să accesați secțiunea Operațiuni de reglementare debifați Căutare de date full-text.

Primim adesea întrebări despre ce încetinește 1c, mai ales când trecem la versiunea 1c 8.3, datorită colegilor noștri de la Interface LLC, vă spunem în detaliu:

În publicațiile noastre anterioare, am atins deja impactul performanței subsistemului de disc asupra vitezei 1C, dar acest studiu a vizat utilizarea locală a aplicației pe un computer separat sau pe un server terminal. În același timp, majoritatea implementărilor mici implică lucrul cu o bază de date de fișiere într-o rețea, unde unul dintre computerele utilizatorului este folosit ca server sau un server de fișiere dedicat bazat pe un computer obișnuit, cel mai adesea și ieftin.

Un mic studiu al resurselor în limba rusă pe 1C a arătat că această problemă este evitată cu sârguință, dacă apar probleme, se recomandă de obicei trecerea la modul client-server sau terminal. De asemenea, a devenit aproape general acceptat faptul că configurațiile dintr-o aplicație gestionată funcționează mult mai lent decât de obicei. De regulă, argumentele oferite sunt „de fier”: „Contabilitatea 2.0 tocmai a zburat, dar „troica” abia s-a mișcat”, desigur, există ceva adevăr în aceste cuvinte, așa că hai să încercăm să ne dăm seama.

Consumul de resurse, la prima vedere

Înainte de a începe acest studiu, ne-am propus două obiective: să aflăm dacă configurațiile bazate pe aplicații gestionate sunt de fapt mai lente decât configurațiile convenționale și care resurse specifice au impactul principal asupra performanței.

Pentru testare, am luat două mașini virtuale care rulează Windows Server 2012 R2 și, respectiv, Windows 8.1, oferindu-le 2 nuclee ale gazdei Core i5-4670 și 2 GB de RAM, ceea ce corespunde aproximativ unei mașini de birou medii. Serverul a fost plasat pe o matrice RAID 0 de două WD Se, iar clientul a fost plasat pe o matrice similară de discuri de uz general.

Ca baze experimentale, am selectat mai multe configurații ale ediției Accounting 2.0 2.0.64.12 , care a fost apoi actualizat la 3.0.38.52 , toate configurațiile au fost lansate pe platformă 8.3.5.1443 .

Primul lucru care atrage atenția este dimensiunea crescută a bazei de informații a Troicii, care a crescut semnificativ, precum și un apetit mult mai mare pentru RAM:

Suntem gata să auzim de obicei: „de ce au adăugat asta la acestea trei”, dar să nu ne grăbim. Spre deosebire de utilizatorii versiunilor client-server, care necesită un administrator mai mult sau mai puțin calificat, utilizatorii versiunilor de fișiere rareori se gândesc la întreținerea bazelor de date. De asemenea, angajații companiilor specializate care deservesc (citește actualizarea) aceste baze de date se gândesc rar la asta.

Între timp, baza de informații 1C este un SGBD cu drepturi depline, cu propriul format, care necesită și întreținere, iar pentru aceasta există chiar și un instrument numit Testarea și corectarea bazei de informații. Poate că numele a jucat o glumă crudă, ceea ce implică cumva că acesta este un instrument pentru depanarea problemelor, dar performanța scăzută este, de asemenea, o problemă, iar restructurarea și reindexarea, împreună cu compresia tabelelor, sunt instrumente binecunoscute pentru optimizarea bazelor de date pentru orice administrator DBMS. . Să verificăm?

După aplicarea acțiunilor selectate, baza de date a „slăbit” brusc, devenind chiar mai mică decât cele „două”, pe care nimeni nu le-a optimizat vreodată, iar consumul de memorie RAM a scăzut ușor.

Ulterior, după încărcarea unor noi clasificatoare și directoare, crearea de indexuri etc. dimensiunea bazei va crește în general, cele „trei” baze sunt mai mari decât cele „două”. Cu toate acestea, acest lucru nu este mai important, dacă a doua versiune s-a mulțumit cu 150-200 MB de RAM, atunci noua ediție are nevoie de o jumătate de gigabyte și această valoare ar trebui să fie luată în considerare la planificarea resurselor necesare pentru lucrul cu programul.

Net

Lățimea de bandă a rețelei este unul dintre cei mai importanți parametri pentru aplicațiile de rețea, în special ca 1C în modul fișier, care mută cantități semnificative de date în rețea. Majoritatea rețelelor întreprinderilor mici sunt construite pe baza unor echipamente ieftine de 100 Mbit/s, așa că am început testarea prin compararea indicatorilor de performanță 1C în rețelele de 100 Mbit/s și 1 Gbit/s.

Ce se întâmplă când lansați o bază de date de fișiere 1C în rețea? Clientul descarcă o cantitate destul de mare de informații în foldere temporare, mai ales dacă aceasta este prima pornire „la rece”. La 100 Mbit/s, se așteaptă să ne confruntăm cu lățimea canalului și descărcarea poate dura o perioadă semnificativă de timp, în cazul nostru aproximativ 40 de secunde (costul împărțirii graficului este de 4 secunde).

A doua lansare este mai rapidă, deoarece unele dintre date sunt stocate în cache și rămân acolo până la repornire. Trecerea la o rețea gigabit poate accelera semnificativ încărcarea programului, atât „la rece”, cât și „la cald”, iar raportul de valori este respectat. Prin urmare, am decis să exprimăm rezultatul în valori relative, luând cea mai mare valoare a fiecărei măsurători ca 100%:

După cum puteți vedea din grafice, Accounting 2.0 se încarcă la orice viteză a rețelei de două ori mai rapid, trecerea de la 100 Mbit/s la 1 Gbit/s vă permite să accelerați timpul de descărcare de patru ori. Nu există nicio diferență între bazele de date „troika” optimizate și neoptimizate în acest mod.

De asemenea, am verificat influența vitezei rețelei asupra funcționării în moduri grele, de exemplu, în timpul transferurilor de grup. Rezultatul este exprimat și în valori relative:

Aici este mai interesant, baza optimizată a celor „trei” într-o rețea de 100 Mbit/s funcționează la aceeași viteză ca a celor „doi”, iar cea neoptimizată arată rezultate de două ori mai proaste. Pe gigabit, rapoartele rămân aceleași, „trei” neoptimizat este și el la jumătate mai lent decât „doi”, iar cel optimizat rămâne în urmă cu o treime. De asemenea, trecerea la 1 Gbit/s vă permite să reduceți timpul de execuție de trei ori pentru ediția 2.0 și la jumătate pentru ediția 3.0.

Pentru a evalua impactul vitezei rețelei asupra muncii de zi cu zi, am folosit Măsurarea performanței, efectuând o secvență de acțiuni predeterminate în fiecare bază de date.

De fapt, pentru sarcinile de zi cu zi, debitul rețelei nu este un blocaj, un „trei” neoptimizat este cu doar 20% mai lent decât un „două”, iar după optimizare se dovedește a fi aproximativ la fel mai rapid - avantajele lucrului în modul client subțire sunt evidente. Trecerea la 1 Gbit/s nu oferă bazei optimizate niciun avantaj, iar cei neoptimizați și cei doi încep să funcționeze mai repede, arătând o mică diferență între ei.

Din testele efectuate, devine clar că rețeaua nu este un blocaj pentru noile configurații, iar aplicația gestionată rulează chiar mai repede decât de obicei. De asemenea, puteți recomanda trecerea la 1 Gbit/s dacă sarcinile grele și viteza de încărcare a bazei de date sunt critice pentru dvs., în alte cazuri, noile configurații vă permit să lucrați eficient chiar și în rețele lente de 100 Mbit/s;

Deci de ce 1C este lent? Vom analiza mai departe.

Subsistemul disc server și SSD

În articolul anterior, am obținut o creștere a performanței 1C prin plasarea bazelor de date pe un SSD. Poate că performanța subsistemului de disc al serverului este insuficientă? Am măsurat performanța unui server de disc în timpul unui grup rulat în două baze de date simultan și am obținut un rezultat destul de optimist.

În ciuda numărului relativ mare de operațiuni de intrare/ieșire pe secundă (IOPS) - 913, lungimea cozii nu a depășit 1,84, ceea ce este un rezultat foarte bun pentru o matrice cu două discuri. Pe baza acestui lucru, putem presupune că o oglindă realizată din discuri obișnuite va fi suficientă pentru funcționarea normală a 8-10 clienți de rețea în moduri grele.

Deci este necesar un SSD pe un server? Cel mai bun mod de a răspunde la această întrebare va fi prin testare, pe care le-am efectuat folosind o metodă similară, conexiunea la rețea este de 1 Gbit/s peste tot, rezultatul este exprimat și în valori relative.

Să începem cu viteza de încărcare a bazei de date.

Poate părea surprinzător pentru unii, dar SSD-ul de pe server nu afectează viteza de încărcare a bazei de date. Principalul factor limitator aici, așa cum a arătat testul anterior, este debitul rețelei și performanța clientului.

Să trecem la refacere:

Am observat deja mai sus că performanța discului este destul de suficientă chiar și pentru lucrul în moduri grele, așa că nici viteza SSD-ului nu este afectată, cu excepția bazei neoptimizate, care pe SSD a ajuns din urmă pe cea optimizată. De fapt, acest lucru confirmă încă o dată că operațiunile de optimizare organizează informațiile în baza de date, reducând numărul de operațiuni I/O aleatoare și crescând viteza de acces la aceasta.

În sarcinile de zi cu zi imaginea este similară:

Doar baza de date neoptimizată beneficiază de SSD. Desigur, puteți achiziționa un SSD, dar ar fi mult mai bine să vă gândiți la întreținerea în timp util a bazei de date. De asemenea, nu uitați de defragmentarea secțiunii cu baze de informații de pe server.

Subsistemul disc client și SSD

Am discutat despre influența SSD-ului asupra vitezei de funcționare a 1C instalat local în materialul anterior, mult din ceea ce s-a spus este valabil și pentru lucrul în modul de rețea. Într-adevăr, 1C utilizează destul de activ resursele de disc, inclusiv pentru activitățile de fundal și de rutină. În figura de mai jos puteți vedea cum Accounting 3.0 accesează destul de activ discul timp de aproximativ 40 de secunde după încărcare.

Dar, în același timp, ar trebui să știți că pentru o stație de lucru în care se lucrează activ cu una sau două baze de date de informații, resursele de performanță ale unui HDD obișnuit produs în masă sunt destul de suficiente. Achiziționarea unui SSD poate accelera unele procese, dar nu veți observa o accelerare radicală în munca de zi cu zi, deoarece, de exemplu, descărcarea va fi limitată de lățimea de bandă a rețelei.

Un hard disk lent poate încetini unele operațiuni, dar în sine nu poate determina încetinirea unui program.

RAM

În ciuda faptului că memoria RAM este acum obscen de ieftină, multe stații de lucru continuă să funcționeze cu cantitatea de memorie care a fost instalată la achiziție. Aici se așteaptă primele probleme. Pe baza faptului că „troika” medie necesită aproximativ 500 MB de memorie, putem presupune că o cantitate totală de RAM de 1 GB nu va fi suficientă pentru a funcționa cu programul.

Am redus memoria sistemului la 1 GB și am lansat două baze de date de informații.

La prima vedere, totul nu este atât de rău, programul și-a redus apetitul și se potrivește bine în memoria disponibilă, dar să nu uităm că nevoia de date operaționale nu s-a schimbat, deci unde a mers? Resetare pe disc, cache, swap etc., esența acestei operațiuni este că datele care nu sunt necesare momentan sunt trimise din RAM rapidă, a cărei cantitate nu este suficientă, pentru a încetini memoria discului.

Unde duce? Să vedem cum sunt folosite resursele de sistem în operațiuni grele, de exemplu, să lansăm un retransfer de grup în două baze de date simultan. Mai întâi pe un sistem cu 2 GB RAM:

După cum putem vedea, sistemul utilizează în mod activ rețeaua pentru a primi date, iar activitatea de pe disc este nesemnificativă în timpul procesării, dar nu este un factor limitativ;

Acum să reducem memoria la 1 GB:

Situația se schimbă radical, sarcina principală cade acum pe hard disk, procesorul și rețeaua sunt inactive, așteptând ca sistemul să citească datele necesare de pe disc în memorie și să trimită acolo date inutile.

În același timp, chiar și munca subiectivă cu două baze de date deschise pe un sistem cu 1 GB de memorie s-a dovedit a fi extrem de incomodă directoarele și reviste deschise cu o întârziere semnificativă și acces activ la disc. De exemplu, deschiderea jurnalului de vânzări de bunuri și servicii a durat aproximativ 20 de secunde și a fost însoțită în tot acest timp de o activitate ridicată pe disc (evidențiată cu o linie roșie).

Pentru a evalua în mod obiectiv impactul RAM asupra performanței configurațiilor bazate pe o aplicație gestionată, am efectuat trei măsurători: viteza de încărcare a primei baze de date, viteza de încărcare a celei de-a doua baze de date și re-rularea grupului într-una dintre bazele de date. . Ambele baze de date sunt complet identice și au fost create prin copierea bazei de date optimizate. Rezultatul este exprimat în unități relative.

Rezultatul vorbește de la sine: dacă timpul de încărcare crește cu aproximativ o treime, ceea ce este încă destul de tolerabil, atunci timpul pentru efectuarea operațiunilor în baza de date crește de trei ori, nu este nevoie să vorbim despre nicio muncă confortabilă în astfel de condiții. Apropo, acesta este cazul când cumpărarea unui SSD poate îmbunătăți situația, dar este mult mai ușor (și mai ieftin) să te ocupi de cauza, nu de consecințe și doar să cumperi cantitatea potrivită de RAM.

Lipsa memoriei RAM este principalul motiv pentru care lucrul cu noile configurații 1C se dovedește a fi inconfortabil. Configurațiile cu 2 GB de memorie la bord ar trebui să fie considerate minim adecvate. În același timp, rețineți că în cazul nostru s-au creat condiții „de seră”: un sistem curat, rulau doar 1C și managerul de activități. În viața reală, pe un computer de serviciu, de regulă, un browser, o suită de birou sunt deschise, rulează un antivirus etc., etc., deci procedați de la nevoia de 500 MB pe bază de date, plus o rezervă, astfel încât în timpul operațiunilor grele nu întâmpinați o lipsă de memorie și o scădere bruscă a productivității.

CPU

Fără exagerare, procesorul central poate fi numit inima computerului, deoarece acesta este cel care procesează în cele din urmă toate calculele. Pentru a-i evalua rolul, am efectuat un alt set de teste, la fel ca pentru RAM, reducând numărul de nuclee disponibile mașinii virtuale de la două la unul, iar testul a fost efectuat de două ori cu cantități de memorie de 1 GB și 2 GB.

Rezultatul s-a dovedit a fi destul de interesant și neașteptat: un procesor mai puternic a preluat destul de eficient sarcina atunci când a existat o lipsă de resurse, în restul timpului fără a oferi beneficii tangibile. 1C Enterprise nu poate fi numită o aplicație care utilizează în mod activ resursele procesorului; Și în condiții dificile, procesorul este împovărat nu atât de calcularea datelor aplicației în sine, cât de costurile generale de service: operațiuni suplimentare de intrare/ieșire etc.

concluzii

Deci, de ce este lent 1C? În primul rând, aceasta este o lipsă de memorie RAM, în acest caz, sarcina principală cade pe hard disk și procesor. Și dacă nu strălucesc cu performanță, așa cum este de obicei cazul în configurațiile de birou, atunci obținem situația descrisă la începutul articolului - „cei doi” au funcționat bine, dar „trei” sunt necinstiți de lenți.

Pe locul al doilea se află performanța rețelei; un canal lent de 100 Mbit/s poate deveni un adevărat blocaj, dar, în același timp, modul client subțire este capabil să mențină un nivel de funcționare destul de confortabil chiar și pe canalele lente.

Atunci ar trebui să acordați atenție unității de disc este puțin probabil să cumpărați un SSD, dar înlocuirea unității cu una mai modernă ar fi o idee bună. Diferența dintre generațiile de hard disk poate fi evaluată din următorul material: Revizuirea a două unități ieftine din seria Western Digital Blue de 500 GB și 1 TB.

Și în sfârșit procesorul. Un model mai rapid, desigur, nu va fi de prisos, dar nu are rost să-i creștem performanța decât dacă acest PC este folosit pentru operațiuni grele: procesare de grup, rapoarte grele, închidere la sfârșitul lunii etc.

Sperăm că acest material vă va ajuta să înțelegeți rapid întrebarea „de ce 1C este lent” și să o rezolvați cel mai eficient și fără costuri suplimentare.

Odată cu creșterea organizației și odată cu creșterea numărului de utilizatori ai bazei de informații 1C Enterprise pe rețeaua locală de calculatoare, sarcina pe stocarea principală a bazei de informații - serverul - crește. Prin urmare, mai devreme sau mai târziu, managerul și specialistul IT al companiei pot avea o întrebare: Cum să asigurăm un sistem rapid, sigur și eficient la cel mai mic cost financiar?

În primul rând, trebuie să alegeți o metodă de organizare a unui complex de computere automatizate corporative pe platforma 1C Enterprise 8. Platforma 1C acceptă două opțiuni de operare: fișier și client-server. În ambele cazuri, toate soluțiile de aplicație funcționează exact la fel.

Versiunea fișierului de lucru 1C conceput pentru ca unul sau mai mulți utilizatori să lucreze într-o rețea locală. În acest caz, toate datele de bază de informații (configurare, bază de date, informații administrative) sunt localizate într-un singur fișier - o bază de date de fișiere dezvoltată special pentru soluțiile de aplicație 1C Enterprise 8.

Avantajele modului de operare fișier

  • Optim pentru un număr mic de utilizatori (până la 5)
  • Ușor de instalat și operat sistemul
  • Pentru a lucra cu baza de informații, nu este necesar niciun software suplimentar, cu excepția sistemului de operare și 1C Enterprise 8
  • Riscul de încălcare a integrității datelor din cauza defecțiunilor computerului și rețelei locale este redus.
  • Creați cu ușurință copii de siguranță prin simpla copiere a fișierului infobase.

Lucrul în versiunea fișierului este posibil atât direct, direct cu fișierul bazei de date, cât și prin intermediul unui server web dacă conexiunile clientului sunt utilizate prin protocolul HTTP sau HTTPS.

Versiunea client-server de lucru 1C Proiectat pentru utilizare în departamente, grupuri de lucru sau în întreaga întreprindere. Este implementat pe baza unei arhitecturi client-server pe trei niveluri:

Aplicație client - cluster de servere 1C Enterprise - Server de bază de date

În versiunea client-server, baza de informații este stocată într-unul dintre SGBD-urile suportate: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. Este accesat după cum este necesar de către aplicația client printr-un cluster de servere 1C Enterprise.

În sistemul 1C Enterprise 8 există trei aplicații client sau client(un program care rulează pentru utilizator) cu diverse capacități: client gros, client subțire, client web.

Client gras vă permite să realizați toate capabilitățile 1C Enterprise 8 în ceea ce privește dezvoltarea, administrarea și execuția codului aplicației. Cu toate acestea, nu acceptă lucrul cu baze de date de informații prin Internet, necesită o instalare prealabilă pe computerul utilizatorului și are o dimensiune de distribuție destul de impresionantă.

Utilizatorii se plâng adesea că „1C 8.3 este lent”: formularele documentelor se deschid lent, procesarea documentelor durează mult, programul pornește, generarea rapoartelor durează mult și așa mai departe.

În plus, astfel de „eșecuri” pot apărea în diferite programe:

Motivele pot fi diferite. Acesta nu este documente restaurate, un computer sau un server slab, serverul 1C este configurat incorect.

În acest articol vreau să mă uit la unul dintre cele mai simple și mai comune motive pentru un program lent - . Această instrucțiune va fi relevantă pentru utilizatorii bazelor de date de fișiere pentru 1-2 utilizatori, unde nu există concurență pentru resurse.

Dacă sunteți interesat de o optimizare mai serioasă a opțiunilor client-server pentru funcționarea sistemului, vizitați secțiunea site-ului.

Unde sunt sarcinile programate în 1C 8.3?

Înainte să am timp să încărc programul, multe sarcini de fundal au fost finalizate în 1C. Le puteți vizualiza accesând meniul „Administrare”, apoi „Suport și întreținere”:

Obțineți 267 de lecții video pe 1C gratuit:

Iată cum arată fereastra cu sarcinile finalizate:

Și iată o listă completă a tuturor sarcinilor programate care sunt lansate:

Printre aceste sarcini se numără, de exemplu, „“, încărcarea diferitelor clasificatoare, verificarea relevanței versiunii programului și așa mai departe. De exemplu, nu am nici un folos pentru aproape toate aceste sarcini. Nu țin înregistrări valutare, controlez singur versiunile și încarc clasificatoare după cum este necesar.

Prin urmare, este în interesul meu (și în majoritatea cazurilor în interesul dumneavoastră) să dezactivați sarcinile inutile.

Dezactivarea sarcinilor programate și de fundal în 1C 8.3

Fotografie de Alena Tulyakova, agenția de știri „Clerk.Ru”

Articolul identifică principalele greșeli pe care le fac administratorii începători 1C și arată cum să le rezolvi folosind testul Gilev ca exemplu.

Scopul principal al scrierii acestui articol este de a evita repetarea nuanțelor evidente pentru acei administratori (și programatori) care nu au câștigat încă experiență cu 1C.

Scopul secundar este ca, dacă am vreo deficiență, Infostart va fi cel mai rapid să-mi semnaleze acest lucru.

Testul lui V. Gilev a devenit deja un fel de standard „de facto”. Autorul de pe site-ul său a dat recomandări destul de clare, dar voi prezenta pur și simplu câteva rezultate și voi comenta cele mai probabile erori. Desigur, rezultatele testelor pe echipamentul dvs. pot diferi, acesta este doar un ghid pentru ceea ce ar trebui să fie și pentru ce vă puteți strădui. Aș dori să observ imediat că modificările trebuie făcute pas cu pas, iar după fiecare pas, verificați ce rezultat a dat.

Sunt articole similare pe Infostart, voi pune link-uri către ele în secțiunile relevante (dacă îmi lipsește ceva, vă rog să-mi sugerați în comentarii, îl voi adăuga). Deci, să presupunem că 1C este lent. Cum se diagnostichează problema și cum se înțelege cine este de vină, administratorul sau programatorul?

Date inițiale:

Calculator testat, cobai principal: HP DL180G6, echipat cu 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Pentru comparație, Core i3-2100 arată rezultate comparabile în testul cu un singur thread. Echipamentul pe care l-am ales în mod deliberat nu a fost cel mai nou, cu echipamente moderne, rezultatele sunt vizibil mai bune.

Pentru testarea serverelor separate 1C și SQL, server SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Pentru a testa o rețea de 10 Gbit, s-au folosit adaptoare Intel 520-DA2.

Versiunea fișierului. (baza de date este pe server într-un folder partajat, clienții se conectează prin rețea, protocol CIFS/SMB). Algoritmul pas cu pas:

0. Adăugați baza de date de testare a lui Gilev la serverul de fișiere în același folder ca bazele de date principale. Ne conectăm de la computerul client și rulăm testul. Ne amintim rezultatul.

Se înțelege că și pentru computerele vechi de acum 10 ani (Pentium pe socket 775), timpul de la clic pe comanda rapidă 1C:Enterprise până la apariția ferestrei bazei de date ar trebui să dureze mai puțin de un minut. (Celeron = lent).

Dacă computerul dvs. este mai rău decât un Pentium pe socket 775 cu 1 GB RAM, atunci simpatizez cu dvs. și vă va fi dificil să obțineți o muncă confortabilă pe 1C 8.2 în versiunea fișierului. Gândiți-vă fie la un upgrade (e timpul) fie la trecerea la un server terminal (sau web, în ​​cazul clientului subțire și formularelor gestionate).

Dacă computerul nu este mai rău, atunci îl puteți da pe administrator. Verificați cel puțin funcționarea rețelei, a antivirusului și a driverului de protecție HASP.

Dacă testul lui Gilev în această etapă a arătat 30 de „papagali” sau mai mult, dar baza de lucru 1C încă funcționează lent, întrebările ar trebui adresate programatorului.

1. Ca ghid pentru cât de mult poate „strânge” un computer client, verificăm doar funcționarea acestui computer, fără rețea. Instalăm baza de date de testare pe un computer local (pe un disc foarte rapid). Dacă computerul client nu are un SSD normal, atunci este creat un disc ram. Deocamdată, cel mai simplu și gratuit este Ramdisk enterprise.

Pentru a testa versiunea 8.2, este suficient un ramdisk de 256 MB și! Cel mai important. După repornirea computerului, cu discul ram în funcțiune, ar trebui să existe 100-200 MB liberi pe el. În consecință, fără un disc ram, pentru funcționarea normală ar trebui să existe 300-400 MB de memorie liberă.

Pentru a testa versiunea 8.3, un disc ram de 256 MB este suficient, dar aveți nevoie de mai multă RAM liberă.

Când testați, trebuie să vă uitați la sarcina procesorului. Într-un caz aproape de ideal (ramdisk), fișierul local 1c încarcă 1 nucleu de procesor atunci când rulează. În consecință, dacă în timpul testării miezul procesorului nu este complet încărcat, căutați punctele slabe. Puțin emoționantă, dar în general corectă, este descrisă influența procesorului asupra funcționării lui 1C. Doar pentru referință, chiar și pe Core i3-urile moderne cu frecvențe înalte, numerele 70-80 sunt destul de realiste.

Cele mai frecvente erori în această etapă.

  • Antivirus configurat incorect. Există multe antivirusuri, setările pentru fiecare sunt diferite, voi spune doar că cu o configurație corespunzătoare, nici web-ul și nici Kaspersky 1C nu interferează. Cu setările implicite, aproximativ 3-5 papagali (10-15%) pot fi luați.
  • Modul de performanță. Din anumite motive, puțini oameni acordă atenție acestui lucru, dar efectul este cel mai semnificativ. Dacă aveți nevoie de viteză, atunci trebuie să faceți acest lucru, atât pe computerele client, cât și pe server. (Gilev are o descriere bună. Singura avertisment este că pe unele plăci de bază, dacă dezactivați Intel SpeedStep, nu puteți activa TurboBoost).
Pe scurt, în timp ce rulează 1C, se așteaptă mult un răspuns de la alte dispozitive (disc, rețea etc.). În așteptarea unui răspuns, dacă modul de performanță este activat, procesorul își scade frecvența. Un răspuns vine de la dispozitiv, 1C (procesorul) trebuie să funcționeze, dar primele cicluri de ceas sunt la o frecvență redusă, apoi frecvența crește - și 1C așteaptă din nou un răspuns de la dispozitiv. Și așa - de multe sute de ori pe secundă.

Puteți (și preferabil) să activați modul de performanță în două locuri:

  • prin BIOS. Dezactivați modurile C1, C1E, Intel C-state (C2, C3, C4). În diferite bios ele sunt numite diferit, dar sensul este același. Este nevoie de mult timp pentru a căuta, este necesară o repornire, dar dacă o faci o dată, atunci o poți uita. Dacă faci totul corect în BIOS, viteza va crește. Pe unele plăci de bază, puteți configura setările BIOS, astfel încât modul de performanță Windows să nu joace un rol. (Exemple de setări BIOS de la Gilev). Aceste setări se referă în principal la procesoarele de server sau la BIOS „avansat”, dacă nu ați găsit acest lucru și NU aveți Xeon, este în regulă.

  • Panou de control - Alimentare - Performanță ridicată. Minus - dacă computerul nu a fost întreținut de mult timp, va face un zgomot mai puternic al ventilatorului, se va încălzi mai mult și va consuma mai multă energie. Aceasta este o taxă de performanță.
Cum să verificați dacă modul este activat. Lansați task manager - performanță - monitor resurse - CPU. Așteptăm până când procesorul este ocupat cu nimic.
Acestea sunt setările implicite.

BIOS C-state activat,

modul de consum echilibrat de energie


BIOS C-state activat, mod de înaltă performanță

Pentru Pentium și Core te poți opri acolo,

Încă poți stoarce puțini „papagali” din Xeon


În BIOS, starea C este dezactivată, modul de înaltă performanță.

Dacă nu utilizați Turbo boost, așa ar trebui să arate

server reglat pentru performanță


Și acum numerele. Permiteți-mi să vă reamintesc: Intel Xeon 5650, disc ram. În primul caz, testul arată 23,26, în ultimul - 49,5. Diferența este aproape dublă. Cifrele pot varia, dar raportul rămâne în esență același pentru Intel Core.

Dragi administratori, puteți critica 1C cât de mult doriți, dar dacă utilizatorii finali au nevoie de viteză, trebuie să activați modul de înaltă performanță.

c) Turbo Boost. Mai întâi trebuie să înțelegeți dacă procesorul dvs. acceptă această funcție, de exemplu. Dacă este compatibil, atunci puteți obține încă destul de legal performanță. (Nu vreau să abordez problemele de overclockare a frecvenței, în special serverele, fă-o pe riscul și riscul tău. Dar sunt de acord că creșterea vitezei Bus de la 133 la 166 dă o creștere foarte vizibilă atât a vitezei, cât și a disipării căldurii)

Cum să activați turbo boost este scris, de exemplu, . Dar! Pentru 1C există câteva nuanțe (nu cele mai evidente). Dificultatea este că efectul maxim al turbo boost are loc atunci când starea C este activată. Și obținem ceva de genul acesta:

Vă rugăm să rețineți că multiplicatorul este maxim, viteza Core este frumoasă și performanța este ridicată. Dar ce se va întâmpla ca rezultat cu 1s?

Dar până la urmă se dovedește că, conform testelor de performanță CPU, versiunea cu un multiplicator de 23 este înainte, conform testelor lui Gilev în versiunea de fișier performanța cu un multiplicator de 22 și 23 este aceeași, dar în client-server versiune - versiunea cu un multiplicator de 23 este groaznic teribil (chiar dacă starea C este setată la nivelul 7, este totuși mai lentă decât cu starea C dezactivată). Prin urmare, recomandarea este să verificați singur ambele opțiuni și să o alegeți pe cea mai bună. În orice caz, diferența dintre 49,5 și 53 de papagali este destul de semnificativă, mai ales fără prea mult efort.

Concluzie - turbo boost trebuie activat. Permiteți-mi să vă reamintesc că nu este suficient să activați elementul Turbo boost în BIOS, trebuie să vă uitați și la alte setări (BIOS: QPI L0s, L1 - dezactivare, scrubbing la cerere - dezactivare, Intel SpeedStep - activare, Turbo boost - activați Panou de control - Opțiuni de alimentare - Performanță ridicată). Și tot (chiar și pentru versiunea de fișier) aș alege opțiunea în care c-state este dezactivat, chiar dacă multiplicatorul este mai mic. Se va dovedi ceva de genul asta...

Un punct destul de controversat este frecvența memoriei. De exemplu, se arată că frecvența memoriei are o influență foarte puternică. Testele mele nu au relevat o asemenea dependență. Nu voi compara DDR 2/3/4, voi arăta rezultatele modificării frecvenței în cadrul aceleiași linii. Memoria este aceeași, dar în BIOS suntem nevoiți să setăm frecvențe mai mici.




Și rezultatele testelor. 1C 8.2.19.83, pentru versiunea de fișier local ramdisk, pentru client-server 1C și SQL pe un singur computer, memorie partajată. Turbo Boost este dezactivat în ambele versiuni. 8.3 arată rezultate comparabile.

Diferența este în cadrul erorii de măsurare. Am scos în mod special capturi de ecran ale CPU-Z pentru a arăta că, odată cu o schimbare a frecvenței, se schimbă și alți parametri, aceeași Latență CAS și Întârziere RAS la CAS, care neutralizează schimbarea frecvenței. Diferența va fi atunci când modulele de memorie sunt modificate fizic, de la mai lent la mai rapid, dar nici acolo cifrele nu sunt deosebit de semnificative.

2. După ce am sortat procesorul și memoria computerului client, trecem la următorul loc foarte important - rețeaua. S-au scris multe volume de cărți despre reglarea rețelei, există articole despre Infostart (, și altele), dar aici nu mă voi concentra pe acest subiect. Înainte de a începe testarea 1C, vă rugăm să vă asigurați că iperf între două computere arată întreaga lățime de bandă (pentru cardurile de 1 Gbit - ei bine, cel puțin 850 Mbit, sau mai bine 950-980), că sfatul lui Gilev a fost urmat. Apoi - cel mai simplu test de funcționare va fi, destul de ciudat, copierea unui fișier mare (5-10 gigaocteți) în rețea. Un semn indirect de funcționare normală pe o rețea de 1 Gbit va fi viteza medie de copiere de 100 MB/sec, funcționare bună - 120 MB/sec. Aș dori să vă atrag atenția asupra faptului că punctul slab (inclusiv) poate fi încărcarea procesorului. Protocolul SMB pe Linux este destul de slab paralelizat, iar în timpul funcționării poate „mânca” destul de ușor un nucleu de procesor și nu mai consumă.

Și mai departe. Cu setările implicite, clientul Windows funcționează cel mai bine cu un server Windows (sau chiar cu o stație de lucru Windows) și protocolul SMB/CIFS, un client Linux (debian, ubuntu nu s-a uitat la celelalte) funcționează mai bine cu Linux și NFS ( funcționează și cu SMB, dar pe NFS papagalii sunt mai înalți). Faptul că în timpul copierii liniare un server Windows Linux pe NFS este copiat într-un flux mai rapid nu înseamnă nimic. Tuningul Debian pentru 1C este un subiect pentru un articol separat, încă nu sunt pregătit pentru asta, deși pot spune că în versiunea de fișier am obținut performanțe chiar puțin mai bune decât versiunea Win pe același echipament, dar cu postgres cu peste 50 de utilizatori am încă totul foarte rău.

Cel mai important lucru pe care îl știu administratorii „arși”, dar începătorii nu îl țin cont. Există multe modalități de a seta calea către baza de date 1c. Puteți face servershare, puteți face 192.168.0.1share, puteți utiliza net z: 192.168.0.1share (și în unele cazuri va funcționa și această metodă, dar nu întotdeauna) și apoi specificați unitatea Z. Se pare că toate aceste căi indică același lucru în același loc, dar pentru 1C există o singură metodă care oferă o performanță normală destul de fiabilă. Deci, iată ce trebuie să faceți corect:

Pe linia de comandă (sau în politici, sau orice este convenabil pentru dvs.) - utilizați net DriveLetter: servershare. Exemplu: net use m: serverbases. Subliniez în mod specific NU adresa IP, ci numele serverului. Dacă numele serverului nu este vizibil, adăugați-l la dns de pe server sau local la fișierul hosts. Dar adresa trebuie să fie după nume. În consecință, în drum spre baza de date, accesați acest disc (vezi imaginea).

Și acum voi arăta cu cifre de ce acesta este sfatul. Date inițiale: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 OS Win 2008 R2, Win 7, Debian 8. Ultimele drivere, actualizări aplicate. Înainte de testare, m-am asigurat că Iperf oferă toată lățimea de bandă (cu excepția cardurilor de 10 Gbit, a reușit să stoarce doar 7,2 Gbit, voi vedea de ce mai târziu, serverul de testare nu este încă configurat corect). Discurile sunt diferite, dar peste tot există un SSD (am introdus special un singur disc pentru testare, nu este încărcat cu nimic altceva) sau un raid de la un SSD. Viteza de 100 Mbit a fost obținută prin limitarea setărilor adaptorului Intel 362 Nu a existat nicio diferență între Intel 350 de cupru de 1 Gbit și Intel X520-DA2 de 1 Gbit (obținut prin limitarea vitezei adaptorului). Performanță maximă, turbo boost este dezactivat (doar pentru comparabilitate a rezultatelor, turbo boost pentru rezultate bune adaugă puțin mai puțin de 10%, pentru rezultate proaste este posibil să nu aibă niciun efect). Versiunile 1C 8.2.19.86, 8.3.6.2076. Nu dau toate numerele, ci doar pe cele mai interesante, ca să ai cu ce să compari.

CIFS de 100 Mbit

Win 2008 - Win 2008

contact prin adresa ip

CIFS de 100 Mbit

Win 2008 - Win 2008

chemând pe nume

CIFS de 1 Gbit

Win 2008 - Win 2008

contact prin adresa ip

CIFS de 1 Gbit

Win 2008 - Win 2008

chemând pe nume

CIFS de 1 Gbit

Win 2008 - Win 7

chemând pe nume

CIFS de 1 Gbit

Win 2008 - Debian

chemând pe nume

CIFS de 10 Gbit

Win 2008 - Win 2008

contact prin adresa ip

CIFS de 10 Gbit

Win 2008 - Win 2008

chemând pe nume

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

Concluzii (din tabel și din experiența personală. Se aplică numai pentru versiunea fișierului):

  • Prin intermediul rețelei, puteți obține numere destul de normale pentru lucru dacă această rețea este configurată corect și calea este introdusă corect în 1C. Chiar și primul Core i3 poate produce cu ușurință peste 40 de papagali, ceea ce este destul de bine, iar aceștia nu sunt doar papagali, în munca reală diferența este și ea vizibilă. Dar! Limitarea atunci când lucrați cu mai mulți (mai mult de 10) utilizatori nu va mai fi rețeaua, aici 1 Gbit este încă suficient, dar blocarea în timpul lucrului cu mai mulți utilizatori (Gilev).
  • platforma 1C 8.3 este de multe ori mai pretențioasă în ceea ce privește configurarea corectă a rețelei. Setări de bază - vezi Gilev, dar rețineți că totul poate fi influențat. Am văzut o accelerare de la dezinstalarea (și nu doar de la oprirea) antivirusului, de la eliminarea protocoalelor precum FCoE, de la schimbarea driverelor la o versiune mai veche, dar certificată Microsoft (în special pentru carduri ieftine precum ASUS și DLC), de la scoaterea celei de-a doua plăci de rețea. de pe server. Există o mulțime de opțiuni, configurați-vă rețeaua cu atenție. Poate exista o situație în care platforma 8.2 oferă numere acceptabile, iar 8.3 - de două sau chiar de mai multe ori mai puțin. Încercați să jucați cu versiunile platformei 8.3, uneori obțineți un efect foarte mare.
  • 1C 8.3.6.2076 (poate mai târziu, încă nu am căutat versiunea exactă) este încă mai ușor de configurat prin rețea decât 8.3.7.2008. Am reușit să obțin o funcționare normală în rețea din 8.3.7.2008 (la papagalii comparabili) doar de câteva ori nu am putut să o repet pentru un caz mai general. Nu am înțeles mare lucru, dar judecând după împachetarea picioarelor de la Process Explorer, înregistrarea acolo nu este la fel de bună ca în 8.3.6.
  • În ciuda faptului că atunci când lucrezi pe o rețea de 100 Mbit, programul său de încărcare este mic (putem spune că rețeaua este gratuită), viteza de operare este totuși mult mai mică decât pe 1 Gbit. Motivul este latența rețelei.
  • Toate celelalte lucruri fiind egale (o rețea care funcționează bine) pentru 1C 8.2, conexiunea Intel-Realtek este cu 10% mai lentă decât Intel-Intel. Dar realtek-realtek poate da, în general, o tasare bruscă din senin. Prin urmare, dacă aveți bani, este mai bine să păstrați cardurile de rețea Intel peste tot dacă nu aveți bani, atunci instalați Intel doar pe server (CO); Și există de multe ori mai multe instrucțiuni pentru reglarea plăcilor de rețea Intel.
  • Setările implicite antivirus (folosind drweb versiunea 10 ca exemplu) ocupă aproximativ 8-10% din papagali. Dacă îl configurați așa cum trebuie (permiteți procesului 1cv8 să facă totul, deși nu este sigur), viteza este aceeași ca și fără antivirus.
  • NU citiți guru Linux. Un server cu samba este grozav și gratuit, dar dacă instalați Win XP sau Win7 (sau și mai bine - server OS) pe server, atunci versiunea de fișier a 1c va funcționa mai rapid. Da, samba și stiva de protocoale și setările de rețea și multe, multe altele pot fi bine reglate în debian/ubuntu, dar acest lucru este recomandat specialiștilor. Nu are rost să instalezi Linux cu setările implicite și apoi să spui că este lent.
  • Este o idee destul de bună să verificați funcționarea discurilor conectate prin utilizarea rețelei folosind fio . Cel puțin va fi clar dacă acestea sunt probleme cu platforma 1C sau cu rețea/disc.
  • Pentru versiunea pentru un singur utilizator, nu mă pot gândi la teste (sau la o situație) în care diferența dintre 1 Gbit și 10 Gbit ar fi vizibilă. Singurul lucru în care 10Gbit pentru versiunea de fișier a dat rezultate mai bune este conectarea discurilor prin iSCSI, dar acesta este un subiect pentru un articol separat. Totuși, cred că pentru versiunea de fișier cardurile de 1 Gbit sunt suficiente.
  • Nu înțeleg de ce, cu o rețea de 100 Mbit, 8.3 funcționează considerabil mai repede decât 8.2, dar a fost un fapt. Toate celelalte echipamente, toate celelalte setări sunt absolut aceleași, doar că într-un caz este testat 8.2, iar în celălalt - 8.3.
  • Neajustat NFS win-win sau win-lin dă 6 papagali, nu i-am inclus în tabel. După tuning am primit 25, dar a fost instabil (diferența de măsurători a fost mai mare de 2 unități). Încă nu pot da recomandări despre utilizarea Windows și a protocolului NFS.
După toate setările și verificările, rulăm din nou testul de pe computerul client și ne bucurăm de rezultatul îmbunătățit (dacă funcționează). Dacă rezultatul s-a îmbunătățit, există mai mult de 30 de papagali (și mai ales mai mult de 40), mai puțin de 10 utilizatori lucrează în același timp, iar baza de date de lucru este încă lentă - aproape sigur o problemă cu programatorul (sau aveți a atins deja capacitățile de vârf ale versiunii fișierului).

Server terminal. (baza de date este pe server, clienții se conectează prin rețea, protocol RDP). Algoritmul pas cu pas:

  • Adăugăm baza de date de testare a lui Gilev la server în același folder ca bazele de date principale. Ne conectăm de pe același server și rulăm testul. Ne amintim rezultatul.
  • Exact la fel ca în versiunea de fișier, configuram procesorul. În cazul unui server terminal, procesorul joacă în general rolul principal (se presupune că nu există puncte slabe evidente, cum ar fi lipsa memoriei sau o cantitate imensă de software inutil).
  • Configurarea plăcilor de rețea în cazul unui server terminal nu are practic niciun efect asupra funcționării lui 1c. Pentru a asigura un confort „special”, dacă serverul tău produce mai mult de 50 de papagali, te poți juca cu versiuni noi ale protocolului RDP, doar pentru confortul utilizatorilor, răspuns mai rapid și derulare.
  • Când un număr mare de utilizatori lucrează activ (și aici puteți încerca deja să conectați 30 de persoane la o bază de date, dacă încercați), este foarte recomandabil să instalați o unitate SSD. Din anumite motive, se crede că discul nu afectează în mod deosebit funcționarea lui 1C, dar toate testele sunt efectuate cu memoria cache a controlerului activată pentru scriere, ceea ce este incorect. Baza de testare este mică, se potrivește destul de bine în cache, de unde și numerele mari. Pe bazele de date reale (mari) totul va fi complet diferit, astfel încât memoria cache este dezactivată pentru teste.
De exemplu, am verificat funcționarea testului Gilev cu diferite opțiuni de disc. Am instalat discurile din ceea ce era la îndemână, doar pentru a arăta tendința. Diferența dintre 8.3.6.2076 și 8.3.7.2008 este mică (în versiunea Ramdisk Turbo boost 8.3.6 produce 56.18 și 8.3.7.2008 produce 55.56, la alte teste diferența este și mai mică). Consum de energie - performanță maximă, turbo boost dezactivat (dacă nu se specifică altfel).
Raid 10 4x SATA 7200

ATA ST31500341AS

Raid 10 4x SAS 10kRaid 10 4x SAS 15kSSD unicRamdiskRamdiskCache-ul activat

Controler RAID

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
  • Cache-ul controlerului RAID activat elimină toate diferențele dintre discuri, numerele sunt aceleași atât pentru sat, cât și pentru cas. Testarea cu el pe o cantitate mică de date este inutilă și nu este indicativă de niciun fel.
  • Pentru platforma 8.2, diferența de performanță între opțiunile SATA și SSD este mai mult decât dublă. Aceasta nu este o greșeală de tipar. Dacă te uiți la monitorul de performanță în timpul testului pe unitățile SATA. apoi puteți vedea clar „Timp de funcționare a discului activ (în%)” 80-95. Da, dacă activați memoria cache a discurilor în sine pentru înregistrare, viteza va crește la 35, dacă activați memoria cache a controlerului raid - până la 49 (indiferent de ce discuri sunt testate în acest moment). Dar aceștia sunt papagali cache sintetici în munca reală, cu baze de date mari, nu va exista niciodată un raport de acces la cache de 100%.
  • Viteza chiar și a SSD-urilor ieftine (am testat pe Agility 3) este suficientă pentru a rula versiunea fișierului. Resursa de înregistrare este o altă problemă, trebuie să o priviți în fiecare caz specific, este clar că Intel 3700 o va avea cu un ordin de mărime mai mare, dar prețul este corespunzător. Și da, înțeleg că atunci când testez o unitate SSD, testez și cache-ul acestei unități într-o măsură mai mare, rezultatele reale vor fi mai mici.
  • Cea mai corectă soluție (din punctul meu de vedere) ar fi să alocați 2 discuri SSD într-un raid în oglindă pentru o bază de date de fișiere (sau mai multe baze de date de fișiere) și să nu plasați nimic altceva acolo. Da, cu o oglindă, SSD-urile se uzează la fel, iar acesta este un minus, dar cel puțin electronica controlerului este protejată cumva de erori.
  • Principalele avantaje ale unităților SSD pentru versiunea de fișiere vor apărea atunci când există multe baze de date, fiecare cu mai mulți utilizatori. Dacă există 1-2 baze de date și există aproximativ 10 utilizatori, atunci discuri SAS vor fi suficiente. (dar în orice caz, uită-te la încărcarea acestor discuri, cel puțin prin perfmon).
  • Principalele avantaje ale unui server terminal sunt că poate avea clienți foarte slabi, iar setările de rețea afectează mult mai puțin serverul terminal (din nou, K.O.).
Concluzii: dacă rulați testul Gilev pe un server terminal (de pe același disc unde se află bazele de date de lucru) și în acele momente când baza de date de lucru încetinește, iar testul Gilev arată un rezultat bun (peste 30), atunci funcționarea lentă a bazei de date principale de lucru este de vină cel mai probabil un programator.

Dacă testul lui Gilev arată numere mici și aveți un procesor cu ceas mare și discuri rapide, atunci administratorul trebuie să ia cel puțin perfmon, înregistrând toate rezultatele undeva și să urmărească, să observe și să tragă concluzii. Nu va exista un sfat definitiv.

Opțiune client-server.

Testele au fost efectuate doar pe 8.2, deoarece pe 8.3 totul depinde destul de serios de versiune.

Pentru testare, am ales diferite opțiuni de server și rețele între ele pentru a arăta principalele tendințe.

1C: Xeon 5520

SQL: Xeon E5-2630

1C: Xeon 5520

SQL: Xeon E5-2630

Fibre Channel - SSD

1C: Xeon 5520

SQL: Xeon E5-2630

Fibre Channel - SAS

1C: Xeon 5650

SQL: Xeon E5-2630

1C: Xeon 5650

SQL: Xeon E5-2630

Fibre Channel - 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

Se pare că am luat în considerare toate opțiunile interesante, dacă mai este ceva care vă interesează, scrieți în comentarii, voi încerca să o fac.

  • SAS pe sistemele de stocare este mai lent decât SSD-urile locale, chiar dacă sistemele de stocare au dimensiuni mai mari de cache. SSD-urile, atât locale, cât și pe sistemele de stocare pentru testarea lui Gilev, funcționează la viteze comparabile. Nu cunosc niciun test standard cu mai multe fire (nu doar înregistrarea, ci toate echipamentele), cu excepția testului de încărcare 1C de la MCC.
  • Schimbarea serverului 1C de la 5520 la 5650 aproape a dublat performanța. Da, configurațiile serverului nu se potrivesc complet, dar arată o tendință (nicio surpriză).
  • Creșterea frecvenței pe serverul SQL dă cu siguranță un efect, dar nu același ca pe serverul 1C MS SQL este excelent la (dacă se cere să facă acest lucru) să folosească multi-core și memorie liberă.
  • Schimbarea rețelei între 1C și SQL de la 1 Gbit la 10 Gbit dă aproximativ 10% papagali. ma asteptam la mai mult.
  • Activarea memoriei partajate dă în continuare un efect, deși nu de 15%, așa cum este descris în articol. Asigurați-vă că o faceți, din fericire, este rapid și ușor. Dacă în timpul instalării cineva a dat serverului SQL o instanță numită, atunci pentru ca 1C să funcționeze, numele serverului trebuie specificat nu prin FQDN (tcp/ip va funcționa), nu prin localhost sau doar ServerName, ci prin ServerNameInstanceName, de exemplu zz- testzztest. (În caz contrar, va apărea o eroare DBMS: Microsoft SQL Server Native Client 10.0: Furnizor de memorie partajată: Biblioteca de memorie partajată folosită pentru a stabili o conexiune cu SQL Server 2000 nu a fost găsită. HRESULT=80004005, HRESULT=80004005, HRESULT=80004Srvr, SQL Server 2005 : SQLSTATE=08001, stare=1, Severitate=10, nativ=126, linie=0).
  • Pentru utilizatorii sub 100, singurul punct în care îl împărțim în două servere separate este o licență Win 2008 Std (și mai veche), care acceptă doar 32 GB de RAM. În toate celelalte cazuri, 1C și SQL trebuie să fie instalate pe un singur server și să li se ofere mai multă memorie (cel puțin 64 GB). A oferi MS SQL mai puțin de 24-28 GB de RAM este o lăcomie nejustificată (dacă crezi că ai suficientă memorie și totul funcționează bine, poate că versiunea de fișier a 1C ar fi suficientă pentru tine?)
  • Cât de rău funcționează combinația dintre 1C și SQL într-o mașină virtuală este subiectul unui articol separat (hint - vizibil mai rău). Nici în Hyper-V totul nu este atât de clar...
  • Modul de performanță echilibrat este rău. Rezultatele sunt destul de conforme cu versiunea fișierului.
  • Multe surse spun că modul de depanare (ragent.exe -debug) determină o scădere semnificativă a performanței. Ei bine, se reduce, da, dar nu aș numi 2-3% un efect semnificativ.
Aici vor fi cele mai puține sfaturi pentru un caz anume, pentru că... Frânele în versiunea client-server de lucru sunt cel mai dificil caz și totul este configurat foarte individual. Cel mai simplu mod este să spuneți că pentru funcționarea normală trebuie să luați un server separat DOAR pentru 1C și MS SQL, să puneți acolo procesoare cu frecvența maximă (peste 3 GHz), unități SSD pentru baza de date și mai multă memorie (128+) , nu utilizați virtualizarea. A ajutat - grozav, ești norocos (și vor fi mulți astfel de norocoși, mai mult de jumătate din probleme pot fi rezolvate cu un upgrade adecvat). Dacă nu, atunci orice alte opțiuni necesită luare în considerare și setări separate.