Максималното потребление на памет за повикване е надвишено. Преместване на базата данни TEMPDB на друг по-голям диск

сега малко по-подробно:

Клъстер 1C 8.3

На първо място, след инсталирането на клъстера 1C беше необходимо да се създадат работни процеси. Както се оказа, клъстерните процеси започнаха да се създават автоматично в зависимост от натоварването на базата данни.

Тестово изпълнение на фонови задачи на основната база данни накара клъстера 1C да претовари безкрайно rphost.exe и допълнителният rphost.exe не искаше да бъде създаден. След ровене в настройките всичко стана ясно.

Максимална памет на работния процесе количеството памет, което работните процеси могат да използват заедно. Трябва да сте много внимателни, когато задавате параметъра, измерен в байтове. Ако зададете грешна стойност (недостатъчна за нормална работа на потребителя), потребителите ще получат грешката „Няма достатъчно свободна памет на 1C сървъра“. Можете също да получите тази грешка, когато квотата на паметта на 1C сървъра е изтекла.

Безопасно потребление на памет за повикване- позволява ви да контролирате потреблението на памет по време на повикване на сървъра, измерено в байтове. Ако едно повикване използва повече памет от очакваното, това повикване ще бъде завършено в рамките на клъстера 1C без рестартиране на работния процес (rphost.exe). Съответно „губещият“, който е направил обаждането на сървъра, ще загуби сесията си с базата данни 1C, без да засяга работата на други потребители.

в един GB - 1073741824 байта, следователно в 2 GB - 2147483648 байта

Количеството памет за работни процеси, до което сървърът се счита за продуктивен - ако този параметър бъде превишен, сървърът в клъстера 1C ще спре да приема нови връзки.

Брой информационна сигурност на процес- ви позволява да изолирате информационни бази за работни процеси. По подразбиране текущият 1C клъстер беше настроен на „8“, но в продължение на няколко часа работа сървърът стана много нестабилен, потребителските сесии замръзнаха. След изолиране на всяка информационна база (стойност - "1") проблемите изчезнаха.

Брой връзки на процес- стойността по подразбиране е "128". Тъй като текущата база данни има много голямо натоварване от фонови задачи (логистични изчисления, анализ на ценови листи, анализ на конкуренти и т.н.), беше решено броят да се намали до „25“.

Настройките на самия клъстер 1C са се променили леко:

Ниво на отказоустойчивост- това е броят работещи сървъри, които могат да се провалят едновременно и това няма да доведе до необичайно прекратяване на потребителите. Услугите за архивиране се стартират автоматично в количеството, необходимо за осигуряване на определената толерантност към грешки. В реално време активната услуга се репликира към резервните.

Режим на споделяне на натоварването- има две опции за параметъра: „Приоритет по производителност“ - изразходва се повече памет на сървъра и производителността е по-висока, „Приоритет по памет“ - 1C клъстерът спестява памет на сървъра.

Сървър 8.3 се характеризира с ново преработен вътрешен код, въпреки че „отвън“ може да изглежда, че това е леко модифициран 8.2.

Сървърът стана по-„автоматично конфигурируем“; някои параметри, като броя на работните процеси, вече не се създават ръчно, а се изчисляват въз основа на описанията на изискванията за задачи за толерантност към грешки и надеждност.

Това намалява вероятността от неправилно конфигуриране на сървъра и понижава изискванията за квалификация на администраторите.

Разработен е механизъм за балансиране на натоварването, който може да се използва или за увеличаване на производителността на системата като цяло, или за използване на нов режим „спестяване на памет“, който ви позволява да работите „с ограничена памет“ в случаите, когато конфигурацията използвано „обича да изяжда паметта“.

Стабилността на работа при използване на големи количества памет ще се определя от новите параметри на производствения сървър.

Особено интересен е параметърът „безопасно потребление на памет за повикване“. За тези, които нямат представа какво е това, е по-добре да не тренират на „продуктивна“ основа. Параметърът „Максимален размер на паметта на работните процеси“ позволява в случай на „препълване“ да не се срине целият работен процес, а само една сесия „с губещия“. „Количеството памет на работния процес, до което сървърът се счита за продуктивен“ ви позволява да блокирате нови връзки веднага щом този праг на паметта бъде надвишен.

Препоръчвам да изолирате работните процеси по информационна база, например, като посочите параметъра „Брой информационна сигурност на процес = 1“. При няколко силно натоварени бази данни това ще намали взаимното влияние както по отношение на надеждността, така и на производителността.

Отделен принос за стабилността на системата има „разходът” на лицензи/ключове. В 8.3 стана възможно да се използва „мениджър на софтуерни лицензи“, напомнящ на мениджъра „аладин“. Целта е да можете да поставите ключа на отделна машина.

Той е внедрен като друга „услуга“ в клъстерния мениджър. Можете да използвате например „безплатен“ лаптоп. Добавете го към клъстера 1C 8.3, създайте отделен мениджър върху него с услугата „услуга за лицензиране“. Можете да поставите хардуерен hasp ключ във вашия лаптоп или да активирате софтуерни лицензи.

Най-голям интерес за програмистите трябва да представляват „Изискванията за присвояване на функционалност“.

Изисквания към зададената функционалност на 1в

Така че на лаптоп с ключ за сигурност, за да не стартирате потребители на сървъра на клъстера, трябва да добавите „изисквания“ към обекта на изискване „Клиентска връзка с информационна сигурност“ - „Не присвоявай“, т.е. попречи на работните процеси на този сървър да обработват клиентски връзки.

Още по-интересна е възможността да се изпълняват „само фонови задачи“ на производствения сървър на клъстера без потребителски сесии. По този начин можете да преместите силно натоварени задачи (код) на отделна машина. Освен това можете да изпълнявате една фонова задача за „затваряне на месеца“, като използвате „Стойност на допълнителен параметър“ на един компютър и фоновата задача „Актуализиране на индекса на пълен текст“ на друг. Изясняването става чрез индикацията „Стойност на допълнителен параметър”. Например, ако посочите BackgroundJob.CommonModule като стойност, можете да ограничите работата на работния сървър в клъстера само до фонови задания с произволно съдържание. BackgroundJob.CommonModule стойност.<Имя модуля>.<Имя метода>- ще посочи конкретен код.

Клъстер 1C 8.2

Сесиите позволяват балансиране на натоварването и толерантност към грешки в управлявано приложение.

Мениджърът на клъстери вече е станал по-сложен. Някои функции вече могат да бъдат отделени в отделен процес и дори поставени на друг работещ сървър в клъстера. Това ви позволява да балансирате натоварването на сървъра.

Толерантността към грешки на сървър 8.2 се постига чрез:

  • Съхраняване на информация за сесията на потребителя.
  • Потребителят вече не е обвързан с работния процес.
  • Резервиране на работни процеси в клъстер.
  • Трябва да има няколко работни процеса, включително излишни
  • Резервация на клъстер.

Посочва се резервен клъстер; когато са свързани, те са изброени в реда за свързване

Това ви позволява да осигурите непрекъснатост на работата!

Ако физическата връзка на клиента с клъстера е прекъсната (чистачката е извадила кабела, захранването на мрежовото оборудване е изключено, има проблем с доставчика), не е необходимо да се свързвате отново с информационната база и да стартирате всички работата отново. След като физическата връзка бъде възстановена, потребителят може да продължи да работи от мястото, където е била прекъсната.

Ако е необходима поддръжка на клъстерни компютри, те могат да бъдат изключени по време на работа, без да спират потребителите да работят с информационната база.

Ако който и да е сървър в клъстера се повреди, работата на потребителя няма да спре; тя автоматично ще бъде прехвърлена към резервния клъстер и/или резервните работни процеси. За потребителите такъв преход ще бъде невидим.

Ако един от работните процеси на клъстера се повреди, потребителите, свързани към него, ще бъдат автоматично прехвърлени към други или резервни работни процеси. Такъв преход също ще бъде невидим за потребителите.

Термини, понятия

Защо се нуждаете от 1C сървър?

Терминът "сървърен клъстер" се отнася до няколко компютъра (сървъри), изпълняващи обща задача.

Задачите, решени от сървърния клъстер 1C:Enterprise 8, са показани на фигурата по-долу.

Разлика между 8.1 и 8.2

Клъстер 1C 8.1

Сървърният клъстер 1C:Enterprise 8.1 е реализация на идеите за разпределение на натоварването върху сървъри, обслужващи клиентски заявки. Този механизъм разпределя натоварването върху изчислителните ресурси в рамките на един сървър или няколко сървъра („Работни сървъри“), като по този начин осигурява мащабиране на приложението. Сървърният клъстер дублира кода, който обслужва клиентските връзки. Дублираният изпълним код на клъстера се нарича "Работен процес" (rphost). При инсталиране на клъстер се създава само един работен процес.
Няколко работни процеса на един сървър позволяват ефективно използване на количеството RAM и процесорни ресурси за изпълнение на заявки, както и свързване на клиентска сесия с друг работен процес, ако текущият се „срине“.
Програмата Server Agent (ragent) е отговорна за разбирането на това, което се изпълнява на конкретен сървър. Спирането на сървърния агент ще направи сървъра недостъпен за използване от клъстера. Агентът съхранява своята информация във файла srvribrg.lst.
Информацията за работните бази данни и включените работни процеси е собственост на „Мениджъра на сървъра“ (rmngr). Той съхранява тази информация във файла 1CV8Reg.lst. Спирането на мениджъра на сървъра може да доведе до рестартиране на клиентските приложения, ако мениджърът се рестартира успешно или до пълно спиране на работещите сървъри на целия клъстер.
1C:Enterprise 8.1 позволява създаването на няколко независими клъстера на един сървър. Всеки от тях се идентифицира в мрежата чрез уникален „IP порт“ и уникален номер в сервизните файлове. Първият клъстер получава порт 1541 по подразбиране.
Добавката Enterprise Servers е предназначена за управление на клъстер.
Можете да се свържете със сървъри чрез име на сървър или IP адрес.

Агент на сървъра

Сървърният агент „знае“ за всички клъстери, които работят на сървъра. Тази информация се съхранява във файла srvribrg.lst със списък на клъстери и администратори на списъци. Основният порт на агента е 1540. На всеки Работен сървър може да бъде стартиран само един агент, който обслужва всички възможни клъстери на този сървър.
За да получите по-подробна информация визуално, използвайте помощната програма Process Explorer (разработена от Sysinternals). Програмата ви позволява да надникнете по-задълбочено във всички работещи процеси, включително сървърен клъстер 1C:Enterprise 8.1.

Мениджър на клъстери

Мениджърът на клъстера отговаря за работата на клъстера. Всеки клъстер има свой мениджър. Мениджърът съхранява информация за клъстера във файла 1CV8Reg.lst (регистър на клъстера). Всеки Cluster Manager също има свой собствен порт на работния сървър. За първия клъстер портът на мениджъра по подразбиране е 1541. Именно този порт се показва в добавката на 1C:Enterprise Servers в клона Clusters, идентифицирайки клъстера.
Мениджърът получава заявки от клиентската част на 1C:Enterprise 8.1 и взема решение на кой работен поток да даде тази заявка за услуга.

Мениджърът използва сервизния порт, за да взаимодейства с работни процеси.

Работният процес

Работният процес е отговорен за „работата с клиенти“. Можем да кажем, че в предишната версия на 1C:Enterprise 8.0 имаше само един „Workflow“.
В клъстер 1C:Enterprise 8.1 може да има няколко работни процеса. Мениджърът на сървъра решава кой работен процес ще обслужва клиентската връзка. За клиентски връзки работните процеси получават по подразбиране диапазон от IP портове 1560 – 1591. Освен това на всеки работен процес се присвоява сервизен порт за комуникация с мениджъра на клъстера. Всеки работен процес използва до 2 Gb RAM в 32-битова операционна система. В 64-битова операционна система ограничението се налага от физическото количество RAM

Клъстер 1C 8.2

Сървърен клъстер 1C:Enterprise 8.2 - по-нататъшно развитие на сървърните технологии 8.2.

Сървърът може да работи “като 8.1”, т.е. той остава съвместим с предишните технологии.

Освен това е внедрен нов подход към работата на сървъра. Сега, вместо процесите, сесиите играят важна роля.

Сесиите позволяват балансиране на натоварването и толерантност към грешки в управлявано приложение.

Мениджър на клъстери

Мениджърът на клъстери вече е станал по-сложен. Някои функции вече могат да бъдат отделени в отделен процес и дори поставени на друг работещ сървър в клъстера. Това ви позволява да балансирате натоварването на сървъра.

Толерантността към грешки на сървър 8.2 се постига чрез:

  • Съхраняване на информация за сесията на потребителя.
    • Потребителят вече не е обвързан с работния процес.
  • Резервиране на работни процеси в клъстер.
    • Трябва да има няколко работни процеса, включително излишни
  • Резервация на клъстер.
    • Посочва се резервен клъстер; когато са свързани, те са изброени в реда за свързване

Това позволява непрекъснатост на работата:

Ако физическата връзка на клиента с клъстера е прекъсната (чистачката е извадила кабела, захранването на мрежовото оборудване е изключено, има проблем с доставчика), не е необходимо да се свързвате отново с информационната база и да стартирате всички работата отново. След като физическата връзка бъде възстановена, потребителят може да продължи да работи от мястото, където е била прекъсната.

Ако е необходима поддръжка на клъстерни компютри, те могат да бъдат изключени по време на работа, без да спират потребителите да работят с информационната база.

Ако който и да е сървър в клъстера се повреди, работата на потребителя няма да спре; тя автоматично ще бъде прехвърлена към резервния клъстер и/или резервните работни процеси. За потребителите такъв преход ще бъде невидим.

Ако един от работните процеси на клъстера се повреди, потребителите, свързани към него, ще бъдат автоматично прехвърлени към други или резервни работни процеси. Такъв преход също ще бъде невидим за потребителите.

Клъстер 1C 8.3

Сървър 8.3 се характеризира с ново преработен вътрешен код, въпреки че „отвън“ може да изглежда, че това е леко модифициран 8.2.

Сървърът стана по-„автоматично конфигурируем“; някои параметри, като броя на работните процеси, вече не се създават ръчно, а се изчисляват въз основа на описанията на изискванията за задачи за толерантност към грешки и надеждност.

Разработен е механизъм за балансиране на натоварването, който може да се използва или за увеличаване на производителността на системата като цяло, или за използване на нов режим „спестяване на памет“, който ви позволява да работите „с ограничена памет“ в случаите, когато конфигурацията използвано „обича да изяжда паметта“.

Стабилността на работа при използване на големи количества памет ще се определя от новите параметри на производствения сървър.

Особено интересен е параметърът „безопасно потребление на памет за повикване“. За тези, които нямат представа какво е това, е по-добре да не тренират на „продуктивна“ основа. Параметърът „Максимален размер на паметта на работните процеси“ позволява в случай на „препълване“ да не се срине целият работен процес, а само една сесия „с губещия“. „Количеството памет на работния процес, до което сървърът се счита за продуктивен“ ви позволява да блокирате нови връзки веднага щом този праг на паметта бъде надвишен.

Препоръчвам да изолирате работните процеси по информационна база, например, като посочите параметъра „Брой информационна сигурност на процес = 1“. При няколко силно натоварени бази данни това ще намали взаимното влияние както по отношение на надеждността, така и на производителността.

Отделен принос за стабилността на системата има „разходът” на лицензи/ключове. В 8.3 стана възможно да се използва „мениджър на софтуерни лицензи“, напомнящ на мениджъра „аладин“. Целта е да можете да поставите ключа на отделна машина.

Той е внедрен като друга „услуга“ в клъстерния мениджър. Можете да използвате например „безплатен“ лаптоп. Добавете го към клъстера 1C 8.3, създайте отделен мениджър върху него с услугата „услуга за лицензиране“. Можете да поставите хардуерен hasp ключ във вашия лаптоп или да активирате софтуерни лицензи.

Най-голям интерес за програмистите трябва да представляват „Изискванията за присвояване на функционалност“.

Така че, на лаптоп с ключ за защита, за да не стартирате потребители на сървъра на клъстера, трябва да добавите „изисквания“ към обекта на изискване „Клиентска връзка с информационна сигурност“ - „Не присвоявай“, т.е. попречи на работните процеси на този сървър да обработват клиентски връзки.

Още по-интересна е възможността да се изпълняват „само фонови задачи“ на производствения сървър на клъстера без потребителски сесии. По този начин можете да преместите силно натоварени задачи (код) на отделна машина. Освен това можете да изпълнявате една фонова задача за „затваряне на месеца“, като използвате „Стойност на допълнителен параметър“ на един компютър и фоновата задача „Актуализиране на индекса на пълен текст“ на друг. Изясняването става чрез индикацията „Стойност на допълнителен параметър”. Например, ако посочите BackgroundJob.CommonModule като стойност, можете да ограничите работата на работния сървър в клъстера само до фонови задания с произволно съдържание. BackgroundJob.CommonModule стойност.<Имя модуля>.<Имя метода>- ще посочи конкретен код.

Разрешаване на възможни проблеми с инсталацията

Когато инсталирате сървърната част на 1C:Enterprise 8.1, можете да създадете нов потребител или да изберете съществуващ акаунт.

В случай на избор на съществуващ акаунт, трябва да предоставите правилната парола и потвърждение, в противен случай по-нататъшното стартиране на сървърната страна ще доведе до грешка.
Когато стартирате Cluster Agent за първи път, се създава клъстер по подразбиране.
Клъстерът по подразбиране има следните характеристики:
· номер на порт – 1541;
· Обхват на IP порта – 1560:1591;
· поддръжка на много работни потоци – дезактивирана;
· един работен процес, номерът на порта е зададен от посочения диапазон.
Ако има някакви проблеми при първото стартиране на Cluster Agent, клъстерът по подразбиране може да не бъде създаден. Това се проявява във факта, че когато сървърният агент (ragent) стартира, той стартира, но не стартира други клъстерни процеси (rmngr, rphost). Списъкът с клъстери svrribrg.lst изглежда така:
{
{0},
В този случай можете да спрете процеса на ragent, да изтриете списъка с клъстери (srvribrg.lst) и да стартирате ragent отново.

Проверете съвпадението между портовете, посочени в параметъра на порта на командния ред за стартиране на услугата агент на сървъра, и тези, посочени в диалоговия прозорец за параметри на централния сървър на конзолата на клъстера:

— Спрете услугата 1C:Enterprise 8.1 Server Agent.

Ако сървърният агент работи като приложение, той може да бъде спрян чрез натискане на клавишната комбинация Ctrl+C.
- Уверете се в диспечера на задачите, че всички процеси ragent, rmngr, rphost са приключили. Ако е необходимо, изпълнете ги с помощта на диспечера на задачите.

— Отворете свойствата на услугата 1C:Enterprise 8.1 Server Agent.

- Обърнете внимание на реда „Изпълним файл“ (Път до изпълним файл). Той има параметъра -d, последван от директорията с данни на клъстера. Всички файлове, свързани с клъстера, се намират в тази директория.
- Изтрийте цялото съдържание на тази директория.
— Стартирайте услугата 1C:Enterprise 8.1 Server Agent.
- Уверете се в диспечера на задачите, че всички процеси ragent, rmngr, rphost са стартирали.
— Стартирайте конзолата на клъстера и регистрирайте централния сървър в нея. Конзолата трябва да се свърже с централния сървър и да покаже един клъстер, създаден по подразбиране.
Възможните проблеми с повредата на сървърния клъстер включват проблеми с ключове за сигурност, права на акаунт за услуга и неправилни параметри за стартиране.

  1. Ключът за защита на сървъра се инсталира ЛОКАЛНО на всеки сървър в предприятието
  2. Не задавайте акаунт за услуга с празна парола
  3. При множество клъстери използваните портове не трябва да се припокриват

Моля, имайте предвид, че по време на инсталационния процес на платформата 1C:Enterprise 8.1 могат да се показват съобщения за грешка. Най-вероятните съобщения са изброени по-долу. Посочени са причините, довели до съобщенията и стъпките за отстраняването им.

Грешка 1069: Услугата не работи поради грешка при влизане

Проблемът е свързан с правата на акаунта да работи като системна услуга. Отворете помощната програма Local Security Policy и добавете потребителя (от чието име се стартират работните сървъри на клъстера) към политиките за влизане като услуга и влизане като групово задание.
Ако данните, съхранени в сервизните файлове, са повредени, стартирането на производствените сървъри на клъстера може да е неуспешно. Уверете се, че сървърният агент на 1C:Enterprise 8.1 работи (процес на ragent в диспечера на задачите).
Не забравяйте, че Windows Event Auditing също е инструмент за анализ. За да направите това, вижте дали някакви „подозрителни“ съобщения се появяват в регистъра на събитията на Windows.

Грешка 8007056B / 800708C5

Новата парола не отговаря на правилата за пароли. Паролата може да е твърде кратка или вече сте използвали тази парола наскоро.
Причина: посочената парола за акаунта в диалоговия прозорец „Инсталиране на сървър на 1C: Enterprise“ не отговаря на изискванията на политиката за сигурност.
Решение: Задайте нова парола за избрания акаунт, която отговаря на изискванията на политиката за сигурност или отслабете изискванията на приложената политика за сигурност, т.е. не изисквайте „сложна“ парола, не ограничавайте броя на знаците в паролата, не проверявайте опитите за повторение и т.н.

Грешка 1923: Няма привилегии за инсталиране от услуга

Причина: Грешката е свързана с правата за инсталиране на акаунта като приложения. Тази грешка е типична за опити за инсталиране на сървър на домейн контролер, където са необходими повишени мерки за сигурност.
Решение: Не използвайте домейн контролер за хостване на корпоративния сървър или облекчете изискванията за сигурност и укажете правата „Изпълни като услуга“ или „Изпълни като пакетно задание“ за избрания акаунт.

Грешка 80070056

Вашата парола не можа да бъде променена. Всяка парола трябва да се използва поне x дни.
Причина и решение: Друга грешка, която възниква, когато изискванията на политиката за сигурност за използваните пароли са нарушени. Решението е подобно на грешка 800708C5.

Windows Sockets - 11004(0x00002AFC)

1) Уверете се, че на работния сървър на клъстера в диспечера на задачите се изпълнява следното:
Сървърен агент (ragent.exe),
Мениджър на клъстери (rmngr.exe),
Работен процес на клъстер (rphost.exe).
2) За да проверите разделителната способност на името на IP адреса, стартирайте от командния ред:
ping име на машина
В отговора на системата на командата ни интересува дали IP адресът е определен.
3) Ако името е определено, но работният процес все още не е намерен, тогава се уверете, че IP адресът на името е определен<имя машины>И<имя машины>.<имя домена>не се определят по различен начин.

(Windows Sockets - 10054(0x00002746).

Отдалеченият хост насилствено затвори връзката.
Това съобщение може да бъде получено, ако сървърът се рестартира или работният процес бъде принуден да бъде изтрит.
Тази грешка обикновено не се появява при повторно свързване. Ако грешката остане, е необходимо да се проучат причините за повредата на производствените сървъри на клъстера.
Тази грешка може да възникне, когато работен процес достигне максималния капацитет на паметта на 32-битови системи.
Друг случай е опит за свързване от клиент със съобщение за грешка:

(Windows Sockets - 10060(0x0000274C)

Опитът за установяване на връзка беше неуспешен, защото... необходимият отговор не е получен от друг компютър в рамките на необходимото време или вече установена връзка е прекъсната поради неправилен отговор от вече свързания компютър.
Същността на тази грешка е липсата на отговор в рамките на определено време (таймаут).
1) Уверете се, че вашата защитна стена не блокира трафика на приложението. Изключете защитната си стена.
За да направите това, изпълнете командата от командния ред (командата е достъпна от Windows XP и Windows Server 2003; по-ранните версии нямат вградена защитна стена, но може да се инсталира софтуер на трети страни):
netshзащитна стенакомплектopmodeдеактивирайте
Ако командата е успешна, ще получите съобщение:
ДОБРЕ.
В допълнение към защитната стена, мрежовите филтри могат да блокират трафика. Те са деактивирани по подразбиране. Уверете се обаче, че е така:

  1. Отворете папката Мрежови връзки.
  2. Щракнете с десния бутон върху мрежовата връзка, която искате да конфигурирате, и изберете Имоти.
  3. В раздела са често срещани(за локална мрежова връзка) или в раздела Нет(за всички други връзки) изберете Интернет протокол (TCP/IP)и натиснете бутона Имоти.
  4. Щракнете върху бутона Допълнително.
  5. Отворете раздела Настроики, изберете опция TCP/IP филтриранеи натиснете бутона Имоти.
  6. Уверете се, че квадратчето за отметка Активиране на TCP/IP филтриране (всички адаптери)отстранени.

2) Уверете се, че ресурсите на процесора не са натоварени на 100% (CPU%).
3) Измерете мрежовата активност на клиентския и сървърния интерфейс. Натоварването на мрежовия адаптер не трябва да надвишава 60%.

(Windows Sockets - 10061(0x0000274D)

Връзката не е установена, защото Целевият компютър отхвърли заявката за връзка.
Типична причина за тази грешка е липсата на работещ сървърен агент. Стартирайте сървъра ръчно или рестартирайте сървъра, за да стартира автоматично.

Отговори на въпроси

Мултиплатформен 1C

Сървърна инсталация

Въпрос: Грешка при инсталиране на 1c сървър на MS Server 2008 R2 x64 Когато инсталирате 1c сървър чрез командния ред, например, ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d “C:\Program Files\1cv82 \ (взет от ITS диска), командният ред изписва съобщението: „Грешка! Грешка на OpenSCManager!“ В този случай услугата не е създадена. Тестван на 8.1.15.14 и 8.2.10.77

О: За да инсталирате от командния ред на операционна система, където присъства UAC, трябва да използвате услугата RunAs, т.к. Дори ако потребителят е член на групата администратори, UAC блокира действия, които променят състоянието на системата.

Ключове за защита

Въпрос: Защитният ключ за сървър 8.2 позволява ли ми да стартирам сървър 8.1?
О: Да, така е

Q: За да стартирам 1C сървър, имам ли нужда от някакви сървърни hasp ключове? Локален, или няма да работи за 5 потребители?

О: да, сървърът се нуждае от собствен ключ, локалните потребителски и мрежови ключове няма да работят. Повече подробности в « « , слайд номер 30.

Q: Да приемем, че 1C сървърен клъстер се състои от 3 физически сървъра. колко ключа за сигурност са необходими?

Въпрос: Има терминален сървър и ключ за 5 лиценза, трябва да се закупи 6-ти допълнителен лиценз. Разрешително. Възможно ли е да го инсталирате на сървъра до ключа на 5? И всичките 6 потребителя ще работят ли в терминални сесии или 5 - под терминала, а 1 във файловата версия?
О: Не, няма да го направят. Шестият лиценз под формата на локален ключ трябва да бъде включен в компютъра на потребителя, но не и в терминала.

Актуализации на 1C сървър

В: Когато бъде пусната нова версия 8.2.xxx на платформата, каква е процедурата за актуализиране на сървъри и клиенти?
A: 8.2 дистрибуции инсталират своите файлове в различни папки (всяка версия има своя собствена папка), т.е. теоретично остава възможно да се извикат няколко версии на сървъра паралелно.

Нямах никакви проблеми. Въпреки това, трябва внимателно да наблюдавате портовете, заети от екземпляра на сървъра 1C. Не трябва да има кръстовища.

Настройка на 1C сървър

В: В 1C 8.1 какъв е най-добрият начин да поставите информационни бази, ако има няколко от тях, в един клъстер или да създадете отделен клъстер за всяка база данни? О: При голям обем или натоварване тестовите бази данни трябва да бъдат поставени в отделни клъстери!

Въпрос: ВЪПРОС: Работният процес 1C:Enterprise 8.1 еднонишково приложение ли е или многонишково? Тези. могат ли да се заредят много ядра с един свързан потребител? С няколко? Какво ще кажете за работния процес 1C:Enterprise 8.2? Благодаря ти.
A: 1Сv8.exe и rphost.exe във версия 8.1 консумират 1 ядро. Тъй като в 8.1 връзката на клиента е строго обвързана с работния процес, можем условно да приемем, че обработката на клиента 1C се извършва в рамките на едно ядро. Изключение прави СУБД, която използва ядра, независимо от това как работи сървърът 1C.

Във версия 8.2 връзките са заменени от сесии. Сесиите може вече да се изпълняват в различни работни процеси. Следователно извикването на 8.2 с една нишка вероятно не е правилно. Клиент 8.2 също визуално зарежда няколко ядра, така че това:

Платформа 8.2 не реализира всички възможности на многонишкова система, но използва много по-добре хардуерните възможности в сравнение с 8.1, включително по отношение на паралелизма.

Въпрос: Необходимо ли е да има няколко работни процеса на 1C:Enterprise 8.1 за сървъра на базата данни (MS SQL), за да зареди множество ядра? (Отбелязва се, че MS SQL обикновено „зарежда“ само едно ядро, т.е. „паралелизиране“ на обработката на една заявка в няколко ядра по правило не се случва.) Благодаря.
О: Няма нужда специално да управлявате MS SQL; това е сравнително самонастройваща се система, която използва ресурси според нуждите. Можете да контролирате паралелизма на изпълнение:

EXEC sys.sp_configure N’максимална степен на паралелизъм’, N’5′
ОТИВАМ
ПРЕКОНФИГУРИРАЙТЕ С ОТМЕНЯНЕ
ОТИВАМ

Можете да създадете няколко работни процеса на сървъра 1C въз основа на факта, че един работен процес не предоставя възможност на потребителите да се свържат отново, в случай че работният процес се срине. Процес 2 (на 8.2 е по-добре да го направите „резервен“) решава този проблем. Но има смисъл да добавите трети или повече работни процеси само ако първите два работни процеса са силно натоварени (повече от 90%). Няма смисъл да умножавате ненужно работните процеси, това може да влоши производителността.

О: Трябва да има поне 1 резервен работен процес в 8.2.

Failover Cluster

Въпрос: Въпрос за активиране на резервиране за клъстери 1s 8.2. Ако нашият сървър се срине (чистачката извади кабела), името на мрежата, например „сървър:2540“, ще бъде недостъпно. Как клиент, чийто низ за връзка казва „сървър:2540“, знае, че трябва да се свърже с резервния клъстер? откъде ще вземе името на другия сървър? Какво става, ако напишете клъстери, разделени със запетаи в низа за връзка с базата данни?
О: Няколко клъстера се комбинират в „група за излишък“. За тази цел в модула на клъстера има „списък с резервации“.

Когато клиент за първи път получи достъп до клъстер, му се дава списък с клъстери, включени в групата за резервиране.

Ако клиентът никога не се е свързвал с вас, тогава в този случай трябва ръчно да посочите адресите на всички клъстери, например storm:2541,monster:2541.

Синхронизираните данни се обменят между резервни клъстери.

Въпрос: Какво се случва след възстановяването на основния клъстер? когато потребителите преминаха към архивиране.

О: Те се връщат. Възможно е да има паузи по време на превключване, докато синхронизирате тези клъстери.

Фонови задачи

Въпрос: Как да изтрия фоново задание, работещо на сървъри 1C:8.1 и 1C:8.2?

О: Възможността за отмяна на рутинна задача работи само ако кодът се изпълнява във вградения език на 1C:Enterprise. Ако кодът се изпълнява във външни библиотеки, тогава такава задача не може да бъде отменена, освен чрез принудително прекратяване на работния поток. Ако в процеса има блок StartTransaction() - CommitTransaction(), тогава е малко вероятно. Други фонови задания могат да бъдат изтрити чрез конзолата за задания.

Регулаторни процедури

Въпрос: Възможно ли е да се унищожи базата по време на T&I?

О: Не съм запознат с такива случаи, но IMHO всичко е възможно. Следователно би било добра идея да направите резервно копие преди T&I.

Въпрос: Вячеслав, по какви причини не извършвате повторно индексиране с помощта на 1C тестване и корекция?
О: Възможностите на СУБД са по-подходящи за тези цели, тъй като те по същество също възстановяват индексите, но не изискват изключително изземване на базата данни.

Списание за технологии

Въпрос: Добър ден. Въпрос от технологично списание: Трябва да получа копия на екрани на работни станции в случай на грешки на 1C. Трябва ли да настроя технологичен журнал на работните станции за това или е само за сървъра?
О: Можете да конфигурирате получаване на екранна снимка само когато платформата падне, а не когато има грешка. Въпреки това, няма голяма полза от такава операция; напълно достатъчно е да събирате извънредни ситуации с помощта на технологичен дневник. В същото време повечето от грешките могат да се видят с помощта на TZ от страната на 1C сървъра. Изключение биха били събития като „грешка при форматиране на потока“, свързана с остарял кеш на метаданни.

Проблеми и грешки

Въпрос: Срещали ли сте проблем - изчезването на настройките за отчет за потребителите при динамично актуализиране на конфигурации на платформата 8.2. Някакви препоръки как да се справя с това?
О: Проблемите, свързани с динамичното актуализиране, са отразени в „1C сървъри: Enterprise 8.1 и 8.2 - какво да ядем“), слайд номер 60. Изтрий кеш-памет. Може би в някои случаи е необходимо да се разбере къде точно се съхраняват потребителските настройки. Ако е необходимо, съхранявайте като двоични данни в информационния регистър.

Въпрос: Свързан въпрос, защото... това е от значение за файловия режим: какви грешки коригира chdbfl.exe?
О: Това е инструмент за коригиране на грешки в структурата за съхранение на данни. Това може да е ситуация, при която например се появява „Файлът на базата данни е повреден.../1Cv8.1CD“. Тези. поправя повреда на файла на базата данни. Въпреки това, той не изпълнява T&I функции. Пускам chdbfl.exe, ако T&I не работи успешно.

Въпрос: Моля, кажете ми, ако сте срещали такъв проблем. когато има голям брой потребители в базата данни (около 40) при обработка на големи документи, например отразяване на ПО в рег. Отчитане на около 8000 реда. Съобщението за грешка е, че няма достатъчно памет на корпоративния 1C сървър и потребителят, който е инициирал този документ, пада. След това документът може да бъде обработен само след рестартиране на сървърния агент на 1C.
О: Изглежда, че има изтичане на памет:

1. Рестартирайте 1C сървъра, увеличете броя на работните процеси и запазете само тази една база данни в клъстера.

2. Разбийте задържането на части, да кажем 1000 реда наведнъж. Използвайки TZ, проследявайте обекти, които заемат памет в началото на дадена операция, но не освобождават памет след завършване.

3. Инсталирайте версията x64, увеличете количеството RAM, преминете към 8.2.

Въпрос: Въпрос за тестване и управление. Възможно ли е да се стартира „Проверка на референтната цялост“ въз основа на URDB с избор въз основа на предадените данни? (т.е. в някои възли физически няма обекти, но има връзки към тях). Благодаря ти!
О: За съжаление, това все още не е възможно.

Въпрос: Защо тестването и коригирането не решават всички проблеми наведнъж, трябва ли да го изпълнявате няколко пъти?

О: Само разработчиците могат да отговорят точно. Изпълнявам T&I според разпоредбите (циклично), така че този въпрос не е много актуален за мен. T&I трябва да се извършва не само веднъж, а непрекъснато, като „ТО на автомобил“.

Въпрос: Има ли разлика между T&I 8.1 и 8.2?

О: В момента на писане на отговора и версия 8.2.10 не знам разликата.

Въпрос: Необходимо ли е преиндексиране по време на преструктуриране?
О: Няма нужда.

други

В: Уважаеми господа, някой опитвал ли се е да дублира бази данни с помощта на MSSql 2008? Възможно ли е изобщо?

Q: Въпрос относно принудителното налагане на споделена памет на сървър 1s 8.2

О: Няма нужда да налагате нищо, сървърът ще разбере.

Въпрос: За 1C:Enterprise 8.1 са забелязани ситуации, когато на същия хардуер версията на файловия сървър с „тежки“ операции и един потребител работи много по-бързо от версията клиент-сървър, когато всички „връзки“ (база данни сървър, 1C сървър: предприятие и клиент) са инсталирани на един и същ сървър. Освен това, когато извършвате тази „тежка“ операция, няма очевидни хардуерни претоварвания (натоварването на процесора, паметта и твърдите дискове е минимално). Тоест има много хардуерни ресурси, но работи бавно. Срещу какво можем да „починем“? Благодаря ти.
О: Предимството на клиент-сървърната архитектура от гледна точка на производителността е способността да се обработват клиентски заявки за данни ПАРАЛЕЛНО. Тези. Скоростта на потока не е показател, по който да се правят генерални изводи. Механизмите, които подобряват паралелността, все още могат леко да намалят производителността в рамките на една нишка.

За да откриете недвусмислено тясното място във вашия случай, трябва да получите натоварването на сървърното оборудване и да го сравните във времето с най-дългите операции в режим клиент-сървър. Често това е прекомерно движение на данни към страната на клиента. Тези. Вместо да извършва операции на сървъра 1C, данните от базата данни се прехвърлят през сървъра към клиента.

Скоростта в една нишка на версията клиент-сървър ще навакса само производителността на файловата версия. Струва си да се справите с този проблем, ако времето на работа в абсолютни числа се измерва в не по-малко от минути. Оптимизирането в рамките на 1-3 секунди заявки е съмнително.

Q: За разликата между терминала на Windows и тънкия клиент 1C.
О: Докато повечето решения не бъдат НАПЪЛНО преведени на 8.2, определено е трудно да се говори за практическо сравнение на тези технологии.

Ясно е, че тънкият клиент 1C трябва да консумира по-малко трафик и да осигурява възможност за работа през мрежата. Но това е нещо, което все още предстои да бъде внедрено, а терминалните решения се използват много широко сега.

За консервативни, прагматични ръководители на проекти, конвертиращи 8.1 в 8.2 - терминално решение. За малки проекти с ниска цена на грешки и конфигурация, незабавно внедрена с управлявани формуляри и системи за контрол на достъпа, тънък клиент е за предпочитане IMHO.

Въпрос: Как да проведем тестване на натоварване, близко до реалните условия? В крайна сметка не можете да принудите потребителите да „щракнат върху нещо“.

A: 1C: Тестови център с селекция от най-трудните операции, не е необходимо 100% възпроизвеждане, самите щраквания не са трудни, главно провеждане и изискване на отчети. Ще има отделен уебинар за тестването. Ще ви разкажа и по-подробно.

05.04.2017 |

Клъстер 1C 8.3

На първо място, след инсталирането на клъстера 1C беше необходимо да се създадат работни процеси. Както се оказа, клъстерните процеси започнаха да се създават автоматично в зависимост от натоварването на базата данни.

Тестово изпълнение на фонови задачи на основната база данни накара клъстера 1C да претовари безкрайно rphost.exe и допълнителният rphost.exe не искаше да бъде създаден. След ровене в настройките всичко стана ясно.

Максимална памет на работния процесе количеството памет, което работните процеси могат да използват заедно. Трябва да сте много внимателни, когато задавате параметъра, измерен в байтове. Ако зададете грешна стойност (недостатъчна за нормална работа на потребителя), потребителите ще получат грешката „Няма достатъчно свободна памет на 1C сървъра“. Можете също да получите тази грешка, когато квотата на паметта на 1C сървъра е изтекла.

Безопасно потребление на памет за повикване- позволява ви да контролирате потреблението на памет по време на повикване на сървъра, измерено в байтове. Ако едно повикване използва повече памет от очакваното, това повикване ще бъде завършено в рамките на клъстера 1C без рестартиране на работния процес (rphost.exe). Съответно „губещият“, който е направил обаждането на сървъра, ще загуби сесията си с базата данни 1C, без да засяга работата на други потребители.

в един GB - 1073741824 байта, следователно в 2 GB - 2147483648 байта

Количеството памет за работни процеси, до което сървърът се счита за продуктивен - ако този параметър бъде превишен, сървърът в клъстера 1C ще спре да приема нови връзки.

Брой информационна сигурност на процес- ви позволява да изолирате информационни бази за работни процеси. По подразбиране текущият 1C клъстер беше настроен на „8“, но в продължение на няколко часа работа сървърът стана много нестабилен, потребителските сесии замръзнаха. След изолиране на всяка информационна база (стойност - "1") проблемите изчезнаха.

Брой връзки на процес- стойността по подразбиране е "128". Тъй като текущата база данни има много голямо натоварване от фонови задачи (логистични изчисления, анализ на ценови листи, анализ на конкуренти и т.н.), беше решено броят да се намали до „25“.

Настройките на самия клъстер 1C са се променили леко:

Ниво на отказоустойчивост- това е броят работещи сървъри, които могат да се провалят едновременно и това няма да доведе до необичайно прекратяване на потребителите. Услугите за архивиране се стартират автоматично в количеството, необходимо за осигуряване на определената толерантност към грешки. В реално време активната услуга се репликира към резервните.

Режим на споделяне на натоварването- има две опции за параметъра: „Приоритет по производителност“ - изразходва се повече памет на сървъра и производителността е по-висока, „Приоритет по памет“ - 1C клъстерът спестява памет на сървъра.

Сървър 8.3 се характеризира с ново преработен вътрешен код, въпреки че „отвън“ може да изглежда, че това е леко модифициран 8.2.

Сървърът стана по-„автоматично конфигурируем“; някои параметри, като броя на работните процеси, вече не се създават ръчно, а се изчисляват въз основа на описанията на изискванията за задачи за толерантност към грешки и надеждност.

Това намалява вероятността от неправилно конфигуриране на сървъра и понижава изискванията за квалификация на администраторите.

Разработен е механизъм за балансиране на натоварването, който може да се използва или за увеличаване на производителността на системата като цяло, или за използване на нов режим „спестяване на памет“, който ви позволява да работите „с ограничена памет“ в случаите, когато конфигурацията използвано „обича да изяжда паметта“.

Стабилността на работа при използване на големи количества памет ще се определя от новите параметри на производствения сървър.

Особено интересен е параметърът „безопасно потребление на памет за повикване“. За тези, които нямат представа какво е това, е по-добре да не тренират на „продуктивна“ основа. Параметърът „Максимален размер на паметта на работните процеси“ позволява в случай на „препълване“ да не се срине целият работен процес, а само една сесия „с губещия“. „Количеството памет на работния процес, до което сървърът се счита за продуктивен“ ви позволява да блокирате нови връзки веднага щом този праг на паметта бъде надвишен.

Препоръчвам да изолирате работните процеси по информационна база, например, като посочите параметъра „Брой информационна сигурност на процес = 1“. При няколко силно натоварени бази данни това ще намали взаимното влияние както по отношение на надеждността, така и на производителността.

Отделен принос за стабилността на системата има „разходът” на лицензи/ключове. В 8.3 стана възможно да се използва „мениджър на софтуерни лицензи“, напомнящ на мениджъра „аладин“. Целта е да можете да поставите ключа на отделна машина.

Той е внедрен като друга „услуга“ в клъстерния мениджър. Можете да използвате например „безплатен“ лаптоп. Добавете го към клъстера 1C 8.3, създайте отделен мениджър върху него с услугата „услуга за лицензиране“. Можете да поставите хардуерен hasp ключ във вашия лаптоп или да активирате софтуерни лицензи.

Най-голям интерес за програмистите трябва да представляват „Изискванията за присвояване на функционалност“.

Изисквания към зададената функционалност на 1в

Така че на лаптоп с ключ за сигурност, за да не стартирате потребители на сървъра на клъстера, трябва да добавите „изисквания“ към обекта на изискване „Клиентска връзка с информационна сигурност“ - „Не присвоявай“, т.е. попречи на работните процеси на този сървър да обработват клиентски връзки.

Още по-интересна е възможността да се изпълняват „само фонови задачи“ на производствения сървър на клъстера без потребителски сесии. По този начин можете да преместите силно натоварени задачи (код) на отделна машина. Освен това можете да изпълнявате една фонова задача за „затваряне на месеца“, като използвате „Стойност на допълнителен параметър“ на един компютър и фоновата задача „Актуализиране на индекса на пълен текст“ на друг. Изясняването става чрез индикацията „Стойност на допълнителен параметър”. Например, ако посочите BackgroundJob.CommonModule като стойност, можете да ограничите работата на работния сървър в клъстера само до фонови задания с произволно съдържание. BackgroundJob.CommonModule стойност.<Имя модуля>.<Имя метода>- ще посочи конкретен код.

Клъстер 1C 8.2

Сесиите позволяват балансиране на натоварването и толерантност към грешки в управлявано приложение.

Мениджърът на клъстери вече е станал по-сложен. Някои функции вече могат да бъдат отделени в отделен процес и дори поставени на друг работещ сървър в клъстера. Това ви позволява да балансирате натоварването на сървъра.

Толерантността към грешки на сървър 8.2 се постига чрез:

  • Съхраняване на информация за сесията на потребителя.
  • Потребителят вече не е обвързан с работния процес.
  • Резервиране на работни процеси в клъстер.
  • Трябва да има няколко работни процеса, включително излишни
  • Резервация на клъстер.

Посочва се резервен клъстер; когато са свързани, те са изброени в реда за свързване

Това ви позволява да осигурите непрекъснатост на работата!

Ако физическата връзка на клиента с клъстера е прекъсната (чистачката е извадила кабела, захранването на мрежовото оборудване е изключено, има проблем с доставчика), не е необходимо да се свързвате отново с информационната база и да стартирате всички работата отново. След като физическата връзка бъде възстановена, потребителят може да продължи да работи от мястото, където е била прекъсната.

Ако е необходима поддръжка на клъстерни компютри, те могат да бъдат изключени по време на работа, без да спират потребителите да работят с информационната база.

Ако който и да е сървър в клъстера се повреди, работата на потребителя няма да спре; тя автоматично ще бъде прехвърлена към резервния клъстер и/или резервните работни процеси. За потребителите такъв преход ще бъде невидим.

Ако един от работните процеси на клъстера се повреди, потребителите, свързани към него, ще бъдат автоматично прехвърлени към други или резервни работни процеси. Такъв преход също ще бъде невидим за потребителите.

Често заедно със сървъра на 1C:Enterprise на машината работят други услуги - терминален сървър, SQL сървър и др. И в един момент сървърът на 1C: Enterprise, или по-скоро работният процес на rphost, изяжда повече памет от планираното или цялата памет. Което води до забавяне на други услуги и зомбиране на сървъра. За да избегнете подобни ситуации, трябва да конфигурирате автоматично рестартиране на работните процеси на сървъра на 1C:Enterprise

Решение

1. Отворете административната конзола на сървърите на 1C Enterprise;
2. Разширете дървото на централния сървър до клъстери и изберете клъстера, който ни интересува. В примера има само един клъстер;
3. Отворете свойствата на избрания клъстер и вижте следния формуляр

Свойства на сървърния клъстер 1C:Enterprise 8.3

Нека да разгледаме примера, показан на изображението:

Интервал за рестартиране— време, след което процесът rphost ще бъде принуден да се рестартира. Преди да приключи процесът, се стартира нов rphost процес, към който се прехвърлят всички връзки и едва тогава старият процес ще приключи. Това няма да повлияе по никакъв начин на изживяването на потребителя. Интервалът е посочен в секунди, в примера са посочени 24 часа.

Разрешен размер на паметта— количеството памет, в рамките на което работният процес може да работи без проблеми. Обемът е посочен в килобайти, в примера стойността е 20 гигабайта (всъщност цифрата е твърде голяма и трябва да започнете от конкретната система, но средната цифра е 4 GB). Веднага след като паметта, заета от работния процес, надвиши зададената стойност, обратното броене започва.

Интервал за превишаване на допустимото количество памет— след като таймерът, стартиран след превишаване на допустимото количество памет, отброи определеното време, ще бъде стартиран нов работен процес, към който се прехвърлят всички връзки, старият процес е маркиран като деактивиран. Интервалът е посочен в секунди, в примера са посочени 30 секунди.

Спрете деактивираните процеси след— времето, след което работният процес, маркиран като забранен, ще бъде спрян; ако стойността е 0, процесът няма да бъде завършен. Интервалът е посочен в секунди, в примера са посочени 60 секунди.

След като приложите настройките, не е необходимо да рестартирате сървърната услуга, те се прилагат динамично.

Обща сума

Така настройваме автоматично рестартиране на работните процеси на сървъра на 1C:Enterprise и получаваме по-стабилна система; ако възникне изтичане на памет, работата на конкретна сесия ще бъде прекратена.

Освен това в някои ситуации можете да си поиграете с настройките и да предотвратите възможен срив на сървъра, ако направите грешки.

На първо място, след инсталирането на клъстера 1C беше необходимо да се създадат работни процеси. Както се оказа, клъстерните процеси започнаха да се създават автоматично в зависимост от натоварването на базата данни.

Тестово изпълнение на фонови задачи на основната база данни накара клъстера 1C да претовари безкрайно rphost.exe и допълнителният rphost.exe не искаше да бъде създаден. След ровене в настройките всичко стана ясно.

Максимална памет на работния процесе количеството памет, което работните процеси могат да използват заедно. Трябва да сте много внимателни, когато задавате параметъра, измерен в байтове. Ако зададете грешна стойност (недостатъчна за нормална работа на потребителя), потребителите ще получат грешката „Няма достатъчно свободна памет на 1C сървъра“. Можете също да получите тази грешка, когато квотата на паметта на 1C сървъра е изтекла.

Безопасно потребление на памет за повикване– позволява ви да контролирате консумацията на памет по време на повикване на сървъра, измерена в байтове. Ако едно повикване използва повече памет от очакваното, това повикване ще бъде завършено в рамките на клъстера 1C без рестартиране на работния процес (rphost.exe). Съответно „губещият“, който е направил обаждането на сървъра, ще загуби сесията си с базата данни 1C, без да засяга работата на други потребители.

в един GB – 1073741824 байта, следователно в 2 GB – 2147483648 байта

Количеството памет за работни процеси, до което сървърът се счита за продуктивен - ако този параметър бъде превишен, сървърът в клъстера 1C ще спре да приема нови връзки.

Брой информационна сигурност на процес– позволява ви да изолирате информационни бази за работни процеси. По подразбиране текущият 1C клъстер беше зададен на „ 8 “, но в продължение на няколко часа работа сървърът се държеше много нестабилно, потребителските сесии замръзнаха. След изолиране на всяка информационна база (стойност – „1“) проблемите изчезнаха.

Брой връзки на процес- стойност по подразбиране " 128 “. Тъй като текущата база данни има много голямо натоварване от фонови задачи (логистични изчисления, анализ на ценови листи, анализ на конкуренти и т.н.), беше решено броят да се намали до „25“.

Настройките на самия клъстер 1C са се променили леко:

Ниво на отказоустойчивост– това е броят работещи сървъри, които могат едновременно да се провалят и това няма да доведе до необичайно прекъсване на потребителите. Услугите за архивиране се стартират автоматично в количеството, необходимо за осигуряване на определената толерантност към грешки. В реално време активната услуга се репликира към резервните.

Режим на споделяне на натоварването– има две опции за параметъра: „Приоритет по производителност“ – изразходва се повече памет на сървъра и производителността е по-висока, „Приоритет по памет“ – 1C клъстерът спестява памет на сървъра.

Сървър 8.3 се характеризира с ново преработен вътрешен код, въпреки че „отвън“ може да изглежда, че това е леко модифициран 8.2.

Сървърът стана по-„автоматично конфигурируем“; някои параметри, като броя на работните процеси, вече не се създават ръчно, а се изчисляват въз основа на описанията на изискванията за задачи за толерантност към грешки и надеждност.

Това намалява вероятността от неправилно конфигуриране на сървъра и понижава изискванията за квалификация на администраторите.

Разработен е механизъм за балансиране на натоварването, който може да се използва или за увеличаване на производителността на системата като цяло, или за използване на нов режим „спестяване на памет“, който ви позволява да работите „с ограничена памет“ в случаите, когато конфигурацията използвано „обича да изяжда паметта“.

Стабилността на работа при използване на големи количества памет ще се определя от новите параметри на производствения сървър.

Особено интересен е параметърът „безопасно потребление на памет за повикване“. За тези, които нямат представа какво е това, е по-добре да не тренират на „продуктивна“ основа. Параметърът „Максимален размер на паметта на работните процеси“ позволява в случай на „препълване“ да не се срине целият работен процес, а само една сесия „с губещия“. „Количеството памет на работния процес, до което сървърът се счита за продуктивен“ ви позволява да блокирате нови връзки веднага щом този праг на паметта бъде надвишен.

Препоръчвам да изолирате работните процеси по информационна база, например, като посочите параметъра „Брой информационна сигурност на процес = 1“. При няколко силно натоварени бази данни това ще намали взаимното влияние както по отношение на надеждността, така и на производителността.

Отделен принос за стабилността на системата има „разходът” на лицензи/ключове. В 8.3 стана възможно да се използва „мениджър на софтуерни лицензи“, напомнящ на мениджъра „аладин“. Целта е да можете да поставите ключа на отделна машина.

Той е внедрен като друга „услуга“ в клъстерния мениджър. Можете да използвате например „безплатен“ лаптоп. Добавете го към клъстера 1C 8.3, създайте отделен мениджър върху него с услугата „услуга за лицензиране“. Можете да поставите хардуерен hasp ключ във вашия лаптоп или да активирате софтуерни лицензи.

Най-голям интерес за програмистите трябва да представляват „Изискванията за присвояване на функционалност“.

Изисквания към зададената функционалност на 1в

Така че, на лаптоп с ключ за сигурност, за да не стартирате потребители на сървъра на клъстера, трябва да добавите „изисквания“ към обекта на изискване „Клиентска връзка с информационна сигурност“ – „Не присвоявай“, т.е. попречи на работните процеси на този сървър да обработват клиентски връзки.

Още по-интересна е възможността да се изпълняват „само фонови задачи“ на производствения сървър на клъстера без потребителски сесии. По този начин можете да преместите силно натоварени задачи (код) на отделна машина. Освен това можете да изпълнявате една фонова задача за „затваряне на месеца“, като използвате „Стойност на допълнителен параметър“ на един компютър и фоновата задача „Актуализиране на индекса на пълен текст“ на друг. Изясняването става чрез индикацията „Стойност на допълнителен параметър”. Например, ако посочите BackgroundJob.CommonModule като стойност, можете да ограничите работата на работния сървър в клъстера само до фонови задания с произволно съдържание. BackgroundJob.CommonModule стойност.<Имя модуля>.<Имя метода>– ще посочи конкретен код.