Lassan működik 1s 8.2. Automatizálási tippek
A munka felgyorsítása az 1C-ben: Számvitel 8.3 (3.0-s verzió), vagy letilthatja az ütemezett és háttérfeladatokat
2019-01-15T13:28:19+00:00Azok, akiknek már sikerült átállniuk az 1C: Accounting 8.3 új kiadására (3.0-s verzió), észrevették, hogy lassabb lett, mint a deuce. Néhány furcsa lassítás, végtelen napi többszöri háttérfeladatok, amikre senki sem kérte fel a tudtunk nélkül.
Közvetlenül az átállás után a könyvelőim azt mondták nekem, hogy az 1C: Accounting 3.0 új kiadása őszintén szólva lelassul a korábbiakhoz képest! És lehetetlen dolgozni.
Elkezdtem kitalálni, és nagyon hamar rájöttem, hogy a lefagyások és az azt követő felhasználói elégedetlenség fő oka a rutin- és háttérfeladatok, amelyek közül sok alapértelmezés szerint engedélyezve van, bár a könyvelők túlnyomó többsége számára nem szükséges.
Nos, például miért kell naponta százszor lefuttatnunk a "Szövegkivonás" feladatot, ha nem hajtunk végre teljes szöveges (könyvelők, ne féljetek) keresést az adatbázisunk összes objektumában.
Vagy minek folyamatosan letölteni az árfolyamokat, ha nem vagy alkalmanként csinálunk deviza tranzakciókat (és előtte mi magunk kattinthatunk a letöltési árfolyamok gombra).
Ugyanez vonatkozik az 1C állandó kísérletére, hogy csatlakozzon a webhelyhez, és ellenőrizze és frissítse a banki osztályozókat. Miért? Jómagam megnyomom a gombot, hogy frissítsem az osztályozókat, ha nem találom meg a megfelelő bankot a BIC alapján.
Ennek módjáról az alábbi pontokban olvashat.
1. Lépjen az „Adminisztráció” részre, és válassza ki a „Karbantartás” elemet a műveleti panelen ():
2. A megnyíló ablakban keresse meg és válassza ki a „Rendszeres és háttérfeladatok” elemet:
3. Nyissa meg az összes olyan jobot, amelynél a Be oszlop van. megér egy dögöt.
4. Törölje az "Engedélyezve" jelölést, majd kattintson a "Mentés és bezárás" gombra.
5. Végezze el ezt a mellékelt feladatok mindegyikével, és élvezze az új kiadást. Általában véleményem szerint sokkal jobb, mint a kettes.
Ugyanakkor néhányat azok közül, amelyeket letiltottál rutinfeladatokat a platform továbbra is visszakapcsolja.
Az 1C rendszer domináns pozíciót foglal el a kis- és középvállalkozások automatizálási piacán. Ha egy cég az 1C számviteli rendszert választotta, akkor általában szinte minden alkalmazott dolgozik benne, a közönséges szakemberektől a menedzsmentig. Ennek megfelelően a vállalat üzleti folyamatainak sebessége az 1C sebességétől függ. Ha az 1C nem kielégítő sebességgel dolgozik, akkor ez közvetlenül befolyásolja az egész vállalat munkáját és a profitot.
Valójában van Az 1C gyorsítás három módja:
- A hardver kapacitásának növelése.
- Az operációs rendszer és a DBMS beállítások optimalizálása.
- Kód és algoritmusok optimalizálása 1C-ben.
Az első módszer eszköz- és licencvásárlást igényel, a harmadik a programozóktól sok munkaerőt igényel, és ennek eredményeként mindkét út jelentős anyagi költségekkel jár. Mindenekelőtt a programkódra kell figyelni, mivel a szerver kapacitásának növekedése nem tudja kompenzálni a hibás kódot. Bármely programozó tudja, hogy néhány sornyi kóddal olyan folyamatot lehet létrehozni, amely teljesen betölti bármely szerver erőforrásait.
Ha a cég bízik a programkód optimálisságában, és még mindig lassan fut, általában a menedzsment a szerverkapacitás növelése mellett dönt. Ezen a ponton felvetődik egy logikus kérdés: mi hiányzik, mennyit és mit kell ennek hatására hozzátenni.
Az 1C cég meglehetősen homályos választ ad arra a kérdésre, hogy mennyi erőforrásra van szükség, erről korábban írtunk bejegyzéseinkben. Ezért önállóan kell kísérleteket végeznie, és ki kell találnia, hogy mitől függ az 1C teljesítménye. Az alábbiakban ismertetjük az EFSOL teljesítménykísérleteit.
Amikor az 1C 8.2-vel dolgozunk, különösen a felügyelt űrlapokat használó konfigurációknál, furcsa tényt vettünk észre: az 1C gyorsabban fut egy munkaállomáson, mint egy nagy teljesítményű szerveren. Ráadásul a munkaállomás minden tulajdonsága rosszabb, mint a szerveré.
1. táblázat – Konfigurációk, amelyeken a kezdeti tesztelést elvégezték
A munkaállomás 155%-kal nagyobb teljesítményt mutat, mint egy kiváló teljesítményű 1C szerver. Elkezdtük kitalálni, mi a baj, és szűkíteni kezdtük a keresések körét.
1. ábra - Teljesítménymérés a munkaállomáson a Gilev-teszttel
Az első gyanú az volt, hogy Gilev tesztje nem volt megfelelő. A nyomtatványok megnyitásának, a dokumentumok feladásának, a jelentéskészítésnek, stb. műszeres eszközökkel végzett mérései azt mutatták, hogy a Gilev-teszt a munka tényleges sebességével arányos becslést ad 1C-ben.
A RAM száma és gyakorisága
Az interneten elérhető információk elemzése azt mutatta, hogy sokan írnak az 1C teljesítményének a memóriafrekvenciától való függéséről. A frekvenciától van, és nem a hangerőtől. Úgy döntöttünk, hogy teszteljük ezt a hipotézist, mivel 1066 Mhz-es RAM-frekvenciánk van a szerveren, szemben a munkaállomáson 1333 Mhz-rel, és a szerver RAM mennyisége már jóval magasabb. Úgy döntöttünk, hogy nem 1066 Mhz-et, hanem 800 Mhz-et teszünk azonnal, hogy jobban látható legyen a teljesítmény memóriafrekvenciától való függésének hatása. Az eredmény - a termelékenység 12%-kal csökkent, és 39,37 egységet tett ki. 1066 Mhz helyett 1333 MHz-es memóriát telepítettünk a szerverre, és enyhe teljesítménynövekedést kaptunk - körülbelül 11%. A termelékenység 19,53 egység volt. Ennek megfelelően nem a memóriáról van szó, bár a frekvenciája kis növekedést ad.
2. ábra - Teljesítménymérés a munkaállomáson a RAM frekvenciájának csökkentése után
3. ábra - Teljesítménymérés a szerveren a RAM frekvenciájának növelése után
Lemez alrendszer
A következő hipotézis a lemez alrendszerre vonatkozott. Rögtön két hipotézis merült fel:
- Az SSD-k jobbak, mint a SAS-meghajtók, még akkor is, ha raid 10-ben vannak.
- Az iSCSI lassú vagy nem működik megfelelően.
Ezért az SSD helyett egy rendes SATA lemezt telepítettek a munkaállomásra, és ugyanez történt a szerverrel is - az alap egy helyi SATA lemezre került. Ennek eredményeként a teljesítménymérés semmilyen módon nem változott. Valószínűleg ez történik, mivel elegendő RAM van, és a lemezeket gyakorlatilag semmilyen módon nem használják a teszt során.
CPU
A szerveren lévő processzorok természetesen erősebbek és kettő is van, de a frekvencia valamivel alacsonyabb, mint a munkaállomáson. Úgy döntöttünk, hogy ellenőrizzük a processzor frekvenciájának hatását a teljesítményre: nem volt kéznél magasabb frekvenciájú processzor a szerver számára, ezért csökkentettük a processzor frekvenciáját a munkaállomáson. Azonnal 1,6-ra csökkentettük, így a korreláció világosabbá vált. A teszt kimutatta, hogy a teljesítmény jelentősen visszaesett, de még 1,6-os processzorral is csaknem 28 darabot produkált a munkaállomás, ami közel másfélszer többet, mint a szerveren.
4. ábra - Teljesítménymérés 1,6 Ghz-es processzorral rendelkező munkaállomáson
videokártya
Az interneten vannak olyan információk, amelyek szerint a videokártya befolyásolhatja az 1C teljesítményét. Igyekeztünk integrált munkaállomás videót, professzionális adaptert használni Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, régi GeForce grafikus kártya 16 MbSDR. A Gilev-teszt során nem észleltek szignifikáns különbséget. Talán a videokártya továbbra is befolyásolja, de valós körülmények között, amikor meg kell nyitnia a kezelt űrlapokat stb.
Jelenleg két gyanú merül fel, hogy miért fut gyorsabban a munkaállomás még észrevehetően rosszabb teljesítmény mellett is:
- CPU. A munkaállomáson lévő processzor típusa jobban megfelel az 1C-nek.
- Lapkakészlet. Ha egyéb dolgok nem változnak, a munkaállomásunk újabb lapkakészlettel rendelkezik, ez lehet az oka.
Tervezzük a szükséges alkatrészek beszerzését és a tesztek folytatását, hogy végre kiderüljön, mi okozza a több a teljesítmény az 1C-től függ. Amíg a jóváhagyási és beszerzési folyamat zajlik, úgy döntöttünk, hogy elvégezzük az optimalizálást, különösen mivel ez nem kerül semmibe. A következő lépéseket azonosították:
1. szakasz. Rendszerbeállítás
Először is végezzük el a következő beállításokat a BIOS-ban és az operációs rendszerben:
- A szerver BIOS-ban tiltsa le az összes beállítást a processzor energiájának megtakarítása érdekében.
- Válassza ki a „Maximális teljesítmény” tervet az operációs rendszerben.
- A processzor is a maximális teljesítményre van hangolva. Ez megtehető a PowerSchemeEd segédprogrammal.
2. lépés: Az SQL szerver és az 1C:Enterprise szerver beállítása
A következő módosításokat hajtjuk végre a DBMS-kiszolgáló és az 1C:Enterprise beállításain.
- A megosztott memória protokoll konfigurálása:
- A megosztott memória csak a platformon lesz engedélyezve az 1C 8.2.17-től kezdődően, a korábbi kiadásokon a Named Pipe engedélyezve lesz - némileg gyengébb sebességgel. Ez a technológia csak akkor működik, ha az 1C és az MSSQL szolgáltatások ugyanarra a fizikai vagy virtuális szerverre vannak telepítve.
- Javasoljuk, hogy az 1C szolgáltatást hibakeresési módba helyezze, paradox módon ez teljesítménynövekedést ad. Alapértelmezés szerint a hibakeresés le van tiltva a szerveren.
- SQL szerver beállítása:
- Csak egy szerverre van szükségünk, a hozzá tartozó többi szolgáltatásra, és esetleg valaki használja is, csak lassítja a munkát. Leállítjuk és letiltjuk az olyan szolgáltatásokat, mint: FullText Search (az 1C-nek saját teljes szöveges keresési mechanizmusa van), Integration Services stb.
- Állítsa be a szerver számára lefoglalt memória maximális mennyiségét. Erre azért van szükség, hogy az sql szerver számoljon ezzel az összeggel, és előre megtisztítsa a memóriát.
- Állítsa be a szálak maximális számát (Maximális dolgozói szálak), és állítsa be a megnövelt szerverprioritást (Boost priority).
3. szakasz: Működő adatbázis felállítása
A DBMS-kiszolgáló és az 1C:Enterprise optimalizálása után továbblépünk az adatbázis-beállításokhoz. Ha az alap még nem lett telepítve a .dt fájlból, és ismeri a hozzávetőleges méretét, akkor jobb, ha azonnal jelzi az elsődleges fájl inicializálási méretét az alapméret „>=” jelével, de ez egy kérdés az íze, akkor is növekedni fog, ha kihelyezik. De meg kell adni az automatikus méretnövelést: kb. 200 MB adatbázisonként és 50 MB naplónként, mert. alapértelmezett értékek - 1 MB-os növekedés és 10% -os növekedés nagyon lelassítja a szervert, amikor minden 3. tranzakcióval növelnie kell a fájlt. Ha RAID-tömböt használ, jobb, ha az alapfájlt és a naplófájlt különböző fizikai lemezeken vagy RAID-csoportokon tárolja, és korlátozza a napló növekedését. Javasoljuk, hogy a Tempdb fájlt egy nagy sebességű tömbbe helyezze át, mivel a DBMS gyakran hozzáfér.
4. szakasz. Ütemezett feladatok beállítása
Az ütemezett feladatokat a Menedzsment részben található Karbantartási terv segítségével, grafikus eszközökkel egész egyszerűen elkészítjük, így ennek mikéntjét nem írjuk le részletesen. Nézzük meg, milyen műveleteket kell végrehajtani a teljesítmény javításához.
- Az indexeket töredezettségmentesíteni kell, és a statisztikákat naponta frissíteni kell. ha az index töredezettsége > 25%, ez drasztikusan csökkenti a szerver teljesítményét.
- A statisztika töredezettségmentesítése és frissítése – gyorsan megtörténik, és nincs szükség a felhasználók leválasztására. Naponta is ajánlott elvégezni.
- Teljes újraindexelés - adatbáziszárral történik, hetente legalább egyszer ajánlott. Természetesen a teljes újraindexelés után az indexek töredezettségmentesülnek és a statisztikák azonnal frissülnek.
Ennek eredményeként a rendszer, az SQL szerver és a munkabázis finomhangolásával 46%-kal sikerült növelnünk a termelékenységet. A méréseket 1C műszerrel és Gilev teszttel végeztük. Ez utóbbi 25,6 egységet mutatott az eredeti 17,53-mal szemben.
Rövid következtetés
- Az 1C teljesítménye nem nagyon függ a RAM frekvenciájától. Elegendő térfogat elérésekor nincs értelme a további memóriabővítésnek, mivel az nem vezet a teljesítmény növekedéséhez.
- Az 1C teljesítménye nem függ a videokártyától.
- Az 1C teljesítménye nem függ a lemez alrendszerétől, feltéve, hogy a lemezek olvasási vagy írási sorát nem lépik túl. Ha SATA meghajtók vannak telepítve, és nem lépték túl a várakozási sort, akkor az SSD telepítése nem javítja a teljesítményt.
- A teljesítmény nagymértékben függ a processzor frekvenciájától.
- Az operációs rendszer és az MSSQL szerver megfelelő konfigurálásával anyagköltségek nélkül 40-50%-os 1C teljesítménynövekedés érhető el.
FIGYELEM! Nagyon fontos pont! Minden mérést tesztbázison végeztünk a Gilev teszt és az 1C műszeres eszközök segítségével. Egy valós adatbázis viselkedése valós felhasználókkal eltérhet a kapott eredményektől. Például a tesztadatbázisban nem találtunk teljesítményfüggést a videokártyától és a RAM mennyiségétől. Ezek a következtetések meglehetősen kétségesek, és valós körülmények között ezek a tényezők jelentős hatással lehetnek a teljesítményre. A felügyelt űrlapokat használó konfigurációkkal végzett munka során fontos a videokártya, és egy nagy teljesítményű grafikus processzor felgyorsítja a munkát a programfelület megrajzolása szempontjából, vizuálisan ez az 1C gyorsabb működésében nyilvánul meg.
Lassan megy az 1C? Rendelje meg számítógépek és szerverek informatikai karbantartását az EFSOL sokéves tapasztalattal rendelkező szakembereitől, vagy vigye át 1C-jét egy nagy teljesítményű és hibatűrő 1C virtuális szerverre.
Rendszerintegráció. Tanácsadó
1C: A könyvelés az egyik leghíresebb és legkényelmesebb program könyvelés. Ennek bizonyítéka, hogy minden tevékenységi területen jelen van: kereskedelem, gyártás, pénzügy stb.
Sajnos, mint mindenki számítógépes programok 1C: Számvitelben is vannak különféle hibák és lefagyások. Az egyik leggyakoribb probléma a rendszer lassú működése.
Annak érdekében, hogy megértsük az előfordulásának okait, és megpróbáljuk megoldani őket, a mai cikk készült.
A lassú munkavégzés gyakori okainak megszüntetése 1C
1. A program lassú működésének leggyakoribb oka az 1C alapfájlhoz való hosszú távú hozzáférés, amely a merevlemez hibái vagy az internetkapcsolat rossz minősége miatt lehetséges, felhőtechnológiák használata esetén . Problémák lehetnek a víruskereső rendszer beállításaiban is.
Megoldás: Végezzen hibaelhárítási vizsgálatot, és töredezettségmentesítse a merevlemezt. Tesztelje az internet-hozzáférés sebességét. Alacsony díjak (kevesebb, mint 1 Mb / s) esetén vegye fel a kapcsolatot a szolgáltató TP szolgáltatásával. Ideiglenesen tiltsa le a vírusvédelmet és a tűzfalat a víruskereső rendszerben.
2. Talán a program lassú működése az adatbázisfájl nagy méretéből adódik.
A probléma megoldásához nyissa meg az 1C-t "Konfigurátor" módban, válassza ki az "Adminisztráció" elemet a rendszermenüben, majd a "Tesztelés és javítás" menüpontot. Az ablakban az „Információs adatbázis táblák tömörítése” menüpontot kell kiválasztani, alul a „Tesztelés és javítás” menüpont aktív. Kattintson a "Futtatás" gombra, és várja meg, amíg a folyamat befejeződik.
3. Következő lehetséges oka- elavult szoftver vagy magának a programnak egy elavult verziója.
Kiút ebből a helyzetből: frissítse az operációs rendszer szoftverét vagy telepítse az 1C program legújabb verzióját. A megelőző intézkedések érdekében mindig frissítsen a legújabb verzióra, amely kiküszöböli a korábbi konfigurációk hibáit.
telepíteni legújabb verzió 1C rendszer esetén be kell lépnie a programba "Konfiguráció" módban, majd a menüből lépjen a "Szolgáltatás" -> "Segédprogramok" -> "Konfiguráció frissítése", majd válassza ki az alapértelmezett beállításokat, és kattintson a "Frissítés" gombra.
Ez a cikk a fő tényezőket tárgyalja: amikor az 1C lelassul, az 1C lefagy, az 1C pedig lassan működik. Az adatok a SoftPoint 1C + MS SQL kombinációjára épülő nagy informatikai rendszerek optimalizálása terén szerzett sokéves tapasztalata alapján készültek.
Először is érdemes megjegyezni azt a mítoszt, hogy az 1C-t nem nagyszámú felhasználó egyidejű működésére tervezték, amelyet aktívan támogatnak a fórumozók, akik kényelmesnek találják ezeket a bejegyzéseket, hogy mindent úgy hagyjanak, ahogy van. Kellő türelemmel és tudásszinttel tetszőleges számú felhasználóhoz eljuttathatja a rendszert. A lassú munka és a fagyos 1C többé nem lesz probléma.
A gyakorlatból: Az 1C v7.7 optimalizálása a legegyszerűbb (az 1C 8.1, 1C 8.2, 1C 8.3 optimalizálása nehezebb feladat, mivel az alkalmazás 3 hivatkozásból áll). A 400 egyidejű felhasználó elérése meglehetősen tipikus projekt. 1500-ig már nehéz, kemény munkát igényel.
A második mítosz: az 1C teljesítményének javítása és az 1C lefagyások elkerülése érdekében erősebb szervert kell telepíteni. Általában az optimalizálási projektekben az esetek 95% -ában elfogadható teljesítmény érhető el akár frissítés nélkül, akár a berendezés jelentéktelen részének frissítésével, például hozzáadással. RAM. Ugyanakkor meg kell jegyezni, hogy a berendezésnek továbbra is szerver alapúnak kell lennie, különösen lemez alrendszer. Az elavult lemezalrendszer csak az egyik oka annak, hogy az 1C lassú.
A többfelhasználós munka fő korlátja az 1C-ben a blokkoló mechanizmus. Általában az 1C zárai, és nem a szerverberendezések akadályozzák meg, hogy sok ember dolgozzon az adatbázisban. Ennek a problémának a leküzdéséhez keményen kell dolgoznia, és meg kell változtatnia a zárak logikáját az 1C-ben - táblázatosról soronként csökkenteni kell őket. Ekkor például egy dokumentum tartása csak egy dokumentumot blokkol, és nem az összes dokumentumot a rendszerben.
1. ábra: 1C blokkoló sor a PerfExpert megfigyelő rendszerben, az 1C felhasználókról szóló információkkal, egy konfigurációs modullal és egy adott kódsorral ebben a modulban.
Az 1C zárszerkezet cseréje nagyon összetett technológia. Nem mindenki képes kihozni egy ilyen trükköt, és számukra csak egy út maradt - a szerkezet optimalizálása és a műveletek végrehajtási idejének felgyorsítása. Az a tény, hogy az 1C blokkolása és a műveletek befejezéséhez szükséges idő erősen összefüggő mutatók. Például, ha a dokumentum feladása 15 másodpercet vesz igénybe, akkor nagy számú felhasználó esetén nagy valószínűséggel valaki más próbálja meg feladni a dokumentumot, és a zárban vár. Ha a végrehajtási időt legalább 1 másodpercre csökkenti, akkor a művelet 1C blokkolása jelentősen csökken.
A blokkolás szempontjából veszélyesebbek a csoportos feldolgozások, amelyek végrehajtási ideje hosszú lehet, és egyben 1C blokkolást okozhat. Minden olyan feldolgozás, amely megváltoztatja az adatokat, mint például a dokumentumok újrasorolása vagy kötegelt feldolgozása, zárolja a táblákat, és megakadályozza, hogy más felhasználók dokumentumokat tegyenek közzé. Természetesen minél gyorsabban hajtják végre ezeket a feldolgozásokat, az kevesebb idő zárak és könnyebben kezelhetőek a felhasználók számára.
A súlyos jelentések, amelyek csak olvasási műveleteket hajtanak végre, szintén veszélyesek lehetnek a zárolások szempontjából, bár úgy tűnik, hogy nem zárolják az adatokat. Az ilyen jelentések befolyásolják a blokkolások intenzitását az 1C-ben, lelassítva a rendszer egyéb műveleteit. Ez azt jelenti, hogy ha a jelentés nagyon nehéz, és lefoglalja a szerver erőforrásainak nagy részét, akkor kiderülhet, hogy a jelentés elindítása előtt 1 másodpercig ugyanazokat a végrehajtásokat hajtották végre, a jelentés végrehajtása során pedig 15 másodpercig. Természetesen a műveletek végrehajtási idejének növekedésével a blokkolás intenzitása is nő.
2. ábra: Betöltés a működő szerveren a konfigurációs modulokkal összefüggésben, minden felhasználótól. Minden modulnak saját színe van. Az 1C-ből létrehozott terhelésben egyértelmű kiegyensúlyozatlanság van.
Az optimalizálás fő szabálya, hogy a dokumentum ideje minimális időt vesz igénybe, és csak a szükséges műveleteket hajtsa végre. Például gyakran használnak regiszterszámításokat a könyvelési feldolgozás során a szűrési feltételek megadása nélkül. Ebben az esetben olyan szűrőket kell megadnia a regiszterekhez, amelyek lehetővé teszik a legjobb szelektivitás elérését, anélkül, hogy megfeledkeznünk arról, hogy a szűrési feltételeknek megfelelően a regiszternek megfelelő indexekkel kell rendelkeznie.
A súlyos jelentések futtatása mellett az MS SQL és az MS Windows nem optimális beállításai lelassíthatják a műveletek végrehajtási idejét, és ezáltal növelhetik az 1C blokkolás intenzitását. Ez a probléma az ügyfelek 95% -ánál található. Meg kell jegyezni, hogy ezek komoly szervezetek szerverei, és magasan képzett rendszergazdák egész osztályai vesznek részt támogatásukban és konfigurációjukban.
A kiszolgáló nem megfelelő beállításának fő oka a rendszergazdák attól való félelme, hogy bármit is módosítanak egy futó szerveren, és a szabály, hogy „A legjobb a jó ellensége”. Ha az adminisztrátor megváltoztatja a szerver beállításait és problémák kezdődnek, akkor a hatóságok minden haragja a hanyag adminisztrátorra árad. Ezért neki kifizetődőbb mindent úgy hagyni, ahogy van, és egyetlen lépést sem tenni felettesei parancsa nélkül, mint saját felelősségére kísérletezni.
A második ok a hálózatoptimalizálási problémákkal kapcsolatos egyértelmű információk hiánya. Nagyon sok vélemény létezik, amelyek gyakran teljesen ellentmondanak egymásnak. Minden optimalizálással foglalkozó véleménynek megvannak az ellenfelei és a fanatikusai, akik megvédik azt. Ennek eredményeként az internet és a fórumok inkább összekeverik a szerverbeállításokat, semmint segítséget. Ilyen bizonytalan helyzetben az adminisztrátornak még kevésbé van kedve változtatni valamit a szerveren, ami legalább valahogy működik.
Első pillantásra a kép tiszta - mindent optimalizálnia kell, ami lelassítja az 1C szervert. De képzeljük magunkat egy ilyen optimalizáló helyébe – mondjuk 1C 8.1 8.2 8.3 SCP és 50 felhasználó dolgozik egyszerre. Egy szörnyű napon a felhasználók panaszkodni kezdenek, hogy az 1C lassú, és meg kell oldanunk ezt a problémát.
Mindenekelőtt megnézzük, mi történik a szerveren - hirtelen van valami független vírusirtó, amely teljes rendszervizsgálatot végez. Az ellenőrzés azt mutatja, hogy minden rendben van - a szerver 100% alatt van betöltve, és csak az sqlservr folyamat.
Gyakorlatból: az egyik junior rendszergazda saját kezdeményezésére bekapcsolta az automatikus frissítést a szerveren, a Windows és az SQL örömmel frissült, és a frissítés után az 1C felhasználók munkájában hatalmas lassulás kezdődött, vagy az 1C egyszerűen lefagy. .
A következő lépés annak ellenőrzése, hogy mely programok töltik be az MS SQL-t. Az ellenőrzés azt mutatja, hogy a terhelés körülbelül 20 alkalmazáskiszolgáló-kapcsolatból származik.
Gyakorlatból: az oldalon lévő adatokat gyorsan frissítő program elakadt, és ahelyett, hogy 4 óránként frissített volna, megállás nélkül, szünetek, a szerver erős terhelése, az adatok blokkolása nélkül tette.
A helyzet további elemzése nagy nehézségekbe ütközik. Már rájöttünk, hogy a terhelés közvetlenül az 1C-től származik, de hogyan lehet megérteni, hogy pontosan mit csinálnak a felhasználók? Vagy legalábbis kik ők. Nos, ha 10 1C felhasználó van a szervezetben, akkor csak átsétálhat rajtuk, és megtudhatja, mit csinálnak most, de a mi esetünkben ötvenen vannak, és több épületben vannak szétszórva.
Az általunk vizsgált példában a helyzet még nem bonyolult. És képzeld el, hogy a lassulás nem ma volt, hanem tegnap. Ma már nem ismétlődik a helyzet, minden rendben van, de ki kell deríteni, hogy tegnap miért nem tudtak dolgozni az operátorok (természetesen csak otthonról indulás előtt panaszkodtak, mert szeretnek egész nap chatelni, mert semmi sem működik, tetszik nekik több, mint dolgozni). Ez az eset rávilágít egy olyan szerver naplózási rendszerre, amely mindig megőrzi a kiszolgáló főbb paramétereinek előzményeit, és amelyből az események sorrendje visszaállítható.
A naplózó rendszer egyszerűen nélkülözhetetlen eszköz a rendszeroptimalizálásban. Ha hozzáadja az aktuális állapot online megtekintésének lehetőségét, akkor kap egy rendszert a szerver állapotának figyelésére. Minden optimalizálási projekt a szerverállapot-statisztikák gyűjtésével kezdődik a szűk keresztmetszetek azonosítása érdekében.
Amikor elkezdtünk dolgozni az optimalizálás területén, sok szerverfigyelő rendszert kipróbáltunk, sajnos nem sikerült olyat találni, ami ezt a problémát megfelelő szinten megoldja, így saját erőből kellett létrehoznunk egy rendszert. Az eredmény egy egyedülálló termék, a PerfExpert, amely lehetővé tette az informatikai rendszerek optimalizálásának folyamatainak automatizálását és racionalizálását. A programot az 1C-vel való szoros integráció, az észrevehető további terhelés hiánya és a többször bizonyított harci helyzetekben való gyakorlati használatra való alkalmassága jellemzi.
Visszatérve a példánkra, a legvalószínűbb eredmény a következő: Az adminisztrátor azt mondja: „A programozók a hibásak, akik a konfigurációt írták”, a programozók azt válaszolják: „Minden jól meg van írva – a szerver nem működik jól.” És a szekér, ahogy mondani szokás, még mindig ott van. Ennek eredményeként az 1C lelassul, lefagy vagy lassan fut.
Mindenesetre az 1C teljesítményproblémák megoldása érdekében javasoljuk, hogy először vásárolja meg és használja a teljesítményfigyelést PerfExpert , ez lehetővé teszi a megfelelő vezetői döntés meghozatalát és pénzt takarít meg. A termék alkalmas mind a kisméretű IS 1C:Enterprise - 50 felhasználóig, mind a rendszerekhez - 1000 felhasználótól. 2015 júliusától teljesítményfigyelés PerfExpert tanúsítványt kapott 1C: Kompatibilis, tesztelték Microsoft és nemcsak az 1C rendszerek, hanem mások teljesítményproblémák megoldásában is segít információs rendszerek az alapon MS SQL Server (Axapta, CRM Dynamics, Doc Vision és mások).
Ha tetszett az információ, a következő javasolt lépések a következők:
- Ha önállóan szeretne megbirkózni az 1C műszaki teljesítményproblémáival (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) és egyéb információs rendszerek, akkor az Almanachunkban található műszaki cikkek egyedi listája az Ön számára (Zárak és holtpontok, nagy CPU- és lemezterhelés, adatbázis-karbantartás és indexhangolás csak egy kis része az ott található műszaki anyagoknak).
.
- Ha szeretné megbeszélni a teljesítményproblémákat szakértőnkkel, vagy PerfExpert teljesítményfigyelő megoldást szeretne rendelni akkor hagyjon egy kérést, és a lehető leghamarabb felvesszük Önnel a kapcsolatot.
Az 1C egy olyan program, amelyet bármely vállalkozás tevékenységének automatizálására terveztek. Ez a segédprogram nagymértékben leegyszerűsíti a vállalaton belüli számos műveletet. A termék felhasználói azonban többször is észrevették, hogy az 1C néha lelassul. Ennek rengeteg oka lehet, és egyáltalán nem szükséges, hogy magában a programban legyen a dolog. Valószínűleg nem rendelkezik a normál működéshez szükséges összes programmal rendszerkövetelmények, de néha más okai is vannak a segédprogram lassú működésének.
Mik a minimális rendszerkövetelmények az 1C működéséhez?
Mint minden más számítógéphez tervezett szoftvertermékhez, az 1C-hez is vannak minimális rendszerkövetelmények. Ezeket elemezzük most.
Az 1C rendszerkövetelményei:
- magsebesség: 2,4 GHz (kliens-szerver esetén), 3 GHz (fájlérték);
- Memória (RAM): 8 GB ( fájl verzió), 4 GB (kliens-szerverhez);
- Internet kapcsolat sebessége - legalább 100 Mb / s;
- szabad hely a merevlemezen - legalább 2 GB.