Unul dintre serverele 1C, pe care le servesc, sau comportat foarte ciudat. utilizarea procesorului pe 1C masina de server a fost aproape întotdeauna 100%, chiar și atunci când nimeni nu este de lucru pe ea. Baza de date este stocată în MSSQL, acestea au fost relativ abundente, dar oamenii reali care au lucrat cu ei - un pic. În același timp munca nu este mai mare de utilizatori de 10-15 ani într-un mod foarte lent.
Acest server a atras atenția mea imediat, de îndată ce am început să lucrez cu el. Administratorul precedent luptat cu un rezultat de performanță, a câștigat 2 coșuri pentru raid extern separat în cadrul bazei de date MSSQL și temporare 1C date de utilizator, dar problema existentă de utilizare a procesorului nu este rezolvată, deși un pic roți neîncărcate, dar problema reală nu era în ele.
Pe server este situat la aproximativ 30-35 de baze, care au lucrat pentru 1-2 persoane și o pereche de baze au fost, în cazul în care au lucrat pentru 3-5 persoane la un moment dat. Tot ceea ce e cool cu serverul MSSQL pe un singur server cu un singur fier vechi și un kseonom 32 GB de agenți. În principiu, fierul a fost mai mult decât pentru aceste sarcini.
Primul lucru pe care am observat este faptul că procesorul a fost încărcat, chiar și pe timp de noapte, atunci când nimeni nu lucrează pe server. Am urcat în consola de administrare pentru a vedea ce încărcare a procesorului. Sa dovedit că aceste sarcini de fundal. Pentru cele mai multe baze nu au fost necesare și oprit toate inutile. Procesorul de sarcină a scăzut imediat la un nivel acceptabil de 60-70%, iar roțile în general, complet descărcate. Am uitat despre serverul în orice moment.
Din nou, a revenit la el, atunci când oamenii au început să se plângă foarte lent bazele 1C de lucru. Procesor la acel moment a fost aproape întotdeauna încărcată la 100%. sarcinile de fundal nenecesare au dispărut. A fost necesar să se ocupe mai îndeaproape, ceea ce este problema.
Noi înțelegem că este în procesorul va fi livrat rmngr.exe
încărcarea procesorului în mod egal și dat rphost.exe proces rmngr.exe. Rphost a fost configurat si optimizat anterior. Acestea sunt setările date funcționarea stabilă, fără necesitatea de a reporni serverul de luni de zile:
încărcare Rphost dată de sarcinile de fond rămase și ce să fac cu el, nu am știut. Și rmngr doresc să înțeleagă și să știe exact ce consumă timp CPU. În acest proces conține toate procesele managerului de cluster:
Este posibil să se împartă serviciile de management de cluster pentru o varietate de procese sistem rmngr.exe și de a determina ce fel de sarcină de serviciu pe procesor de BIP. Separarea poate include astfel de proprietăți în serverul de producție:
După ce a pus un Daw, agent de server 1C se reporni cu noile setări. După aceasta, în Task Manager va avea aproximativ 15 procese rmngr.exe cu diferite pid. A se vedea, procedeu care utilizează cel mai procesor și 1C Management Console, consultați administratorii de cluster vedea descrierea pid procesului.
În cazul meu a fost de serviciu înregistrările din jurnal. Pentru a afla, dublu-clic pe procesul cu pid necesar:
Pavel a făcut caz, a constatat frânele inculpatului. Am făcut capturi de ecran, atunci când a rezolvat problema, așa că am nici o sarcină.
jurnal de servicii 1C CPU
Am aflat ce dă exact sarcină excesivă pe server. M-am uitat la volumul de bușteni. Unele baze a ajuns la dimensiunea de 10-15 concerte. După curățare, serverul a devenit mult mai ușor pentru a încărca din nou a scăzut, dar undeva de până la 80-90%, iar timp de câteva luni, am uitat de server.
El a reamintit frânelor și a procesorului său de utilizare la 100%. Realizată de mai sus rezultatul operației nu este dat. Baz a fost un pic mai mult și a trebuit să se gândească la modul în care să descarce server. El a lucrat la 100%, chiar si in afara orelor, atunci când nu a fost un singur utilizator real. jurnal de service consumat 30-40% din timp CPU.
Am început să atenție lână Internet pe un anumit subiect și a găsit unele note. Au fost oameni care au acordat o atenție la volumul de muncă excesiv al înregistrărilor de serviciu jurnal. Ca o soluție alternativă la problema, au oferit pentru a reveni la o versiune mai veche de a face busteni LGF în loc de un nou LGD. Nu știu ce sa schimbat fundamental în Jurnalul de format jurnal de logare, dar pentru ca oaspeții să încerce, sarcina procesorului scade. Privind în perspectivă să spun că acest sfat mi-a ajutat.
Traduceți server de pe versiunea veche a exploatării forestiere în jurnalul
Orice setări sau soluții automate pentru traducerea înregistrărilor jurnal jurnal în formatul vechi LGF nu. Pentru a utiliza formatul vechi, trebuie să opriți serviciul 1C Agent: Server Enterprise. Apoi, du-te la folderul C: \ Program Files (x86) \ 1cv8 \ srvinfo \ reg_1541. selectați prin baza de date cu id-ul în care doriți să modificați formatul de fișier jurnal. Am avut o mulțime de baze, am fost leneș pentru a schimba manual fiecare format. Am ales baza cu cel mai mare volum și a schimbat formatul numai pentru ei.
Fiecare dosar are o bază de director 1Cv8Log. și în el 2 fișiere: 1Cv8.lgd și 1Cv8.lgd-jurnal. Acestea ar trebui să fie eliminate și în loc să le în acest dosar a crea un 1Cv8.lgf fișier gol. Efectuați această operație cu toate bazele necesare, în cazul în care vă va schimba formatul jurnalului. Vechi nu elimină în mod necesar, este mai bine să se mute undeva, dintr-o dată vin în evidență la îndemână de ea.
Puteți începe apoi serviciul Server Agent 1C: Enterprise. După trecerea la formatul vechi al raportului, rmngr.exe procesul de încărcare a scăzut la aproape 0, un server, în general, acceptabil la 40-60%.
concluzie
Odată ce ați rezolva toate problemele de pe un server de 1C, procesele de management de cluster trebuie să se reunească în 1, responsabil pentru eliminarea acestei opțiuni din caseta de proprietățile serverului de producție. 1C nu se recomandă să folosească acest mod de operare, așa cum este de depanare.
Încă o dată, am câștigat 1C frânele sub formă de 100% rmngr.exe serviciu CPU. Cu baze 1C niciodată nu trebuie să se plictisească, să decidă în mod constant orice probleme și probleme care apar mai des după actualizare. Cu privire precaut la creșterea proceselor de consum de resurse rphost.exe. Mă simt instinctiv că în curând trebuie să decidă utilizarea întrebărilor procesorului de acestea.