Testare stresanta. Test de sarcină standard Test de viteză 1s

O operațiune obligatorie pentru orice implementare sau modificare a unui sistem informatic existent este evaluarea vitezei necesare a sistemului și planificarea resurselor de calcul necesare pentru implementarea acestuia. În prezent, nu există o soluție exactă la această problemă în formă generală și dacă, în ciuda complexității și costului său, un astfel de algoritm este propus de orice producător, atunci chiar și mici modificări ale hardware-ului, versiunii software, configurației sistemului sau cantității sau comportamentului standard al utilizatorului va duce la erori semnificative.

Cu toate acestea, există o mulțime de modalități de a evalua configurația software și hardware necesară pentru a obține performanța necesară. Toate aceste metode pot fi utilizate în procesul de selecție, dar consumatorul trebuie să-și înțeleagă aplicațiile și limitările.

Majoritatea metodelor existente de evaluare a performanței se bazează pe un anumit tip de testare.

Există două tipuri principale de testare: componentă și integrală.

Testarea componentelor implică testarea componentelor individuale ale unei soluții, variind de la performanța procesoarelor sau a subsistemelor de stocare până la testarea performanței serverului în ansamblu, dar fără sarcina utilă sub forma unei anumite aplicații de afaceri.

Abordarea integrată se caracterizează printr-o evaluare a performanței soluției în ansamblu, atât componentele software cât și hardware. În acest caz, se poate folosi atât o aplicație de business, care va fi folosită în soluția finală, cât și unele aplicații model care emulează unele procese și încărcări standard de afaceri.

Culoarea verde a graficului, împreună cu câțiva indicatori selectați condiționat din dreapta, ne permite să facem o evaluare generalizată multiplatformă a performanței „bune”.

Cum să fii mulțumit de rezultatele testelor tale

Ați primit ca rezultat un anumit indice de performanță (viteză). Nu contează dacă rezultatul este bun sau rău - acesta este rezultatul PLATFORMEI care rulează pe hardware-ul tău. În cazul versiunii client - server, acesta este rezultatul unui lanț complex de solicitări care trec prin diverse secțiuni. Obțineți rezultatul real total, care este determinat de blocajul din sistem. Întotdeauna există un blocaj.

Cu alte cuvinte, atât setările DBMS, setările sistemului de operare, cât și hardware-ul au un impact asupra rezultatului general al echipei.

Care server este mai bun

Acest test, efectuat pe un anumit server, dă rezultatul pe baza totalității setărilor hardware, sistem de operare, bază de date etc. Cu toate acestea, un rezultat ridicat pe un anumit hardware de server înseamnă că, în condiții normale, același rezultat va fi obținut pe un hardware de server identic. Acest test este un instrument gratuit care vă ajută să comparați instalarea 1C:Enterprise sub Windows și Linux, trei SGBD-uri diferite acceptate de platforma 1C:Enterprise 8.

Testați siguranța

Testul este absolut sigur. Nu duce la o „crash” a serverului (nu există un algoritm de „stres”) și nu necesită măsuri preliminare chiar și pe un server de „combat”. De asemenea, datele confidențiale nu sunt înregistrate în rezultatele testelor. Sunt colectate informații despre parametrii CPU, RAM, HDD. Numerele de serie ale dispozitivului nu sunt colectate. Puteți verifica cu ușurință toate acestea - codul de testare este deschis 100%. Este imposibil să trimiți orice informație fără știrea ta.

Clasificare TPC-Debit A-local / TPC-1C-GILV-A

Testul aparține secțiunii de teste universale integrale multiplatforme. Mai mult, este aplicabil pentru opțiunile de fișier și client-server pentru utilizarea 1C:Enterprise. Testul funcționează pentru toate SGBD-urile suportate de 1C.

Universalitatea vă permite să faceți o evaluare generalizată a performanței fără a fi legat de o anumită configurație tipică a platformei.

Pe de altă parte, aceasta înseamnă că pentru calcule precise ale unui proiect personalizat, testul vă permite să faceți o evaluare preliminară înainte de testarea de sarcină specializată.

Descărcați testul

Acest test nu este comercial și poate fi descărcat gratuit pentru 8.2 și gratuit pentru 8.3.

Detalii tehnice

Ce se întâmplă în test în cadrul unui ciclu de operare „un”?

Caracteristici de utilizare a testului pe o bază de date PostgreSQL

Setați parametrul standard_conforming_strings din fișierul de configurare postgresql.conf la „off”

Cum se măsoară sarcina de fier

Trebuie remarcat faptul că testul în sine efectuează deja parțial măsurarea. Pentru o imagine mai detaliată, vă recomand să utilizați utilitarul Process Explorer al lui Mark Rusinovich.

Figura prezintă un exemplu de măsurare pentru versiunea fișierului.

Evaluarea și prognoza performanței

Sarcina principală după implementarea unui sistem informațional este funcționarea sa rapidă, stabilă și fără probleme, care mulțumește utilizatorii.

Cu toate acestea, adesea odată cu creșterea numărului de utilizatori, a volumului de date și a intensității intrării, performanța programului scade catastrofal. Timpul de operare și de răspuns al sistemului cresc în mod critic.

Toate acestea duc la nemulțumiri în rândul utilizatorilor sistemului de la toate nivelurile și la muncă ineficientă.

În ciuda faptului că acest comportament al sistemului este previzibil, mulți nu sunt pregătiți pentru acest scenariu.

Există un număr mare de cazuri în care crearea sistemelor de contabilitate a fost planificată și realizată fără o analiză preliminară detaliată a modului în care acest sistem s-ar comporta cu volume mari de date (de exemplu, cu muncă intensivă paralelă a mai mult de o mie de oameni). Astfel de proiecte au cheltuit sume uriașe de bani pentru crearea sistemului. Dar după implementare, durata de viață a acestor sisteme a fost de un an și jumătate. Apoi s-a stabilit că sistemul nu poate face față sarcinilor, s-a alocat un nou buget și s-a început un nou proiect de implementare a unui sistem „mai bun”, ceea ce a implicat aceleași consecințe.

În prezent, există o singură soluție la această problemă - testarea sarcinii.

Testare stresanta

Testare de încărcare – analiză a comportamentului sistemului atunci când se emulează o încărcare reală a utilizatorului.

Principalele obiective ale testării de sarcină:

  • Testați performanța pe diverse configurații software și hardware
  • Testați performanța sistemului cu diferite volume de date
  • Determinați comportamentul sistemului în condiții de solicitare

Astfel, testul de sarcină ar trebui să permită următoarea evaluare a sistemului:

  • evaluarea performanței sistemului informațional sau a părților sale individuale în funcție de parametrii dați ai modelului de întreprindere pentru a:
  • selectarea echipamentelor;
  • formularea cerințelor operaționale;
  • evaluarea aplicabilitatii sistemului informatic;
  • evaluarea scalabilității sistemului informațional la schimbarea:
  • volumul bazei de informații;
  • numărul de utilizatori concurenți;
  • sarcina pe sistem;
  • evaluarea modificărilor indicatorilor de performanță a sistemului la modificarea:
    • funcționalitatea sistemului (rafinarea sistemului sau a algoritmilor individuali);
    • configuratii de echipamente.
    • identificarea problemelor care apar numai în timpul lucrului cu mai mulți utilizatori (conflicte de blocare etc.).

Un test de sarcină ajută nu numai la evaluarea anumitor caracteristici. Dar, cel mai important, vă permite să identificați blocajele sistemului în avans și să rezolvați problema în cel mai eficient mod.

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 doar 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 upgrade (este 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-uri „avansate”, dacă nu ați găsit asta ș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ă puteț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. S-ar putea să existe 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ă un antivirus.
  • NU citiți guru Linux. Un server cu samba este grozav și gratuit, dar dacă instalați Win XP sau Win7 (sau chiar mai bine - server OS) pe server, atunci versiunea de fișier a 1c va funcționa mai rapid. Da, samba și stiva de protocol ș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 10 Gbit 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 15kUn singur SSDRamdiskRamdiskCache-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 accesare în cache de scriere 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ă chestiune, 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 un disc SSD, testez și cache-ul acestui disc î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, funcționează la viteze comparabile pentru testul lui Gilev. 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 (dacă îl întrebați) să folosiți 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.

Testul de încărcare standard este conceput pentru a evalua performanța hardware-ului și software-ului serverului la așa-numiții „Utilizatori Standard 1C”. Domeniul principal de aplicare a acestui test este selectarea configurațiilor hardware și software ale serverului în scopul unei implementări specifice.

Probleme de rezolvat

  • Calculul performanței unei configurații date de hardware și software de server
  • Compararea performanței diferitelor configurații hardware și software de server
  • Selectarea echipamentelor necesare functionarii acestui sistem informatic
  • Calculul parametrilor echipamentelor necesare functionarii acestui sistem informatic

Ce evaluează testul?

Testul evaluează performanța întregul set de hardware și software de server din punctul de vedere al sarcinilor tipice pentru sistemele care rulează pe platforma 1C:Enterprise 8. Adică, evaluarea rezultată nu reflectă performanța unei singure componente de server a sistemului (de exemplu, un server funcțional într-un cluster 1C:Enterprise), ci mai degrabă întreaga configurație a serverului în ansamblu. Partea server a sistemului, a cărei performanță este măsurată prin acest test, include:

  • toate serverele de lucru utilizate pentru a implementa clusterul 1C:Enterprise și serverele DBMS
  • sisteme de operare ale tuturor serverelor de lucru;
  • setările sistemelor de operare, 1C: Enterprise și DBMS.

În timpul testării, testul va crește automat numărul de utilizatori concurenți până când una dintre componentele hardware sau software ale sistemului nu mai poate face față sarcinii. Acest lucru va duce la o evaluare proastă a performanței și testul se va opri cu ultima valoare bună ca rezultat. În același timp, componentele rămase pot fi subîncărcate într-o măsură sau alta.

Astfel, testul evaluează performanța părții server a sistemului pe baza blocajului său, adică a componentului său cel mai puțin productiv.

Dacă partea de server a sistemului nu este bine echilibrată pentru a funcționa cu 1C:Enterprise, atunci prin eliminarea blocajului (înlocuirea sau actualizarea celei mai puțin productive componente) puteți obține un rating de performanță mai ridicat.

Vă rugăm să rețineți că testul nu evaluează în niciun fel performanța părții client a sistemului, așa că acest factor ar trebui exclus complet. Cu alte cuvinte, stațiile de lucru client nu ar trebui să devină un blocaj al sistemului. Această problemă este discutată mai detaliat în capitolul „Pregătirea părții client a bancului de testare”.

Cum funcționează testul

Testul de încărcare standard este o bază de informații 1C:Enterprise 8.2 cu o configurație bazată pe „Managementul întreprinderii de producție”. Configurația este combinată cu Test Center 2.0, care include un script de testare.

Scenariul de testare include emularea procesului de afaceri „vânzări în SCP”, și anume: crearea mai multor documente diferite, generarea de rapoarte și alte acțiuni aplicate. Testul funcționează în modul paralel complet, adică fiecare utilizator lucrează cu propriile sale date unice și nu există așteptări pentru încuietori. Utilizatorul finalizează un ciclu complet de vânzări pe minut.

Calculatoare (denumire convențională) care participă la teste - descriere (discurile sunt indicate doar pentru baza de date):

(clarificare intre servere de retea de 1 Gbit)

1) IT33- desktop pe Core i5 4 nuclee 2,8 GHz, DDR3 3 GB, un hard disk de 7200 rps.

2) REAL- CEL MAI PUTERNANT cum credeam)) 8 nuclee Xeon la 3 GHz, DDR2 48 GB, RAID10 pe SSD

3) REAL2- 8 nuclee Xeon la 2 GHz, DDR2 22 GB,RAID10 pe hard disk SAS de 10.000 rps

Testele au fost efectuate în configurația 1c de la Gilev:

„SQL Server” ---> „1C Server” ---> „Evaluare” + „Numele computerului client (dacă nu este specificat, atunci este același din listă)”

>1)REAL2--->REAL2--->25.64(TCP--SQL)
>2)REAL2--->REAL2--->26.32(SQL--Memorie partajată)

>3)REAL2--->REAL2--->25.64(SQL--Memorie partajată) + IT33(client) - de la client la rețeaua de servere=10 Mbit

>4 )REAL2--->REAL2--->24.27(SQL--Memorie partajată) + REAL(client) - hmm.. rețea ciudată de 1 Gbit... de ce sunt mai puțini papagali..
>5)REAL2--->REAL2--->37.59(Fișier)

** **** **************************
>1)REAL--->REAL--->8.73(TCP--SQL)

>2)REAL---> Real2--->11.99(TCP--SQL) --- asta începe deja să-mi dea câteva gânduri))

>3)REAL--->REAL--->17.48 (Fișier)

** **** ******************************

>1)IT33--->IT33--->26.88(TCP--SQL)
>2)IT33--->IT33--->34.72(SQL--Memorie partajată)
>3)IT33--->IT33--->59.52(Fișier)

Rezultate:

M-am uitat la rezultatele testelor... răsucite într-un loc și altul)) și apoi mi-am dat seama (am făcut măsurători ale vitezei RAM-ului),

ce zici de viteza lui 1s 8.x (observ ca Rezultatele Testelor se bazeaza pe modul SINGLE-USER, dar si pentru versiunea client-server cu lucru multi-user - cred ca vor avea si o pondere considerabila de influenta) -

Deci viteza lui 1C este afectată de: frecvența magistralei CPU + frecvența memoriei RAM

----> ceea ce afectează Vitezele de SCRIERE și CITIRE în RAM. Care este baza performanței lui 1s 8.x.

Calculatoare care au împărțit premii în ceea ce privește viteza de operare 1s))

1) IT33--->IT33--->59.52(Fișier)

RAM DDR 3 (citește 11089 MB/s, scrie 7047 MB/s) ------ așa cum mă așteptam, diferența va fi semnificativă cu serverele

2) REAL2--->REAL2--->37.59(Fișier)
- RAM DDR2 (citire=3474, scriere=2068)

3) REAL--->REAL--->17.48(Fișier)
- RAM DDR2 (Citire=1737 MB/s, Scriere=1042 MB/s) - după cum sa dovedit, viteza este mai mică decât pe Real2 - exact de 2 ori,

Datorită nucleelor ​​virtuale activate (Hyper-trading), cel mai probabil îl vom dezactiva.

CONCLUZII:

Cea mai mare viteză de operare de 1s 8.x este atinsă:

I) pentru opțiunea Fișier (nu mă interesează personal)

A) lansarea Clientului (orice) pe un computer cu viteză mare de lucru cu RAM. (de exemplu Terminal Server

DB acolo).

II) pentru opțiunea Client-Server

1) Clienți groși 1C pe „Serverul terminal” - cu +

2) Clienți subțiri 1C- nu există nicio diferență specială unde... dar este recomandabil să o configurați prin „HTTP://”.
3a) „SQL Server” + „1C Enterprise Server”(în modul Memorie partajată) - pe o mașină cu Cea mai mare viteză RAM de scriere/citire + Miezuri CPU cu cea mai înaltă frecvență GHz discuri

Clarificări:

- a sustineMemorie partajată- a aparut pe motor incepand cu 8.2.17 (ATENTIE in configuratie - nu trebuie activat modul de compatibilitate cu versiunile anterioare ale motorului), pe motoarele anterioare se vor folosi Naimed Pipes - arata si rezultate bune))

- RAID pe unități SSD- este recomandabil să utilizați RAID10 - pentru toleranța la erori, ținând cont de SCALA de scriere:

exemplu RAID10 (4 bucăți penalizare de scriere = 2), viteza de scriere = 4/2 = 2 discuri, fără penalizare de citire.

De asemenea, puteți crește și mai mult fiabilitatea și stabilitatea vitezei SSD - folosind nu întreaga capacitate a discului.

exemplu (creșterea fiabilității unui SSD desktop la nivelul unui SSD server):

Dacă, de exemplu, SSD Intel 520 seria 120 GB și alocă 81 GB și lasă restul spațiului nealocat -

atunci aproximativ 32% din spațiul SSD va fi alocat pentru supraprovizionare în plus față de 8% ascuns deja existent. În total obținem aproximativ 40%

Diferența dintre seria SSD pentru server Intel 710 și seria SSD pentru desktop Intel 320 este tocmai diferența de supraprovizionare: mai mult de 40% pentru Intel 710 și 8% pentru Intel 320.

Dacă există mulți clienți 1C de la 100 în sus:

1) Pe tehnologiile actuale de rețea Ethernet - NU este recomandabil să ștergeți „SQL” „Server 1C”.

de exemplu din cauza latenței (întârzierilor) în rețeaua Gigabit Ethernet - viteza reală de schimb cu SQL = 30 Megaocteți/s - ceea ce nu este suficient nici măcar pentru lucrul intensiv cu baza de date a 1 utilizator.

2) Pentru că de fapt, „Server 1C” = „Obiect DBMS” (obiecte multidimensionale) și „SQL” = „SGBD relațional”(stocare de date în tabel plat)

=> în baza de date SQL, o proiecție FLAT a obiectelor 1C este stocată și 1C Server colectează un obiect din această proiecție, apoi lucrează cu acest obiect și în final, la finalizarea lucrării, îl așează din nou într-o vedere plată și îl stochează în SQL.

Ca urmare, între „SQL” și „1C Server”, trebuie să renunțați să-l împărțiți în două servere fizice. Dar puteți folosi implementarea completă a nodurilor NUMA. ( Acest lucru trebuie să fie susținut de sistemul de operare și de procesoarele înșiși).


3b) Separăm serverele SQL și serverele 1c separat: Pe tehnologiile Ethernet actuale - de exemplu Gigabit - NU Practic
-SQL către server cu Cea mai mare viteză RAM de scriere/citire + Miezuri CPU cu cea mai înaltă frecvență GHz
-niste Servere FIZICE din Clusterul 1c c Cea mai mare viteză RAM de scriere/citire + Miezuri CPU cu cea mai înaltă frecvență GHz+ este recomandabil să utilizați RAID pe SSD- discuri