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 tud használni
Ha nincs elég memória, a szerver nem tud új kapcsolatokat fogadni, vagy lefagy, ha az aktuális munkamenetnek több memóriára van szüksége
www.viva64.com/ru/k/0036
2) Nézd meg a "Működő szerver beállításai" beállításokat, esetleg rossz beállítások vannak beállítva. Nekem is ugyanez volt a problémám, és a szerver folyamatosan összeomlott. A beállításaim a mellékletben vannak. 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ázis méretét, 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ó illeszkedik a rendelkezésre álló RAM mennyiségéhez.
PostgreSQL telepítve Linuxra, 3 GB RAM, 3 CPU mag.
Szerver 1C8: 11 GB RAM, 5 CPU mag
4 alap, egyenként körülbelül 1 GB (feltöltve a dt-be)

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

Korábban én is PostgreSQL-t használtam, de közben problémákba ütköztem, amikor a PostgreSQL adatbázissal dolgoztam, és nemrég váltottam MS SQL-re.

A szervered nem rossz az adatbázisoknak. A PostgreSQL használatához nagyon jól kell konfigurálnia. Ha kicsik az alapok, sok hangolási hiba "megbocsátható". Amikor csak elkezdtük az 1C + PostgreSQL implementálását, akkor is nagyon gyakran voltak problémáink az adatbázissal (gyakran lefagytak, lassan működött). A PostgreSQL-t jobb Linuxon használni, mint Windowson. Jómagam nem vagyok adatbázis-specialista, az adatbázisszerver felállításához az 1Sbit szakembert fogadtuk fel, aki beállította nekünk és ezután nem volt probléma a munkában.

Tanács:
Ne fukarkodjon az adatbázisaival, kérjen fel egy adatbázis-szakértőt, aki beállítja Önnek. Egy ember nem lehet mindenben szakértő.

1) mióta ellenőrizted magát az adatbázist és újraindexelted? VÁKUUM és REINDEX
2) Régóta végezte az adatbázis tesztelését és javítását az 1C használatával?
3) az adatbázis naplófájlja egy külön HDD-re van áthelyezve?
4) A HDD erősen terhelt?

Fontolja meg az MS Sql-re való váltást, gyakran "szinte" 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 segíteni Skype-ban: tisartisar

Béreljen adatbázis-szakértőt

Miért váltottunk MS SQL-re:
UT konfigurációt használunk, és a hónap végén néha olyan hibák adódtak, amelyeket sehogyan sem lehetett megoldani. Ha átvisszük az adatbázist fájl módba, és elkezdjük a hónap zárását, akkor minden rendesen bezárult, költségszámításkor ugyanaz az adatbázis került fel a PostgreSQL szerverre, hibák történtek. Abban a pillanatban fél év lemaradásban voltunk a záró hónapokban a lebegő hibák előfordulása miatt. 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ő árak kerekítése sem működik megfelelően PostgreSQL-en. Valójában az 1C PostgreSQL-en végzett munkája támogatott, de továbbra is ajánlott az MS SQL használata.
Emiatt az MS SQL-re való átállás mellett döntöttek. az 1C stabilitása 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 eszközökkel
3) egy cikk a biztonsági mentés és a 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.

A zárak hatása az 1C: Enterprise 8 teljesítményére

A gilev csapata évek óta dolgozik a teljesítményproblémákon, és sikeresen oldja meg az olyan problémákat, mint például a zárolási várakozások és a holtpontok megszüntetése.

Az alábbiakban e problémák megoldásában szerzett tapasztalatainkat ismertetjük.

Blokkolási problémák észlelése az 1C-ben

A többjátékos teljesítményével kapcsolatos problémák nem feltétlenül rossz kódnak vagy rossz hardvernek köszönhetők. Először is meg kell válaszolnunk a kérdést: milyen teljesítményproblémák léteznek és mi okozza őket?

Lehetetlen manuálisan nyomon követni több száz felhasználó tevékenységét, szükség van egy olyan eszközre, amely automatizálja az ilyen információk gyűjtését.

Sok eszköz létezik, de szinte mindegyiknek van egy nagyon jelentős hátránya - az ár.

De van kiút - elemzési eszközként választjuk

A problémát MS SQL Serveren fogjuk kivizsgálni, ezért a következő szolgáltatásokra lesz szükségünk ebből a készletből:

1. Hosszú kérések nyomon követése, elemzése(a beállításról itt olvashat bővebben) - szükséges a subd hosszú műveleteinek meglétének felméréséhez.

Valójában jelenlétük ténye lehetővé teszi, hogy azt mondjuk, hogy teljesítményproblémák vannak, és a problémák az 1C konfigurációs kód soraiban rejlenek, amelyeket a szolgáltatás fontossági sorrendbe állít. Először a lista elején található problémákat kell megoldani. A problémasorok ilyen megoldásai hozzák a legnagyobb hatást, pl. lesz a leghasznosabb és leghasznosabb a rendszer felhasználói számára.

(további információ itt) lehetővé teszi annak felmérését, hogy a hosszú (hosszú) kérések idejét valóban a zárolásra való várakozás okozza-e, vagy más okai vannak (nem optimális kód, túlterhelt hardver, stb.) A szolgáltatás megmutatja, hogy miért a várakozási kérés, nevezetesen a blokkolt erőforrás és az, aki blokkolta. Azok. megértjük a blokkoló problémák jelenlétét és okait.

3. Az 1C és MS SQL szerver holtpontjainak elemzése(a beállításról itt olvashat bővebben ) - lehetővé teszi, hogy bonyolultabb, erőforrásvárással járó helyzeteket is kiértékelhessünk, amikor több résztvevő már „elfogta” az erőforrások egy részét zárral, és most várnia kell, várnia kell mindegyikre más, mert nem tudják felszabadítani az elfoglalt erőforrásokat a szomszédok által blokkolt egyéb erőforrások rögzítésének befejezése előtt.

Általában egy ilyen nehéz helyzetben nem lehet kézzel kitalálni, ilyen szolgáltatásra van szüksége.

4. Berendezések terhelésének ellenőrzése(a beállításról itt olvashat bővebben ) segít megválaszolni a kérdéseket - hány felhasználó van a rendszerben, van-e zárjuk, hány zár, bírja-e a hardver a terhelést?

A szolgáltatások beállítása nagyon egyszerű, de még ha kérdései vannak, akkor is vannak!

A fenti eszközök segítségével objektív információkkal rendelkezünk a rendszer teljesítményéről. Ez lehetővé teszi számunkra, hogy helyesen értékeljük a helyzetet, és megfelelő intézkedéseket javasoljunk.

Valójában minden teljesítményproblémáról információt kapunk, és pontosan meg tudjuk válaszolni az olyan kérdéseket, mint „hány probléma van a rendszerben”, „pontosan hol fordulnak elő”, „az egyes problémák milyen gyakorisággal pontosan”, „mely probléma jelentős. és amelyek kisebbek”. Azok. látjuk az összes előfeltételt, amely a probléma okát képezte.

A szolgáltatások lehetővé teszik, hogy jelentősen javítsa a problémák előfordulási feltételeinek megértését anélkül, hogy manuálisan belemerülne olyan dolgokba, mint az információs bázis DBMS szintű adattárolási struktúrája, a zárszerkezet stb.

Ennek eredményeként képet kapunk a mért teljesítményről

- lekérési idő (természetesen a problémakérések súly szerinti rangsorolása (a kérés ideje az erre a kérésre érkező hívások száma szerint);

- várakozási idő a zárakra;

Így elindítottuk a Block Expectation Analysis szolgáltatást

A felső táblázatban a szolgáltatás a letiltás „áldozatainak” listáját mutatja, figyelembe véve az „elvárások súlyosságának” összsúlyát.

Az alsó táblázatban minden áldozat esetében a „erősen versenyképes erőforrásért való küzdelem” egy vagy több résztvevője szerepel, ahol a blokkon felmerült az elvárás.

Az alsó táblázatban nyissa meg az egyik „időtúllépés” esemény tényének részletét. Mint például a képen.

A „bűnös” sort kiemelve látni fogjuk, hogy a _Reference64 tábla lett a szűk keresztmetszet, és a fürtözött indexen probléma volt az „ismeretlen” területtel. Talán a jövőben átnevezzük „táblázatra”, mivel ez a viselkedés jellemző a blokkolási terület növelésére / bővítésére.

Az „áldozatot” mutató sor azt mutatja, hogy melyik kód volt a helyzet túsza, és nem tudott mindent blokkolni, csak a „kulccsal” sor (ez a táblázatban a minimális adatblokkoló terület).

Ezt a problémát "helyesen" és "könnyen" oldhatja meg.

Nehezebb követni a helyes utat - valójában át kell írnia a kódot, minimalizálva az ilyen helyzetek előfordulásának valószínűségét.

Az egyik tényező, bármilyen furcsán is hangzik, az időtartam csökkenése.

A tranzakció időtartamát csökkentheti:

1. az algoritmus átírása

2. a lekérdezés átírásával (a gyorsabb lekérdezés csökkenti a blokkolások lehetőségét a táblákon lévő összetett tranzakciókban, amelyek néha nem is szerepelnek a lekérdezésben!)

2.1 a hiányzó fedőindex hozzáadásával (néha az index nemcsak felgyorsítja a lekérdezést, hanem csökkenti az adatok olvasási területét is, ami csökkenti a blokkolás valószínűségét)

3. a tranzakció során feldolgozott adatok mennyiségének csökkentésével (a lineáris sebesség mellett a zárolás eszkalációjára is emlékezünk)

4. az egyes folyamokon belüli berendezések termelékenységének növelése

Kérjen végrehajtási időt

1) különböző felhasználók párhuzamosan dolgozhatnak különböző adatokkal
2) a különböző felhasználóknak szigorúan egymás után kell dolgozniuk ugyanazokkal az adatokkal

Azonban optimalizálhatja a zárak használatát, ezáltal csökkentve a teljes várakozási időt.

A zárak működése (ez a bekezdés elhagyható)

A zárakat egy speciális SQL Server modul, a Lock Manager kezeli. Feladatai közé tartozik:

• Zárak készítése és felszerelése;
• zárak eltávolítása;
• zár eszkalációja;
• a zárak kompatibilitásának meghatározása;
• holtpontok (deadlocks) megszüntetése és még sok más.

Amikor egy felhasználó kéri az adatok frissítését vagy olvasását, a DBMS tranzakciókezelő átadja az irányítást a DBMS zárkezelőnek, hogy megtudja, a kért erőforrások zárolva vannak-e, és ha igen, akkor a kért zárolás kompatibilis-e az aktuális zárral. Ha a zárolások nem kompatibilisek, az aktuális tranzakció végrehajtása az adatok zárolásának feloldásáig késik. Amint az adatok rendelkezésre állnak, a zárkezelő beszerzi a kért zárolást, és visszaadja az irányítást a tranzakciókezelőnek.

A teljesítmény csökkenésének fő oka a blokkolás

A zárolási várakozás komoly teljesítményproblémát jelent többjátékos módban. És ez érthető is, mert növelik a műveletek várakozási idejét, és ezzel a válaszidőt is. Lehetséges azt mondani, hogy a zárakra való várakozás nem helyes és egy többfelhasználós rendszer hibája? Ez nem mondható el, hiszen maga az erőforrás-zárolási mechanizmus biztosítja az adatok integritását. A reteszelő mechanizmussal az egyidejű adatok SZEKVENCIÁLISAN ÍRódnak.

Különbség a szükséges és a redundáns zárak között

Amikor a felhasználó egy záron várakozó hibát jelez, az ő szemszögéből nézve mindig hiba, mert például zavarja a munkáját – megnő a munkája befejezésének ideje.

A tapasztalat egy egyszerű szabályt sugall, ha a kérés végrehajtási idejének több mint fele ténylegesen blokkolt erőforrásra vár, akkor meg kell nézni: lehet, hogy optimalizálni lehet néhány zárolást, csökkenteni az erőforrás blokkolási időt.

Itt, mint véletlenül, bevezetek egy definíciót:

Várakozás a blokkon egy olyan helyzet, amely akkor fordul elő, amikor két felhasználó egyszerre próbálja rögzíteni ugyanazt az adatot. Ebben az esetben az egyik felhasználó letiltásra kerül, vagyis meg kell várnia az első felhasználó tranzakciójának végét.

A tranzakció számítások és adatokkal végzett műveletek halmaza (a legszembetűnőbb példa egy dokumentum lebonyolításakor), amelyeket egészként hajtanak végre. A tranzakció bármely műveletének elmulasztása a teljes tranzakció törlését vonja maga után.

Így a többfelhasználós infobázisok felhasználói gyakran panaszkodhatnak, hogy ezek miatt a zárak miatt lehetetlen a munkavégzés, miközben valóban lehetnek olyan zárak a kódban, amelyekre ezen a helyen nincs szükség (redundáns).
És a konfigurációs kódban is előfordulhat, hogy ők maguk nem blokkolnak, például itt olvashat róluk http://kb.1c.ru/articleView.jsp?id=30 (a cikk a könyv egy töredéke P.S. Belousov, A.V. Ostroverh "1C: Enterprise: 8.0-8.1"). Egy egyszerű példát ajánlok a zárak közötti különbség magyarázatára:

Az 1C:Vállalati mód konfigurációjában hozzon létre két azonos számlát azonos termékösszetétellel. De mindenképpen adja meg a különböző átvételi raktárakat.
A csúsztatáskezelő kódhoz hozzá kell adni egy sort, amely egy üzenetet jelenít meg a képernyőn (vagy más kódot, amely 21 másodperccel késleltetheti a csúsztatási feldolgozás végrehajtását (a zárolási időtúllépés 20 másodperc után következik be, ha az alapértelmezett paraméterek) ).
Két dokumentum feladása.
Ha időtúllépés lép fel, és logikusan az áruk különböző raktárakba érkeznek, redundáns zárolások vannak az alkalmazásban. Az üzleti logika (gondoljuk a józan észt) itt ne legyenek zárak.
Ha most e két fuvarlevélben azonos raktárakat készítünk. Ekkor az egyidejű magatartási kísérlet eredményeként létrehozott zárak KÖTELEZŐ zárat eredményeznek és ez JÓ!

Azok. míg a számla módosítja a készlet egyenlegét, addig a másiknak várnia kell.

Természetesen ez az egyszerű példa is sok kérdést hagy maga után. Például, ha a dokumentumok egy szállítótól származnak, és a rajta lévő tartozás „költözik”. És ha nem csak a raktárban lévő maradványok költöznek, hanem több nyilvántartás, de különféle típusú dokumentumok.
De a legfontosabb kérdés az, hogy MILYEN ÜZLETI LOGIKÁBAN NEM LEHET BLOKKOLNI. Ki és hol írja elő ezt az üzleti logikát a zárral összefüggésben? De beszéljünk mindent sorban.

Túlzott - felesleges - zárolások, amelyekre nincs szükség az adatok integritásának biztosítása szempontjából, és egyben csökkentik a rendszer általános teljesítményét, növelve a teljes "tétlenségi" időt - a zárakra való várakozást.
A szükséges zárolás akkor következik be, ha két felhasználó ugyanazt az erőforrást (adatobjektumot) rögzíti. Ha a felhasználók nem átfedő erőforrásokkal dolgoznak, de várakozás van a zároláson, akkor a zárolás redundánsnak minősül.

A zárredundancia legérthetőbb kritériumai a következők:

1. Kölcsönös blokkolás;

2. A letiltás szintje (területe) magasabb a szükségesnél (a blokkolási szint emelésének speciális esete, az ún. eszkaláció);

3. A zárolási idő hosszabb, mint a zárobjektum „valódi” használata.

Miután információt kaptam a problémák csoportosításáról az 1C:Enterprise metaadatok kontextusában, javaslom, hogy elsősorban az objektumokra fordítsanak figyelmet:

• Állandók
• Utóbbi
• Számviteli nyilvántartások
• Felhalmozási nyilvántartások
• Információs nyilvántartások
• Számítási regiszterek

1) Egészen a közelmúltig volt egy jól ismert ajánlás, hogy ne írjunk semmit állandókba. Extrém esetben ezt egy felhasználó alól tedd meg, majd ne feledd, hogy amíg a felhasználó egy konstanst „ír”, nem csak ezt, hanem bármely más konstanst is, addig a többi felhasználó „várni fog”. Ezért különösen veszélyes a konstansok használata a vezetés kezelésénél. Az összes állandó értéke tárolva van V egy erőforrás.

Az ábra az SCP konfigurációs állandók fizikai helyét mutatja az MS SQL Server 2005 adatbázistáblájában.

Ez azt jelenti, hogy ha egy konstans blokkolva van, akkor az összes konstans blokkolva lesz. A DBMS a tábla ÖSSZES SORÁJÁT zárolja, azaz. minden állandóra.

A platform legutóbbi kiadásaiban azonban az állandók tárolása megváltozott. Most minden állandó egy külön táblázat. Azonban ne ragadd magad túl, ha több ezer táblát hozol létre, zárat kaphatsz a mesterbázison.

Figyelem, ha a konfigurációja már régóta létezik, akkor a konfigurátor tesztelése és javítása részben "átszervezéssel" módosíthatja a tárolási formátumot.

2) Ne használja a Sequence metaadat objektumot. Legalábbis az operatív magatartás közbeni mozgásoktól, nem operatív (kiegészítő magatartás) végrehajtásához. Tekintse meg, hogyan valósul meg az SCP legújabb verzióiban.

3) Ha a rendszer többfelhasználós módban hajtja végre a mozgások operatív rögzítését a számviteli nyilvántartásban, akkor javasolt:

• engedélyezze a felosztott összegek módot ehhez a regiszterhez;
• ne használjon regiszteregyenleg-ellenőrzést az üzemeltetési munka során.

4) A felhalmozási regiszterben olyan esetekben, amikor nincs szükség "működési" adatok beszerzésére, engedélyezheti az összesítések felosztását, ami növeli az adatrögzítés párhuzamosságát és gyorsítja a munka egészét. Óvatosan figyelje a méréseket, hogy a "maradványokat" a lehető legnagyobb részletességgel kapja meg a méréseken.

5) A platform által létrehozott néhány redundáns zártól csak a . A konfigurációk automatikus üzemmódjában a platform „átveszi” az erőforrások blokkolását. Az automata üzemmód gondtalan használatának ára az indextartományok határán való zárolás, üres asztal zárolása, záreszkaláció.

Ezek a zárak teljesen eltűnnek a tranzakcióban szereplő adatokból. Vagyis felügyelt módban futtatva ez a holtpont nem lehetséges.

Többször mondtam már, hogy „menedzselt blokkolás”, „felügyelt mód”. Meg kell értenie, hogy kétféle blokkolás létezik:
A DBMS-zárak automatikusan be vannak állítva DBMS-szinten a lekérdezések végrehajtásakor.
1C: A vállalati zárak automatikusan beállításra kerülnek az adatok írásakor (módosításakor), és mindig manuálisan az adatok beolvasásakor.

Egy aprólékos olvasó azt fogja mondani, hogy az 1C objektum- és nem objektumzárakra is osztódik, de most nem érintjük ezt a megközelítést.

De megjegyzem, hogy ez több követelményt támaszt az 1C szakember képesítésével és tapasztalatával szemben.

6) A hiányzó indexek (különösen az összetett lekérdezéseknél) általában a fő tényező a szükségesnél magasabb szintű zárolások előfordulásában. Azok. paradoxon, egyrészt azt mondtam, hogy a lekérdezés optimalizálása előtt azt mondtam, hogy először meg kell nézni a zárakat, most pedig azt mondom, hogy a zárolások optimalizálásához optimalizálni kell a lekérdezést. Mentségem van arra, hogy a konfiguráció áthelyezése felügyelt zárolásokra csökkenti a felesleges zárolásokat még az optimálistól eltérő lekérdezések esetén is. Ennek oka a tranzakciós elkülönítési szint csökkentése, ami viszont kevesebb okot ad a DBMS-zárkezelőnek a túlzott zárolás megszerzésére.

A túlzott zárolás fő okai (összefoglalva a fentieket)

- tervezési hibák
(a párhuzamosság mértékét az határozza meg, hogy „milyen finomra vannak szeletelve az adatok”: párhuzamos munkavégzés lehetséges a táblázat két sorával, az egysoros munka csak szekvenciálisan megy végbe)
(hibák a metaadatok használatában: konstansok, sorozatok rögzítése, operatív elszámolás a számviteli nyilvántartásokban)
- túlzott blokkolás az automatikus üzemmód hibája miatt (platform - DBMS link).
— szuboptimális lekérdezési teljesítmény
(például egy táblázat szkennelésekor a teljes táblázat blokkolva van - redundáns terület
és a blokkolási idő növekszik - többletidő, további blokkolások növelik a blokkolás eszkalációjának valószínűségét)

Mint látható, a zárak optimalizálásának feladata „sokrétű”. A problémát kiváltó „kontextust” a lehető legjobban reprezentálni kell. Milyen forrásokon, milyen kódon. Mennyire reális szükség van erre a zárra, vagy felesleges.

Egy gyereknek és egy felnőttnek torokfájása van. Amikor az orvos felteszi a kérdést: "Mi a baj?", a gyermek az orvosra néz, és sikoltozni fog (bízz bennem, tudom), míg a felnőtt rámutat a betegség tüneteire. Ez a látszólagos különbség az orvost a probléma azonosításának különböző módszereihez irányítja.
Gyermek esetén az orvosnak meg kell felelnie sok teszteket, adatokat gyűjt, kombinál, elemzéseket végez, és csak ezután tesz javaslatokat. Míg egy felnőttnél feltesz néhány kérdést, és mivel a kezdeti adatok száma kicsi, a probléma elemzésére és azonosítására fordított idő lényegesen kevesebb lesz. Ennek eredményeként az ajánlások sokkal hamarabb megjelennek.

Használja szolgáltatásainkat, és több lehetősége lesz a probléma elemzésére és ingyenes megoldás megtalálására!

Hogyan lehet bezárni a 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.

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

Először is nyugodjon meg, és olvassa el a cikket. Abszolút mindenki volt már ilyen helyzetben, minden programot ember ír, tehát nem tökéletes. 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 meg kell találnia, hogy a program valóban lefagy-e, és a fent leírt tünetek mindegyike megfigyelhető-e, vagy csak elindított egy erőforrás-igényes alkalmazást vagy programot, amelytől a rendszer nem akad 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.

- Kiabálj, üsd a billentyűzetet (ez biztosan nem az ő hibája).
- Nem kell újra megpróbálni futtatni ugyanazt a programot, vagy még inkább más programokat - ez csak súlyosbítja a helyzetet.
- Húzza ki a tápfeszültséget, kapcsolja ki, indítsa újra (ez egy extrém módszer).

Mi a teendő, ha a program lefagy

1. Mielőtt áttérne a radikálisabb módszerekre, próbálja meg bezárni a tálcán a jobb gombbal a leakasztott programra kattintva, és kiválasztja a megfelelő elemet.
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.

Az "alkalmazások" fül érdekel minket, itt jelen pillanatban az összes számítógépen futó alkalmazás megjelenik. Olyan alkalmazást keresünk, amely lefagyott (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ó bármely programhoz bizonyos folyamatok kapcsolódnak. És a jelenleg lefagyott programnak is megvan a maga folyamata, amit úgy tudhat meg, hogy jobb gombbal a program parancsikonjára kattint, és kiválasztja a → "Tulajdonságok" menüpontot. Az én példámban ez a folyamat → VideoConverter.exe

A Folyamat fület kiválasztva keresse meg a folyamatot (esetemben ez a „VideoConverter.exe”), és kattintson a → „Folyamat befejezése” elemre, vagy, hogy biztos legyen benne, → kattintson a jobb gombbal a folyamatra → „Folyamat 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ó programok, például a program segítségével is bezárhatja

Az informatikusok számára jól ismert, hogy az „1C-t lógó” felhasználók panaszának számos oka van. A helyes „diagnózis” felállításához – a probléma azonosításához és elemzéséhez – azt reprodukálni kell, mert a reprodukálhatatlan problémát általában szinte lehetetlen megoldani. Az 1C fagyasztás tüneteinek megértése után megtesszük az első lépést egy hatékony rendszer felé.

Nagyon hosszú rendszerindítás

Normális jelenség, ha egy nehéz konfigurációt először egy felhasználó alatt indítanak el, miután az IB-t hozzáadták a számítógép adatbázisainak listájához. Az első futtatás során a konfiguráció gyorsítótárazásra kerül. A második és az azt követő indításoknak gyorsabbnak kell lenniük.

A rendszer hosszú ideig tartó indítása problémákat jelezhet a konfiguráció architekturális megvalósításában. A konfiguráció nagy részét a keretrendszer csak a kívánt metaadat-objektum első elérésekor olvassa be. A hosszú indítás nagyszámú metaadat-objektum használatának valószínűségét jelzi (sok hívás különféle általános modulokhoz, feldolgozás stb.).

Meg kell jegyezni, hogy az első alkalommal, amikor bármely modul szövegéhez hozzáfér, az összeállításra kerül. Ez a folyamat is időt vesz igénybe, ami különösen akkor szembetűnő, ha sok modul van. Így a lassú indítás problémáját a konfiguráció módosítása (optimalizálása) oldja meg, aminek az a célja, hogy letiltja a rendszer indításakor végrehajtott összes opcionális algoritmus végrehajtását.

Előfordulhat, hogy a konfiguráció az indításkor adatokat próbál olvasni az internetről. Megnöveli a rendszerindítási időt is.

Nagyon hosszú nyitva tartás

Az űrlapok hosszan tartó megnyitásának okai lehetnek:

1. Számos vezérlőelem az űrlapon – időt fordítanak az űrlap létrehozására és az űrlapelemek helyének összekapcsolására;
2. Algoritmusok végrehajtása az űrlap inicializálása során. Előfordulhat, hogy az űrlap létrehozásakor bizonyos feltételeket ellenőriznek és/vagy a kapcsolódó objektumokat kiolvassák az adatbázisból.

Az első problémát az űrlap egyszerűsítésével "kezeljük". Például a vezérlőelemek egy része külön formába helyezhető, ami még kényelmesebb lehet a felhasználó számára. Például, ha az űrlapon a "Város", "Utca", "Ház" stb. címmező szerepel, akkor jobb, ha a címet külön űrlapon szerkeszti.

A második problémát az űrlap létrehozása és megnyitása során végrehajtott műveletek elemzésével, valamint ezen algoritmusok optimalizálásával oldjuk meg. Lehet, hogy az algoritmusok egy része már elavult, néhány pedig egyszerűsíthető és optimalizálható, például az adatbázisban lévő adatokhoz való hozzáférés megszüntetése vagy minimalizálása.

Interaktív műveletként vegye figyelembe a felhasználó azon kísérletét, hogy értéket jelöljön ki egy űrlapelemben. Erre válaszul a rendszer "gondolkozik valamin". Ez a következő okok miatt fordulhat elő:

1. Az adott műveleten futó algoritmusok megvizsgálják vagy kiszámítják a kapcsolódó adatokat, amelyek befolyásolják az értékválasztási módot;
2. Az érték kiválasztásához megnyitott kiválasztási űrlap az összes objektumot beolvassa az adatbázisból az inicializáláskor.

Az első probléma megoldásához használja a "Teljesítménymérést", keressen erőforrás-igényes algoritmusokat és optimalizálja azokat.

A második probléma gyakran megoldható a kiválasztási űrlap megvalósításának egyszerű elemzésével. Például győződjön meg arról, hogy a dinamikus lista tulajdonság "Dinamikus adatolvasás" értékre van állítva, a "Main Table" tulajdonság megfelelően van beállítva, és a lista megvalósítása nem használ nyilvánvalóan erőforrás-igényes algoritmusokat.

Vannak olyan helyzetek is, amikor a kiválasztási űrlap megnyitásakor minden kapcsolódó adat beolvasásra kerül az adatbázisból (például a "Nómenklatúra" kiválasztási űrlap megnyitásakor a raktárakban lévő áruegyenleg kerül kiolvasásra). Általában nem ez a legjobb megoldás. A kapcsolódó adatokat legjobban aszinkron módon, az űrlap megnyitása után lehet beolvasni. Ez kevesebb kényelmetlenséget okoz a felhasználónak, mert. Az űrlap megjelenítése után a felhasználó némi időt tölt a megnyitott űrlap észlelésével, és ezt az időt a kapcsolódó adatok betöltésére fordíthatja.

Nagyon lassú válasz a frissítésekre

Az egyik triviális tünet azonban néhány rendszerproblémáról árulkodik: az 1C frissítés lefagy a biztonsági mentés indításakor. Ez főleg az interneten keresztüli frissítéskor fordul elő, és nagy valószínűséggel azt jelzi, hogy a konfigurációt hosszú ideje nem frissítették, és az egymásra gördülő kiadások lefagyást okoztak. Megelőzheti ezt a problémát, ha időben telepíti a frissítéseket, és ha találkozik vele, egyszerűen megszakíthatja a biztonsági mentési folyamatot. A konfigurátor elindítása után az adatbázis a normál módban végrehajtott változtatásokkal indul.

Meg kell jegyezni, hogy az 1C 8.3 a frissítések során leggyakrabban azért is lefagy, mert erőforrásigényesebb hardvert igényel, mint a platform korábbi verziói. Érdemes odafigyelni a RAM mennyiségére, és szükség esetén növelni - ez elvileg segít az "1C lefagy a konfiguráció frissítésekor" probléma megoldásában.

Tárgyak hosszú távú rögzítése/dokumentumok feladása

Ebben az esetben a "fényképkezelés" gyakorlatilag kizárt, mivel az okok nagyon sokfélék lehetnek, kezdve az objektumban található nagy mennyiségű adattal, a zárakra való várakozásig.

De ebben az esetben is ki lehet vázolni egy irányvonalat az elemzéshez.

A rögzítési idő jelentős változásának hiánya a napszakból vagy a felhasználók számából (durva, szubjektív becslés szerint) az objektum kódjában vagy adatmennyiségében jelentkező problémára utal. Az elemzéshez célszerű a „Teljesítménymérés” eszközt használni.

A rögzítési idő kardinális változása tisztázatlan függőségekkel a probléma megjelenésének statisztikai elemzését igényli, pl. teljesítményelemzés. A legegyszerűbb módja a naplóhasználat elemzése. További előny, hogy az 1C:Enterprise 8 platform támogatja a naplóadatok SQLite formátumú fájlba történő mentését. Ez lehetővé teszi, hogy SQL lekérdezéseket használjon a naplóadatok elemzéséhez. A naplóadatokból nagyon is ki lehet számítani az objektum írási idejét, mivel minden objektum írása egy tranzakcióban történik, és minden tranzakciónak saját azonosító száma van.

Ha a statisztikai elemzés eredménye azt mutatta, hogy az objektum rögzítési ideje a napszaktól függ, és nem a felhasználók számától, akkor elemezni kell az 1C szerver és az adatbázisszerver munkaterhelését. Lehetséges, hogy rutinfolyamatok futnak a szerveren, amelyek felesleges erőforrásokat foglalnak el.

Ha az objektumok írási ideje a felhasználók számától függ, akkor a problémák nagy valószínűséggel a kódban (esetleg a zárolásokra várakozva) vagy a hardver áteresztőképességében vannak. Megoldásukhoz az „1C: Technológiai szakértő” kompetenciával rendelkező szakembert kell bevonni, mivel nincsenek egységes szabályok az ilyen probléma megoldására.

Ha valamelyik program nem válaszol, akkor sem az egérre, sem a billentyűzetre nem reagál, és talán még a „program nem válaszol” felirat is megjelent, ezt hívják lefagyott programnak.

Néha megtörténik, hogy egy lefagyott program nem zavarja a munkáját, néha pedig éppen ellenkezőleg, egy lefagyott program miatt az egész operációs rendszer működése lelassulhat, mindenesetre meg kell oldani a problémát, valamit meg kell oldani. kész.

Mit ne tegyünk:

1) Húzza ki a dugót a konnektorból ez a legnagyobb hiba, amit ebben a helyzetben elkövethet. A számítógép hirtelen áramkimaradása sok stresszt okoz. Ez a tétel magában foglalja a számítógép kikapcsolását is a rendszeregységen található start gombbal, valamint a tápegység kapcsolójának megnyomásával történő kikapcsolását. Ezeknek a módszereknek a lényege ugyanaz, lekapcsolod az áramellátást.

2) Nyomja meg a reset gombot- ez a gomb a rendszeregység elején található, és az újraindítás kényszerítésére szolgál. Csak a legreménytelenebb helyzetekben szabad nyomni, amikor más módszerek nem segítenek.

3) Végezzen extra mozdulatokat- ha egy lefagyott program miatt az operációs rendszere nagyon lelassulna, akkor minden szükségtelen művelet csak tovább rontja a helyzetet. Felesleges műveletek alatt egy lefagyott program újraindításának próbálkozását értem (semmi esetre sem szabad ezt megtenni), bármilyen más program elindítását, a start menü vagy egy másik menü megnyitását. Ha a helyzet különösen kritikus, akkor ne csak mozgassa az egeret, mivel a kurzor lefagyhat, és nehezebb lesz megoldani a problémát.

4) Várjon nagyon sokáig- általában elegendő öt percet várni, hogy megértsük, hogy a program lefagyott, ha gyenge számítógépünk van, adjunk neki 15-20 percet, általában felesleges tovább várni.

5) Legyen ideges- a rendszeregység lábbal rúgása vagy a billentyűzet asztalhoz ütése nem segít a dolgon. Kifejezetten azért írtam ezt a bekezdést, mert ismeretlen okból néha ezt csinálják az emberek (valószínűleg a múltunk is befolyásolja, amikor a csőtévé nem akart működni, általában kézzel ütötték és segített). A számítógép nem egy csöves tévé, nem kell legyőzni.

Mit kell tenni

Meg kell próbálnia bezárni a programot, ha a jobb felső sarokban lévő keresztre kattintás és az alt + f4 kombináció nem segít, akkor a következőket kell tennie:

Nyomja meg a billentyűkombinációt a feladatkezelő hívásához:

Windows xp esetén „Ctrl + Alt + Del”.

Windows 7 esetén "Ctrl + Shift + Esc".

A feladatkezelőben lépjen az „Alkalmazások” fülre, ha a programja megjelenik a feladat részben, válassza ki, és kattintson a „Feladat befejezése” gombra. Ha nincs azonnali reakció, akkor nem kell újra megnyomnia ezt a gombot, csak várnia kell egy kicsit. Egy idő után megjelenik egy ablak, amely figyelmezteti, hogy az adatok elveszhetnek, kattintson a „Befejezés most” gombra. Példaként lásd a képernyőképet (elvégeztem a munkaprogramot, így más lesz a szöveged, de az elv ugyanaz).

Ha ez a módszer nem tudja leállítani a programot, kattintson a jobb gombbal a leakasztott programra, és válassza a "Go to Process" lehetőséget a legördülő menüből. Ön automatikusan a „Folyamatok” fülre kerül, a kívánt folyamat már ki van választva, csak a „Folyamat befejezése” gombra kell kattintania.

Ha a leakasztott program nem jelenik meg az "Alkalmazások" lapon, akkor lépjen a "Folyamatok" fülre, keresse meg a leakasztott program folyamatát, és fejezze be. A legegyszerűbb név szerint keresni egy folyamatot, lehet keresni a processzorterhelés mértéke alapján is, általában ez a százalék nagy egy függő alkalmazásnál.