Error: gsrvr.exe - Application Error: The application failed to initialize properly
Article ID: 23953
Software: ArcSDE 8.1, 8.3, 8.1.2, 8.2, 9.0, 9.1, 9.2, 9.3, 9.3.1
Platforms: Windows NT 4.0, 2000, 2003Server
Error Message
After making several connections to an ArcSDE service, the connection hangs and a gsrvr.exe crash appears on the ArcSDE server. Querying the arcsde service with sdemon -o status hangs. Existing connections continue to function and new connections made by way of direct connect work. Any new application server connections hang and more gsrvr.exe application errors may appear on the server.
"gsrvr.exe - Application Error: The application failed to initialize properly"
Cause
Windows has exhausted its 'non-interactive desktop heap'.
The ArcSDE application server, the giomgr, runs as a service on Windows and spawns windows child processes, called gsrvrs. All windows processes run within a desktop, a logical display and container for icons, windows, and threads.
There are two kinds of desktops: interactive and non-interactive. Desktops operate within window stations. Windows services, depending on how they start, usually allocate from the non-interactive desktop heap. The maximum amount of heap memory allocated to noninteractive desktops is limited by a Windows initialization parameter called SharedSection. If you receive the above error message, you may need to change the SharedSection parameter.
A service cannot use more memory than allocated from its non-interactive desktop. When a service exhausts its non-interactive desktop heap, it is unable to create new threads or processes.
When an ArcSDE client connects to an ArcSDE server, that server spawns a gsrvr.exe process. This gsrvr.exe process consumes a small amount of the desktop heap allocated to the ArcSDE service.
If the ArcSDE service starts as a domain account, the gsrvr.exe allocates from the desktop, a non-interactive desktop heap of 512 KB, created for the ArcSDE service.
If the ArcSDE service starts as the LocalSystem account, the gsrvr.exe allocates from the shared desktop, a non-interactive desktop heap of 512 KB, pertaining to all services running as LocalSystem.
If the ArcSDE service starts as the LocalSystem account with 'Allow service to interact with the desktop' enabled, gsrvr.exe allocates from the default desktop an interactive desktop heap of 3 MB.
The size of the interactive and non-interactive desktop heaps is determined by a registry setting under \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.
Within the 'Windows' string value, there is a 'SharedSection' parameter that by default should read:
SharedSection=1024,3072,512
The second and third parameters represent the size of the interactive and non-interactive desktop heaps. If terminal services are enabled, a fourth value may be present in this string. Windows enforces a 48 MB maximum desktop memory limit for all desktops. Windows also uses some of this 48 MB pool for its default window station, screensaver, and logon screen. The size of either of these two parameters can be changed to influence the size of the interactive and non-interactive desktop heaps.
Boosting SharedSection’s third parameter limits the total number of desktops that Windows can create, as each non-interactive desktop is larger, thus using more of the global 48 MB pool. However, each service has more memory available to it. Decreasing SharedSection’s third parameter increases the number of desktops Windows can create but decreases the amount of memory each desktop can consume. For example, increasing the third parameter of SharedSection to 2 MB tells Windows to allocate 2 MB to each new non-interactive desktop. Each service that starts up as a domain account receives a new non-interactive desktop of 2 MB. Each service that starts up as the LocalSystem account allocates from the existing 2 MB system non-interactive desktop. In this case, if the server has more than 20 services configured to start up as a domain account, service startup problems may be experienced after the 20th service is initiated. When the 20th service starts, the global 48 MB limit is close to exhaustion.
Each ArcSDE gsrvr.exe consumes approximately 9 KB of memory from the desktop in which it starts. This figure, 9 KB, is only an approximation. It may differ by platform and load. If the default configuration of the ArcSDE instance and the ArcSDE Windows service has not been changed, approximately 55-64 gsrvrs (ArcSDE client connections) can be created before the error occurs. This number also differs if Windows authentication with ArcSDE for MS SQL Server is used.
Solution or Workaround
The solution depends on the ArcSDE platform. Step 1 is applicable to all ArcSDE RDBMS types. Step 2 is applicable to SQL Server sites only. Step 3 is applicable to sites using terminal services on their sde server. All three of these steps pertain only to Windows platforms.
There is currently no method to determine how much memory is in use by a single desktop or how much is left within the global pool. Use oh.exe, a Windows resource kit tool, to monitor how many desktops are in use.
Estimate the number of gsrvrs needed. For clients like ArcView, ArcEditor, and ArcExplorer, a gsrvr is usually a single ArcSDE connection. For ArcIMS, the number of gsrvrs depends on the service type. Assuming two virtual server threads per spatial server machine CPU, follow this general formula:
(2 image service threads * total CPUs) + (number of query server threads)
For example: (2 * 8) + 8 = 24 gsrvrs
This recommendation also assumes the use of an image and query service, and all AXLs connect as the same user and database to the ArcSDE server. If different databases or users are referenced in the AXLs, then the formula becomes:
(#databases * #mapservice threads)+ (#dbs*#queryservices)
If the number of gsrvrs exceeds 55-64, the maxconnections setting of ArcSDE, consider either changing some of these connections to direct connect or boost the 3rd SharedSection parameter in the registry. As direct connect runs as a thread within the client process, no desktop is allocated to it on the ArcSDE server. To change the SharedSection, find the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems key in the registry and edit the Windows string value. Locate the 'SharedSection' string and boost its third value from 512 to 1024. This doubles the amount of gsrvrs the ArcSDE service can spawn.
SharedSection=1024,3072,1024
The server must be rebooted once SharedSection is changed.
SQL Server sites using Windows authentication for their ArcSDE connections.
Users connecting to ArcSDE services with Windows authentication may experience different connection behavior. When the ArcSDE application server spawns a gsrvr from a Windows authenticated connection, that gsrvr does not allocate from the same desktop as the app server process, the giomgr.exe, but receives its own desktop (non-interactive) of 512 KB.
Multiple Windows authenticated connections from the same machine allocate from the same desktop, but connections from different machines allocate from new desktops. If operating exclusively in Windows authentication mode, more ArcSDE connections may be serviced by reducing the size of both the interactive and non-interactive desktop heap instead of boosting it as mentioned above.
This connection behavior will change in future releases of ArcSDE for MS SQL Server.
Sites that have terminal services or Citrix deployed on their ArcSDE server.
Terminal services reduce the desktop global memory pool from 48 MB to 20 MB. This means that fewer total desktops are created. If operating in this environment, the third parameter of SharedSection can be increased, but use caution with the number of different non-localsystem services created. Remember, whenever a non-localsystem service starts, it allocates memory from the global memory pool to a new desktop.
It is not recommended that SQL Server sites use terminal services with Windows authenticated ArcSDE connections. If this configuration must be run and difficulties are experienced supporting enough ArcSDE connections, allowing the ArcSDE service to interact with the desktop may solve the problem. In this case, do not change any of the SharedSection parameters.
Article ID: 23953
Software: ArcSDE 8.1, 8.3, 8.1.2, 8.2, 9.0, 9.1, 9.2, 9.3, 9.3.1
Platforms: Windows NT 4.0, 2000, 2003Server
Error Message
After making several connections to an ArcSDE service, the connection hangs and a gsrvr.exe crash appears on the ArcSDE server. Querying the arcsde service with sdemon -o status hangs. Existing connections continue to function and new connections made by way of direct connect work. Any new application server connections hang and more gsrvr.exe application errors may appear on the server.
"gsrvr.exe - Application Error: The application failed to initialize properly"
Cause
Windows has exhausted its 'non-interactive desktop heap'.
The ArcSDE application server, the giomgr, runs as a service on Windows and spawns windows child processes, called gsrvrs. All windows processes run within a desktop, a logical display and container for icons, windows, and threads.
There are two kinds of desktops: interactive and non-interactive. Desktops operate within window stations. Windows services, depending on how they start, usually allocate from the non-interactive desktop heap. The maximum amount of heap memory allocated to noninteractive desktops is limited by a Windows initialization parameter called SharedSection. If you receive the above error message, you may need to change the SharedSection parameter.
A service cannot use more memory than allocated from its non-interactive desktop. When a service exhausts its non-interactive desktop heap, it is unable to create new threads or processes.
When an ArcSDE client connects to an ArcSDE server, that server spawns a gsrvr.exe process. This gsrvr.exe process consumes a small amount of the desktop heap allocated to the ArcSDE service.
If the ArcSDE service starts as a domain account, the gsrvr.exe allocates from the desktop, a non-interactive desktop heap of 512 KB, created for the ArcSDE service.
If the ArcSDE service starts as the LocalSystem account, the gsrvr.exe allocates from the shared desktop, a non-interactive desktop heap of 512 KB, pertaining to all services running as LocalSystem.
If the ArcSDE service starts as the LocalSystem account with 'Allow service to interact with the desktop' enabled, gsrvr.exe allocates from the default desktop an interactive desktop heap of 3 MB.
The size of the interactive and non-interactive desktop heaps is determined by a registry setting under \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.
Within the 'Windows' string value, there is a 'SharedSection' parameter that by default should read:
SharedSection=1024,3072,512
The second and third parameters represent the size of the interactive and non-interactive desktop heaps. If terminal services are enabled, a fourth value may be present in this string. Windows enforces a 48 MB maximum desktop memory limit for all desktops. Windows also uses some of this 48 MB pool for its default window station, screensaver, and logon screen. The size of either of these two parameters can be changed to influence the size of the interactive and non-interactive desktop heaps.
Boosting SharedSection’s third parameter limits the total number of desktops that Windows can create, as each non-interactive desktop is larger, thus using more of the global 48 MB pool. However, each service has more memory available to it. Decreasing SharedSection’s third parameter increases the number of desktops Windows can create but decreases the amount of memory each desktop can consume. For example, increasing the third parameter of SharedSection to 2 MB tells Windows to allocate 2 MB to each new non-interactive desktop. Each service that starts up as a domain account receives a new non-interactive desktop of 2 MB. Each service that starts up as the LocalSystem account allocates from the existing 2 MB system non-interactive desktop. In this case, if the server has more than 20 services configured to start up as a domain account, service startup problems may be experienced after the 20th service is initiated. When the 20th service starts, the global 48 MB limit is close to exhaustion.
Each ArcSDE gsrvr.exe consumes approximately 9 KB of memory from the desktop in which it starts. This figure, 9 KB, is only an approximation. It may differ by platform and load. If the default configuration of the ArcSDE instance and the ArcSDE Windows service has not been changed, approximately 55-64 gsrvrs (ArcSDE client connections) can be created before the error occurs. This number also differs if Windows authentication with ArcSDE for MS SQL Server is used.
Solution or Workaround
The solution depends on the ArcSDE platform. Step 1 is applicable to all ArcSDE RDBMS types. Step 2 is applicable to SQL Server sites only. Step 3 is applicable to sites using terminal services on their sde server. All three of these steps pertain only to Windows platforms.
There is currently no method to determine how much memory is in use by a single desktop or how much is left within the global pool. Use oh.exe, a Windows resource kit tool, to monitor how many desktops are in use.
Estimate the number of gsrvrs needed. For clients like ArcView, ArcEditor, and ArcExplorer, a gsrvr is usually a single ArcSDE connection. For ArcIMS, the number of gsrvrs depends on the service type. Assuming two virtual server threads per spatial server machine CPU, follow this general formula:
(2 image service threads * total CPUs) + (number of query server threads)
For example: (2 * 8) + 8 = 24 gsrvrs
This recommendation also assumes the use of an image and query service, and all AXLs connect as the same user and database to the ArcSDE server. If different databases or users are referenced in the AXLs, then the formula becomes:
(#databases * #mapservice threads)+ (#dbs*#queryservices)
If the number of gsrvrs exceeds 55-64, the maxconnections setting of ArcSDE, consider either changing some of these connections to direct connect or boost the 3rd SharedSection parameter in the registry. As direct connect runs as a thread within the client process, no desktop is allocated to it on the ArcSDE server. To change the SharedSection, find the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems key in the registry and edit the Windows string value. Locate the 'SharedSection' string and boost its third value from 512 to 1024. This doubles the amount of gsrvrs the ArcSDE service can spawn.
SharedSection=1024,3072,1024
The server must be rebooted once SharedSection is changed.
SQL Server sites using Windows authentication for their ArcSDE connections.
Users connecting to ArcSDE services with Windows authentication may experience different connection behavior. When the ArcSDE application server spawns a gsrvr from a Windows authenticated connection, that gsrvr does not allocate from the same desktop as the app server process, the giomgr.exe, but receives its own desktop (non-interactive) of 512 KB.
Multiple Windows authenticated connections from the same machine allocate from the same desktop, but connections from different machines allocate from new desktops. If operating exclusively in Windows authentication mode, more ArcSDE connections may be serviced by reducing the size of both the interactive and non-interactive desktop heap instead of boosting it as mentioned above.
This connection behavior will change in future releases of ArcSDE for MS SQL Server.
Sites that have terminal services or Citrix deployed on their ArcSDE server.
Terminal services reduce the desktop global memory pool from 48 MB to 20 MB. This means that fewer total desktops are created. If operating in this environment, the third parameter of SharedSection can be increased, but use caution with the number of different non-localsystem services created. Remember, whenever a non-localsystem service starts, it allocates memory from the global memory pool to a new desktop.
It is not recommended that SQL Server sites use terminal services with Windows authenticated ArcSDE connections. If this configuration must be run and difficulties are experienced supporting enough ArcSDE connections, allowing the ArcSDE service to interact with the desktop may solve the problem. In this case, do not change any of the SharedSection parameters.
No comments:
Post a Comment