8.3 8 server cluster default setting

This article contains information about the 1C installation procedure in the client-server version.

Installation of the 1C platform is described in our other article - “1C Administration”, in the “1C Installation” section. Installing on a server is almost exactly the same as installing on a local computer, with only one difference. In the server version, when selecting components to install, you must select “1C:Enterprise Server” and “1C:Enterprise Server Administration”.

Install 1C on client computers from which connections to the server will be made.

Installation on client computers is no different from the method described earlier in the article “1C Administration”.

Create an infobase in SQL.

Creating an information base in SQL is also very similar to creating a database in the file version. The difference is that at the stage of selecting the information base location type, you must select “On the 1C:Enterprise server”.

In the “Server cluster” item, specify the name (or better yet, the IP address) of the server on which you installed SQL.

In the “Infobase name” section, specify any name you want to give to the database.

DBMS type – SQL.

The database user and his password are the same superuser mentioned above during the installation of MS SQL.

Leave the date offset as default.

It is necessary to check the “Create a database if it does not exist” option and click “Next”.

Now the database has been successfully created on the SQL server and added to the list of available databases. Below in the picture you can see the result of the work done.

It is worth noting that the created database is still empty. This is a framework, a place allocated in SQL for your information base. In order to load your database into this framework, you need to use the Upload/Load information base tools. The Upload/Download procedure is also described in our other article “1C Administration”.

In order to bring the system to an ideal state in the future, it will be necessary to configure a “maintenance plan” for the created database. A maintenance plan is a set of procedures that SQL will perform regularly on a given schedule. For example, it will regularly make backups and delete temporary files. Working with SQL is beyond the scope of this article and will be described in one of the following.

Server cluster 1C:Enterprise 8 (1C:Enterprise 8 Server Cluster)

The 1C:Enterprise 8 server cluster is the main component of the platform, which ensures interaction between the database management system and the user in the case of client-server operation. The cluster makes it possible to organize uninterrupted, fault-tolerant, competitive work for a significant number of users with large information databases.

A 1C:Enterprise 8 server cluster is a logical concept that denotes a set of processes that serve the same set of information databases.

The following capabilities of a server cluster can be identified as the main ones:

  • the ability to function both on several and on one computer (working servers);
  • each worker server can support the functioning of one or several worker processes that service client connections within the boundaries of this cluster;
  • the inclusion of new clients in the cluster’s work processes occurs based on a long-term analysis of work process load statistics;
  • interaction of all cluster processes with each other, with client applications and the database server is carried out via the TCP/IP protocol;
  • cluster processes are running, can be either a service or an application

Client-server option. Scheme of work

In this option, a client application interacts with the server. The server cluster, in turn, interacts with the database server.

The role of the central server of the cluster is played by one of the computers that are part of the server cluster. In addition to serving client connections, the central server also manages the operation of the entire cluster and stores the registry of this cluster.

The cluster is addressed for client connections by the name of the central server and possibly the network port number. If a standard network port is used, then to connect you just need to specify the name of the central server.

During connection establishment, the client application contacts the central server of the cluster. Based on the analysis of worker process load statistics, the central server forwards the client application to the required worker process, which should serve it. This process can be activated on any working server in the cluster, in particular on the central server.

Connection maintenance and user authentication are supported by this workflow until the client stops working with a specific infobase.

Server cluster

A basic server cluster can be a single computer and contain only one worker process.

In the figure you can observe all the elements that, one way or another, take part in the operation of the server cluster. These are the following elements:

  • server cluster processes:
    o ragent.exe;
    o rmngr.exe;
    o rphost.exe;
  • data storage:
    o list of clusters;
    o cluster registry.

The ragent.exe process, called the server agent, ensures the functioning of the computer as part of a cluster. Therefore, the computer on which the ragent.exe process is running should be called a production server. In particular, one of the functional responsibilities of ragent.exe is to maintain a registry of clusters that are located on a specific working server.

Neither the cluster registry nor the server agent are an integral part of the server cluster, but only enable the server and the clusters located on it to function.

The server cluster itself consists of the following elements:

  • one or more rmngr.exe processes
  • cluster registry
  • one or more rphost.exe processes.

Cluster manager (process rmngr.exe). It serves to control the functioning of the entire cluster. A cluster may include several rmngr.exe processes, one of which will always be the main manager of this cluster, and the remaining processes will be additional managers. The central server of the cluster should be called the working server on which the main cluster manager operates and which contains the cluster list. Maintaining the cluster registry is one of the functions of the main cluster manager.

Worker process (rphost.exe process). It is he who directly serves client applications, interacting with the database server. During this process, some server module configuration procedures may be executed.

Scalability of 1C version 8.3

Scalability of a server cluster is achieved in the following ways:

  • increase the number of managers in the cluster and the distribution of services between them
  • increase the number of worker processes that operate on a given worker server
  • increase the number of working servers that make up the cluster.

Using several managers simultaneously.

The functions performed by the cluster manager are divided into several services. These services can be assigned to different cluster managers. This makes it possible to evenly distribute the load across several processes.

However, some services can only be used by the main cluster manager:

  • cluster configuration service
  • debug item management service
  • cluster lock service.

For other services, arbitrary cluster managers are allowed to be assigned:

  • log service
  • object blocking service
  • job service
  • full text search service
  • session data service
  • numbering service
  • custom settings service
  • time service
  • transaction blocking service.

Using multiple workflows simultaneously.

On the one hand, the use of several work processes makes it possible to reduce the load of each specific work process. On the other hand, the use of multiple worker processes leads to more efficient use of the hardware resources of the production server. Moreover, the procedure for launching several work processes increases the reliability of the server, as it isolates groups of clients that work with different information bases. A worker process in a cluster that allows multiple worker processes to run can be restarted automatically within a time interval specified by the cluster administrator.

The ability to use more worker processes (increasing the number of client connections) without increasing the load on a specific worker process results in an upward change in the number of worker servers that are part of the cluster.

Fault tolerance of 1C version 8.3

Resilience to cluster failures is ensured in three ways:

  • redundancy of the cluster itself
  • reservation of work processes
  • resistance to communication channel interruption.

Backing up a 1C cluster version 8.3

Several clusters are combined into a redundancy group. Clusters that are in such a group are automatically synchronized.

If the active cluster fails, it is replaced by the next working cluster in the group. Once the failed cluster is restored, it will become active after data synchronization.

Backup of 1C work processes version 8.3

For each of the workflows, it is possible to specify options for its use:

  • use
  • do not use
  • use as a backup.

If a process crashes, the cluster starts using a currently inactive backup process instead. In this case, the load on it is automatically redistributed.

Resistance of 1C version 8.3 to communication channel interruption

Since each user is provided with his own communication session, the cluster stores data about the users who connected and what actions they performed.

If the physical connection disappears, the cluster will be in a state of waiting for a connection with this user. In most cases, after the connection is restored, the user will be able to continue working exactly from the point where the connection was lost. There is no need to reconnect to the infobase.

Sessions in 1C version 8.3

A session makes it possible to determine the active user of a specific infobase and determine the control flow from this client. The following types of sessions are distinguished:

  • Thin client, Web client, Thick client - these sessions occur when the corresponding clients access the infobase
  • Connection of the “Configurator” type - it occurs when accessing the configurator infobase
  • COM connection – formed when using an external connection to access an infobase
  • WS connection – occurs when accessing the web server infobase as a result of accessing a Web service published on the web server
  • Background job – created when a cluster worker process accesses the infobase. Such a session is used to execute the code of the background job procedure,
    Cluster console – created when the client-server administration utility accesses a worker process
  • COM administrator – occurs when a worker process is accessed using an external connection.
  • Work under different operating systems

Any server cluster processes can operate under both the Linux operating system and the Windows operating system. This is achieved by the fact that cluster interaction occurs under the control of the TCP/IP protocol. The cluster can also include working servers running any of these operating systems.

Server Cluster Administration Utility 8.3

The system package includes a utility for administering the client-server option. This utility makes it possible to change the composition of the cluster, manage information bases, and quickly analyze transaction locks.

Several worker processes on one server make it possible to effectively use the amount of RAM and processor resources to execute requests, as well as connect a client session to another worker process if the current one “crash”.
The Server Agent (ragent) program is responsible for understanding what is running on a specific server. Stopping the server agent will make the server unavailable for use by the cluster. The agent stores its information in the file srvribrg.lst.

Information about work databases and involved work processes is owned by the “Server Manager” (rmngr). It stores this information in the file 1CV8Reg.lst. Stopping the server manager can lead to a restart of client applications if the manager restarts successfully or to a complete stop of the working servers of the entire cluster.

1C: The enterprise allows the possibility of creating several independent clusters on one server. Each of them is identified on the network by a unique “IP port” and a unique number in service files. The first cluster receives port 1541 by default.

The Enterprise Servers snap-in is designed to manage the cluster.
You can connect to servers by server name or IP address.

Server agent

The server agent “knows” about all the clusters that are running on the server. This information is stored in the file srvribrg.lst with a list of clusters and list administrators. The main port of the agent is 1540. On each Working server, only one agent can be launched, servicing all possible clusters on this server.

Let's take a closer look at the cluster properties

Restart interval

This parameter restarts 1C server work processes according to the specified value in seconds. Typically, the parameter is used on application servers that have a 32-bit system, since the memory capacity there is limited to ~ 3.7 GB if the operating system is 64-bit and the application server is 32-bit. If the OS uses a 32-bit architecture, then the total memory consumption of the working process is ~ 1.7 GB. And users can often receive an error message like “Insufficient memory on the 1C Enterprise server.” The easiest way to avoid this error is to restart the work processes, for example 86400 seconds (1 day). When changing the parameter, the time count starts from the start of the 1C application server service.

Allowed memory size

Restarting worker processes when a certain threshold of memory occupied by the worker process in kilobytes is reached.

Interval for exceeding the permissible amount of memory

This means that if within a specified number of seconds the memory specified in the “allowable memory amount” parameter is exceeded, then the 1C server will decide to restart the workflow.

Permissible deviation of the number of server errors

It is calculated as follows. We have server calls that can be seen in the technology log by the “CALL” event, and there are also various exception situations that can be seen in the technology log by the “EXCP” event. The platform calculates the ratio of these events. It is assumed that these events should be approximately the same. If in any work process this ratio exceeds the ratio of these events in other work processes by some significant amount, then such a work process is considered problematic. Just this value is set in this parameter. The recommended value is 50.

Force termination of problematic processes

If we enable this parameter, then according to the “permissible deviation in the number of server errors” parameter, problematic processes will be terminated. If the parameter is disabled, the platform displays the process log event “ATTN”, which indicates the problematic process.

Stop disabled processes after

If one of the “restart interval” or “allowable memory size” parameters is triggered, then when the working process is restarted, it may “fall off”. If the client does not access the server during the restart (is inactive), then the next time it accesses it, it will smoothly switch to the new worker process. If the client contacts the server at the time of restarting the workflow, then in this case it will receive an error message and terminate its work. To prevent this from happening, you must set the value of this parameter in seconds. Usually 120 seconds is enough. During this time, the workflow will have time to process current customer requests and transfer them to a new workflow. Those active clients that the process did not have time to process are terminated and the clients may receive an error.

Fault tolerance level

This setting lives on its own, regardless of the number of central servers. The fault tolerance level can take any value. For example, resiliency level = 1, then each user session is doubled. If the fault tolerance level = 2, then each session is multiplied by 3. The load on the server also increases. When changing the fault tolerance level, if we have a central server, it replicates to each central server: “cluster registry”, “cluster locking service”. There is also replication of services such as “session data service”, “online time stamp service”, “object blocking service”, “licensing service”, “numbering service” to other servers. Among them, the heaviest one is the “session data service”.

Load sharing mode

In terms of performance. When a client connection connects, it will connect to whichever server has a worker process with more available performance. The available performance is set in the workflow properties:


The available performance at the 1C level is calculated as follows: a reference server call is made to all work processes once every 10 minutes and the time of this call is measured. The resulting number is divided by 10,000 (ten thousand) and the application server mechanisms calculate the reference time. In the event that the productivity of a work process has become 25% less than that of the others, connections from this work process begin to go to other work processes until all connections are gone.

Memory priority. User connections will be made to a production server that has more available memory.

Cluster Manager

The cluster manager is responsible for the operation of the cluster. Each cluster has its own Manager. The manager stores information about the cluster in the file 1CV8Reg.lst (cluster registry). Each Cluster Manager also has its own port on the Work Server. For the first cluster, the default Manager port is 1541. It is this port that is displayed in the 1C Servers: Enterprise snap-in in the Clusters branch, identifying the cluster.
The manager receives requests from the client part of 1C: Enterprise and decides which Workflow to give this service request to.

The Manager uses the service port to interact with worker processes.

The working process

The Work Process is responsible for “working with clients.” There can be several worker processes in the 1C: Enterprise 8 cluster. The number of work processes is not created manually, but is calculated based on descriptions of task requirements for fault tolerance and reliability. The server manager decides which worker process will serve the client connection. For client connections, Worker Processes are by default allocated a range of IP ports 1560 – 1591. In addition, each Worker Process is assigned a Service port for communication with the cluster manager.

The working server settings, according to 1C documentation, can only be changed in the CORP version of the 1C application server. In fact, the settings work in both the CORP and PROF versions. If these settings are used in the PROF version, this will be a violation of the license agreement.

Maximum Workflow Memory

This parameter in itself does not limit anything. It works in conjunction with the “safe memory consumption per call” parameter. Let’s imagine that all our work processes in total have reached approximately the memory consumption of the specified value of this parameter. And now a certain user wants to make a certain server call that wants to consume a large amount of memory. As soon as the server call exceeds the amount of memory specified in this parameter by the amount of memory in the “safe memory consumption for one call” parameter, this particular user will receive an error of the form: “safe memory consumption for one client-server call has been exceeded.” This is necessary so that one user cannot overwhelm the working server. The value of parameter 0 is equal to 80% of the memory installed on the 1C server.

Safe memory consumption per call

A value of 0 (default) is 5% of the Maximum Workflow Memory value. The value may be -1. This means that any client-server call that exceeds the specified value of the “maximum worker memory size” parameter.

The amount of work process memory up to which the server is considered productive

Means, if set to a value and worker processes have taken up the amount of memory specified in this parameter, the server will continue to run, but will not accept new connections until the memory is freed.

Number of information security per process

There may be a decrease in performance when there are many infobases and one workflow. Therefore, with this parameter it is possible to reduce the number of databases per process. If you set the value to 1 (in most cases this works quite optimally), then a new worker process (rphost) will be created for each infobase.

Number of connections per process

Same as the parameter above, but depends on the number of connections per process. A value of 0 will mean that there will be only one worker process on each worker server.

Manager for each service

Each central worker server has a main cluster manager with certain services:


They are executed by one service “rmngr”. Let's imagine that this service begins to consume a lot of memory or waste CPU resources. There are usually a few typical suspects. But suddenly you are at a “dead end” and cannot understand what exactly is loading the service, you can check the “manager for each service” checkbox, the service will be divided into 21 processes (this is the number of services in the main cluster manager). And accordingly, using the PID of the process, it will be possible to calculate which service is loading the system.

Central server

This is the server that stores the cluster registry in the 1CV8Clst.lst file. The file stores a list of databases, a list of cluster administrators, a list of functionality assignment requirements, a list of security profiles, and in general all cluster settings. This file is present only where the “central server” checkbox is checked. There can be several central servers. Also on the central servers there are such services as “cluster blocking service”, “cluster configuration service”. As long as at least one central server is operational, the cluster is functioning. Once the most recent central server fails, the cluster becomes unusable regardless of fault tolerance settings.

Functionality assignment requirement

The 1C Enterprise 8.3 server cluster provides a certain set of functionality (called requirement objects), the distribution of which between working servers within the cluster can be controlled. For example, you can specify that all background jobs in the cluster will run on a selected worker server. In order to place a connection or cluster service on any production server, you need to create a functionality assignment requirement for the selected production server. This requirement determines the ability or impossibility of a particular server to perform a particular job. Let's take a closer look at what a functionality assignment requirement is.

Migrating User Connections

Let's say we want user connections to work on worker server #1, but if that server goes down, we want them to fail over to another worker server #2

To do this, we need to create a functionality assignment requirement on server No. 1:


On server No. 2, set the same settings, but change the priority:


The importance of priority is implemented in reverse. That is, priority 1 is higher than priority 2.

Remove the production server from the cluster

We can simply remove the working server from the cluster by deleting it from the list, but in this case all users will be “kicked out” from the system. To make the withdrawal more painless, you can do the following:

Create a functionality assignment requirement with the following settings:


This setting means that there will be no new connections to this production server. Those users who were working will continue to work, but will gradually move to other working servers.

Licensing service

Move the licensing service to a separate server. This is good because software licenses can be tied to a specific computer. Let's create a functionality assignment requirement with the following settings:


Background jobs

With the release of platform 8.3.7, background jobs were divided into 2 groups:

1. Background jobs called from configuration code

2. Routine tasks

Therefore, several settings for assigning functionality are required:



1. To make background jobs run quickly, you need to add session data for background and scheduled jobs



After creating the necessary requirements for assigning functionality, you need to apply them:


Partial – application that will not disrupt the user experience

Full – an application that may disrupt the user experience.

In practice, I have never encountered a situation where, when fully applied, it disrupted the user experience or anything similar. But anything is possible, keep in mind. After application, restarting the 1C application server service is not necessary.

You can always contact 1C optimization specialists; our practical experience will save your time.

In addition to the file version, the 1C:Enterprise system can work with information bases in a client-server version. In the latter case, an architecture is understood that consists of several software layers, schematically depicted in the figure below.

  • Client applications, thin clients and web clients- this is “1C:Enterprise” in various launch modes with which the end user works. For client applications and thin clients, a web browser is sufficient on users' computers (or on), for a web client.
  • Server cluster "1C:Enterprise" is a collection of work processes running on one or more computers and a list of information bases that are located in this cluster. In the server cluster, all the work of application objects is performed, preparations are made for displaying forms (reading infobase objects, filling out form data, arranging elements, etc.) and the command interface, generating reports, and running background jobs. Clients only display information prepared in the server cluster. In addition, service files are stored on the 1C:Enterprise cluster server, as well as an infobase registration log.
  • Database server— on the database server, direct storage and work with data takes place, provided by one of the following database management systems (DBMS) supported by the 1C:Enterprise system:
    • Microsoft SQL Server from Microsoft SQL Server 2000 and higher;
    • PostgrageSQL since version 8.1;
    • IBM DB2 since version 9.1;
    • Oracle Database since version 10g Release 2.
  • Web server required only for web clients and one of the thin client options. Provides interaction of these types of connections with a cluster of 1C:Enterprise servers.

It is also worth noting that each software layer does not necessarily have to be located on a separate physical computer. A server cluster can be located on the same computer with a database server, web server, etc. For example, the following work structure is often found in small organizations:

In this article I will describe the installation of the 1C:Enterprise server version 8.3.4.389 (for other versions of the 1C:Enterprise platform 8.1, 8.2 and 8.3 the steps are similar) on one computer running Windows Server 2008 (R2) or Windows Server 2012 (R2). Microsoft SQL Server 2008 (R2) or Microsoft SQL Server 2012 will be considered as a DBMS. For this we will need:

  1. A computer that meets the system requirements for installing the 1C:Enterprise server and with the OS installed on this computer or .
  2. A computer for a database server, also running an OS or (can be the computer from step 1).
  3. Local administrator rights on both computers.
  4. Distribution kit for installing the 1C:Enterprise server 8.
  5. Software license or HASP4 Net protection key for the 1C:Enterprise server.
  6. Distribution kit for installing Microsoft SQL Server 2008 (R2) or Microsoft SQL Server 2012.

2. Installation of MS SQL Server DBMS

We install the MS SQL Server DBMS on the computer that serves as the database server. To operate the 1C:Enterprise system, it is enough to install the following components:

  • Database Engine Services
  • Management Tools - Basic
    • Management Tools - Complete.

Select sorting options " Cyrillic_General_CI_AS" Details about installing systems

3. Configuring Windows Firewall for DBMS operation

If the database server and the 1C:Enterprise cluster server are located on different physical computers, you need to configure the Windows Firewall on the database server so that the 1C:Enterprise server can work with the DBMS, namely, open incoming connections on the port 1433 (for default SQL Server instance).

  • I wrote in detail about setting up Windows Firewall for Microsoft SQL Server 2008 (R2) / 2012.

4. Adding a user to MS SQL Server

Next, we will add a separate user to MS SQL Server, under which the 1C:Enterprise server databases will be connected. This user will also be the owner of these databases. The user to be added must be authorized on the server using a password and have the following set of roles: dbcreator, processadmin, public. Details about adding a user to

  • Microsoft SQL Server 2008 (R2) I wrote.
  • I wrote Microsoft SQL Server 2012.

5. Installation of the 1C:Enterprise server

Now let's move on to installing the 1C:Enterprise server files and starting the corresponding service. Installation requires a distribution kit of the 1C:Enterprise technology platform. From the list of supplied distributions, the following are suitable:

  • 1C:Enterprise technology platform for Windows - allows installation of a 32-bit 1C:Enterprise server
  • 1C:Enterprise server (64-bit) for Windows - allows installation of both 32-bit and 64-bit 1C:Enterprise servers

(There is also an extended version of KORP server 1C:Enterprise 8.3, details can be found on the 1C website)

Open the directory with the 1C:Enterprise server installation files and run the file setup.exe.

The 1C:Enterprise system installation assistant will start. On the first page click " Further».

On the next page you need to select the components that will be installed; we require the following components:

  • Server 1C:Enterprise— 1C:Enterprise server components
  • Server administration 1C:Enterprise 8— additional components for administering a cluster of 1C:Enterprise servers

The remaining components (the list of components may depend on the specific distribution), depending on the need, can also be installed on this computer. Having made your choice, click “ Further».

Select the interface language that will be used by default and click " Further».

If the 1C:Enterprise server is installed as a Windows service (and in most cases it should be installed as such), I recommend immediately creating a separate user under which the created service will be launched. For this

  • Leave the flag "on" Install 1C:Enterprise server as a Windows service (recommended)»;
  • We move the corresponding switch to “ Create user USR1CV8».
  • Enter the password for the user being created twice. By default, the password must comply with the Windows password policy. You can read more about this:
    • For Microsoft Windows Server 2008 (R2) - ;
    • For Microsoft Windows Server 2012 - .

You can also select an existing user to run the 1C:Enterprise server. In this case, the selected user must have the following rights:

  • Log on as a service
  • Log on as a batch job
  • Performance Log Users.

Also, the user must be given the necessary rights to the directory of server service files (by default C:\Program Files\1cv8\srvinfo for 64-bit and C:\Program Files (x86)\1cv8\srvinfo for a 32-bit server).

Automatically created user USR1CV8 will have all of the above rights.

After filling in the appropriate parameters, click “ Further».

And finally, click “ Install» to start the installation. This will copy the files of the selected components, create configuration files, register program components, create shortcuts, and also start the 1C:Enterprise server service.

Once the installation is complete, the assistant will prompt you to install the protection driver - HASP Device Driver. If you are using a software license for the 1C:Enterprise server, there is no need to install the driver. Leave or remove the flag " Install protection driver" and click " Further».

Often, other services run on the machine along with the 1C:Enterprise server - a terminal server, SQL server, etc. And at some point the 1C:Enterprise server, or rather the rphost worker process, eats up more memory than planned or all the memory. Which leads to a slowdown of other services and zombies of the server. To avoid such situations, you need to configure automatic restart of 1C:Enterprise server workflows

Solution

1. Open the administration console of 1C Enterprise servers;
2. Expand the central server tree to clusters and select the cluster that interests us. In the example there is only one cluster;
3. Open the properties of the selected cluster and see the following form

Properties of the 1C:Enterprise 8.3 server cluster

Let's look at the example shown in the image:

Restart interval— time after which the rphost process will be forced to restart. Before the process terminates, a new rphost process is launched, to which all connections are transferred, and only then will the old process terminate. This will not affect the user's experience in any way. The interval is indicated in seconds, in the example 24 hours are indicated.

Allowed memory size— the amount of memory within which the workflow can operate without problems. The volume is indicated in kilobytes, in the example the value is 20 gigabytes (in fact, the figure is too large and you need to start from the specific system, but the average figure is 4 GB). As soon as the memory occupied by the working process exceeds the specified value, the countdown begins.

Interval for exceeding the permissible amount of memory— after the timer launched after exceeding the permissible amount of memory counts down the specified time, a new worker process will be launched, to which all connections are transferred, the old process is marked as disabled. The interval is specified in seconds, in the example 30 seconds are indicated.

Stop disabled processes after— the time after which the workflow marked as disabled will be stopped; if the value is 0, the process will not be completed. The interval is specified in seconds, in the example 60 seconds are indicated.

After applying the settings, you do not have to restart the server service; they are applied dynamically.

Total

This is how we set up automatic restart of 1C:Enterprise server work processes and get a more stable system; if a memory leak occurs, the work of a specific session will be terminated.

Also, in some situations, you can play with the settings and prevent a possible server crash if you make mistakes.



Related publications