A program lefagyásának több oka is lehet:

1) nézze meg az rphost által lefoglalt memória mennyiségét az 1C szerveren. Ha a szerver x32-es verziója van, akkor a folyamat legfeljebb 1,75 GB RAM-ot használhat
Ha nincs elég memória, a szerver nem tud új kapcsolatokat fogadni, vagy lefagy, ha az aktuális munkamenet további memóriát igényel
www.viva64.com/ru/k/0036
2) Nézze meg a „Working server settings” (Munkakiszolgáló beállítások) beállításait, a beállítások hibásak lehetnek. Volt ez a probléma, és a szerver folyamatosan lefagyott. A beállításaim mellékelve. A szervernek 11 GB van lefoglalva.
3) Problémák adódhatnak a Postgressql beállításakor.

Adja meg a szerver jellemzőit, az adatbázisméreteket, a Postgressql konfigurációkat. Információ nélkül nehéz megmondani.

Saját PostgreSQL konfigurációm: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Ez a konfiguráció a rendelkezésre álló RAM mennyiségéhez van kiválasztva.
PostgreSQL telepítve Linuxra, 3 GB RAM, 3 CPU mag.
Szerver 1C8: 11 GB RAM, 5 CPU mag
4 adatbázis, egyenként körülbelül 1 GB (feltöltve a dt-be)

Adja meg a szerver összes jellemzőjét: 1C8 szerver és adatbázis, fizikai vagy virtuális, operációs rendszer, RAM mennyisége minden szerveren, milyen CPU, mennyi RAM-ot foglalnak el az rphost folyamatok, mennyi van? RAID tömböt használsz?

Korábban magam is PostgreSQL-t használtam, de a folyamat során problémákba ütköztem, amikor egy adatbázist futtattam PostgreSQL-en, és nemrég váltottam MS SQL-re.

A szervered nem rossz ezekhez az adatbázisokhoz. A PostgreSQL használatához nagyon jól ismernie kell a konfigurációját. Ha az adatbázisok kicsik, sok konfigurációs hiba megbocsátható. Amikor csak elkezdtük az 1C + PostgreSQL implementálását, akkor is nagyon gyakoriak voltak az adatbázis működésével kapcsolatos problémák (gyakran voltak lefagyások, lassan működött). A PostgreSQL jobban használható Linuxon, nem Windowson. Jómagam nem vagyok adatbázis-specialista az adatbázis-szerver beállításához, az 1Sbit szakembert fogadtuk fel, ő állította be nekünk, és utána nem volt probléma a működéssel.

Tanács:
Nagy adatbázisai vannak, ne spóroljon, fogadjon adatbázis-szakértőt, aki beállítja Önnek. Egy ember nem lehet mindenben szakértő.

1) mióta ellenőrizte magát az adatbázist és indexelte újra? VÁKUUM és REINDEX
2) mióta tesztelte és javította az adatbázist 1C eszközökkel?
3) az adatbázis naplófájlja külön HDD-re van helyezve?
4) A HDD erősen terhelt?

Fontolja meg az MS Sql-re való váltást, amely gyakran „gyakorlatilag” nem igényel konfigurációt, és könnyebben használható. A PostgreSQL-lel ellentétben az MS Sql készen áll a használatra, de a PostgreSQL-t konfigurálni kell.

Ha kérdésed van írj, hátha tudok valamiben segíteni Skype-on: tisartisar

Béreljen adatbázis-beállító szakembert

Miért váltottunk MS SQL-re:
Az UT konfigurációt használjuk, és a hónap zárásakor előfordult, hogy olyan hibák merültek fel, amelyeket nem tudtunk megoldani. Ha fájl módba vitted át az adatbázist és elkezdted a hónap zárását, akkor minden rendesen bezárult, a költségszámításkor ugyanaz az adatbázis került a PostgreSQL szerverre, hibák történtek. Ekkor lebegő hibák miatt fél év lemaradásban voltunk a záró hónapokban. Létrehoztunk egy tesztadatbázist MS SQL-en, és az a hónap, amelyet nem lehetett lezárni a PostgreSQL-en MS SQL-en, lezárult. Az árlistában szereplő árkerekítés sem működik megfelelően PostgreSQL-en. Valójában az 1C futtatása PostgreSQL-en támogatott, de továbbra is ajánlott az MS SQL használata.
Emiatt döntöttek úgy, hogy MS SQL-re váltanak, mert... a működés stabilitása 1C drágább.

Örülök, hogy segíthettem, ha bármilyen kérdése vagy problémája van, forduljon hozzám.

1) mennyi memória van lefoglalva az MS SQL szerverhez? ez magában az MS SQL szerverben van beállítva.
2) Rendszeresen tesztelje az adatbázist az 1C használatával
3) cikk a biztonsági mentés és karbantartás beállításáról. Ez fontos, és rendszeresen meg kell tenni. Minden nap csinálom. Tekintse meg az útmutató mind a 3 részét.

Hogyan lehet bezárni egy programot, ha lefagy és nem válaszol. Miért fagynak le a programok? Ki a hibás és mit kell tenni? Ebben a cikkben megpróbáljuk elemezni a probléma fő okait és megoldásait.

Egy megnyitott program nem reagál az Ön műveleteire, a kurzor lefagyott vagy homokórává változott, maga a program ablaka a „Nem válaszol” üzenetet jeleníti meg, mindenre kattint, ideges vagy és nem tudja, mit tegyen?

Először is nyugodjon meg, és fejezze be a cikk elolvasását. Abszolút mindenki találta magát ebben a helyzetben, minden programot emberek írnak, tehát nem ideálisak. A legfontosabb dolog, amit meg kell értenünk, hogy ilyen esetekben hogyan kell helyesen cselekedni, és miért történik ez.

Először is ki kell deríteni, hogy a program valóban lefagy-e, és az összes fent leírt tünet megfigyelhető, vagy egyszerűen elindított egy erőforrás-igényes alkalmazást vagy programot, amelytől a rendszer nem fagy le, hanem egyszerűen lelassul.

Mit ne tegyen, ha a program lefagy

Nézzük meg a leggyakoribb hibákat, amelyeket sok kezdő felhasználó elkövet, és ezzel az idejét vesztegeti.

- Sikoltozás, ütés a billentyűzeten (ez biztosan nem az ő hibája).
- Nem kell újra megpróbálni futtatni ugyanazt a programot, vagy különösen más programokat - ez csak ront a helyzeten.
— Húzza ki a tápfeszültséget, kapcsolja ki, indítsa újra (ez a végső módszer).

Mi a teendő, ha a program lefagy

1. Mielőtt a radikálisabb módszerekre térne át, próbálja meg bezárni a tálcán a lefagyott program jobb gombbal történő kattintásával és a megfelelő elem kiválasztásával.
2. Ha nem segít, menj a bevált módszerre, ehhez el kell indítanunk a feladatkezelőt. A feladatkezelőt a Ctrl + Shift + Esc (Windows 7) Ctrl + Alt + Del (Windows XP) billentyűkombinációval hívhatja.

Érdekel bennünket az „alkalmazások” fül, amely a számítógépen jelenleg futó összes alkalmazást mutatja. Megkeressük a lefagyott alkalmazást (az én példámban ez egy program), és kattintson a → Feladat befejezése lehetőségre. Általában ez elég!! Nem segített → 3. pont.
3. Mi a teendő, ha a program továbbra is lefagy? Lépjen a következő lapra → „Folyamatok”. A tény az, hogy a számítógépén futó programokhoz valamilyen folyamat vagy folyamatok kapcsolódnak. És a jelenleg lefagyott programnak is megvan a maga folyamata, amit a program parancsikonjára jobb gombbal kattintva és a → „Tulajdonságok” menüpontot választva megtudhat. Az én példámban ez a folyamat → VideoConverter.exe

A folyamatok fület kiválasztva keresse meg a folyamatot (esetemben ez a „VideoConverter.exe”), és kattintson a → „folyamat befejezése” lehetőségre, vagy a biztosság kedvéért → kattintson a jobb gombbal a folyamatra → „Folyamatok vége”

Így a szokásos Windows-eszközök segítségével megoldható a probléma egy lefagyott programmal. A lefagyott programot harmadik féltől származó programokkal is bezárhatja, például a programmal

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óra épülő nagy informatikai rendszerek optimalizálása terén szerzett sokéves tapasztalatai 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ű munkájára szánják, aktívan támogatják a fórum felhasználói, akik ezekben a bejegyzésekben megnyugvást és okot találnak arra, hogy mindent úgy hagyjanak, ahogy van. Kellő türelemmel és tudással tetszőleges számú felhasználóhoz eljuttathatja a rendszert. A lassú működés és az 1C lefagyása többé nem lesz probléma.

Gyakorlatból: Az optimalizálás legegyszerűbb módja az 1C v7.7 (az 1C 8.1, 1C 8.2, 1C 8.3 optimalizálása nehezebb feladat, mivel az alkalmazás 3 hivatkozásból áll). Egyidejűleg 400 felhasználóra növelni meglehetősen tipikus projekt. 1500-ig már nehéz és 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 kisebb részének frissítésével, például RAM hozzáadásával. Meg kell jegyezni, hogy a berendezésnek továbbra is szerver alapúnak kell lennie, különösen a lemez alrendszernek. Az elavult lemezalrendszer csak az egyik oka annak, hogy az 1C lassan működik.

A többfelhasználós munkavégzés fő korlátja az 1C-ben a reteszelő mechanizmus. Általában az 1C blokkolása, és nem a szerverberendezés akadályozza meg, hogy sok ember dolgozzon az adatbázisban. A probléma megoldásához keményen kell dolgoznia, és meg kell változtatnia az 1C zárolási logikáját - táblázatosról soralapúra csökkenteni. Ekkor például egy dokumentum feladása csak egyet blokkol, és nem az összes dokumentumot a rendszerben.

1. ábra: 1C blokkoló sor a PerfExpert megfigyelő rendszerben, az 1C felhasználók információival, egy konfigurációs modullal és egy adott kódsorral ebben a modulban.

Az 1C reteszelő mechanizmus cseréje nagyon összetett technológia. Nem mindenki tud kihozni egy ilyen trükköt, és számukra csak egy út maradt - a struktúra 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 végrehajtási ideje erősen összefüggő mutatók. Például, ha egy dokumentum feladása 15 másodpercet vesz igénybe, akkor nagy számú felhasználó esetén nagy a valószínűsége annak, hogy az átvitel során valaki más megpróbálja feladni a bizonylatot, és blokkolva vár. Ha a végrehajtási időt legalább 1 másodpercre növeli, akkor a művelet 1C blokkolása jelentősen csökken.

A blokkolás szempontjából veszélyesebb a csoportos feldolgozás, amely hosszú ideig tarthat, és egyben 1C blokkolást okozhat. Minden olyan feldolgozás, amely megváltoztatja az adatokat, például a dokumentumok sorrendjének visszaállítása vagy kötegelt feldolgozása, zárolja a táblákat, és megakadályozza, hogy más felhasználók feladjanak dokumentumokat. Természetesen minél gyorsabban hajtják végre ezeket a feldolgozásokat, annál rövidebb a blokkolási idő, és annál könnyebb lesz a felhasználók számára.

A csak olvasható műveleteket végző súlyos jelentések szintén veszélyesek lehetnek a zárolás 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 műveleteket 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: A működő szerver terhelése a konfigurációs modulok tekintetében, 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 alapszabálya, hogy a dokumentumfeldolgozás 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 megadni 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 indítá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 jelentkezik. Meg kell jegyezni, hogy ezek komoly szervezetek szerverei, amelyek támogatásában és konfigurálásában magasan képzett rendszergazdák egész osztályai vesznek részt.

A helytelen szerverkonfiguráció fő oka a rendszergazdák attól való félelme, hogy bármit is módosítanak egy futó szerveren, és a szabály: „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 gondatlan rendszergazdára á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 van, 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 összezavarják a szerverbeállításokat, mintsem hogy segítsenek. Ilyen bizonytalan helyzetben az adminisztrátornak még kevésbé van kedve bármit megváltoztatni egy valahogyan működő szerveren.

Első pillantásra a kép tiszta - mindent optimalizálnia kell, ami lelassítja az 1C szerver működését. De képzeljük el magunkat egy ilyen optimalizáló helyébe – mondjuk 1C 8.1 8.2 8.3 UPP é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.

Először is nézzük meg, mi történik a szerveren – mi van akkor, ha egy különösen független vírusirtó teljes körű vizsgálatot végez a rendszeren. Az ellenőrzés azt mutatja, hogy minden rendben van - a szerver 100%-os terhelés alatt van, és csak az sqlservr folyamat által.

Gyakorlatból: az egyik junior adminisztrátor saját kezdeményezésére bekapcsolta az automatikus frissítést a szerveren, a Windows és az SQL boldogan frissült, majd a frissítés után hatalmas lassulás kezdődött az 1C felhasználók munkájában, vagy az 1C egyszerűen lefagyott.

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ést körülbelül 20 alkalmazáskiszolgáló-kapcsolat generálja.

Gyakorlatból: hurokba került egy olyan program, amely egy weboldalon azonnal frissíti az adatokat, és ahelyett, hogy 4 óránként frissített volna, folyamatosan, szünetek nélkül, erősen terhelve a szervert és blokkolva az adatokat.

A helyzet további elemzése nagy nehézségekbe ütközik. Azt már megtudtuk, hogy a terhelés közvetlenül az 1C-től származik, de hogyan érthetjük meg, hogy pontosan mit csinálnak a felhasználók? Vagy legalábbis kik ők. Jó, ha egy szervezetben 10 1C felhasználó van, akkor csak átnézheti őket, és megtudhatja, mit csinálnak most, de esetünkben ötvenen vannak, és több épületben vannak elszórva.

Az általunk vizsgált példában a helyzet még nem bonyolult. 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, hiszen szeretnek egész nap chatelni, amiatt, hogy semmi dolgozik, több, mint dolgozik). Ez az eset hangsúlyozza egy olyan szerver naplózási rendszer szükségességét, amely mindig megőrzi a szerver működésének fő paramétereit, é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 szerver állapotfigyelő rendszert. 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 találtunk olyat, ami megfelelő szinten megoldotta volna ezt a problémát, í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ási folyamatainak automatizálását és racionalizálását. A programot az 1C-vel való szoros integráció, az észrevehető többletterhelés hiánya és 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: Az adminisztrátor azt mondja: "A programozók a hibásak, akik a konfigurációt írták." És a szekér, ahogy mondani szokás, még mindig ott van. Ennek eredményeként az 1C lelassul, lefagy vagy lassan működik.

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ések meghozatalát és pénzt takarít meg. A termék egyaránt alkalmas kisméretű 1C:Enterprise IS-ekhez - 50 felhasználóig, és rendszerekhez - 1000 felhasználótól. 2015 júliusa óta teljesítményfigyelés PerfExpert 1C:Compatible tanúsítványt kapott, átment a tesztelésen Microsoft és nemcsak az 1C rendszerek, hanem más, a alapú információs rendszerek teljesítményproblémáinak megoldásában is segít MS SQL Server (Axapta, CRM Dynamics, Doc Vision és mások).

Ha tetszett az információ, további teendőket javasolt:

- Ha önállóan szeretne foglalkozni az 1C teljesítmény technikai problémáival (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) és egyéb információs rendszerek, akkor Almanachunkban egy egyedi lista található a műszaki cikkekről (A blokkolások és a holtpontok, a CPU és a lemezek nagy terhelése, az adatbázis-karbantartás és az 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 kérést, és a lehető leghamarabb felvesszük Önnel a kapcsolatot.

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 lassan, esetenként elfogadhatatlanul lassan működnek. 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ájl módban. Próbáljuk meg kijavítani ezt a hiányosságot.

A miénkben már érintettük a lemezalrendszer teljesítményének az 1C sebességére gyakorolt ​​hatását, de 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ájladatbázissal való munkavégzést jelenti hálózaton keresztül, ahol a felhasználó egyik PC-jét szerverként használják, vagy dedikált fájlszervert, amely egy hagyományos, legtöbbször szintén olcsó számítógépen alapul.

Az 1C orosz nyelvű erőforrásainak egy kis tanulmánya azt mutatta, hogy ezt a problémát gondosan elkerülik, ha problémák merülnek fel, általában ajánlott kliens-szerver vagy terminál módra váltani. Szinte általánosan elfogadottá vált, hogy a felügyelt alkalmazások konfigurációi a szokásosnál sokkal lassabban működnek. Az érvek általában „vasak”: „A számvitel 2.0 csak elrepült, és a „trojka” alig mozdult Természetesen ezekben a szavakban van némi igazság, úgyhogy próbáljuk meg kitalálni.

Erőforrás-felhasználás, első pillantásra

A tanulmány megkezdése előtt két célt tűztünk ki magunk elé: kideríteni, hogy a felügyelt alkalmazásalapú konfigurációk valóban lassabbak-e, mint a hagyományos konfigurációk, és mely konkrét erőforrások befolyásolják elsődlegesen a teljesítményt.

A teszteléshez két Windows Server 2012 R2-t, illetve Windows 8.1-et futtató virtuális gépet vettünk, amelyek 2 magot kaptak a gazda Core i5-4670-ből és 2 GB RAM-ot, ami nagyjából 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 több konfigurációját választottuk ki 2.0.64.12 , amely aztán frissítve lett 3.0.38.52 , minden konfiguráció elindult a platformon 8.3.5.1443 .

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

Készek vagyunk hallani a szokásost: „miért tették hozzá ezt a háromhoz”, de ne kapkodjuk. 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ázisok karbantartására. Az adatbázisokat kiszolgáló (olvasd frissítő) szakosodott cégek munkatársai 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 információs bázis tesztelése, javítása. Talán a név kegyetlen viccet játszott, ami valahogy azt sugallja, hogy ez egy hibaelhárítási eszköz, de az alacsony teljesítmény is probléma, és az átstrukturálás és az újraindexelés, valamint a táblatömörítés jól ismert eszközök az adatbázisok optimalizálására bármely DBMS-adminisztrátor számára. . Ellenőrizzük?

A kiválasztott műveletek alkalmazása után az adatbázis meredeken „fogyott”, még a „kettőnél” is kisebb lett, amit soha senki nem optimalizált, és a RAM-fogyasztás is enyhén 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 általában megnő, a „három” alap nagyobb, mint a „két” alap. Ez azonban nem fontosabb, ha a második verzió megelégedett 150-200 MB RAM-mal, akkor az új kiadáshoz 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 az egyik legfontosabb paraméter a hálózati alkalmazások számára, különösen, mint például az 1C fájl módban, amelyek jelentős mennyiségű adatot mozgatnak a hálózaton keresztül. A legtöbb kisvállalkozás hálózata olcsó 100 Mbit/s-os berendezésekre épül, ezért a tesztelést az 1C teljesítménymutatók összehasonlításával kezdtük meg a 100 Mbit/s és 1 Gbit/s hálózatokban.

Mi történik, ha elindít egy 1C fájladatbázist a hálózaton keresztül? A kliens meglehetősen nagy mennyiségű információt tölt le ideiglenes mappákba, különösen, ha ez az első, „hideg” indítás. 100 Mbit/s-nál várhatóan a csatorna szélességével szembe fogunk futni, és a letöltés jelentős időt vehet igénybe, esetünkben körülbelül 40 másodpercet (a grafikon felosztásának költsége 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ó váltás jelentősen felgyorsíthatja a „hideg” és „meleg” programbetöltést, és az értékek arányát tiszteletben tartják. Ezért úgy döntöttünk, hogy az eredményt relatív értékekben 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 bármilyen hálózati sebesség mellett kétszer gyorsabban tölt be, a 100 Mbit/s-ról 1 Gbit/s-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 nem optimalizált "trojka" adatbázisok között.

Azt is ellenőriztük, hogy a hálózati sebesség milyen hatással van a működésre nehéz üzemmódokban, például csoportos átvitelek során. Az eredményt relatív értékekben is kifejezzük:

Itt érdekesebb, hogy a „három” optimalizált alapja egy 100 Mbit/s-os hálózatban ugyanolyan sebességgel működik, mint a „kettő”, a nem optimalizált pedig kétszer rosszabb eredményt mutat. Gigabiten az arányok változatlanok, az optimalizálatlan „három” is fele olyan lassú, mint a „kettő”, az optimalizált pedig harmadával elmarad. Ezenkívül az 1 Gbit/s-ra való áttérés lehetővé teszi a végrehajtási idő háromszoros csökkentését a 2.0-s kiadás és a felére a 3.0-s kiadás esetében.

A hálózati sebesség mindennapi munkára gyakorolt ​​hatásának értékeléséhez használtuk Teljesítménymérés, előre meghatározott műveletek sorozatát hajtja végre az egyes adatbázisokban.

Valójában a mindennapi feladatoknál a hálózati átvitel nem jelent szűk keresztmetszetet, az optimalizálatlan „három” csak 20%-kal lassabb, mint a „kettő”, és az optimalizálás után nagyjából ugyanilyen gyorsabbnak bizonyul - a vékonykliens módban való munka előnyei nyilvánvalóak. Az 1 Gbit/s-ra való átállás nem ad előnyt az optimalizált alapnak, az optimalizálatlan és a kettő pedig gyorsabban kezd működni, kis különbséget mutatva egymás között.

Az elvégzett tesztekből kiderül, hogy az új konfigurációknál a hálózat nem jelent szűk keresztmetszetet, és a felügyelt alkalmazás a megszokottnál is gyorsabban fut. Javasolhatja az 1 Gbit/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, az új konfigurációk lehetővé teszik a hatékony munkát akár lassú 100 Mbit/s-os hálózatokban is.

Akkor miért lassú az 1C? Majd tovább vizsgáljuk.

Szerverlemez alrendszer és SSD

Az előző cikkben az 1C teljesítményének növekedését értük el azáltal, hogy adatbázisokat helyeztünk SSD-re. Lehet, hogy a szerver lemezalrendszerének teljesítménye nem megfelelő? 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 nagy 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 hagyományos lemezekből készült tükör.

Tehát SSD kell a szerveren? Erre a kérdésre a legjobban a tesztelés adható meg a válasz, amit mi is hasonló módszerrel hajtottunk végre, a hálózati kapcsolat mindenhol 1 Gbit/s, az eredményt relatív értékekben is kifejezzük.

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

Lehet, hogy egyesek számára meglepőnek tűnik, de a szerveren lévő SSD nincs hatással az adatbázis betöltési sebességére. A fő korlátozó tényező itt, ahogy az előző teszt is megmutatta, a hálózati átviteli sebesség és a kliens teljesítménye.

Térjünk át az újrakészítésre:

Fentebb már megjegyeztük, hogy a lemez teljesítménye még nehéz üzemmódokban is elégséges, így az SSD sebessége sem befolyásolja, kivéve az optimalizálatlan alapot, amely az SSD-n utolérte az optimalizáltot. 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 feladatokban hasonló a kép:

Csak a nem optimalizált adatbázis részesül az SSD-ből. Természetesen vásárolhat SSD-t, de sokkal jobb lenne megfontolni az adatbázis időben történő karbantartását. Ne feledkezzünk meg a szakasz töredezettségmentesítéséről sem a szerveren lévő információs bázisokkal.

Klienslemez alrendszer és SSD

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

Ugyanakkor tudnia kell, hogy egy olyan munkaállomáshoz, ahol egy vagy két információs adatbázissal aktív munkát végeznek, egy hagyományos, sorozatgyártású HDD teljesítményerőforrása bőven elegendő. Az SSD vásárlása felgyorsíthat bizonyos folyamatokat, de radikális felgyorsulást a mindennapi munkában nem fog észrevenni, 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 okozhatja a programok lelassulását.

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 összesen 1 GB 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 adatbázist.

Első ránézésre nem is olyan rossz minden, a program visszafogta az étvágyát, és jól belefért a rendelkezésre álló memóriába, de ne felejtsük el, hogy a működési adatok iránti igény nem változott, szóval hova tűnt? Reset lemezre, gyorsítótárra, swapra stb., 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 lemezmemória lassítására kerülnek.

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

Amint látjuk, a rendszer aktívan használja a hálózatot az adatok fogadására és a processzor a feldolgozás során elenyésző, 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 rendkívül kényelmetlennek bizonyult, jelentős késéssel és aktív hozzáféréssel megnyitva a könyvtárakat és magazinokat. Például az áruk és szolgáltatások értékesítése napló megnyitása körülbelül 20 másodpercet vett igénybe, és mindvégig nagy lemezaktivitás kísérte (piros vonallal kiemelve).

Annak érdekében, hogy objektíven értékeljü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ő adatbázis betöltési sebességét, a második adatbázis betöltési sebességét és a csoportos újrafutást az egyik adatbázisban. . Mindkét adatbázis teljesen azonos, és az optimalizált adatbázis másolásával jöttek 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ó munka kényelmetlennek bizonyul. A 2 GB memóriával rendelkező konfigurációkat minimálisan megfelelőnek kell tekinteni. Ugyanakkor ne feledjük, hogy esetünkben „üvegházi” feltételek jöttek létre: tiszta rendszer, csak az 1C és a feladatkezelő futott. A való életben egy munkahelyi számítógépen általában nyitva van egy böngésző, egy irodai programcsomag, fut egy vírusirtó stb. stb., tehát az adatbázisonkénti 500 MB-tól, plusz némi tartaléktól kell kiindulni, hogy nehéz műveletek során nem találkozik memóriahiánnyal és a termelékenység éles csökkenésével.

CPU

Túlzás nélkül a központi processzort nevezhetjük a számítógép szívének, hiszen végső soron ez dolgozza fel az összes számítást. Szerepének kiértékeléséhez egy másik tesztsorozatot is végrehajtottunk, ugyanúgy, mint a RAM esetében, kettőről egyre csökkentve a virtuális gép számára elérhető magok számát, és a tesztet kétszer végeztük el 1 GB és 2 GB memóriával.

Az eredmény meglehetősen érdekes és váratlan volt: egy erősebb processzor meglehetősen hatékonyan vette fel a terhelést, ha erőforráshiány volt, a többi időben 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 a processzort nem annyira magának az alkalmazásnak a adatainak kiszámítása, hanem a rezsiköltségek kiszolgálása terheli: további input/output műveletek stb.

következtetéseket

Szóval, miért lassú az 1C? Először is, ez a RAM hiánya ebben az esetben a merevlemezre és a processzorra esik. És ha nem ragyognak a teljesítményükben, 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, de a „három” istentelenül lassú.

A második helyen a hálózati teljesítmény áll, a lassú 100 Mbit/s-os csatorna igazi szűk keresztmetszetté válhat, ugyanakkor a vékonykliens mód a lassú csatornákon is elég kényelmes működést képes fenntartani.

Akkor érdemes odafigyelni a lemezmeghajtóra, az SSD vásárlása nem valószínű, hogy jó befektetés, de a meghajtó cseréje egy modernebbre jó ötlet. A merevlemezek generációi közötti különbséget a következő anyagból lehet felmérni: .

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

Reméljük, hogy ez az anyag segít gyorsan megérteni a „miért lassú az 1C” kérdést, és a leghatékonyabban és többletköltségek nélkül megoldani.

• Címkék: