Ssd lemez 1s 8.3 fájlhoz. Gilyov – A konfiguráció átvitele kezelt zárakra

A cikk megírásának fő célja nem az, hogy megismételje a nyilvánvaló árnyalatokat azoknak a rendszergazdáknak (és programozóknak), akik még nem szereztek tapasztalatot az 1C-vel kapcsolatban.

Másodlagos cél, ha hiányosságaim vannak, erre a leggyorsabban az Infostart fog rámutatni.

V. Gilev tesztje már egyfajta „de facto” mércévé vált. A szerző a honlapján meglehetősen érthető ajánlásokat adott, de egyszerűen csak adok néhány eredményt, és megjegyzéseket fűzök a legvalószínűbb hibákhoz. Természetesen a teszteredmények az Ön berendezésein eltérhetnek, ez csak iránymutatás, hogy mi legyen és mire lehet törekedni. Azonnal szeretném megjegyezni, hogy a változtatásokat lépésről lépésre kell végrehajtani, és minden lépés után ellenőrizni kell, hogy milyen eredményt hozott.

Az Infostarton is vannak hasonló cikkek, a megfelelő rovatokban linkeket teszek rájuk (ha valamit kihagyok, szóljatok kommentben, felteszem). Tehát tegyük fel, hogy lelassítasz 1 C-ot. Hogyan lehet diagnosztizálni a problémát, és hogyan lehet megérteni, hogy ki a hibás, a rendszergazda vagy a programozó?

Kiinduló adatok:

Tesztelt számítógép, fő tengerimalac: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Összehasonlításképpen a Core i3-2100 egyszálú teszt összehasonlítható eredményeit mutatja. A berendezést kifejezetten nem a legfrissebbre vettük, a modern berendezéseken érezhetően jobbak az eredmények.

Távoli 1C és SQL szerverek teszteléséhez SQL szerver: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

A 10 Gbit-es hálózat teszteléséhez Intel 520-DA2 adaptereket használtak.

Fájl verzió. (az alap a szerveren van a megosztott mappában, a kliensek hálózatra csatlakoznak, a CIFS/SMB protokoll). Lépésről lépésre algoritmus:

0. Adja hozzá a Gilev tesztadatbázist a fájlkiszolgálóhoz ugyanabban a mappában, mint a fő adatbázisok. Csatlakozunk a kliens számítógépről, futtassuk le a tesztet. Emlékszünk az eredményre.

Nyilvánvaló, hogy még a 10 évvel ezelőtti régi számítógépeknél is (Pentium 775-ös foglalattal ) az 1C:Enterprise címkére való kattintástól az adatbázis-ablak megjelenéséig eltelt időnek kevesebbnek kell lennie egy percnél. ( Celeron = lassú munka).

Ha a számítógépe rosszabb, mint egy bekapcsolt Pentium 775-ös foglalat 1 GB RAM-mal, akkor együtt érzek veled, és nehéz lesz kényelmes munkát elérni az 1C 8.2 fájlverzióban. Fontolja meg a frissítést (már régen esedékes), vagy terminál- (vagy vékonykliensek és felügyelt űrlapok esetén webes) kiszolgálóra váltást.

Ha a számítógép nem rosszabb, akkor kirúghatja a rendszergazdát. Legalább ellenőrizze a hálózat, a víruskereső és a HASP védelmi illesztőprogram működését.

Ha Gilev tesztje ebben a szakaszban 30 "papagájt" mutatott ki és még többet, de az 1C munkabázis még mindig lassan működik - a kérdések már a programozóhoz szólnak.

1. Útmutatóként, hogy egy kliens számítógép mennyit tud "kipréselni", csak ennek a számítógépnek a működését ellenőrizzük, hálózat nélkül. A tesztbázist a helyi számítógépre tesszük (egy nagyon gyors lemezre). Ha az ügyfélszámítógép nem rendelkezik normál SSD-vel, akkor létrejön egy ramdisk. Eddig a legegyszerűbb és ingyenes a Ramdisk Enterprise.

A 8.2-es verzió teszteléséhez elég 256 MB ramdisk, és! A legfontosabb dolog. Miután újraindította a számítógépet egy működő ramdiskkel, 100-200 MB szabadnak kell lennie. Ennek megfelelően, ramdisk nélkül, a szabad memória normál működéséhez 300-400 MB-nak kell lennie.

A 8.3-as verzió teszteléséhez elég egy 256 MB-os ramdisk, de több szabad RAM szükséges.

Teszteléskor meg kell nézni a processzor terhelését. Az ideálishoz közeli esetben (ramdisk) az 1c helyi fájl 1 processzormagot tölt be működés közben. Ennek megfelelően, ha a tesztelés során a processzormag nincs teljesen betöltve, keresse a gyengeségeket. Kicsit érzelmes, de általánosságban korrekt, leírják a processzor hatását az 1C működésére. Csak referenciaként, még a modern, magas frekvenciájú Core i3-on is egészen valóságosak a 70-80-as számok.

A leggyakoribb hibák ebben a szakaszban.

a) Helytelenül konfigurált víruskereső. Sok vírusirtó létezik, mindegyiknél más a beállítások, csak azt tudom mondani, hogy megfelelő konfiguráció mellett sem a web, sem a Kaspersky 1C nem zavar. Az "alapértelmezett" beállításokkal kb 3-5 papagáj (10-15%) vihető el.

b) Teljesítmény mód. Valamiért kevesen figyelnek erre, és a hatás a legjelentősebb. Ha gyorsaságra van szüksége, akkor ezt meg kell tennie, mind kliens, mind szerver számítógépeken. (Gilevnek van egy jó leírása. Az egyetlen figyelmeztetés, hogy egyes alaplapokon, ha az Intel SpeedStep ki van kapcsolva, akkor a TurboBoost nem kapcsolható be).

Röviden, az 1C működése során rengeteget kell várni más eszközök (lemez, hálózat stb.) válaszára. Amikor a válaszra vár, ha a teljesítmény mód kiegyensúlyozott, akkor a processzor csökkenti a frekvenciáját. Válasz érkezik az eszköztől, az 1C-nek (a processzornak) működnie kell, de az első ciklusok csökkentett frekvencián mennek, majd a frekvencia emelkedik - és az 1C ismét az eszköz válaszára vár. És így - sok százszor másodpercenként.

A teljesítmény módot két helyen engedélyezheti (és lehetőleg):

BIOS-on keresztül. A C1, C1E, Intel C-state (C2, C3, C4) módok letiltása. Különböző biosokban másképpen hívják őket, de a jelentés ugyanaz. Hosszan keresgélj, újraindítás szükséges, de ha egyszer megtetted, akkor elfelejtheted. Ha minden helyesen történik a BIOS-ban, akkor a sebesség hozzáadódik. Egyes alaplapokon a BIOS beállításai úgy állíthatók be, hogy a Windows teljesítménymódja ne játsszon szerepet. (Példák a Gilev által készített BIOS-beállításra). Ezek a beállítások főként a szerverprocesszorokra vagy a "fejlett" BIOS-ra vonatkoznak, ha nem találtad meg a rendszeredben, és nincs Xeonod – nem baj.

Vezérlőpult - Teljesítmény - Nagy teljesítmény. Mínusz - ha a számítógépet sokáig nem szervizelték, akkor ventilátorral erősebben zümmög, jobban felmelegszik és több energiát fogyaszt. Ez a teljesítmény ára.

Hogyan ellenőrizhető, hogy az üzemmód engedélyezve van-e. Futtassa a Feladatkezelőt – Teljesítmény – Erőforrásfigyelő – CPU. Megvárjuk, amíg a processzor semmivel nem lesz elfoglalva.

Ezek az alapértelmezett beállítások.

BIOS C-állapot beleértve,

kiegyensúlyozott energia üzemmód

BIOS C-állapot beleértve, nagy teljesítményű mód

A Pentium és a Core esetében itt megállhat,

a Xeonból még ki lehet préselni néhány "papagájt".

BIOS C-állapot ki, nagy teljesítményű mód.

Ha nem használja a Turbo boost-ot - így kell kinéznie

teljesítményre hangolt szerver

És most a számok. Hadd emlékeztesselek: Intel Xeon 5650, ramdisk. Az első esetben a teszt 23,26-ot mutat, az utóbbiban - 49,5. A különbség majdnem kétszeres. A számok változhatnak, de az arány nagyjából ugyanaz marad az Intel Core esetében.

Kedves rendszergazdák, tetszés szerint szidhatják az 1C-t, de ha a végfelhasználóknak gyorsaságra van szükségük, engedélyezni kell a nagy teljesítményű módot.

c) Turbo Boost. Először meg kell értenie, hogy például a processzora támogatja-e ezt a funkciót. Ha igen, akkor is teljesen legálisan szerezhet némi teljesítményt. (Nem akarok a túlhúzás problémáival foglalkozni, főleg a szervereknél, ezt csak a saját károdra és kockázatodra tedd. De egyetértek azzal, hogy a busz sebességének 133-ról 166-ra való növelése nagyon észrevehető növekedést eredményez mind a sebességben, mind a hőleadásban)

A turbo boost bekapcsolásának módja meg van írva pl. De! Az 1C esetében van néhány árnyalat (nem a legnyilvánvalóbb). A nehézséget az jelenti, hogy a turbóerősítés maximális hatása a C állapot bekapcsolásakor nyilvánul meg. És valami ilyesmi lesz belőle:

Kérjük, vegye figyelembe, hogy a szorzó a maximális, a Mag sebesség a legszebb, a teljesítmény magas. De mi lesz az 1s eredményeként?

	Tényező	Magsebesség (frekvencia), GHz	CPU-Z egyszálú	Gilev Ramdisk teszt fájl verzió	Gilev Ramdisk teszt kliens-szerver
turbóerősítés nélkül
C-állapot kikapcsolva, turbóerősítés				53.19	40,32
C állapot be, turbóerősítés			1080	53,13	23,04

De a végén kiderül, hogy a CPU-teljesítménytesztek szerint a 23-as szorzós változat van előrébb, Gilev tesztjei szerint a fájlverzióban a teljesítmény 22-es és 23-as szorzóval megegyezik, de a kliens-szerver verzió, a változat 23-as szorzóval horror horror horror (még ha a C -state 7-es szintre van állítva, akkor is lassabb, mint kikapcsolt C állapot esetén). Ezért az ajánlást, ellenőrizze saját maga mindkét lehetőséget, és válassza ki a legjobbat közülük. Mindenesetre a 49,5 és 53 papagájok közötti különbség meglehetősen jelentős, különösen azért, mert ez nem sok erőfeszítést igényel.

Következtetés – a turbófokozót bele kell foglalni. Hadd emlékeztesselek arra, hogy nem elég engedélyezni a Turbo boost elemet a BIOS-ban, meg kell nézni a többi beállítást is (BIOS: QPI L0s, L1 - letilt, scrubbing igény - letilt, Intel SpeedStep - engedélyezés, Turbo boost - Vezérlőpult - Tápellátás - Nagy teljesítmény) . És továbbra is (még a fájlverziónál is) megállnék azon az opciónál, ahol a c-state ki van kapcsolva, pedig ott kevesebb a szorzó. Szerezz valami ilyesmit...

Egy meglehetősen ellentmondásos pont a memória frekvenciája. Például a memória frekvenciája nagyon befolyásos. A tesztjeim nem mutattak ki ilyen függőséget. A DDR 2/3/4-et nem fogom összehasonlítani, a frekvenciaváltoztatás eredményeit ugyanazon a vonalon belül mutatom meg. A memória ugyanaz, de a BIOS-ban alacsonyabb frekvenciákat erőltetünk.

És a teszteredmények. 1C 8.2.19.83, helyi ramdisk fájlverzióhoz, 1C kliens-szerverhez és SQL-hez egy számítógépen, megosztott memória. A Turbo Boost mindkét opciónál le van tiltva. A 8.3 összehasonlítható eredményeket mutat.

A különbség a mérési hibán belül van. Kifejezetten kihúztam a CPU-Z képernyőképeket, hogy megmutassam, más paraméterek is változnak a frekvencia változásával, ugyanaz a CAS késleltetés és a RAS a CAS Delay, ami kiegyenlíti a frekvenciaváltozást. A különbség akkor lesz, amikor a memóriamodulok fizikailag változnak, lassabbról gyorsabbra, de még ott sem túl jelentősek a számok.

2. Amikor kitaláltuk a kliens számítógép processzorát és memóriáját, áttérünk a következő nagyon fontos helyre - a hálózatra. Sok könyvet írtak a hálózati tuningról, vannak cikkek az Infostartról (és mások), itt nem erre a témára koncentrálok. Mielőtt elkezdené az 1C tesztelését, győződjön meg arról, hogy a két számítógép közötti iperf a teljes sávot mutatja (1 Gbit-es kártyáknál - nos, legalább 850 Mbit, de jobb, ha 950-980), hogy betartják-e Gilev tanácsát. Ezután a munka legegyszerűbb tesztje furcsa módon egy nagy fájl (5-10 gigabájt) másolása lesz a hálózaton keresztül. A normál működés közvetett jele egy 1 Gbps-os hálózaton az átlagos másolási sebesség 100 Mb / s, a jó munka pedig 120 Mb / s. Szeretném felhívni a figyelmet, hogy a processzorterhelés is lehet gyenge pont (beleértve). SMB Linuxon a protokoll meglehetősen rosszul párhuzamosított, és működés közben elég könnyen „megeszik” egy processzormagot, és már nem fogyasztja el.

És tovább. Alapbeállításokkal a windows kliens windows szerverrel (vagy akár windows munkaállomással) és SMB/CIFS protokollal működik a legjobban, linux kliens (debian, ubuntu nem nézte a többit) linuxszal és NFS-sel működik a legjobban (SMB-vel is működik, de az NFS papagájokon fent). Az a tény, hogy a win-linux szerver nfs-re való lineáris másolásakor gyorsabban másolódik egy adatfolyamba, az nem jelent semmit. A debian hangolása 1C-re külön cikk témája, még nem állok készen rá, bár elmondhatom, hogy a fájl verzióban még egy kicsit jobb teljesítményt is kaptam, mint a Win verzió ugyanazon a berendezésen, de postgres-el 50 év feletti felhasználók Nekem még mindig nagyon rossz minden.

A legfontosabb dolog , amit a "leégett" adminisztrátorok ismernek, de a kezdők nem veszik figyelembe. Számos módja van az 1c adatbázis elérési útjának beállítására. Megteheti a \\server\share, a \\192.168.0.1\share, netezheti a z: \\192.168.0.1\share parancsot (és bizonyos esetekben ez a módszer is működik, de nem mindig), majd adja meg A Z meghajtó. Úgy tűnik, hogy ezek az utak ugyanarra a helyre mutatnak, de az 1C esetében csak egy mód van, amely meglehetősen stabil teljesítményt biztosít. Tehát a következőket kell helyesen tennie:

A parancssorban (vagy a házirendekben, vagy bármiben, ami megfelel Önnek) - használja a DriveLetter-t: \\server\share. Példa: net use m:\\server\bases. Kifejezetten hangsúlyozom NEM IP címet, mégpedig név szerver. Ha a kiszolgáló név szerint nem látható, adja hozzá a szerver DNS-éhez, vagy helyileg a hosts fájlhoz. De a fellebbezésnek névre szólónak kell lennie. Ennek megfelelően az adatbázis felé vezető úton érje el ezt a lemezt (lásd a képet).

És most számokban mutatom meg, hogy miért ilyen tanácsok. Kiinduló adatok: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kártyák OS Win 2008 R2, Win 7, Debian 8. Legújabb illesztőprogramok, frissítések alkalmazva. Tesztelés előtt megbizonyosodtam arról, hogy az Iperf teljes sávszélességet ad (a 10 Gbites kártyák kivételével kiderült, hogy csak 7,2 Gbitet présel ki, később meglátom, miért, a tesztszerver még nincs megfelelően beállítva). A lemezek különbözőek, de mindenhol van SSD (speciálisan egyetlen lemez van behelyezve tesztelésre, más nincs betöltve) vagy raid SSD-ről. A 100 Mbit sebességet az Intel 362 adapter beállításainak korlátozásával kaptuk, az 1 Gbit réz Intel 350 és az 1 Gbit optika Intel X520-DA2 között (az adapter sebességének korlátozásával kaptuk) nem volt különbség. Maximális teljesítmény, a turbo boost ki van kapcsolva (csak az eredmények összehasonlíthatósága miatt, a turbónövelés kicsivel kevesebb, mint 10%-ot tesz hozzá a jó eredményekhez, rossz eredmények esetén pedig lehet, hogy egyáltalán nem befolyásolja). 1C verzió 8.2.19.86, 8.3.6.2076. Nem adom meg az összes számot, csak a legérdekesebbeket, hogy legyen mihez hasonlítani.

	Win 2008 - Win 2008 ip címről hívni	Win 2008 - Win 2008 Cím név szerint	Win 2008 - Win 2008 Hívás ip címről	Win 2008 - Win 2008 Cím név szerint	Win 2008 - Win 7 Cím név szerint	Windows 2008 – Debian Cím név szerint	Win 2008 - Win 2008 Hívás ip címről	Win 2008 - Win 2008 Cím név szerint
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Következtetések (a táblázatból és személyes tapasztalatból. Csak a fájl verziójára vonatkozik):

A hálózaton keresztül egészen normális számokat kaphat a munkához, ha ez a hálózat normálisan van konfigurálva, és az elérési út helyesen van megírva 1C-ben. Már az első Core i3-ak is 40+ papagájt adnak, ami elég jó, és ezek nem csak papagájok, a valós munkában is érezhető a különbség. De! a korlátozás több (10-nél több) felhasználóval való munkavégzésnél már nem a hálózat lesz, itt 1 Gbit még elég, de többfelhasználós munka során blokkol (Gilev).

Az 1C 8.3 platform sokszor nagyobb igényeket támaszt a kompetens hálózati beállításhoz. Alapbeállítások – lásd Gilev, de ne feledje, hogy minden befolyásolhatja. Gyorsulást tapasztaltam attól, hogy eltávolították (és nem csak kikapcsolták) a víruskeresőt, az olyan protokollok eltávolításától, mint az FCoE, az illesztőprogramok cseréjétől egy régebbi, de microsoft-tanúsítvánnyal rendelkező verzióra (különösen az olyan olcsó kártyák esetében, mint az asus és a dlinkek), és az második hálózati kártya a szerverről. Sok lehetőség, átgondoltan konfigurálja a hálózatot. Előfordulhat olyan helyzet, amikor a 8.2 platform elfogadható számokat ad, a 8.3 pedig kétszer vagy akár többször is kevesebbet. Próbáljon meg játszani a 8.3-as platformverziókkal, néha nagyon nagy hatást ér el.

1C 8.3.6.2076 (talán később, még nem kerestem a pontos verziót) hálózaton keresztül még mindig könnyebben beállítható, mint 2008.7.8. 2008.07.8.-tól a normál hálózati működés elérése (hasonló papagájoknál) csak néhány alkalommal sikerült, általánosabb esetre nem tudnám megismételni. Nem sokat értettem, de a Process Explorer lábtörlőiből ítélve ott nem úgy megy a felvétel, mint a 8.3.6-ban.

Annak ellenére, hogy 100 Mbps-os hálózaton dolgozva kicsi a betöltési ütemezése (mondhatjuk, hogy a hálózat ingyenes), a munka sebessége még mindig jóval kisebb, mint 1 Gbps-en. Ennek oka a hálózati késleltetés.

Ceteris paribus (jól működő hálózat) az 1C 8.2-hez, az Intel-Realtek kapcsolat 10%-kal lassabb, mint az Intel-Intel. De a realtek-realtek általában hirtelen tud éles süllyedést okozni. Ezért ha van pénz jobb, ha mindenhol tartasz Intel hálókártyákat, ha nincs pénz, akkor csak az Intelt rakd a szerverre (a KO-d). Igen, és az intel hálózati kártyák hangolására is sokszor több utasítás van.

Az alapértelmezett víruskereső beállítások (például a drweb 10-es verziója) a papagájok körülbelül 8-10%-át veszik el. Ha megfelelően konfigurálja (engedje meg, hogy az 1cv8 folyamat csináljon mindent, bár ez nem biztonságos) - a sebesség ugyanaz, mint vírusirtó nélkül.

NE olvass Linux gurukat. A sambával rendelkező szerver nagyszerű és ingyenes, de ha Win XP-t vagy Win7-et tesz a szerverre (vagy még jobb - a szerver operációs rendszerére), akkor a fájlban az 1c verzió gyorsabban fog működni. Igen, mind a samba, mind a protokollverem és a hálózati beállítások és még sok más debian / ubuntu jól be van hangolva, de ez a szakembereknek ajánlott. Nincs értelme alapértelmezett beállításokkal telepíteni a Linuxot, és azt mondani, hogy lassú.

A nethasználaton keresztül csatlakoztatott lemezeket érdemes a fio segítségével tesztelni. Legalább világos lesz, hogy ezek a problémák az 1C platformmal vagy a hálózattal / lemezzel vannak-e.

Egyfelhasználós változatnál nem jut eszembe olyan teszt (vagy olyan helyzet), ahol az 1 Gb és a 10 Gb közötti különbség látható lenne. Az egyetlen hely, ahol a 10 Gbps a fájlverzióhoz jobb eredményeket hozott, az iSCSI-n keresztüli lemezek csatlakoztatása volt, de ez egy külön cikk témája. Ennek ellenére úgy gondolom, hogy az 1 Gbit-es kártya elég a fájlverzióhoz.

Miért működik egy 100 Mbit-es hálózatnál a 8.3 észrevehetően gyorsabban, mint a 8.2 - nem értem, de a tény megtörtént. Az összes többi berendezés, az összes többi beállítás pontosan ugyanaz, csak az egyik esetben a 8.2-t tesztelik, a másikban pedig a 8.3-at.

Nem hangolt NFS win - win vagy win-lin 6 papagájt ad, nem vette fel a táblázatba. Tuning után 25-öt kaptam, de instabil (a mérésekben a felfutás több mint 2 egység). Egyelőre nem tudok ajánlást adni a Windows és az NFS protokoll használatára vonatkozóan.

Minden beállítás és ellenőrzés után újra lefuttatjuk a tesztet a kliens számítógépről, örüljünk a javuló eredménynek (ha sikerült). Ha az eredmény javult, több mint 30 papagáj (és különösen több mint 40), kevesebb, mint 10 felhasználó dolgozik egyszerre, és a működő adatbázis továbbra is lelassul - szinte biztosan programozói probléma (vagy már elérte a fájlverzió képességeinek csúcsát).

terminál szerver. (az alap a szerveren van, a kliensek hálózatra csatlakoznak, az RDP protokoll). Lépésről lépésre algoritmus:

0. Adja hozzá a Gilev tesztadatbázist a kiszolgálóhoz ugyanabban a mappában, mint a fő adatbázisok. Ugyanarról a szerverről csatlakozunk, és futtatjuk a tesztet. Emlékszünk az eredményre.

1. Ugyanúgy, mint a fájl verzióban, beállítjuk a munkát. A terminálkiszolgálók esetében általában a processzor játssza a főszerepet (érthető, hogy nincsenek nyilvánvaló gyengeségek, például memóriahiány vagy hatalmas mennyiségű felesleges szoftver).

2. A hálózati kártyák felállítása terminál szerver esetén gyakorlatilag nincs hatással az 1s működésére. A "különleges" kényelem érdekében, ha a szervere több mint 50 papagájt ad ki, játszhat az RDP protokoll új verzióival, csak a felhasználók kényelme, a gyorsabb reagálás és a görgetés érdekében.

3. Nagyszámú felhasználó aktív munkájával (és itt már meg lehet próbálni 30 ember csatlakoztatását egy bázishoz, ha megpróbálja), nagyon kívánatos egy SSD meghajtó telepítése. Valamilyen oknál fogva úgy gondolják, hogy a lemez nem befolyásolja különösebben az 1C működését, de minden tesztet úgy hajtanak végre, hogy a vezérlő gyorsítótára engedélyezve van az írásra, ami hibás. A tesztbázis kicsi, elfér a gyorsítótárban, innen a magas számok. Valódi (nagy) adatbázisokon minden teljesen más lesz, így a gyorsítótár letiltva a tesztekhez.

Például ellenőriztem a Gilev-teszt működését különböző lemezopciókkal. Korongokat tettem abból, ami kéznél volt, csak a tendencia kedvéért. 2076.06.8. és 2008.07.08. között kicsi a különbség (a Ramdisk Turbo boost 8.3.6-os verziójában 56.18-at ad, a 2008.07.08. pedig 55.56-ot, más teszteknél még kisebb a különbség). Energiafogyasztás - maximális teljesítmény, turbónövelés letiltva (hacsak nincs másképp jelezve).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Egyetlen SSD	ramdisk		Gyorsítótár engedélyezve RAID vezérlő
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

A RAID vezérlő mellékelt gyorsítótára minden különbséget kiküszöböl a lemezek között, a számok ugyanazok a sat és az sas esetében is. A vele végzett tesztelés kis mennyiségű adat esetén haszontalan, és nem mutató.

A 8.2-es platformon a SATA és az SSD opciók közötti teljesítménykülönbség több mint duplája. Ez nem elírás. Ha megnézi a teljesítményfigyelőt a SATA meghajtókon végzett teszt során. akkor jól látható "Aktív lemezidő (%)" 80-95. Igen, ha engedélyezi maguknak a lemezeknek az írási gyorsítótárát, a sebesség 35-re nő, ha engedélyezi a raidvezérlő gyorsítótárát - 49-ig (függetlenül attól, hogy mely lemezeket tesztelik jelenleg). De ezek a gyorsítótár szintetikus papagájjai, nagy adatbázisokkal való valós munkában soha nem lesz 100%-os írási gyorsítótár találati aránya.

Még az olcsó SSD-k sebessége is (Agility 3-on teszteltem) elegendő a fájlverzió működéséhez. Az írási erőforrás más kérdés, itt minden konkrét esetben meg kell nézni, egyértelmű, hogy az Intel 3700-nál egy nagyságrenddel magasabb lesz, de ott az ár megfelelő. És igen, megértem, hogy egy SSD meghajtó tesztelésekor ennek a meghajtónak a gyorsítótárát is nagyobb mértékben tesztelem, a valós eredmény kevesebb lesz.

A leghelyesebb (szempontom szerint) megoldás az lenne, ha a fájlbázis (vagy több fájlbázis) tükörraidjához 2 SSD lemezt rendelnénk, és nem tennénk oda semmi mást. Igen, tükörrel az SSD-k ugyanúgy kopnak, és ez egy mínusz, de legalább valahogy biztosítottak a vezérlő elektronikájának hibái ellen.

Az SSD-lemezek fő előnyei a fájlverzióhoz akkor fognak megjelenni, ha sok adatbázis van, és mindegyikhez több felhasználó tartozik. Ha 1-2 alap van, és 10 körüli a felhasználók, akkor elég lesz a SAS lemez. (de mindenesetre - nézd meg ezeknek a lemezeknek a betöltését, legalábbis perfmon-on keresztül).

A terminálszerver fő előnye, hogy nagyon gyenge kliensekkel rendelkezik, és a hálózati beállítások sokkal kevésbé hatnak a terminálkiszolgálóra (megint a KO-d).

Következtetések: ha a Gilev tesztet a terminálkiszolgálón futtatja (ugyanarról a lemezről, ahol a működő adatbázisok találhatók) és azokban a pillanatokban, amikor a működő adatbázis lelassul, és a Gilev teszt jó eredményt mutat (30 felett), akkor a a fő működő adatbázis lassú működése a hibás, valószínűleg programozó.

Ha a Gilev-teszt kis számokat mutat, és van magas frekvenciájú processzora és gyors lemezei is, akkor itt az adminisztrátornak legalább perfmon-t kell vennie, és valahova rögzítenie kell az összes eredményt, és figyelnie kell, megfigyelnie kell, le kell vonnia a következtetéseket. Nem lesz végleges tanács.

Kliens-szerver opció.

A teszteket csak a 8.2, tk. A 8.3-as verzión minden nagyon komolyan függ a verziótól.

A teszteléshez különböző szerverlehetőségeket és a köztük lévő hálózatokat választottam, hogy megmutassam a főbb trendeket.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiber csatorna-SSD	SQL: Xeon E5-2630 Fiber csatorna - SAS	SQL: Xeon E5-2630 Helyi SSD	SQL: Xeon E5-2630 Fiber csatorna-SSD	SQL: Xeon E5-2630 Helyi SSD	1C: Xeon 5650 =	1C: Xeon 5650 = megosztott memória	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1С 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Úgy tűnik, hogy minden érdekes lehetőséget megvizsgáltam, ha valami más érdekel - írd meg a megjegyzésekben, megpróbálom megtenni.

A tárhelyen lévő SAS lassabb, mint a helyi SSD-k, annak ellenére, hogy a tárhely nagy gyorsítótárral rendelkezik. A Gilev teszthez használt SSD-k, valamint helyi és tárolórendszerek hasonló sebességgel működnek. Nem ismerek semmilyen szabványos többszálas tesztet (nem csak rekordokat, hanem minden berendezést), kivéve az MCC-ből származó 1C terhelést.

Az 1C szerver 5520-ról 5650-re cseréje majdnem megkétszerezte a teljesítményt. Igen, a szerver konfigurációk nem egyeznek teljesen, de ez egy trendet mutat (semmi meglepő).

Az SQL szerveren a frekvencia növelése biztosan meghozza a hatását, de nem olyan, mint az 1C szerveren, az MS SQL szerver tökéletesen képes (ha rákérdezünk) többmagos és szabad memória használatára.

Ha a hálózatot 1C és SQL között 1 Gb/s-ról 10 Gb/s-ra változtatjuk, a papagájok körülbelül 10%-át eredményezi. Többet vártak.

A Megosztott memória engedélyezése továbbra is a leírt hatást adja, bár nem 15%-ot. Ügyeljen arra, hogy tegye meg, ez gyors és egyszerű. Ha valaki a telepítés során adott egy elnevezett példányt az SQL szervernek, akkor ahhoz, hogy az 1C működjön, a kiszolgáló nevét nem FQDN-nel kell megadni (a tcp / ip fog működni), nem a localhost-on vagy csak a Kiszolgálónéven keresztül, hanem például a Kiszolgálónév\Példánynéven keresztül zz-teszt\zzteszt. (Egyébként DBMS hiba lép fel: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Az SQL Server 2000-hez való csatlakozáshoz használt megosztott memória könyvtár nem található. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSTATSEVr =08001, állapot=1, súlyosság=10, natív=126, sor=0).

A 100 évnél fiatalabb felhasználók számára a két különálló szerverre való felosztás egyetlen pontja a Win 2008 Std (és régebbi verziók) licence, amely csak 32 GB RAM-ot támogat. Minden más esetben az 1C-t és az SQL-t feltétlenül ugyanarra a szerverre kell telepíteni, és több (legalább 64 GB) memóriát kell adni. Indokolatlan kapzsiság az MS SQL-nek 24-28 GB-nál kevesebb RAM-ot adni (ha úgy gondolod, hogy van rá elég memória, és minden jól működik, talán az 1C fájlverzió is elég lenne neked?)

Hogy mennyivel rosszabbul működik egy rakás 1C és SQL egy virtuális gépben, az egy külön cikk témája (tipp – érezhetően rosszabb). Még a Hyper-V-ben sem olyan egyértelműek a dolgok...

A kiegyensúlyozott teljesítmény mód rossz. Az eredmények jól egyeznek a fájl verziójával.

Sok forrás szerint a hibakeresési mód (ragent.exe -debug) erőteljesen csökkenti a teljesítményt. Hát csökkenti, igen, de a 2-3%-ot nem nevezném jelentős hatásnak.

Szerver tervezése az "1C:Enterprise 8" igényeihez közepes és nagyvállalatok számára

Az anyag azoknak a műszaki szakembereknek szól, akik szervermegoldásokat terveznek az 1C:Enterprise 8 igényeihez, 25-250 vagy annál nagyobb felhasználóterheléssel. Figyelembe veszik a szükséges teljesítmény szerverkomponensenkénti felmérésének kérdéseit, figyelembe véve az extrém terhelési eseteket, a virtualizáció hatását. A nagyvállalatok hibatűrő vállalati infrastruktúrájának kiépítésének kérdéseit a következő anyag tárgyalja.

A szükséges berendezések teljesítményének becslése.

A berendezés kiválasztásához legalább előzetes felmérés szükséges a CPU, RAM, lemez alrendszer és hálózati interfész erőforrások iránt.
Itt kétféleképpen érdemes megfontolni:
a) Kísérleti, amely lehetővé teszi objektív adatok beszerzését a jelenlegi berendezések terheléséről és a szűk keresztmetszetek azonosítását;
b) Becsült, amely lehetővé teszi az empirikusan nyert átlagolt adatok alapján értékelést.
A leghatékonyabb a két módszer együttes alkalmazása.

Terhelésfigyelés, eredmények értékelése, szűk keresztmetszetek feltárása és követelmények generálása

Miért fontos terheléselemzést végezni, ha már rendelkezik futó rendszerrel?
Itt lenne a leghelyesebb az orvostudományhoz hasonlítani. Amikor a páciens orvoshoz fordul, először vizsgálatot végeznek, vizsgálatokat írnak elő, majd a rendelkezésre álló információk teljes komplexumát értékelik és kezelést írnak elő. A szerver tervezésénél pontosan ugyanez a helyzet.
A terhelési paraméterek mérésére és az eredmények elemzésére fordítva, jutalmul megkapjuk a megtervezett szervert a feladatunkhoz legjobban illően. A végeredmény - jelentős megtakarítás, mind a kezdeti költségek, mind a jövőbeni működési költségek.

A szerver teljesítményét a fő alrendszerek keretein belül értékeljük: központi processzorok, RAM, lemez bemeneti / kimeneti alrendszer és hálózati interfészek. A Windows környezetben van egy szabványos Windows Performance Monitor (perfmon) eszközkészlet a számítási terhelés kiértékeléséhez. Más rendszereknek saját, egyenértékű értékelési eszközei vannak.
Általánosságban elmondható, hogy az egyes alrendszerek terhelése nagymértékben függ az általuk használt alkalmazásoktól és adattípusoktól. Az 1C-hez kapcsolódó alkalmazások blokkjában a legkritikusabb a CPU, a RAM, az SQL szervernél pedig a lemez alrendszer. Ha több szerver között van elosztva, a hálózati interfész is kritikus fontosságú. Csak azokkal a paraméterekkel fogunk dolgozni, amelyek az alkalmazott feladat szempontjából fontosak számunkra.
Az elemzéshez szükséges adatokat egy átlagos munkanapon legalább 24 órával korábban kell begyűjteni. Ideális esetben három átlagos munkanap adatgyűjtése. A szűk keresztmetszetek megtalálásához célszerű a legnagyobb terhelés napján adatokat venni.
Az alábbiakban leírtak hasznosak lesznek, mind az új szerver tervezésének előkészítésének szakaszában (a beszállító feladatának meghatározásához), mind az üzemeltetés során a berendezés paramétereiben bekövetkezett változások objektív értékeléséhez és az esetleges további „hangoláshoz” ” általánosságban az „1C: Enterprise 8” alatti szoftver- és hardverkomplexumból.

CPU. Leginkább egy paraméter érdekel minket - " Processzor: % Processzoridő» (« Processzor: % Processzoridő "). A Microsoft a következőket mondja erről a paraméterről: „Ez a számláló nyomon követi azt az időt, amelyet a CPU egy szál végrehajtásával tölt, miközben az fut. A 80% és 90% közötti állandó CPU-használati szint CPU-frissítést vagy több processzor hozzáadásának szükségességét jelezheti." Így, ha a CPU terhelése átlagosan 70-80% között van, akkor ez a CPU erőforrások felhasználásának hatékonyságának és a csúcsidőszaki teljesítménytartaléknak az optimális aránya. Kevesebb - a rendszer alulterhelt. Több mint 80% - veszélyben, 90% - a rendszer túlterhelt, vagy el kell osztani a terhelést más gazdagépekhez, vagy át kell költözni egy új, termelékenyebb szerverre.

CPU elemzés . A modern processzorok esetében érdemes először megtudni, hány magra van szüksége. Maga a Windows elég hatékonyan osztja el a terhelést a magok között, és azon ritka esetek kivételével, amikor a szoftverszinten egyértelmű a magokhoz való kötődés, az összes processzormag többé-kevésbé egyenletesen lesz betöltve. Általában, ha van paramétere "% cpu idő» 50-70%-on belül van - minden rendben, van tartalék. Ha kevesebb, mint 50%, akkor a rendszerében már több mag van, csökkentheti a számát, vagy más feladatokkal terhelheti a szervert. Átlagos terhelés 80% vagy több – a rendszernek több magra van szüksége.

RAM . Itt két paramétert érdemes követni:
« Memória: Rendelkezésre álló Mbyte» (« Memória: Rendelkezésre álló MB "). Normál operációs rendszeren ennek a számlálónak a kiszolgálón telepített fizikai memória mennyiségének legalább 10%-ának kell lennie. Ha túl kevés a rendelkezésre álló memória, a rendszer kénytelen lesz a lapozófájlt használni az aktív folyamatokhoz. Ennek eredményeként észrevehető késések lépnek fel a rendszer "lefagyásáig".
« memória:%ElkötelezettbájtokBan benhasználat», « Memória: % lefoglalt memóriahasználat ". A számláló magas értéke azt jelzi, hogy a rendszer nagy terhelést tapasztal a RAM-on. Nagyon kívánatos, hogy ez a paraméter 90% alatt legyen, mert. 95%-nál fennáll az OutOfMemory hiba esélye.

RAM elemzés . A legfontosabb paraméter a rendelkezésre álló RAM elérhetősége a kiszolgálón, amely lehetővé teszi a fenti számlálók hatékony figyelését.

lemez alrendszer. Nagyon gyakran az 1C:Enterprise 8 teljesítményével kapcsolatos kérdések a lemez alrendszer elégtelen teljesítményével kapcsolatosak. És itt van elég sok lehetőségünk arra, hogy a berendezést a feladatra optimalizáljuk. Ezért maximális figyelmet fordítunk a lemezalrendszer-számlálók elemzésére.

« % Szabad hely' a logikai meghajtón lévő szabad terület százalékos aránya. Ha a lemezkapacitás kevesebb, mint 15%-a szabad, akkor az túlterheltnek minősül, és a további elemzése nagy valószínűséggel nem lesz teljesen korrekt - erősen befolyásolja a lemezen lévő adatok töredezettsége. Az ajánlott szabad terület mennyisége a szerver lemezén legalább 20%, lehetőleg több SSD esetén.
« augusztus Disk sec/Transfer» az átlagos lemezelérési idő. A számláló az egy lemezes kommunikációs művelethez szükséges átlagos időt mutatja ezredmásodpercben. Kissé terhelt rendszerek esetén (például fájltárolók, virtuális gépek tárolói) célszerű 25-30 ms-on belül tartani az értékét. Erősen terhelt szervereknél (SQL) – kívánatos, hogy ne haladja meg a 10 ms-ot. A nagy számlálóértékek azt jelzik, hogy a lemez alrendszer túlterhelt. Ez egy szerves mutató, amely részletesebb elemzést igényel. Milyen műveleteket, olvasást vagy írást, és milyen arányban mutatnak a számlálók augusztus Disk sec/Read(átlagos lemezolvasási idő másodpercben) és augusztus Disk sec/Write(átlagos lemezelérési idő írásonként).
Integrált jelző Átl. A Disk sec/Transfer a RAID5/RAID6-ban az olvasási műveletek jelentős túlsúlyával a normál tartományon belül lehet, az írási műveletek pedig jelentős késéssel fognak megtörténni.
3.augusztus Lemezsor hossza(átlagos lemezsorhossz) valójában egy integrált jelző, és abból áll augusztus Lemezolvasási sor hossza(a lemezre olvasási sor átlagos hossza) és augusztus Lemez írási sor hossza(a lemez írási sorának átlagos hossza). Megmutatja, hogy átlagosan hány I/O művelet várható, amikor a merevlemez elérhetővé válik. Ez nem mérhető mutató, hanem a Little-törvény szerint a sorelméletből számolva N = A * Sr, ahol N a függőben lévő kérések száma a rendszerben, A a kérések aránya, Sr a válaszidő. Normálisan működő lemezalrendszer esetén ez a jelző nem haladhatja meg a RAID-csoportban lévő lemezek számát 1-nél többel. Az SQL Server osztályú alkalmazásokban kívánatos az átlagértéket 0,2-nél kisebb szinten tartani.
4.Jelenlegi lemezsor hossza(aktuális lemezsor hossza) mutatja a kiválasztott lemezhez címzett függőben lévő és függőben lévő kérések számát. Ez az aktuális érték, egy pillanatnyi mutató, nem pedig egy időszak átlagértéke. A lemezalrendszerhez intézett kérések feldolgozásának késleltetési ideje arányos a sor hosszával. Az állandósult állapotú kényelmes működés érdekében a függőben lévő kérések száma legfeljebb 1,5-2-szeresével haladhatja meg a tömbben lévő fizikai lemezek számát (feltételezzük, hogy egy több lemezből álló tömbben minden lemez egyidejűleg kiválaszthat egy kérést a tömbből sor).
5.Lemezátvitel/mp(lemezelérések/mp) – Az egy másodpercen belül teljesített egyedi lemez I/O kérések száma. Megmutatja az alkalmazások valós igényeit a lemezalrendszer véletlenszerű olvasásához és írásához. Több egyedi számlálót összegző mutatóként lehetővé teszi az általános helyzet gyors felmérését.
6.Lemezolvasás/mp- A másodpercenkénti olvasási hozzáférések száma, azaz a lemezolvasási műveletek gyakorisága. Az SQL Server osztályú alkalmazások legfontosabb paramétere, amely meghatározza a lemez alrendszer tényleges teljesítményét.
Normál, bevezetett módban a hozzáférések intenzitása nem haladhatja meg a lemezek fizikai képességeit - az egyéni korlátokat, megszorozva a tömbben lévő lemezek számával.

100-120 IOPS SATA vagy NL SAS meghajtónként;

200-240 IOPS SAS 15000 rpm lemezenként;

65 000 IOPS Intel SSD osztályú s3500 sorozatonként (SATA);

7.Lemezírás/mp- a másodpercenkénti írási hozzáférések száma, vagyis a lemezre írási műveletek gyakorisága. Rendkívül fontos paraméter az SQL Server osztályú alkalmazásokhoz. Normál üzemmódban a hozzáférési sebesség nem haladhatja meg a lemezek fizikai korlátait, szorozva a tömbben lévő lemezek számával, és figyelembe véve a kiválasztott RAID-típus írási büntetését.

80-100 IOPS SATA vagy NL SAS meghajtónként;

180-220 IOPS SAS lemezenként;

2 .20 GHz

DDR4
1600/1866/2133

3 .50 GHz

DDR4 1600/1866/2133/2400

1. táblázat – A RAM-mal való munka paraméterei

RAM . A teljes kiszolgáló teljesítményét befolyásolja a telepített memória típusa. Például az LR DIMM, az architektúrája miatt, mindig nagyobb késleltetéssel rendelkezik, mint a hagyományos DDR4 RDIMM memória. Különösen a viszonylag rövid lekérdezéseknél, jellemző az SQL-re, amikor az 1C-vel dolgozik. A nagyobb késleltetés és a lényegesen magasabb ár alapján csak akkor van értelme LR DIMM-et telepíteni, ha az RDIMM-ek segítségével nem lehet a szükséges mennyiségű RAM-ot megszerezni.
Hasonlóképpen, a DDR4 2400 valamivel gyorsabban fog futni, mint a DDR4 2133 - ha a CPU támogatja a magas frekvenciákat.

hálózati felület. Itt tanácsos betartani az egyszerű szabályokat:
a) A szervernek legalább három 1Gb Ethernet vagy magasabb (10Gb, 40Gb) hálózati interfésszel kell rendelkeznie, és ezek közül legalább kettő szerver hálózati chipen. Természetesen a ceteris paribus előnyben részesítendő a 10 Gb Ethernet infrastruktúra, főleg a berendezések árának eltűnőben lévő kis különbsége miatt (10 Gb hálózati kártyák és 10 Gb portok 1 GB / 10 Gb switcheken).
b) A szervernek támogatnia kell egyik vagy másik KVM-over-IP technológiát a távoli felügyelethez.
A finomságok közül kiemelhető a virtualizációs eszközök nagyon jó támogatása az összes Intel szerver hálózati chip által, valamint a terhelés hatékony elosztása a CPU magok között 10 Gb+-ig.

Lemez alrendszer :

A lemez alrendszer két összetevőből áll:
- bemeneti/kimeneti alrendszer SAS HBA vezérlők és RAID vezérlők formájában;
- tárolóeszközök, vagy esetünkben - SSD és HDD lemezek.

RAJTAÜTÉS.
Az operációs rendszer és az adatbázis-tárolási feladatokhoz általában a RAID 1 vagy RAID 10, valamint ezek különféle szoftveres megfelelői kerülnek felhasználásra.

1. A Windows Server segítségével teljesen szoftveres RAID (Soft RAID) rendszerindító meghajtónak nem használható, de DB, tempDB és SQL log tárolására igen alkalmas. A Windows Storage Spaces technológia meglehetősen magas teljesítményt nyújt a tárolási megbízhatóság és a teljesítmény tekintetében, és számos további funkciót is kínál, amelyek közül a legérdekesebb az 1C feladatokkal összhangban a „Tiered storage”. A technológia előnye, hogy a leggyakrabban kért adatok egy részét a rendszer automatikusan az SSD-re helyezi.
Ami az 1C feladatokat illeti, általában vagy All-Flash SSD-tömböt használnak, vagy nagyon nagy (1 TB és nagyobb) és több éves adatbázisokhoz – többszintű tárhelyet.
A Windows Storage Spaces technológia egyik előnye, hogy képes RAID-t létrehozni NVMe meghajtókon.

2. Az operációs rendszer hosztolásához a hardver-szoftver RAID1 hatékony, amely az Intel és az Intel® Rapid Storage Technology lapkakészletére épül ( IntelRST).
Ebben a hardver szintű bemeneti-kimeneti műveleteket az alaplapi lapkakészlet végzi, gyakorlatilag CPU erőforrások használata nélkül. A tömb pedig a Windows alatti illesztőprogramok miatt szoftverszinten kezelhető.
Mint minden kompromisszumos megoldásnak, az Intel RST-nek is vannak hátrányai.
a) Az Intel RST működése az operációs rendszerbe betöltött illesztőprogramoktól függ. Ez magában hordozza annak kockázatát, hogy az illesztőprogramok vagy az operációs rendszer frissítésekor olyan helyzet állhat elő, hogy a RAID-lemez nem lesz elérhető. Rendkívül valószínűtlen, mert Az Intel és a Microsoft nagyon barátságosak, és nagyon jól tesztelik a szoftvereiket, de ez nem kizárt.
b) A kísérletek eredményei alapján közvetett bizonyítékok arra utalnak, hogy az Intel RST illesztőprogram-modell RAM erőforrásokat használ az írási gyorsítótárazáshoz. Ez növeli a teljesítményt, de magában hordozza az adatvesztés kockázatát is, ha a kiszolgáló teljesítménye nem tervezett.
Ennek a megoldásnak is vannak előnyei.
Az egyik mindig a nagyon nagy teljesítmény, amely egyenrangú, sőt néha jobb is, mint a teljes hardveres RAID-vezérlők.
A második a hardveres-szoftveres RAID1 támogatása NVMe meghajtókhoz (az írás idején nem a rendszerindító meghajtókhoz). És itt van egy érdekes szolgáltatás azok számára, akik nagy terhelésű lemezalrendszereket használnak. Ellentétben a Windows Storage Spaces szolgáltatással, amely az I/O által elfoglalt magot csaknem 100%-ra "terheli", az Intel RST, amikor a magterhelés eléri a hozzávetőlegesen 70%-ot, a következő magot kapcsolja az I/O folyamathoz. Ennek eredményeként egyenletesebb a CPU magok terhelése és valamivel jobb teljesítmény nagy terhelésnél.

4. ábra – CPU kihasználtság A Windows tárolóterületei vs. Intel RST

3. Egy teljesen hardveres RAID egy 2-6 SSD-vel rendelkező szerverben a RAID 1-ben elérhető SAS HBA-val egy LSI SAS 3008 lapkakészleten, például egy Intel® RAID Controller RS3WC080-on. Ehhez egy speciális „IR” firmware-t kell telepíteni a SAS HBA-ba. Ezenkívül ez a SAS HBA támogatja a SAS 3.0 szabványt (12 Gb / s), körülbelül 300 dolláros áron. Kiváló választás itt az Intel® RAID Controller RS3WC080, amely a szükséges firmware-rel érkezik.
Ennek a megoldásnak az a lényege, hogy a szerver SSD-knek nincs szükségük írási gyorsítótárra. Ezenkívül a fejlettebb RAID-vezérlők letiltják a beépített írási gyorsítótárukat is, amikor SSD-vel dolgoznak. Így a HBA, amely nem rendelkezik SAS gyorsítótárral RAID vezérlő módban, meglehetősen sikeresen megbirkózik a nagy sebességű írási és olvasási feladatokkal közvetlenül az SSD-ről, és meglehetősen tisztességes teljesítményt nyújt.

4. Nagy terhelésű, nagyszámú SAS vagy SATA SSD meghajtóval rendelkező szerverek esetén kívánatos egy teljes értékű Intel® RAID Controller RS3MC044 vagy Adaptec RAID 8805 osztályú RAID vezérlő telepítése. Hatékonyabb I / O processzorokkal és fejlett algoritmusokkal rendelkeznek a HDD és SSD lemezekkel való munkavégzéshez, beleértve azokat is, amelyek lehetővé teszik a tömb összeállításának felgyorsítását a meghibásodott lemez cseréje után.

Tárolóeszközök (SSD-k)és HDD).
a) Megbízhatóság SSD és HDD .
Általában a lemezek elméleti megbízhatóságát a "Nem helyrehozható olvasási hibák olvasott bitenkénti száma" paraméterrel értékelik, amely úgy fordítható le, hogy "A helyreállíthatatlan olvasási hiba valószínűsége az olvasott bitek száma szerint". Megmutatja, hogy mennyi adatot olvasnak ki a lemezről, a statisztikák szerint helyrehozhatatlan hibára kell számítani.
Egy másik fontos paraméter a lemez meghibásodásának valószínűségét mutatja - AFR (éves hibaarány) vagy "Éves hibaarány".
Az alábbi táblázat a tipikus SATA Enterprise HDD 7200 prm (SATA Raid Edition), SAS HDD Enterprise 15 000 prm, SATA SSD Enterprise meghajtók adatait tartalmazza.

Paraméter	Lemez típusa
Paraméter	Vállalati SATA\SAS NL 7200 prm	Enterprise SAS 15 000 ppm (10 000 ppm)	Vállalati SATA SSD
Nem helyrehozható olvasási hibák olvasási bitenként
Olyan kötet, amely statisztikailag várhatóan helyrehozhatatlan hibát okoz olvasáskor

Tab. 2 - a HDD és az SSD elméleti megbízhatósága

Az Intel® SSD DC S3510 sorozat osztályába tartozó Enterprise SATA SSD 10-szer alacsonyabb, mint a SAS Enterprise 15 000 prm HDD és 100-szor alacsonyabb, mint a SATA Enterprise HDD 7200 prm. Így az Enterprise-osztályú SSD-k elméletileg és megbízhatóbbak, mint bármely HDD.

b) Ezután becsüljük meg teljesítmény SSD és HDD .
Az adatbázis szempontjából, amely valójában 1C, a legfontosabb csak három lemezparaméter:
- a késleltetést (Latency) vagy a lemez válaszidejét mikroszekundumban mérik (a kevesebb jobb);
- a másodpercenkénti olvasási műveletek száma (Disk Reads / sec), IOPS-ben mérve (a több jobb);
- írási műveletek száma másodpercenként (Disk Writes/sec), IOPS-ben mérve.
Foglaljuk össze ezt a három paramétert egy táblázatban:

Paraméter	Lemez típusa
Paraméter	Vállalati SATA / SAS NL 7200 prm	Enterprise SAS 15 000 ppm (10 000 ppm)	Vállalati SATA SSD	Vállalati NVMe SSD
Késési idő (lemez olvasási/írási válaszidő), mikroszekundum
Lemezolvasás/mp (olvasási műveletek száma másodpercenként), IOPS
Lemezírás/sec (írási műveletek száma másodpercenként), IOPS

Tab. 3 - HDD és SSD teljesítmény.

Amint a táblázatból jól látható, NVMe SSD (például Intel® SSD DC P3600 Series) késleltetés Felülmúlja az Enterprise SAS HDD-t 100 alkalommal, és által I/O műveletek száma másodpercenként - in 200 alkalommal felvételhez és 1500 alkalommal olvasáshoz.
Ésszerű a HDD technológia használata adatbázisok tárolására?

v) Napi mennyiség felülírása a szerver számára SSD .
A formában lévő "zsemlék" mellett szuperkondenzátorÁramkimaradás és hardveres titkosítási modulok esetén a szerver SSD-knél van a legfontosabb paraméter - az SSD lemez teljes kapacitásából a napi újraírás becsült mennyisége. Ha Intel szerver SSD-kről beszélünk, akkor ennek a kötetnek a napi újraírását értjük 5 éven keresztül, ami a garancia részét képezi. Ez az opció lehetővé teszi az SSD-k "elsősorban olvasási", "írási-olvasási orientált" és "nehéz írásorientált" kategóriákba rendezését. Táblázatos formában így néz ki:

Intel SSD meghajtó
Napi felülírás (kapacitástól)

4. lap – SSD felülírási mennyisége naponta.

Ennek megfelelően a kiszolgálón megfelelően kiválaszthatja a lemezeket kifejezetten a feladathoz.
Például az Intel SSD s3510 elegendő az operációs rendszer és az SQL napló tárolására.
DB és tempDB tároláshoz az Intel SSD s3610 vagy az Intel SSD s3710 alkalmasabb.

Példák lemezes alrendszerek tervezésére.
A fentiekkel felvértezve állítsunk össze több lemezalrendszert a különféle követelményeknek megfelelően.
a) Szerver 45 felhasználó számára, DB - 15 GB, évi növekedés - 4 GB, tempDB - 0,5 GB, SQL log - 2 GB.
Itt gazdaságilag indokolt két Intel SSD s3510 240 GB-os lemez RAID1 telepítése operációs rendszer és SQL Log igényekhez, valamint két Intel SSD s3510 120 GB-os lemez RAID1 telepítése DB és tempDB igényekhez. Egy beépített Intel® RAPID alkalmas RAID-vezérlőként.
b) Szerver 100 felhasználó számára, DB - 55 GB, évi növekedés - 15 GB, tempDB - 4 GB, SQL log - 8 GB.
Egy ilyen szerverhez két Intel SSD s3510 240 GB-os lemezből álló RAID1-et kínálhat operációs rendszer és SQL Log igényekhez, és két Intel SSD s3610 200 GB-os lemez RAID1-ét DB és tempDB igényekhez. RAID vezérlőként az Intel® RAID Controller RS3WC080 (egyszerű hardver, gyorsítótár nélkül) az optimális.
c) Szerver 200 felhasználó számára, DB - 360 GB, évi növekedés - 70 GB, tempDB - 24 GB, SQL napló - 17 GB.
Ez a szerver már nagyon elfoglalt. Az operációs rendszerhez továbbra is két Intel SSD s3510 240 GB-os lemezből RAID1-et használunk. Az SQL Log és a tempDB két Intel SSD s3510 120 GB-os meghajtóból álló dedikált RAID1-en tárolható. A DB-táblákhoz pedig gyűjtse össze a RAID10-et négy Intel SSD s3610 400 GB-os lemezről. RAID-vezérlőként célszerű a "fejlett" Intel® RAID-vezérlő RS3MC044 használata.

Virtualizáció
A modern szerverek teljesítménye gyakran lehetővé teszi, hogy egy fizikai - több virtuális szerveren helyezkedjen el. Az optimális elhelyezésük érdekében célszerű szem előtt tartani, hogy a virtualizáció hogyan hat az egyes szerverkomponensekre.
A CPU és a RAM azok a területek, amelyek a legkevesebb teljesítményveszteséget szenvedik el virtuális környezetben. Ennek megfelelően a főként ezeket használó szoftverkomponensek fájdalommentesen elhelyezhetők a Virtuális Gépben (VM). Ezek közé tartozik az 1C:Enterprise 8. Application Server x64, a Remote Desktop szolgáltatás és az IIS.
Az I / O alrendszerek észrevehetően nagyobb veszteségeket szenvednek el a virtualizáció során: 5-15% - a hálózati interfész és legfeljebb 25% - a lemez alrendszer. Van egy SQL Serve szoftverkomponensünk, amely érzékeny a lemez alrendszer teljesítményére - teljesen logikus, hogy nem a "VM-ben", hanem a fizikai "hardverben" helyezzük el.
Általában ezt külön szerverekkel vagy szervercsoportokkal teszik meg 1C alatt:
- A Windows és az MS SQL Server operációs rendszer telepítve van a hardveren;
- 1C:Enterprise 8. Az alkalmazáskiszolgáló x64 elindul a virtuális gépen és a licenckiszolgáló ugyanazon a virtuális gépen;
- egy külön VM-szolgáltatásban, Távoli asztalon vagy IIS-ben.
Ha több szoftverkomponenst használ egy szerveren, pl. különböző virtuális gépeken további helyet kell biztosítani a lemez alrendszer szintjén történő elhelyezésükhöz. Általában ezek az operációs rendszerrel rendelkező rendszerlemezek - 480 GB-ra vagy annál nagyobbra nőnek.

biztonsági mentés
Meglehetősen elterjedt gyakorlat, hogy két nagy kapacitású merevlemezt (4-8 TB) telepítenek a RAID1-be egy szerverre az adatbázisok helyi másolatainak tárolására, valamint fájltárolásra. Egy ilyen tárolónak nincsenek magas követelményei a véletlenszerű hozzáférés sebességére vonatkozóan. Az olvasás és az írás lineáris sebessége pedig teljesen elegendő a napi biztonsági mentések és a felhasználói fájlok mentéséhez. Egy ilyen kötetet a RAID-vezérlő bármely elérhető verzióján összeszerelhet, és az Intel® RAPID-on továbbra is elég gyorsan működik.

És kérem, ne felejtse el, hogy a felelős feladatokhoz külön szerverrel kell rendelkeznie túltápláltság .

Hosszú évek óta folynak viták a fórumokon arról, hogy mi gyorsíthatja fel az 1C fájl munkáját.

Természetesen sok recept létezik, köztük néhány, amit a tanfolyamon megosztok.

De bárki bármit mond, az 1C fájl esetében az 1-es számú szűk keresztmetszet természetesen a lemez alrendszere!

Valójában "Fájl".

A többszörös lemezelérés valóban "lelassíthatja" az összes munkát az 1C Enterprise-ban.

És ha többfelhasználós hozzáférésről beszélünk, akkor ez itt nyilvánvaló.

Hogyan lehet ezt a problémát megoldani?

Természetesen gyorsabb HDD-kre, SAS-meghajtókra, RAID-re, SSD-kre váltva, vagy akár úgy, hogy az „extrém keresők” RAM-lemezre, vagyis egy PC vagy szerver RAM-jába helyezik az adatbázist.

Valójában ebben a cikkben az összes módszert érintjük, de természetesen különös figyelmet fordítunk az utolsóra.

Mivel a hálózaton nincsenek megfelelő cikkek, amelyek feltárhatnák az 1C és a RAM lemezek használatának sok árnyalatát, valamint az összes többi lemezalrendszer intelligens tesztjeit, figyelembe véve az 1C-ben végzett mindennapi munkát.

De sok kérdés van itt:

Ki használhatja és mikor?

Milyen helyzetekben?

Megbízhatóság?

Alkalmazási terület?

Valódi sebességtesztek különféle műveletekben 1C-n?

Kezdjük talán a közönséges HDD-kkel.

Természetesen a probléma lényege a HDD mechanikájában rejlik, ami nem biztosítja a szükséges sebességet az 1C-ben történő fájlmunkához (főleg a többfelhasználós hozzáféréshez).

A HDD felgyorsításának egyetlen módja, ha az 5400-as fordulatszámú HDD-t 7200-as fordulatszámúra cserélik.

Igen, a fordulatszám számít, és a 7200 ford./perc minden bizonnyal gyorsabb, mint az 5400.

Ez az, ha érezni akarjuk a különbséget. (De érdemes megjegyezni, hogy manapság gyakorlatilag az összes HDD 7200 sebességgel működik.)

A 7200 ford./perc fordulatszámú hajtások megközelítőleg ugyanazt az eredményt mutatják.

És legyen az SATA 2 vagy SATA 3.

A SATA (eng. Serial ATA) egy soros adatcsere interfész információtároló eszközökkel.

Ha a SATA III interfészt hajszolja (For HDD), akkor itt nem lesz kézzelfogható sebesség, csak nagyon kicsi a szám. (később teszteljük a HDD sebességét csak SATA II és SATA III támogatással).

Mellesleg, a " CrystalDiskInfo " programmal megtudhatja, hogy a lemeze jelenleg melyik interfészen működik (és melyik interfészt támogatja).

SATA/300MB/s - SATA 2

SATA/600MB/s - SATA 3

—| SATA/300 (lásd az 1. ábrát) - az első a lemez aktuális működési módja, a második a SATA/300 a támogatott üzemmód. (Néha az első nem jelenik meg, régebbi lemezeken).

A második ábrán azt látjuk, hogy mind a munka, mind a HDD-támogatással rendelkezik SATA 3, azaz 600 MB / s. - az interfész áteresztőképessége.

(Az interfészek kérdésére később még visszatérünk).

A másik dolog az, ha a közönséges HDD-ket RAID - 0-ba (Stripe) helyezzük.

Két vagy négy lemezzel a RAID 0 érezhetően növeli az adatátviteli sebességet, de egyáltalán nem nyújt megbízhatóságot. Bármilyen olcsó és akár szoftveres RAID vezérlő alkalmas a felépítésére. Alkalmas azok számára, akiknek minimális költséggel ki kell szorítaniuk a maximális teljesítményt a hagyományos HDD-k fájlrendszeréből.

A sebesség még néhány régi SSD-vel is összehasonlítható, de sajnos itt a sebességért a megbízhatósággal fizetünk. Ha legalább az egyik lemez meghibásodik, akkor mindkét lemezen minden információ elvész!

Tehát az 1C adatbázisok ilyen RAID-del történő gyakori biztonsági mentése szükséges.

Milyen sebesség miatt?

A RAID - 0 adatai egyenletesen oszlanak el a tömb lemezei között, a lemezek egybe vannak egyesítve, amely több részre osztható. Az elosztott olvasási és írási műveletek lehetővé teszik a munka sebességének jelentős növelését, mivel több lemez egyidejűleg olvassa/írja az adatok részét.

Más szóval, a RAID 0 egyszerűen ügyesen megkerüli a mechanikát ennek a sebességnek köszönhetően.

Ez a RAID-10

De a rendszer megszervezéséhez szükséges lemezek minimális száma 4.

Természetesen ebben a cikkben egy egyszerű 1C fájlról beszélünk, ezért csak olyan kisvállalatok költségvetési megoldásait elemezzük, ahol egyáltalán nem állnak rendelkezésre belépő szintű szerverek.

Ugyanezen okból a gyorsabb és drágább SAS-meghajtók, az iSCSI-protokollok nem kerülnek elemzésre.

Csak az SSD meghajtók gyorsabbak, mint a szerver SAS.

Néhány évvel ezelőtt nem tanácsoltam "szilárdtest" vásárlást az 1C-ben végzett munkához.

Ez a vélemény azonban megváltozott a mai megbízható és viszonylag olcsó SSD-meghajtók nyomán.

Például a SAMSUNG ma 10 év garanciát ad egyes lemezeire!

Intel, SanDisk, Corsair és mások 5 év garancia az SSD-re!

Az SSD-k sokkal megbízhatóbban, gyorsabban kezdtek működni, a vezérlők pedig észrevehetően intelligensebbek lettek, ezért ezek a garanciák.

Az árakról

Természetesen az INTEL vállalati szintű SSD-meghajtói egy fillérünkbe kerülnek.

De vannak jó költségvetési alternatívák is.

Például "szilárdtest" a SanDisk X400 256 GB-tól csak 95 dollárba kerül nekünk!

Tulajdonképpen 1C-ben is teszteljük, a cikk következő részében.

A SanDisk X400 meghajtó jó, megbízható (5 év garancia), gyors (olvasás/írás akár 540/520 MB/s).

És mivel sebességről beszélünk, itt figyelembe kell venni egy olyan pillanatot, mint a SATA 3.

A SATA III (verzió 3.x) interfész, hivatalos nevén SATA 6 Gb/s, a 6,0 Gb/s sebességgel futó SATA interfészek harmadik generációja. Az interfész által támogatott sávszélesség 600 MB/s. Ez az interfész visszafelé kompatibilis a SATA II -3Gb/s interfésszel.

A SATA II sávszélessége mindössze 300 MB/s, ami egy HDD-hez bőven elég, de a mai SSD-khez abszolút nem.

Az SSD-ben rejlő lehetőségek kiaknázásához legalább 600 MB/s sávszélességű interfészre van szüksége, azaz SATA III-ra.

De ne aggódjon, ha 2010 után vásárolt számítógépet vagy szervert, akkor nagy valószínűséggel van raktáron. (Egyébként alaplapot kell cserélni).

Egyébként szeretném felhívni a figyelmet a különböző gyártók SATA III vezérlőire (ugyanazon alaplapon), például az Intel és a Marvell, ahol az előbbi jelentősen nyerhet a sebesség terén. (Valójában a minap magam is meggyőződtem erről. Az Intel akár 35%-kal is gyorsabbnak bizonyult).

Természetesen nem a SATA III az egyetlen interfész az SSD-meghajtóval való kommunikációhoz.

A "szilárdtest" fejlesztői a SATA III - 600 MB / s - áteresztőképességére hagyatkoztak, és új eszközöket dobtak piacra SATA Express, M.2, mSATA, PCI Express csatlakozási felületekkel.

Már teljesen eltérő sebességek léteznek:

PCI Express x2 2.0 8Gb/s (800MB/s)

SATA Express 10 Gb/s (1000 MB/s)

PCI Express x4 2.0 16 Gb/s (1600 MB/s)

PCI Express x4 3.0 32Gb/s (3200MB/s)

Sajnos manapság ezek az eszközök sok pénzbe kerülnek, és nehéz költségvetésnek nevezni egy ilyen megoldást.

Az SSD további felgyorsítása érdekében létrehozhat egy két meghajtóból álló RAID 0-t, amely akár megkétszerezi az SSD sebességét.

De mi lehet gyorsabb egy SSD-nél?

Természetesen RAM!

Itt a sebesség nem hasonlítható össze a HDD-vel, RAID-del vagy SSD-vel.

Vannak módok (speciális szoftver), amellyel a RAM egy részét kiveheti és lemezt hozhat létre belőle.

Most a "RAM" sokkal olcsóbb, mint 5 éve, és a "táblán" sokan már 8-16 vagy még több GB RAM-mal rendelkeznek.

Az egész trükk a szükséges méret kiosztása (az 1C alap alatt a tempó, és ha a méret engedi, akkor nyomja rá a teljes platformot erre a lemezre.).

Ezt már így is mondtam "szélső" nem nehéz megérteni, miért.

Ha hirtelen hiba lép fel a rendszerben, azonnal elveszíti az adatbázist, valamint mindent, ami ezen a lemezen lesz!

Természetesen ahhoz, hogy valóban működjön a RAM-lemezen található 1C-ben, kiszolgáló hardverre, szerver RAM-ra, szünetmentes tápegységekre és megbízható hardverre van szüksége. (alaplap, processzor stb.).

+ gyakori biztonsági mentések.

Aztán persze 1C-ben is lehet így dolgozni.

De mi van, ha nincs ilyen „vas”, minket a költségvetési megoldások érdekelnek?

Miért kell egyáltalán szétszedni az 1C munkáját egy RAM-lemezen?

Az előny a barátok!, Természetesen nem a felhasználók állandó munkájához az 1C-ben, hanem inkább a különféle rutin műveletek elvégzéséhez.

Hónapzárás, átütemezés, törlés, "alapvágás" (bármilyen más hasonló munka), ami nagyszámú dokumentumhoz, könyvtárhoz és minden máshoz kapcsolódik.

Sok ilyen művelet napokig is eltarthat! Míg a RAM-ban több órán keresztül!

Ha például a felhasználói 1C-ben dolgoznak egy webböngészőn keresztül, akkor az teljesen elhelyezhető a RAM-ban, ez jelentősen felgyorsítja a felhasználó munkáját 1C-ben a weben keresztül.

Más szóval, ideiglenesen használhatja a RAM-lemezt különféle nehéz műveletek végrehajtására 1C-ben a folyamat felgyorsítása érdekében, majd visszahelyezheti az alapot az SSD-re vagy a HDD-re.

Ez egy jó trükk, használhatod!

Az 1C fájl valódi tesztelésének megkezdéséhez a fenti lemezrendszereken szinte minden készen áll, kivéve a RAM-lemezt.

Alkossuk meg!

Az ingyenes "Dataram RAMDisk" program segítségünkre lesz

Ingyenes verziója elegendő lesz egy 4 GB-os lemez létrehozásához. (További - fizetett ~ 21 dollár).

A „Storage Professionals” LinkedIn csoport (egyébként javaslom, hogy figyeljenek oda a vitacsoportok létezésére a LinkedInen, érdekes lehet) már egy hete tárgyalja a témát:
Az SSD-meghajtók meghibásodási aránya
Néhány idézet onnan, amelyeket fordítás nélkül adok, mivel minden világos (minden bekezdés egy idézet-töredék egy-egy személy üzenetéből ebben a szálban).
Vállalkozóként dolgozom egy közép-nyugati bankban, és körülbelül 9 hónapja vannak SSD-ink az EMC VMAX-ban. Még nem láttunk kudarcot
Egyszer több hetes kísérletet folytattam, hogy kiégessem a különböző gyártók SSD-it. Körülbelül egy hónapig futtattam őket 100%-ban véletlenszerűen. Fusion IO-k körülbelül 30 000 IOP-val meghajtónként, STEC-ek / Intelek körülbelül 7 000. Soha egyiket sem sikerült elbukni.
A Fusion IO annyi írást írt abban a hónapban, amennyit egyetlen SAS-meghajtó több mint egy évtized alatt meg tudott tenni.
Körülbelül 150 SSD-meghajtónk van, és 1 meghibásodást tapasztaltunk az elmúlt 12 hónap során.
Alig 12 hónapja használok SSD-ket cx4-960 clariionban, hiba nélkül (nagy ms sql tempdb-t lefedve).
Saját tapasztalataim szerint (az SSD rendszereket 2 és fél éve szállították először), az SLC SSD meghibásodási aránya a forgó meghajtókéval azonos tartományba esik.
Ez az. Van min gondolkodni azoknak, akik még mindig azt hiszik, hogy az SSD-erőforrás írásra való rettenetesen korlátozott hogy az SSD nem megbízható, és futás közben az Enterprise Flash meghajtók úgy halnak meg, mint egy kiégett kínai USB flash meghajtó Kingston.

Az 1C fájlmódban elért teljesítményének kérdése meglehetősen akut, különösen a kis cégek számára, amelyek nem engedhetik meg maguknak a jelentős berendezésekbe történő beruházásokat. Ennek ellenére az alkalmazás "étvágya" kiadásról kiadásra csak nő, és egyre sürgetőbbé válik a mérsékelt költségvetési költségek melletti teljesítménynövelés. Ebben az esetben a jó megoldás az SSD vásárlása és elhelyezése.

Egyik ügyfelünk, egy kis könyvelő cég panaszkodni kezdett az 1C:Enterprise lassú teljesítménye miatt. Valójában az alkalmazás nem túl gyors működése meglehetősen sivár lett a Accounting 2.0-ról a Accounting 3.0-ra való átállás után.

Volt egy egyszerű terminálszerver egy Core i3 2120-on, 8 GB RAM-mal, két Western Digital RE4-ből álló RAID 1 lemeztömbbel, amely három-hat felhasználót szolgált ki, és mindegyik két-három bázissal működött egyszerre.

A teljesítményelemzés azonnal feltárt egy szűk keresztmetszetet - a lemez alrendszerét (a képernyőkép az SSD telepítése után készült, tehát a RAID tömb C: és E: logikai meghajtókat tartalmaz).

Az egyszerű számítások azt mutatták, hogy akár egy információs bázis elindítása is csaknem teljesen kihasználja a tömb teljesítményét, körülbelül 150 IOPS-t az aktuális olvasási/írási arány mellett – ez a tényleges korlát két nem a leggyorsabb lemez tükrében. Mi közvetetten jelzi a sor méretét.

A munkanap elején több adatbázis egyidejű elindítása a szerver jelentős lelassulásához és a rendszer válaszkészségének csökkenéséhez vezetett. Ezenkívül kellemetlen átgondoltság volt megfigyelhető a magazinokkal való munka során, a jelentések készítésekor stb.

A tömb teljesítménytesztje is alacsony eredményt mutatott, a mai szabványok szerint inkább hordozható meghajtókhoz.

Világossá vált, hogy a lemez alrendszert frissíteni kell. A tömeges merevlemezekre épülő produktív tömb létrehozásának az előzetes becslések szerint is korlátot szabott mind a megfizethető költségvetés, mind a hardver fizikai lehetőségei, amelyeknek egyszerűen nem volt a házában a szükséges számú SATA port és lemezrekesz. Ezért az SSD vásárlása mellett döntöttek.

Mivel nem terveztek nagy lemezterhelést, elsősorban az ár miatt esett a választás. A sebességjellemzők is háttérbe szorultak, mivel a szűk keresztmetszet a SATA-II interfész volt. Ennek eredményeként megvásárolták 128 Gb Corsair Neutron LAMD, amely a szerverre telepítve a következő sebességjellemzőket mutatta:

Mint látható, a szekvenciális hozzáférési műveletek várhatóan befutottak az interfész sávszélességébe, de esetünkben ennek másodlagos jelentősége van. A fő figyelmet a véletlen hozzáférésű műveletekre kell fordítani, amelyek nagyságrenddel felülmúlják a hagyományos HDD-két.

A következő eldöntendő kérdés, hogy tükrözzük-e az SSD-t, és feláldozzuk-e a TRIM-et a hibatűrés érdekében, vagy egyetlen meghajtóként hagyjuk, és a sebességet választjuk a hibatűrés helyett. Meg kell jegyezni, hogy a modern SSD-k a TRIM parancs mellett saját lebomlásgátló technológiájukat is használják, például a szemétgyűjtést, ami lehetővé teszi, hogy még a TRIM nélküli rendszereken is elég hatékonyan működjenek. Az ebben a sorozatban használt LAMD (Link_A_Media Devices) SSD vezérlő a vállalati szintű meghajtók szintjén is nagyon hatékony szemétgyűjtő technológiával működik, ami általában véve nem meglepő, hiszen fejlesztői a vállalati szegmensben dolgoznak már egy ideje. hosszú idő.

Mivel a napi bevitt dokumentumok mennyisége csekély, egyetlen SSD-re szorítkoztunk, kötelező napi biztonsági mentéssel. Közvetett módon a szilárdtestalapú meghajtó használatának hatása a teljesítményfigyelő segítségével értékelhető:

Jelentősen nőtt az I / O műveletek száma, valamint a lemezzel való csere sebessége, miközben a sor hossza nem haladja meg az egyet. Ezek nagyon jó mutatók, még ellenőrizni kell, hogy tevékenységeink mennyire gyorsították fel a munkát közvetlenül az 1C:Enterprise segítségével.

Ennek érdekében egy kis expressz tesztelést végeztünk, melynek során mértük az infobázis betöltésének idejét, illetve egy dokumentumkészlet csoportos újrafeladási idejét egy bizonyos ideig. A tesztelés során a konfigurációt használták 1C: Számvitel 3.0.27.7 az emelvényen 8.3.3.721 .

A teljesítményelemzés során arra is figyelmet fordítottunk, hogy az 1C:Enterprise munkája során aktívan használ ideiglenes mappákat, amelyek esetünkben a merevlemezen helyezkedtek el. Ezért a maximális teljesítmény elérése érdekében ezeket is érdemes SSD-re átvinni, azonban aki szereti spórolni a szilárdtestalapú meghajtók erőforrásával, annak mindkét lehetőséget bevontuk a tesztbe: amikor az adatbázisok az SSD-n helyezkednek el, ill. az ideiglenes mappát a merevlemezen, és amikor az alkalmazást teljesen felhasználta az SSD.

Mint látható, az infobázisok SSD-re átvitele azonnal több mint felére csökkentette a betöltési idejüket, és az átvitel körülbelül 30%-kal gyorsult fel. Ugyanakkor a közös munka során a termelékenység csökkenésével kapcsolatos probléma teljesen megszűnt.

Az ideiglenes mappák SSD-re átvitele lehetővé teszi a betöltési idő több mint harmadával történő csökkentését és a dokumentumok sebességének körülbelül a kétszeresét. Még a lemez-erőforrások megtakarításának elkötelezett híveinek is van min gondolkodniuk. Véleményünk erről a kérdésről a következő: ha SSD-t vásárolt, akkor azt maximálisan ki kell használnia.

Tegyünk egy kis kitérőt. Az általunk használt lemez Corsair Neutron Megvan erőforrás 2-3K törlési/írási ciklusok. Az egyszerű számítások azt mutatják, hogy ha a teljes lemezkapacitást minden nap teljesen felülírják, akkor 5-8 évbe telik az erőforrás kimerítése. Ezenkívül a statisztikák azt mutatják, hogy a garanciális időszak alatti SSD meghibásodásának fő oka nem az erőforrás kimerüléséhez kapcsolódik, hanem gyártási hiba vagy a firmware hibája.

Végezetül szeretném elmondani, hogy az SSD használata ma talán az egyetlen hatékony módja annak, hogy jelentősen növelje az 1C:Enterprise teljesítményét fájl módban. És ami a legfontosabb, még a kisvállalkozások számára is megfizethető.