05.04.2017 |

Klaster 1C 8.3

Prije svega, nakon instaliranja 1C klastera, prethodno je bilo potrebno stvoriti radne tokove. Kako se ispostavilo, procesi klastera počeli su se automatski stvarati ovisno o opterećenju baze podataka.

Probni rad pozadinskih zadataka glavne baze podataka učinio je 1C klaster beskrajno preopterećiti rphost.exe, a dodatni rphost.exe nije želio biti stvoren ni na koji način. Pretražujući postavke, sve je postalo jasno.

Maksimalna memorija tokom rada je količina memorije koju radni tokovi mogu koristiti zajedno. Morate biti vrlo oprezni prilikom postavljanja parametra, mjerenih u bajtovima. Ako postavite pogrešnu vrijednost (nedovoljnu za normalan rad korisnika), korisnici će dobiti pogrešku "Nema dovoljno slobodne memorije na 1C poslužitelju." Ovu grešku možete dobiti i kada je memorijska kvota završila na serveru 1C.

Sigurno korištenje memorije po pozivu - omogućava vam kontrolu potrošnje memorije tokom poziva poslužitelja, mjereno u bajtovima. Ako poziv koristi više memorije nego što se očekivalo, ovaj poziv bit će završen unutar 1C klastera bez ponovnog pokretanja tijeka rada (rphost.exe). Prema tome, "gubitnik" koji je uputio poslužiteljski poziv izgubit će sesiju s 1C bazom bez utjecaja na rad drugih korisnika.

u jednom GB - 1073741824 bajta, dakle u 2 GB - 2147483648 bajtova

Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom - ako se ovaj parametar premaši, poslužitelj u 1C klasteru će prestati prihvaćati nove veze.

Broj IB-a po postupku- omogućuje vam izoliranje baza podataka o tijekovima rada. Prema zadanim postavkama, trenutni klaster 1C bio je postavljen na "8", ali nekoliko sati sam poslužitelj je bio vrlo nestabilan, korisničke sesije su prekinule. Nakon izolacije svake baze podataka (vrijednost - „1“), problemi su nestali.

Broj veza po postupku - Zadana vrijednost je "128". Budući da trenutna baza ima veoma veliko opterećenje pozadinskih zadataka (izračunavanje logistike, analiza cijena, analiza konkurenata itd.), Odlučeno je da se broj smanji na "25".

Postavke samog 1C klastera su se takođe malo promijenile:

Nivo tolerancije greške- ovo je broj radnih poslužitelja koji istovremeno mogu uspjeti, a to neće dovesti do hitnog isključivanja korisnika. Usluge izrade sigurnosnih kopija pokreću se automatski u onoj mjeri koja je potrebna kako bi se osigurala zadana tolerancija greške. U stvarnom vremenu, aktivna usluga se replicira u pripravnosti.

Način dijeljenja opterećenja - postoje dvije opcije za parametar: "Prioritet u performansama" - memorija servera se troši više i performanse su veće, "Prioritet u memoriji" - klaster 1C štedi memoriju poslužitelja.

Server 8.3 karakterizira redizajnirani interni kod, mada može izgledati "izvana" da je modificirani 8.2.

Poslužitelj je postao više "automatski podesiv", dio parametara poput broja radnih procesa se više ne izrađuje ručno, već se izračunava na temelju opisa zahtjeva tolerancije kvarova i pouzdanosti.

To smanjuje vjerojatnost pogrešnih postavki poslužitelja i snižava zahtjeve za kvalifikaciju administratora.

Razvijen je mehanizam za uravnoteženje opterećenja, koji se može koristiti ili za poboljšanje performansi sistema u cjelini ili korištenja novog načina „uštede u memoriji“, koji omogućava rad sa „ograničenom memorijom“ u slučajevima kada korištena konfiguracija „voli jesti memoriju“.

Stabilnost pri korištenju velike količine memorije određuje se novim parametrima radnog servera.

Posebno je zanimljiva opcija „sigurne potrošnje memorije po pozivu“. Za one koji imaju lošu predstavu o tome šta je - bolje je ne trenirati „produktivno“. Parametar „Maksimalna količina memorije radnog toka“ omogućava da tokom „overflowa“ ne uruši čitav tok rada, već samo jedan „sa gubitnikom“. "Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom" omogućava vam blokiranje novih veza čim se prijeđe ovaj prag memorije.

Preporučujem izoliranje radnih tokova od info baza, na primjer, specificiranje parametra „Broj IS po procesu \u003d 1 ″. S nekoliko visoko opterećenih baza podataka, to će smanjiti međusobni utjecaj kako u pouzdanosti tako i u performansama.

Poseban doprinos stabilnosti sistema predstavlja „trošenje“ licenci / ključeva. U 8.3. Postalo je moguće koristiti „softverski menadžer licenci“ koji liči na „aladin“ menadžera. Cilj je mogućnost odvođenja ključa u zasebnu mašinu.

Provodi se kao još jedna "usluga" u cluster manageru. Možete koristiti, na primjer, „besplatni“ laptop. Dodajte ga u klaster 1c 8.3, kreirajte zasebnog upravitelja na njemu pomoću usluge "usluga licenciranja". Možete da ubacite hardverski hasp ključ u laptop ili aktivirate softverske licence.

Najveći interes za programere trebao bi predstavljati "Zahtjevi za imenovanje funkcionalnosti".

Uslovi za dodeljenu funkcionalnost 1s

Dakle, na laptopu sa sigurnosnim ključem, kako ne biste pokrenuli korisnike na cluster poslužitelju, morate dodati „zahtjeve“ za objekt zahtjeva „Povezivanje klijenta s IB“ - „Ne dodijeli“, tj. Sprečite radne procese ovog poslužitelja da obrađuju veze klijenta.

Od još većeg interesa je mogućnost pokretanja „samo pozadinskih poslova“ na radnom klaster poslužitelju bez korisničkih sesija. Tako se visoko opterećeni zadaci (kôd) mogu prenijeti u zasebni stroj. Štaviše, na jednom je računalu moguće pokrenuti jedan pozadinski zadatak „zatvaranje mjeseca“ putem „Vrijednosti dodatnog parametra“, a na drugom pozadinski zadatak „Ažuriranje indeksa punog teksta“. Dopunjavanje se ukazuje na „Vrijednost dodatnog parametra“. Na primjer, ako kao vrijednost navedete BackgroundJob.CommonModule, rad proizvodnog poslužitelja u klasteru možete ograničiti na samo pozadinske zadatke s bilo kojim sadržajem. Vrijednost BackgroundJob.CommonModule.<Имя модуля>.<Имя метода> - navesti određeni kod.

Klaster 1C 8.2

Sesije vam omogućavaju da uravnotežite radno opterećenje i toleranciju grešaka u upravljanoj aplikaciji.

Upravitelj klastera sada je složeniji. Neke se funkcije sada mogu odvojiti u zaseban proces i čak staviti na drugi radni server klastera. To vam omogućava da uravnotežite opterećenje servera.

Tolerancija greške poslužitelja 8.2 postiže se:

Spremanje podataka o sesiji korisnika.
Korisnik više nije vezan za tijek rada.
Rezervacija radnih procesa u klasteru.
Mora postojati nekoliko radnih tokova, uključujući suvišne
Rezervacija klastera

Rezervni klaster je označen, kada su spojeni, navedeni su u priključnom nizu

To osigurava kontinuirani rad!

Kada se prekine fizička veza klijenta s klasterom (čistač je izvukao kabel, mrežna oprema je isključena, provajder je imao problema), nije potrebno ponovno se povezati s bazom podataka i započeti sve radove ponovo. Nakon vraćanja fizičke veze, korisnik može nastaviti s radom od mjesta na kome je prekinuta.

Ako je potrebno održavanje klasterskih računala, oni se mogu isključiti ispravno tijekom rada bez sprečavanja korisnika da rade s bazom podataka.

Ako bilo koji poslužitelj u klasteru ne uspije, rad korisnika neće se zaustaviti, automatski će se prenijeti u sigurnosne kopije i / ili radne procese izrade sigurnosnih kopija. Za korisnike će ovaj prijelaz biti neupadljiv.

Ako se jedan od radnih tijekova klastera sruši, korisnici koji su spojeni na njega automatski će se prebaciti u druge ili u pripravnosti. Takav će prelaz biti nevidljiv i za korisnike.

Često druge usluge - terminalni poslužitelj, SQL server itd. - rade s 1C: Enterprise serverom na uređaju. I u nekom trenutku 1C: Enterprise poslužitelj, tačnije rphost radni tijek, pojede više memorije nego što je planirano ili svu memoriju. To dovodi do usporavanja drugih servisa i zombija na poslužitelju. Da bi se izbjegle takve situacije, potrebno je konfigurirati automatsko ponovno pokretanje radnih procesa 1C: Enterprise poslužitelja

Odluka

1. Otvorite administrativnu konzolu 1C Enterprise servera;
2. Proširite stablo centralnog poslužitelja na klastere i odaberite klaster koji nas zanima. U primjeru postoji samo jedan klaster;
3. Otvorite svojstva odabranog klastera i pogledajte sljedeći obrazac

Server 1C: Svojstva klastera poslužitelja 8.3

Analizirajmo primer prikazan na slici:

Interval ponovnog pokretanja - vrijeme nakon kojeg će se postupak rfosta prisilno pokrenuti. Prije nego što se proces zaustavi, pokreće se novi rphost proces na koji se prenose sve veze, a tek tada će stari proces biti dovršen. Ovo neće uticati na rad korisnika. Interval je naveden u sekundi, u primjeru 24 sata.

Dozvoljena memorija - količinu memorije u kojoj tijek rada može raditi bez problema. Glasnoća je navedena u kilobajtima, na primjeru je vrijednost 20 gigabajta (u stvari, cifra je prevelika i trebate započeti s određenog sustava, ali prosječna je vrijednost 4 GB). Čim memorija zauzeta tijekom rada premaši navedenu vrijednost, odbrojavanje započinje.

Interval prekoračenja memorije - nakon što se tajmer pokrene, nakon što prekorači dopuštenu količinu memorije, broji određeno vrijeme, započinje novi tijek rada na koji se prenose sve veze, stari postupak se označava isključenim. Interval je naveden u sekundi, u primjeru 30 sekundi.

Procesi gašenja mogu se zaustaviti - vrijeme nakon kojeg će se zaustaviti tijek rada koji je označen kao isključen; ako je navedena vrijednost 0, proces neće biti dovršen. Interval je naveden u sekundi, u primjeru 60 sekundi.

Nakon primjene postavki ne možete ponovo pokrenuti uslugu poslužitelja, oni se primjenjuju dinamički.

Ukupno

Tako smo postavili automatsko ponovno pokretanje radnih procesa 1C: Enterprise poslužitelja i dobili smo stabilniji sistem; ako dođe do curenja memorije, zaustavit će se specifična sesija.

U nekim se situacijama možete poigrati s postavkama i spriječiti mogući pad sustava ako se naprave greške.

Server 8.3 karakterizira redizajnirani interni kod, mada može izgledati "izvana" da je modificirani 8.2.

Poslužitelj je postao više "automatski podesiv", dio parametara poput broja radnih procesa se više ne stvara ručno, već se izračunava na temelju opisa zahtjeva zadataka za tolerancijom grešaka i pouzdanost.

Razvijen je mehanizam za uravnoteženje opterećenja, koji se može koristiti ili za povećanje ukupnih performansi sistema ili korištenje novog načina „uštede u memoriji“, koji omogućava rad sa „ograničenom memorijom“ u slučajevima kada korištena konfiguracija „voli jesti memoriju“.

Stabilnost pri korištenju velike količine memorije određuje se novim parametrima radnog servera.

Posebno je zanimljiva opcija "sigurne potrošnje memorije po pozivu". Za one koji imaju lošu predstavu o tome šta je - bolje je ne trenirati „produktivno“. Parametar "Maksimalna količina memorije radnog tijeka" omogućava vam da "nadjačate" cijeli tijek rada tijekom "prelijevanja", ali samo jednu sesiju "s gubitnikom". "Količina memorije radnog tijeka na koju se poslužitelj smatra produktivnom" omogućava vam blokiranje novih veza čim se prijeđe ovaj prag memorije.

Najveći interes za programere trebao bi predstavljati "Zahtjevi za imenovanje funkcionalnosti".

Od još većeg interesa je mogućnost pokretanja „samo pozadinskih poslova“ na radnom klaster poslužitelju bez korisničkih sesija. Tako se visoko opterećeni zadaci (kôd) mogu prenijeti u zasebni stroj. Pored toga, na jednom je računalu moguće pokrenuti jedan pozadinski zadatak „zatvaranje mjeseca“ kroz „Vrijednost dodatnog parametra“, a na drugom pozadinski zadatak „Ažuriranje indeksa punog teksta“. Na primjer, ako kao vrijednost navedete BackgroundJob.CommonModule, rad proizvodnog poslužitelja u klasteru možete ograničiti na samo pozadinske zadatke s bilo kojim sadržajem. Vrijednost BackgroundJob.CommonModule ..- naznačit će specifičan kôd.

Jasno je da nema smisla ponavljati dokumentaciju. Ali ako neko savjetuje razumno, proširit ću članak.

Ispis (Ctrl + P)

U ovom članku pregledavam glavne aktivnosti koje je potrebno obaviti za povećanje performansi 1C u verziji 1C klijent-poslužitelj:

Povećanje hardverskih kapaciteta.
Konfiguriranje 1C: Enterprise Server
Podešavanje SQL servera
Optimizacija koda i algoritama u 1C.

1. Povećanje hardverskog kapaciteta

Minimalni zahtevi za računarima koji su dostavljeni na sertifikaciju kompaniji „C“ za dobijanje logotipa „Kompatibilno! Sistem programa 1C: Enterprise "su napisani

Performanse 1C poslužitelja: poduzeće u velikoj mjeri ovisi o frekvenciji procesora, a za poslužitelj baze podataka karakteristike računala moraju zadovoljiti zahtjeve Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Konfiguriranje 1C: Enterprise poslužitelja

Upute za postavljanje proizvodnih poslužitelja s tehnološkom platformom 1C: Enterprise mogu se pregledati na ITS disku

U verziji 8.3 dodano je nekoliko novih parametara u konfiguraciji proizvodnih poslužitelja:

Maksimalna memorija tokom rada. Postavka vam omogućava podešavanje količine memorije koja može biti zauzeta svim radnim procesima ovog klastera na ovom radnom poslužitelju.
Sigurno korištenje memorije po pozivu. Podešavanje vam omogućuje ograničenje količine memorije koja će biti zauzeta prilikom upućivanja poslužiteljskog poziva na ovom proizvodnom poslužitelju.
Broj sigurnosti informacija po procesu i broj veza po procesu. Ova podešavanja omogućuju vam neizravno upravljanje brojem radnih procesa na ovom proizvodnom poslužitelju.
Menadžer za svaku uslugu. Postavljanje vam omogućava pokretanje svake usluge upravljanja klasterima kao zaseban proces.

3. Podešavanje SQL servera

Značajka podešavanja Microsoft Sql servera u cilju povećanja performansi može se vidjeti na ITS disku

Koristeći Plan održavanja u odjeljku za upravljanje, morate izvršiti sljedeće planirane zadatke za povećanje produktivnosti:

Defragmentacija indeksa i ažuriranje statistika trebalo bi raditi svakodnevno, jer ako je fragmentacija indeksa\u003e 25%, to dramatično smanjuje performanse poslužitelja.
Defragmentacija i ažuriranje statistika - vrši se brzo i ne zahtijeva isključenje korisnika. Takođe se preporučuje raditi svakodnevno.
Potpuna ponovna deksidacija - vrši se s blokiranjem baze podataka, preporučuje se to raditi najmanje jednom sedmično. Naravno, nakon potpunog ponovnog dexeksiranja, odmah se vrši defragmentacija indeksa i ažuriranje statistika.

3.1 analiza stupnja fragmentacije indeksa

Prekomjerna fragmentacija indeksa stvara probleme velikim operacijama I / O. Nakon izvođenja intenzivnih operacija izmjene podataka u tablicama baze podataka, vrijeme izvršavanja upita i operacija izmjene podataka se povećava.

To je zbog činjenice da se tijekom takvih operacija indeksi modificiraju, što dovodi do njihove rascjepkanosti i povećanja broja operacija ulaza / izlaza prilikom korištenja indeksa u procesu čitanja i pisanja podataka.

Za efikasnu upotrebu indeksa Potreban je Microsoft SQL Server

Redovno reindeksirajte tablice baze podataka naredbom DBCC DBREINDEX ( table_name ) .
Redovno defragmentirajte indekse baze podataka pomoću naredbe DBCC INDEXDEFRAG (ime_ baze podataka, table_name index_name) .

Izbor načina za rješavanje ovog problema ovisi o intenzitetu operacija za izmjenu tablica baze podataka.

MS SQL Server 2005 predstavio je nove alate za kontrolu ovog parametra.

Funkcija dinamičke kontrolne tablice sys.dm_db_index_physical_stats vraća postotak fragmentacije u stupcu avg_fragmentation_in_percent. Ako vrijednost u ovom stupcu prelazi 25%, preporučuje se defragmentirati ovaj indeks radi vraćanja izvornih parametara performansi. Skeniranje velikih raspona podataka koji su uobičajeni u aplikacijama za skladištenje podataka i izvještavanje mogu imati koristi od smanjene fragmentacije indeksa.

Upotreba ovih podataka može značajno smanjiti opterećenje sustava i izbjeći nepotrebnu defragmentaciju onih indeksa za koje nije potreban.

3.2 Korištenje fizičke memorije veće od 2 GB u Microsoft SQL Serveru

Microsoft SQL Server 2000 Standardno izdanje i Microsoft SQL Server 2005 Workgroup Editionmogu koristiti do 2 GB fizičke memorije koja se dinamički raspoređuje i oslobađa ovisno o radnom opterećenju. Sa porastom volumena baze podataka, ova količina RAM-a postaje nedovoljna za učinkovito predmemoriranje podataka i održavanje performansi na prihvatljivoj razini.

3.3 Smanjenje veličine dnevnika transakcija Microsoft SQL Server

Izvođenje intenzivnih operacija radi izmjene podataka info baze dovodi do povećanja veličine datoteka s podacima i dnevnika transakcija. U nekom trenutku stari unosi u dnevnik transakcija postaju nepotrebni za oporavak baze podataka i mogu se izbrisati, čime se oslobađa prostor za nove unose. Ako ne blagovremeno izbrišete stare zapise dnevnika transakcija, nakon nekog vremena datoteka dnevnika transakcija može zauzeti sav slobodni prostor na disku i rad s bazom podataka postat će nemoguć.

Da biste smanjili veličinu datoteke dnevnika, prvo morate izbrisati neaktivne zapise dnevnika transakcija pomoću naredbe BACKUP LOG, a zatim pomoću naredbe DBCC SHRINKFILEsmanjite veličinu datoteke dnevnika transakcija. Slijed naredbi koje se izvršavaju u Upitni analizator, kao što slijedi:

BACKUP LOG Ime baze podataka SA TRUNCATE_ONLY

DBCC SHRINKFILE(Transaction_Journal_File_Name)

3.4 Premještanje TEMPDB baze podataka na drugi veći pogon.

TEMPDB je sistemska baza podataka Microsoft SQL Server, koja pohranjuje privremene tablice koje su kreirali i sam poslužitelj i korisnici. Ova se baza podataka rekreira svaki put kada ponovno pokrenete Microsoft SQL Server. Veličina ove baze podataka prema zadanim postavkama je neograničena i automatski se povećava, ako je potrebno, u dijelovima od 10% trenutne veličine TEMPDB. Međutim, korisnik ove parametre može nadjačati. Prema zadanim postavkama minimalna veličina ove baze podataka koja se postavlja kada se pokrene Microsoft SQL Server, određuje se veličinom baze podataka MODEL. Dnevnik transakcija automatski se briše u ovoj bazi podataka, a brišu se samo neaktivni unosi dnevnika transakcija.

Kada 1C: Enterprise 8 radi u režimu klijent-poslužitelj, privremene tablice se široko koriste . Pored toga, TEMPDB koristi Microsoft SQL Server prilikom postavljanja upita pomoću izraza. GRUPA PO, UNION, Različita itd.

U procesu 1C: Enterprise 8, moguće je značajno povećanje veličine TEMPDB baze podataka. Ako veličina diska na kojoj se nalazi TEMPDB baza podataka nije dovoljna, rad 1C: Enterprise 8 možda neće uspjeti.

Ako se ovaj problem javlja redovito, preporučuje se premještanje TEMPDB-a na drugi veći pogon.

Ova se operacija može izvesti na sljedeći način:

1. odrediti logička imena datoteka baze podataka TEMPDB (stupac "IME" rezultata postupka). Da biste to učinili, pokrenite sljedeću naredbu u Query Analyzeru:

UPORABI tempdb GO EXEC sp_helpfile GO 2. promijeni lokaciju datoteka TEMPDB baze podataka naredbom ALTER BATABASE. Da biste to učinili, pokrenite sljedeći niz naredbi u Analizatoru upita: UPORABITE master GO ALTER DATABASE tempdb MODIFY FILE (NAME \u003d tempdev, FILENAME \u003d "New_Disk: \\ New_Catalog \\ tempdb.mdf") PROMIJENITE DATABASU tempdb MODIFY FILE (NAME \u003d templog, FILENAME \u003d "New_Drive: \\ New_Directory \\ templog.ldf") GO 3. Ponovo pokrenite Microsoft SQL Server.

4. Optimizacija koda i algoritama u 1C

4.1 Optimizacija upita

Značajan dio problema koji vode do suboptimalnog rada s upitima može se otkriti analizom konfiguracijskog koda i strukture metapodataka. Postoji lista tipičnih pogrešaka u kodu i strukturi podataka, čije su posljedice dobro proučene i lako predvidljive. Analiza koda pomoću ove liste omogućuje vam rješavanje većine problema s izvedbom upita bez uranjanja u detaljne tehničke informacije (tekst upita u SQL-u, plan upita itd.).

Glavni razlozi neaptimalnog rada upita dijagnosticiranih na razini konfiguracijskog koda i strukture metapodataka smatraju se na ITS disku:

podupitnica se pridružuje
veze na virtualne tablice
neusklađenost indeksa i upita za upite
koristeći logički ILI u uvjetima
koristeći podupite u stanju pridruživanja
primanje podataka putem tačke iz polja složene vrste
filtriranje virtualnih tablica bez korištenja parametara

4.2 Korišćenje merenja performansi

1C: Enterprise 8 omogućava vam uklanjanje pogrešaka i mjerenje performansi za kôd na ugrađenom jeziku koji se može izvršiti i na klijentu i na poslužitelju. Značajka mjerenja performansi za bazu podataka klijenta-poslužitelja u 1C: Enterprise 8 je ta što se rezultati mjerenja performansi kombiniraju u jednu datoteku. Oni uključuju podatke o napretku izvršavanja koda na ugrađenom jeziku kako na klijentu tako i na poslužitelju. Da biste dobili takvo mjerenje, dovoljno je pokrenuti poslužitelj 1C: Enterprise 8 u načinu uklanjanja pogrešaka (koristeći tipku naredbenog retka / debug ), a u Konfiguratoru u pravo vrijeme samo uključite način mjerenja performansi.

Način mjerenja performansi u 1C: Enterprise 8 omogućava vam uspješno optimiziranje performansi klijent-poslužiteljskih aplikacija. Da biste izvršili ovu optimizaciju, dovoljno je izvršiti samo nekoliko koraka, nakon čega analizirate rezultate mjerenja performansi i nastavite sa poboljšanjem koda na ugrađenom jeziku.

Više informacija o korištenju mjerenja performansi može se pronaći na ITS disku.

Prije nego što započnete rad na optimizaciji sustava, uvijek je potrebno dobiti početnu procjenu performansi pomoću „integrirane procjene performansi sistema APDEX“.

4.3 Alat za preradu koda

Funkcije refaktoringa koda implementirane u konfiguratoru platforme 8.3.5, 1068. kao i funkcije automatske pretvorbe modalnih metoda i odjeljaka kodova prikazane su na slici 1.

Slika 1 Alat za preusmjeravanje koda u konfiguratoru

Programeri platforme objašnjavaju potrebu za tim alatima činjenicom da kôd aplikativnih rješenja treba biti jasan, pogotovo kada na konfiguraciji radi grupa od nekoliko programera. Tada se programski kod lako održava i mijenja.

Pobjeda nije bila laka ....
Pokušaću sve detaljno opisati, mada je prošlo dosta vremena. Nadam se da će informacije koje sam prikupio pomoći administratorima sistema i pustiti me da pišem za razmišljanje.
Baze sam prenio na 1 jagodicu i dodijelio korisniku 8.3 agent - nije pomoglo ...

Putovao sam našim Runetom nadaleko i pronašao dva zanimljiva članka sa kojima predlažem da se upoznate.

Prvi put prilično detaljan test između dvije platforme: PS je srednja verzija i dvojezgarni poslužitelj. Ispada da su prilično zanimljive točke na koje sam isticao dok sam radio u drugim kompanijama.
efsol.ru/articles/tuning-1c.html

Drugi se odnosi na testove 1c na virtualnim mašinama. U njemu sam upravo vidio razlog kašnjenja u pokretanju konfiguracije:
efsol.ru/articles/performance-comppare-1c.html

Nakon obilaska okolo nedelju dana i isprobavanja nekoliko tehnika, nisam mogao riješiti problem prvim lansiranjem. Ali primijetio sam jednu zanimljivu regularnost ... Kada tanki klijent radi, pokretanje drugog sistema se događa gotovo odmah. Promijenio je postavke broj sigurnosnih podataka po procesu: 8 (temelji na 8.3 do sada 5). Kao rezultat, budući da je server prestao gubiti vrijeme stvarajući RPHOST prilikom ulaska u trag. bazu i ostatak potrošio je samo na iskrcavanje konfekcije sa jagodice. Smanjilo je vrijeme početka druge baze za 10-7 sekundi.

Ova opcija, u principu, potpuno mi odgovara s obzirom na to da 7-10 korisnika radi sa svakom bazom podataka, config je stalno u RPHOSTe, a vrijeme poziva je 4-8 sekundi zajedno s autentifikacijom.

Ako imate problema što se baza ne otvara često, onda kao opciju mogu ponuditi da podnesem malo reg. zadatak za pozivanje korisnika u svaku bazu podataka i konfigurirajte ponovno pokretanje usluge navečer (bilo putem servisa ili intervala ponovnog pokretanja). Mislim da bi to trebalo pomoći, mada ovdje počivamo na dostupnosti licence, tako da moramo razmišljati)))

Ali još jedan neugodan trenutak izbio je, na jednom od foruma dobio sam ovaj odgovor:
Offtop. Imate li CORP licence?

Napredne karakteristike servera nivoa 1C: Enterprise 8.3 CORP u odnosu na 64-bitni poslužitelj na nivou PROF:
* sigurna potrošnja memorije po pozivu;
* broj informacione sigurnosti po procesu;
* Količina memorije radnih procesa na koju se server smatra produktivnom;
* maksimalna količina memorije za radne procese;
* strategija uravnoteženja (memorija, performanse);

Korištenje gore navedene funkcije upotrebom proizvoda „1C: Enterprise 8. Server License (x86-64)“ na nivou PROF, odnosno koji u nazivu nemaju oznaku KORP, je nezakonito.

Odlučio sam da razjasnim sa momcima iz tri različite kompanije da li znaju da postoji platformi corp. Na koji je odgovor dobio u obliku: prsta koji se vrti u hramu i slanja na forum 1c. I ispod je odgovor iz podrške 1:

1) \u003e\u003e\u003e Želio bih pojasniti razlike između 8.3 corp platforme i 8,3 prof.
https: //partners.v8.1c.ru/forum/message/1301566#m _...
www.1c.ru/news/info.jsp?id\u003d16733

Zapravo, kada koristite PROF platformu, prema licenci, možete koristiti samo zadane postavke klastera.

Ako naiđete na probleme sa zadanim postavkama klastera (nema memorije, nemogućnost ažuriranja konfiguracije itd.), Tada
ovo je ponašanje greška (bilo na platformi ili na ovom aplikacijskom rješenju).
Zahtjev s konkretnim primjerima za stvaranje žalbi za ispravak.
U trenutku kada je greška ispravljena, pismeno odobrenje (potpisano od strane direktora 1C CJSC) za upotrebu funkcionalnosti Corp.
2) \u003e\u003e\u003e Molimo pojasnite, tj. postoje dvije platforme 8.3?
Ne. Platforma nije trenutni trenutak sama.
Međutim, pravo na korištenje KORP funkcionalnosti pojavljuje se samo nakon kupnje odgovarajuće licence.
Trenutno ni softverska kontrola ove licence.
Stoga je licenca CORP više pravni koncept.

Iskreno, ne vjerujem u razne vrste zavjera, ali kada tvrtka ima gotovo 100% monopol na tržištu malih i srednjih poduzeća, pojavljuju se različite misli.
"Pojavit će se ažuriranje neke vrste konfiguracije za izvještavanje, koja će zahtijevati ažuriranje platforme na kojoj će se već provoditi kontrola programa ... I tada ćete nam platiti (1) u cijelosti od ... djece."
P.S. Želim pojasniti da se moj poslužitelj temelji na 2008r2 i da mogu postojati razlike od 2012. Svejedno, kernel se detaljno sadi tamo, a hiper-v 3.0 je također odrastao u zekama. Ali kako oni kažu "Živo je !!!" i rad 1c na virtualnim mašinama nije samo moguć, već je i dobrodošao. Na izlazu imamo 30 korisnika 8,2 i 20 korisnika 8,3. Sretno svima vama, budite tolerantniji i nikada ne odustajte)))