Fékek a fájlalapon - hogyan lehet elkerülni (a legutóbbi tapasztalatok alapján). Tippek az 1c hálózaton keresztüli lassú működéséhez

Megint lelassul az 1C?Időt vesztegetsz jelentésírás közben?Belefáradt a teázásba, miközben az adatcserére vár?

Az 1C lassú működésével kapcsolatos helyzet nem ritka. Ezt elviselheti, vagy optimalizálhatja az 1C és a berendezések beállításait, ami jelentősen megnöveli a munka sebességét.

Szolgáltatásaink segítenek Önnek abban, hogy a munkanapja során többet végezzen! Tudjuk, hogyan lehet felgyorsítani az 1C-t, hogy soha ne ismételje el a „1C lefagy” szavakat.

Miért tud lefagyni vagy lelassulni az "1C"?

A probléma a hardverben lehet. Memóriahiány a szerveren 1C-vel, instabil munka a helyi hálózaton, problémák a merevlemezzel vagy a biztonsági kulcsokkal - mindez lelassíthatja az 1C-t és idegessé teheti. Ezenkívül az 1C lefagyhat a következők miatt:

• rossz platform és konfiguráció kompatibilitás,
• kezdő 1C programozók baklövései,
• hatalmas alap,
• nagy számú felhasználó.

Még az 1C-vel végzett normál műveletek során elkövetett hibák is lassú működéshez vezethetnek.

Hogyan lehet gyorsítani az 1C-t?

Így működünk:

• Ellenőrizzük, hogy a berendezés megfelel-e az 1C technológiai követelményeknek. Talán növelnie kell a RAM-ot, konfigurálnia kell az 1C szervert, ki kell cserélnie a lemezt, vagy ellenőriznie kell a helyi hálózat sebességét. Más szóval, átfogó ellenőrzést végzünk minden, a folyamatban részt vevő berendezésen.
• Ellenőrizzük az 1C munkájában részt vevő egyéb szolgáltatások beállításait. Például a helytelenül konfigurált SQL-adatbázis vagy a megbízhatatlan terminál-hozzáférés nagymértékben lelassíthatja az 1C-t.
• Ellenőrizzük az 1C konfigurációs kód helyességét, amikor problémák vannak. Nem titok, hogy ugyanaz a szoftverprobléma többféleképpen is megoldható. A nem optimális kód gyakran az 1C lefagyását okozza.
• Ellenőrizzük a felhasználók munkasémáját, amikor az 1C-vel dolgozunk. Néha maguk a felhasználók lelassítják az 1C-t, és nincsenek tudatában ennek.

Az „1C lelassul” kifejezést bizonyára mindenki hallotta, aki az 1C:Enterprise platformon lévő termékekkel dolgozik. Valaki panaszkodott, valaki elfogadta a panaszokat. Ebben a cikkben megpróbáljuk megvizsgálni a probléma leggyakoribb okait és a megoldási lehetőségeket.

Térjünk rá a metaforára: mielőtt megtudnánk, miért nem ment el valahova az ember, érdemes megbizonyosodni arról, hogy van-e járható lába. Tehát kezdjük a hardver- és hálózati követelményekkel.

Ha a Windows 7 telepítve van:

Ha a Windows 8 vagy 10 telepítve van:

Ne feledje továbbá, hogy legalább 2 GB szabad lemezterületnek kell lennie, és a hálózati kapcsolatnak legalább 100 Mb / s sebességűnek kell lennie.

Nincs sok értelme figyelembe venni a szerverek jellemzőit a kliens-szerver verzióban, mert ebben az esetben minden a felhasználók számától és az 1C-ben megoldott feladatok sajátosságaitól függ.

A szerver konfigurációjának kiválasztásakor tartsa szem előtt a következőket:

• Az 1C szerver egy dolgozói folyamata átlagosan 4 GB-ot fogyaszt (nem tévesztendő össze a felhasználói kapcsolattal, mert egy munkafolyamatnak annyi kapcsolata lehet, amennyit a szerver beállításaiban megad);
• Az 1C és egy DBMS (különösen az MS SQL) használata ugyanazon a fizikai szerveren nyereséget ad nagy adattömbök feldolgozása során (például egy hónap lezárása, egy modell szerinti költségvetés kiszámítása stb.), de jelentősen csökkenti a teljesítményt kirakott műveletek (például megvalósítási dokumentum létrehozása és lebonyolítása stb.);
• Ne feledje, hogy az 1C szervereket és a DBMS-t 1 GB-tól „vastag” csatornán keresztül kell csatlakoztatni;
• Használjon nagy teljesítményű lemezeket, és ne kombinálja az 1C szerver és a DBMS szerepkörét más szerepekkel (például fájl, AD, tartományvezérlő stb.).

Ha a berendezés ellenőrzése után az 1C továbbra is „lelassul”

Van egy kis cégünk, 7 fő, 1C "lelassul". Szakemberekhez fordultunk, és azt mondták, hogy csak a kliens-szerver opció ment meg minket. De nekünk egy ilyen megoldás nem elfogadható, túl drága!

Rendszeres karbantartás elvégzése az adatbázisban*:

1. Indítsa el az adatbázist konfigurátor módban.

2. A főmenüben válassza ki az "Adminisztráció" elemet, és abban - "Tesztelés és javítás".

3. Állítsa be az összes jelölőnégyzetet a képen látható módon. Kattintson a Futtatás gombra.

*Ez az eljárás 15 perctől egy óráig is tarthat, az alap méretétől és a számítógép jellemzőitől függően.

Ha ez nem segít, akkor kliens-szerver kapcsolatot hozunk létre, de további hardver- és szoftverbefektetés nélkül:

1. Válassza ki az iroda legkevésbé terhelt számítógépét az álló (nem notebook) közül: legalább 4 GB RAM-mal és legalább 100 Mb/s hálózati kapcsolattal kell rendelkeznie.

2. Aktiválja rajta az IIS-t (Internet Information Server). Ezért:

3. Tegye közzé adatbázisát ezen a számítógépen. Erről a témáról elérhető anyagok az ITS-en, vagy forduljon támogatási szakemberhez.

4. Felhasználói számítógépeken konfigurálja az adatbázishoz való hozzáférést vékony kliensen keresztül. Ezért:

Nyissa meg az indítóablak 1C.

Válassza ki a munkaalapot. Ez itt a bázisod. Kattintson a Szerkesztés gombra. Állítsa a kapcsolót "A webszerveren" állásba, az alatta lévő sorban adja meg annak a szervernek a nevét vagy IP-címét, amelyen az IIS aktiválva lett, valamint azt a nevet, amelyen az adatbázist közzétették. Kattintson a "Tovább" gombra.

Állítsa a „Main Startup Mode” kapcsolót „Vékony kliens” módba. Kattintson a "Befejezés" gombra.

Elég nagy cégünk van, de nem is túl nagy, 50-60 fős, kliens-szerver opciót használunk, de az 1C rettenetesen lassú.

Ebben az esetben ajánlatos az 1C szervert és a DBMS szervert két különböző szerverre szétválasztani. A szétválasztásnál ügyeljen arra, hogy ha ugyanazon a fizikai szerveren maradtak, amelyet egyszerűen virtualizáltak, akkor ezeknek a szervereknek a lemezeinek másnak kell lenniük - fizikailag különbözőnek! Emellett ügyeljen az ütemezett feladatok beállítására a DBMS-kiszolgálón, ha MS SQL-ről van szó (erről bővebben az ITS webhelyén olvashat).

Elég nagy cégünk van, több mint 100 felhasználóval. Minden az 1C erre az opcióra vonatkozó ajánlásai szerint van beállítva, de egyes dokumentumok vezetésekor az 1C nagyon „lelassul”, és néha blokkolási hiba lép fel. Esetleg készíts egy konvolúciót az alapból?

Hasonló helyzet adódik egy nagyon specifikus felhalmozási nyilvántartás vagy könyvelés (de gyakrabban - felhalmozás) mérete miatt, amiatt, hogy a nyilvántartás vagy egyáltalán nincs „lezárva”, azaz. vannak bevételi mozgások, de nincs kiadásmozgás, vagy nagyon nagy azoknak a méréseknek a száma, amelyekkel a regiszter egyenlegeit számítják. Még az is előfordulhat, hogy a két előző ok keveredik. Hogyan állapítható meg, hogy melyik regiszter ront el mindent?

Rögzítjük a dokumentumok lassú feldolgozási idejét, illetve azt az időpontot és a felhasználót, akinek blokkolási hibája van.

Nyissa meg a regisztrációs naplót.

A „Data.Conduct” eseménytípussal megtaláljuk a szükséges dokumentumot a megfelelő időben, a megfelelő felhasználó számára.

A teljes tranzakcióblokkot a tranzakció törléséig nézzük, ha letiltási hiba történt, vagy a leghosszabb változást keressük (az előző rekordhoz képest több mint egy perc).

Ezt követően hozunk döntést, szem előtt tartva, hogy ezt a regisztert mindenképpen olcsóbb összecsukni, mint a teljes adatbázist.

Nagyon nagy cég vagyunk, több mint 1000 felhasználó, naponta több ezer dokumentum, saját informatikai részlegünk, hatalmas szerverpark, többször optimalizáltuk a kéréseket, de az 1C lelassul. Úgy tűnik, kinőttük az 1C-t, és valami erősebbre van szükségünk.

Az ilyen esetek túlnyomó többségében nem az 1C „lassul le”, hanem az alkalmazott megoldás architektúrája. Amikor egy új üzleti program mellett dönt, ne feledje, hogy olcsóbb és egyszerűbb az üzleti folyamatait egy programba írni, mint egyesekhez, különösen egy nagyon drága programhoz átdolgozni. Csak az 1C biztosít ilyen lehetőséget. Ezért jobb, ha felteszed magadnak a kérdést: „Hogyan lehet megoldani a helyzetet? Hogyan lehet az 1C-t "repülni" ilyen köteteken? Nézzünk meg néhány kezelési lehetőséget:

• Használja az 1C által támogatott párhuzamos és aszinkron programozás technológiáit (háttérfeladatok és kérések egy hurokban).
• A megoldás architektúrájának kialakításakor a legszűkebb helyeken tagadja meg a felhalmozási nyilvántartások és könyvelési nyilvántartások használatát.
• Adatstruktúra (felhalmozási és/vagy információs regiszterek) kialakításakor kövesse a szabályt: "A leggyorsabban írható és olvasható tábla egy oszlopos táblázat." Hogy mi forog kockán, az világossá válik, ha egy tipikus RAUS-mechanizmust nézünk.
• Nagy mennyiségű adat feldolgozásához használjon segédfürtöket, ahol ugyanaz az adatbázis csatlakozik (de ezt semmi esetre sem szabad interaktív munkavégzés közben megtenni!!!). Ez megkerüli a szabványos 1C zárakat, ami lehetővé teszi az adatbázissal való munkavégzést majdnem ugyanolyan sebességgel, mint amikor közvetlenül SQL eszközökkel dolgozik.

Érdemes megjegyezni, hogy az 1C optimalizálása holdingok és nagyvállalatok számára egy külön, nagy cikk témája, ezért figyelje a weboldalunkon található anyagok frissítéseit.

Az utóbbi időben a felhasználók és a rendszergazdák egyre gyakrabban panaszkodnak, hogy a felügyelt alkalmazás alapján kifejlesztett új 1C konfigurációk lassúak, esetenként elfogadhatatlanul lassúak. Nyilvánvaló, hogy az új konfigurációk új funkciókat és képességeket tartalmaznak, ezért erőforrásigényesebbek, de a legtöbb felhasználó nem érti, hogy mi befolyásolja elsősorban az 1C működését fájlmódban. Próbáljuk meg kijavítani ezt a hiányt.

A miénkben már érintettük a lemezes alrendszer teljesítményének az 1C sebességére gyakorolt ​​hatását, azonban ez a tanulmány az alkalmazás külön PC-n vagy terminálszerveren történő helyi használatára vonatkozott. Ugyanakkor a legtöbb kis implementáció egy fájlbázissal, hálózaton keresztüli munkavégzéssel jár, ahol a felhasználó egyik PC-jét szerverként használják, vagy dedikált fájlszerverrel, amely normál, legtöbbször szintén olcsó számítógépre épül.

Az 1C orosz nyelvű erőforrásainak egy kis tanulmánya azt mutatta, hogy ezt a problémát szorgalmasan megkerülik; problémák esetén általában azt tanácsolják, hogy váltsanak kliens-szerver vagy terminál módra. És az is szinte általánosan elfogadottá vált, hogy a felügyelt alkalmazások konfigurációi sokkal lassabban működnek, mint a szokásosak. Az érvek általában "vasat" kapnak: "itt a Accounting 2.0 csak repült, és a" trojka "alig mozdul, persze van némi igazság ezekben a szavakban, úgyhogy próbáljuk meg kitalálni.

Erőforrás-felhasználás egy pillantással

A tanulmány megkezdése előtt két célt tűztünk ki magunk elé: kideríteni, hogy a felügyelt alkalmazás-alapú konfigurációk valóban lassabbak-e, mint a hagyományos konfigurációk, és mely erőforrások hatnak a legnagyobb mértékben a teljesítményre.

A teszteléshez két Windows Server 2012 R2-t, illetve Windows 8.1-et futtató virtuális gépet vettünk, amelyekben a gazda Core i5-4670 2 magja és 2 GB RAM-ja van, ami egy átlagos irodai gépnek felel meg. A szervert egy kettős RAID 0 tömbre, a klienst pedig egy hasonló általános célú lemeztömbre helyezték.

Kísérleti alapként az Accounting 2.0 kiadás számos konfigurációját választottuk 2.0.64.12 , amely aztán frissítve lett 3.0.38.52 , minden konfiguráció a platformon futott 8.3.5.1443 .

Az első dolog, ami felkelti a figyelmet, a trojka információs bázisának megnövekedett mérete, és jelentősen megnőtt, valamint sokkal nagyobb étvágy a RAM iránt:

Már készen állunk arra, hogy halljuk a megszokottat: "mit tettek hozzá ehhez a trióhoz", de ne kapkodjunk. Ellentétben a kliens-szerver verziók felhasználóival, amelyek többé-kevésbé képzett rendszergazdát igényelnek, a fájlverziók felhasználói ritkán gondolnak az adatbázis-karbantartásra. Az ezeket a bázisokat kiszolgáló (olvasd - frissítő) szakcégek alkalmazottai is ritkán gondolnak erre.

Mindeközben az 1C információs bázis egy teljes értékű saját formátumú DBMS, amely szintén karbantartást igényel, és ehhez még egy olyan eszköz is van, Az infobázis tesztelése és javítása. Talán a név kegyetlen viccet játszott, ami azt sugallja, hogy ez egy hibaelhárítási eszköz, de a gyenge teljesítmény is probléma, és az átstrukturálás és az újraindexelés, valamint a táblatömörítés minden RDBMS-adminisztrátor számára jól ismert adatbázis-optimalizáló eszköz. Ellenőrizzük?

A kiválasztott műveletek alkalmazása után az adatbázis drámaian "fogyott", még a "kettőnél" is kevesebb lett, amit még senki sem optimalizált, és a RAM fogyasztása is kissé csökkent.

Ezt követően új osztályozók és könyvtárak betöltése, indexek létrehozása stb. az alap mérete nőni fog, általában a "három" alapjai nagyobbak, mint a "kettő" alapjai. Ez azonban nem fontosabb, ha a második verzió megelégedett 150-200 MB RAM-mal, akkor az új kiadásnak már fél gigabájt kell, és ezt az értéket kell figyelembe venni a programmal való munkához szükséges erőforrások tervezésénél. .

Háló

A hálózati sávszélesség a hálózati alkalmazások egyik legfontosabb paramétere, különösen 1C fájl módban, amely jelentős mennyiségű adatot mozgat a hálózaton keresztül. A legtöbb kisvállalkozás hálózata olcsó 100 Mbps-os berendezésekre épül, ezért a tesztelést az 1C teljesítménymutatóinak összehasonlításával kezdtük meg 100 Mbps és 1 Gbps sebességű hálózatokban.

Mi történik, ha elindítja az 1C fájlbázist a hálózaton keresztül? A kliens meglehetősen nagy mennyiségű információt tölt le az ideiglenes mappákba, különösen, ha ez az első "hideg" indítás. 100 Mbps-nál várhatóan belefutunk a sávszélességbe, és a letöltés is jelentős időt vehet igénybe, esetünkben körülbelül 40 másodpercet (a grafikonosztás ára 4 másodperc).

A második indítás gyorsabb, mivel az adatok egy része a gyorsítótárban tárolódik, és ott is marad az újraindításig. A gigabites hálózatra való áttérés jelentősen felgyorsíthatja a program betöltését, mind a "hideg", mind a "meleg", és megfigyelhető az értékek aránya. Ezért úgy döntöttünk, hogy az eredményt relatív értékben fejezzük ki, minden mérés legnagyobb értékét 100%-nak véve:

Amint az a grafikonokon is látható, az Accounting 2.0 kétszer olyan gyorsan töltődik be bármilyen hálózati sebesség mellett, a 100 Mbps-ről 1 Gbps-ra való átállás négyszeresére gyorsítja a letöltési időt. Ebben a módban nincs különbség az optimalizált és a nem optimalizált trojka adatbázisok között.

Azt is ellenőriztük, hogy a hálózat sebessége milyen hatással van a nagy igénybevételű működésre, például a csoportos újratelepítés során. Az eredményt relatív módon is kifejezzük:

Itt érdekesebb, hogy a „trojka” optimalizált bázisa egy 100 Mbit/s-os hálózatban ugyanolyan sebességgel működik, mint a „kettő”, a nem optimalizált pedig kétszer a legrosszabb eredményt mutatja. Gigabiten az arányok megmaradnak, a nem optimalizált "három" is kétszer olyan lassú, mint a "kettő", az optimalizált pedig harmadával elmarad. Ezenkívül az 1 Gb / s-ra való áttérés lehetővé teszi a végrehajtási idő háromszoros csökkentését a 2.0-s verzió és kétszeresére a 3.0-s verzió esetén.

A hálózati sebesség napi munkára gyakorolt ​​hatásának értékeléséhez a teljesítménymérés előre meghatározott műveletek sorozatának végrehajtásával az egyes adatbázisokban.

Valójában a mindennapi feladatoknál a hálózati sávszélesség nem jelent szűk keresztmetszetet, egy optimalizálatlan "három" csak 20%-kal lassabb, mint a kettő, és az optimalizálás után nagyjából ugyanennyivel gyorsabban is kiderül - a vékonykliens módban való munka előnyei befolyásolják. Az 1 Gb / s-ra való átállás nem ad előnyt az optimalizált alapnak, a nem optimalizált alap és a kettes pedig gyorsabban kezd működni, kis különbséget mutatva közöttük.

Az elvégzett tesztekből kiderül, hogy a hálózat nem jelent szűk keresztmetszetet az új konfigurációk számára, és a felügyelt alkalmazás a megszokottnál is gyorsabban működik. Javasolhatja az 1 Gb/s-ra való váltást is, ha a nehéz feladatok és az adatbázis-betöltési sebesség kritikus az Ön számára, más esetekben az új konfigurációk lehetővé teszik a hatékony munkát akár lassú 100 Mb/s-os hálózatokban is.

Akkor miért lassul le az 1C? Tovább fogunk vizsgálni.

Szerverlemez alrendszer és SSD

Az előző cikkben az 1C teljesítményének növekedését értük el az adatbázisok SSD-re helyezésével. Lehet, hogy a szerverlemez alrendszer teljesítménye nem elég? Egy lemezszerver teljesítményét csoportos futtatás során, egyszerre két adatbázisban mértük, és meglehetősen optimista eredményt kaptunk.

A másodpercenkénti bemeneti / kimeneti műveletek (IOPS) viszonylag magas száma (913) ellenére a sor hossza nem haladta meg az 1,84-et, ami egy kétlemezes tömb esetében nagyon jó eredmény. Ez alapján feltételezhetjük, hogy 8-10 hálózati kliens normál működéséhez nehéz üzemmódban elég lesz egy tükör a hagyományos lemezekről.

Tehát SSD kell a szerveren? A legjobb válasz erre a kérdésre segít a tesztelésben, amelyet hasonló módszertannal végeztünk, a hálózati kapcsolat mindenhol 1 Gb / s, az eredményt relatív értékekben is kifejezzük.

Kezdjük az adatbázis betöltési sebességével.

Lehet, hogy valakinek meglepőnek tűnik, de a szerveren lévő SSD-bázis nem befolyásolja az adatbázis letöltési sebességét. A fő korlátozó tényező itt, amint azt az előző teszt is mutatja, a hálózati átviteli sebesség és a kliens teljesítménye.

Térjünk át az újrahuzalozásra:

Fentebb már megjegyeztük, hogy a lemez teljesítménye nagy igénybevételre is elég, így az SSD sebességét sem befolyásolja, kivéve a nem optimalizált alapot, amely utolérte az SSD optimalizáltját. Valójában ez ismét megerősíti, hogy az optimalizálási műveletek rendszerezik az információkat az adatbázisban, csökkentve a véletlenszerű I/O műveletek számát és növelve a hozzáférés sebességét.

A mindennapi feladatoknál hasonló a kép:

Csak a nem optimalizált alap részesül az SSD előnyeiből. Természetesen vásárolhat SSD-t, de sokkal jobb lenne az alapok időszerű karbantartására gondolni. Ne feledkezzünk meg a szerver infobase partíciójának töredezettségmentesítéséről sem.

Klienslemez alrendszer és SSD

Elemeztük az SSD hatását a helyileg telepített 1C sebességére ben, az elmondottak nagy része a hálózati módban végzett munkára is igaz. Valójában az 1C meglehetősen aktívan használja a lemez erőforrásait, beleértve a háttérben és az ütemezett feladatokat is. Az alábbi ábrán láthatja, hogy az Accounting 3.0 a betöltés után körülbelül 40 másodpercig meglehetősen aktívan hozzáfér a lemezhez.

Ugyanakkor tudnia kell, hogy egy olyan munkaállomáshoz, ahol egy vagy két információs bázissal aktív munkát végeznek, a hagyományos, tömegsorozatú HDD teljesítményerőforrásai bőven elegendőek. Az SSD vásárlása felgyorsíthat bizonyos folyamatokat, de radikális gyorsulást nem fog észrevenni a mindennapi munkában, hiszen például a letöltést korlátozza a hálózati sávszélesség.

A lassú merevlemez lelassíthat bizonyos műveleteket, de önmagában nem képes lelassítani a programot.

RAM

Annak ellenére, hogy a RAM ma már obszcén olcsó, sok munkaállomás továbbra is a vásárláskor telepített memóriával működik. Itt várakoznak az első problémák. Abból a tényből kiindulva, hogy az átlagos "trojka" körülbelül 500 MB memóriát igényel, feltételezhetjük, hogy a teljes 1 GB-os RAM nem lesz elegendő a programmal való munkához.

A rendszermemóriát 1 GB-ra csökkentettük, és elindítottunk két információs bázist.

Első ránézésre nem is olyan rossz minden, a program mérsékelte az étvágyát és teljesen a rendelkezésre álló memórián belül maradt, de ne felejtsük el, hogy a működési adatok iránti igény nem változott, akkor hova tűntek? Lemezbe, gyorsítótárba, swapba stb. kiöblítve ennek a műveletnek az a lényege, hogy a gyors RAM-ból, aminek a mennyisége nem elegendő, az éppen nem szükséges adatok a lassú lemezre kerülnek.

Hová vezet? Nézzük meg, hogyan használják fel a rendszer erőforrásait nehéz műveleteknél, például indítsunk el egy csoportos újrafutást egyszerre két adatbázisban. Először egy 2 GB RAM-mal rendelkező rendszeren:

Mint látható, a rendszer aktívan használja a hálózatot az adatok fogadására, a processzort pedig a feldolgozására, a lemezaktivitás elenyésző, a feldolgozás során időnként megnő, de nem korlátozó tényező.

Most csökkentsük a memóriát 1 GB-ra:

A helyzet gyökeresen megváltozik, a fő terhelés most a merevlemezre esik, a processzor és a hálózat tétlenül várja, hogy a rendszer beolvassa a szükséges adatokat a lemezről a memóriába, és oda küldje a felesleges adatokat.

Ugyanakkor a két nyitott adatbázissal végzett szubjektív munka egy 1 GB memóriával rendelkező rendszeren is rendkívül kényelmetlennek bizonyult, a könyvtárak és folyóiratok jelentős késéssel és aktív lemezeléréssel nyíltak meg. Például az Áruk és szolgáltatások értékesítése magazin megnyitása körülbelül 20 másodpercet vett igénybe, és végig nagy lemezaktivitás kísérte (piros vonallal kiemelve).

Annak érdekében, hogy objektíven felmérhessük a RAM hatását a felügyelt alkalmazáson alapuló konfigurációk teljesítményére, három mérést végeztünk: az első bázis betöltési sebességét, a második bázis betöltési sebességét és az egyik bázis csoportos újraküldését. Mindkét alap teljesen azonos, és az optimalizált alap másolásával jött létre. Az eredményt relatív egységekben fejezzük ki.

Az eredmény magáért beszél, ha a betöltési idő körülbelül harmadával növekszik, ami még mindig teljesen elviselhető, akkor az adatbázisban a műveletek végrehajtásának ideje háromszorosára nő, ilyen körülmények között nem kell kényelmes munkáról beszélni. Ez egyébként akkor van így, ha az SSD vásárlása javíthat a helyzeten, de sokkal egyszerűbb (és olcsóbb) az okot kezelni, nem a következményeket, és csak a megfelelő mennyiségű RAM-ot vásárolni.

A RAM hiánya a fő oka annak, hogy az új 1C konfigurációkkal való munkavégzés kényelmetlen. A minimálisan megfelelő konfigurációkat 2 GB memóriával kell megfontolni. Ugyanakkor ne feledje, hogy esetünkben "üvegházi" feltételek jöttek létre: tiszta rendszer, csak az 1C és a feladatkezelő indult el. A való életben egy böngésző, egy irodai programcsomag, egy vírusirtó stb. általában meg van nyitva egy működő számítógépen, ezért vegye figyelembe az adatbázisonkénti 500 MB-ot és némi tartalékot, hogy nehéz műveletek során ne ütközzen hiányba. a memória és a teljesítmény drasztikus romlása.

CPU

A központi feldolgozó egységet túlzás nélkül a számítógép szívének nevezhetjük, hiszen végső soron ő dolgozza fel az összes számítást. Szerepének kiértékeléséhez egy másik tesztsorozatot is lefuttattunk, ugyanúgy, mint a RAM esetében, kettőről egyre csökkentve a virtuális gép rendelkezésére álló magok számát, míg a tesztet kétszer, 1 GB és 2 GB memóriamérettel.

Az eredmény elég érdekes és váratlan lett, egy erősebb processzor elég hatékonyan vette át a terhelést az erőforrások hiányában, egyébként anélkül, hogy kézzelfogható előnyöket nyújtott volna. Az 1C Enterprise (fájl módban) aligha nevezhető olyan alkalmazásnak, amely aktívan használja a processzor erőforrásait, meglehetősen igénytelen. Nehéz körülmények között pedig nem annyira magának az alkalmazásnak az adatainak kiszámítása, hanem a rezsi költségek kiszolgálása terheli a processzort: további I/O műveletek stb.

következtetéseket

Szóval, miért lassul le az 1C? Először is, ez a RAM hiánya, a fő terhelés ebben az esetben a merevlemezre és a processzorra esik. És ha nem ragyognak a teljesítménnyel, mint általában az irodai konfigurációkban, akkor a cikk elején leírt helyzetet kapjuk - a "kettő" jól működött, a "három" pedig szemérmetlenül lelassul.

A második helyen a hálózati teljesítmény áll, a lassú 100 Mbps-os csatorna igazi szűk keresztmetszetet jelenthet, ugyanakkor a vékonykliens mód a lassú csatornákon is elég kényelmes működési szintet képes fenntartani.

Akkor érdemes figyelni a lemezesre, az SSD vásárlása nem valószínű, hogy jó befektetés, de a lemezt korszerűbbre cserélni nem lesz felesleges. A merevlemezek generációi közötti különbség a következő anyagból becsülhető meg: .

És végül a processzor. A gyorsabb modell természetesen nem lesz felesleges, de nincs sok értelme a teljesítményét növelni, hacsak ezt a számítógépet nem használják nehéz műveletekre: kötegelt feldolgozás, súlyos jelentések, hónapzárás stb.

Reméljük, hogy ez az anyag segít gyorsan megérteni a "miért lassul le az 1C" kérdését, és a leghatékonyabban és többletköltség nélkül megoldja.

• Címkék:

A megtekintéséhez engedélyezze a JavaScriptet

Fotó: Alena Tulyakova, IA Clerk.Ru

A cikk bemutatja azokat a fő hibákat, amelyeket a kezdő 1C rendszergazdák elkövetnek, és bemutatja, hogyan lehet ezeket megoldani a Gilev-teszt példáján.

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ésén 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 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 legfrissebbnek 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.

Feltételezhető, hogy még a 10 évvel ezelőtti régi számítógépek esetében is (Pentium 775-ös foglalaton) az 1C:Enterprise parancsikonra való kattintástól az adatbázis-ablak megjelenéséig tartó időnek kevesebbnek kell lennie, mint egy percnek. (Celeron = lassú munka).

Ha a számítógépe rosszabb, mint egy 775 foglalatos pentium 1 GB RAM-mal, akkor együttérzek Önnel, é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öbb, 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. 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. 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 helyesen 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 a 70-80-as számok egészen valóságosak.

A leggyakoribb hibák ebben a szakaszban.

• 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.
• teljesítmény mód. Erre valamiért kevesen figyelnek, és a hatás a legjelentősebb. Ha gyorsaságra van szüksége, akkor ezt meg kell tennie, mind a kliens, mind a 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 rengetegen várnak 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):

• a 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 Gilev BIOS-beállítására). 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 a mó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-state engedélyezve, kiegyensúlyozott energia üzemmód
BIOS C-state engedélyezett, 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".
A BIOS-ban a C állapotok ki vannak kapcsolva, nagy teljesítményű mód. Ha nem használja a Turbo Boost funkciót, í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 felelősségedre é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 ehhez hasonló a kép:

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?

De a végén kiderül, hogy a CPU-teljesítménytesztek szerint a 23-as szorzós változat előrébb tart, Gilev tesztjei szerint a fájlverzióban a teljesítmény 22-es és 23-as szorzóval megegyezik, de a kliens-szerver változat, 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 mindkét lehetőséget saját maga, és válassza ki a legjobbat közülük. Mindenesetre a 49,5-ös és az 53-as 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 - disable, scrubbering - disable, Intel SpeedStep - enable, Turbo boost - Vezérlőpult – Tápellátás – Nagy teljesítmény) . És még mindig (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, ugyanazon a vonalon belül mutatom meg a frekvenciaváltás eredményeit. 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, hogy 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 frekvencia vá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 fogok erre a témára koncentrálni. 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. Az 1 Gbps-os hálózaton a normál működés közvetett jele a 100 Mb / s átlagos másolási sebesség, a jó munka pedig 120 Mb / s. Szeretném felhívni a figyelmet, hogy a processzorterhelés is lehet gyenge pont (beleértve). Az SMB protokoll Linuxon meglehetősen gyengén 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 lineáris másolás során az NFS-en futó Win-Linux szerver gyorsabban egy adatfolyamba másolódik, nem jelent semmit. A debian 1C-re hangolása külön cikk témája, még nem vagyok 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 még mindig nagyon rossz.

A legfontosabb, hogy a "leégett" adminisztrátorok mit tudnak, 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. Csinálhatsz servershare-t, lehet 192.168.0.1share-t, netezheted a z: 192.168.0.1share-t (és bizonyos esetekben ez a módszer is működik, de nem mindig), majd megadhatod a Z meghajtót. Úgy tűnik, ezek az útvonalak mind arra mutatnak ugyanarra a dologra ugyanoda, de 1C esetén csak egy mód van, ami elég stabil teljesítményt ad. 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: servershare-t. Példa: net use m:serverbases. Külön hangsúlyozom, NEM az IP címet, hanem a szerver nevét. 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 adja a teljes sávszélességet (a 10 Gbit-es 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 kapott) nem volt különbség. Maximális teljesítmény, a turbo boost le van tiltva (csak az eredmények összehasonlíthatósága miatt, a turbófokozó valamivel kevesebb, mint 10%-ot ad 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.

	100 Mbit CIFS Win 2008 - Win 2008 ip címről hívni	100 Mbit CIFS Win 2008 - Win 2008 címet név szerint	1 Gbit CIFS Win 2008 - Win 2008 ip címről hívni	1 Gbit CIFS Win 2008 - Win 2008 címet név szerint	1 Gbit CIFS Win 2008 - Win 7 címet név szerint	1 Gbit CIFS Windows 2008 – Debian címet név szerint	10 Gbit CIFS Win 2008 - Win 2008 ip címről hívni	10 Gbit CIFS Win 2008 - Win 2008 címet 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 egész 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 megfelelő 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 longs), és az második hálózati kártya a szerverről. Sok lehetőség van, á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.
• Az 1C 8.3.6.2076 (talán később, még nem kerestem a pontos verziót) a hálózaton keresztül még mindig könnyebben beállítható, mint 2008.7.8. 2008.08.07.-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írusvédelmi 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 mindent elvégezzen, 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 helyez 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 a debian / ubuntuban jól be van hangolva, de ez 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 szituáció), ahol látható lenne az 1 Gb és a 10 Gb közötti különbség. 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:

• A Gilev tesztadatbázist ugyanabba a mappába adjuk a szerverhez, mint a fő adatbázisokat. Ugyanarról a szerverről csatlakozunk, és futtatjuk a tesztet. Emlékszünk az eredményre.
• A fájlverzióhoz hasonlóan beállítjuk a processzort. A terminálszerverek 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).
• A hálózati kártyák beállítása terminálszerver 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.
• Nagyszámú felhasználó aktív munkájával (és itt már 30 embert is megpróbálhat egy bázishoz csatlakoztatni, ha megpróbálja), nagyon kívánatos az 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árában engedélyezve van az írás, 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, ezért a gyorsítótár letiltva van a tesztekhez.

Például ellenőriztem a Gilev teszt működését különböző lemezopciókkal. Tettem lemezeket abból, ami kéznél volt, csak hogy megmutassam a tendenciát. 2076.06.8. és 2008.08.3. 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	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 a sas esetében is. A kis mennyiségű adattal végzett tesztelés 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 jelenleg melyik lemezeket tesztelik). 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 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ájlalap) 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 mindegyik több felhasználóval rendelkezik. 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 kliensei lehetnek, é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 vannak) és azokban a pillanatokban, amikor a működő adatbázis lelassul, és a Gilev teszt jó eredményt mutat (30 felett), akkor a lassú a fő működő adatbázis működése a hibás, valószínűleg egy 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.

	1C: Xeon 5520 SQL: Xeon E5-2630	1C: Xeon 5520 SQL: Xeon E5-2630 Fiber csatorna-SSD	1C: Xeon 5520 SQL: Xeon E5-2630 Fiber csatorna - SAS	1C: Xeon 5650 SQL: Xeon E5-2630	1C: Xeon 5650 SQL: Xeon E5-2630 Fiber csatorna-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
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 érdekli - írja 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 természetesen meghozza a hatását, de nem ugyanazt, mint az 1C szerveren, az MS SQL szerver tökéletesen képes (ha rákérdeznek) többmagos és szabad memória használatára.
• Ha a hálózatot 1C és SQL között 1 Gbps-ről 10 Gbps-re változtatja, 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 biztosítja a hatást, bár nem 15%, a cikkben leírtak szerint. Ügyeljen arra, hogy tegye meg, ez gyors és egyszerű. Ha valaki adott az SQL szervernek egy elnevezett példányt a telepítés során, 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 SzerverNéven keresztül, hanem a KiszolgálónévPéldánynéven keresztül, például zz- testzztest. (Egyébként a következő 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:, SQLSTATE=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 a 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 ennyire 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.

Konkrét esetre lesz a legkevesebb tanács, mert. A kliens-szerver üzemmódban a fékek a legnehezebb esetek, és minden nagyon egyedileg van beállítva. A legegyszerűbb, ha azt mondjuk, hogy normál működéshez külön szervert kell venni CSAK 1C és MS SQL-hez, oda kell tenni a maximális frekvenciájú processzorokat (3 GHz felett), az alaphoz SSD meghajtókat és több memóriát (128+) , ne használjon virtualizációt. Segített - kiváló, szerencsés vagy (és sok ilyen szerencsés lesz, a problémák több mint felét egy megfelelő frissítés megoldja). Ha nem, akkor minden más lehetőség már külön mérlegelést és beállításokat igényel.

Gyakran kapok olyan kérdéseket, mint:

• mi miatt lelassul az 1C szerver?
• 1C-vel rendelkező számítógép nagyon lassan működik
• Az 1C kliens rettenetesen lassú

Mit kell tenni és hogyan lehet megnyerni, és így tovább, sorrendben:

Az ügyfelek nagyon lassan dolgoznak az 1C szerververziójával

Az 1C lassú működése mellett a hálózati fájlokkal való lassú munka is megfigyelhető. A probléma normál működés közben és az RDP-nél jelentkezik

ennek megoldására a Seven vagy a 2008-as szerver minden telepítése után mindig lefuttatom

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=letiltva chimney=letiltva

és a hálózat problémamentesen működik

néha a legjobb:

netsh interface tcp set global autotuning= HighlyRestricted

így néz ki a beállítás

Konfigurálja a víruskeresőt vagy a Windows tűzfalat

A víruskereső vagy a Windows tűzfal konfigurálása az 1C szerver működéséhez (például egy csomag az 1C szerverről: Enterprise és MS SQL 2008).

Szabályok hozzáadása:

• Ha az SQL szerver fogad kapcsolatokat a szabványos 1433-as TCP-porton, akkor engedélyezzük.
• Ha az SQL-port dinamikus, engedélyeznie kell a kapcsolatot a %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe alkalmazással.
• Az 1C szerver az 1541-es portokon, az 1540-es fürtön és az 1560-1591-es tartományon működik. Teljesen misztikus okokból néha a nyitott portok ilyen listája mégsem teszi lehetővé a kapcsolatot a szerverrel. A biztos működés érdekében engedélyezze az 1540-1591 tartományt.

Szerver / számítógép teljesítményének hangolása

Annak érdekében, hogy a számítógép maximális teljesítménnyel működjön, ehhez be kell állítania:

1. BIOS beállítások

• A szerver BIOS-ban tiltsa le az összes beállítást a processzor energiájának megtakarítása érdekében.
• Ha van "C1E" és feltétlenül SZABADÍTSA LE!!
• Néhány nem túl párhuzamos feladatnál a biosban is javasolt a hyperthreading kikapcsolása
• Bizonyos esetekben (főleg HP-nál!) be kell lépni a szerver BIOS-ába és ott ki kell kapcsolni azokat az elemeket, amelyek nevében ott van az EIST, Intel SpeedStep és C1E.
• Ehelyett ugyanott kell megkeresni a processzorhoz kapcsolódó elemeket, aminek a nevében ott van a Turbo Boost, és ENGEDÉLYEZNI kell őket.
• Ha a BIOS általános jelzéssel rendelkezik az energiatakarékos módról, és engedélyezi azt a maximális teljesítményű módban (ezt "agresszívnek" is nevezhetjük)

2. Sémabeállítások az operációs rendszerben - Nagy teljesítmény

Az Intel Sandy Bridge architektúrájú szerverek dinamikusan módosíthatják a processzorok frekvenciáját.