Could not access any ArcGIS Enterprise portal machines. No buffer space available.

[StephenKaranja]

Hi everyone,

We're running ArcGIS Enterprise 11.5 in a single-machine deployment. When accessing the portal via a web adaptor, we get the error "Could not access any ArcGIS Enterprise portal machines. Please contact your system administrator." When accessing the portal via the 7443 port, the browser reports the error: ERR_NO_BUFFER_SPACE.

When accessing the Portal Administrator Directory (portaladmin) via port 7443, we get the following error:

RuntimeException: SocketException: No buffer space available (maximum connections reached?): connect

Restarting the server machine usually resolves the problem until it occurs again later.

We'd appreciate any help in resolving this problem. Thanks.

Regards,

Stephen

[SimonSchütte_ct]

How do your system stats look like when this error occurs and after restart?

[HenryLindemann]

In ArcGIS Server 11.5, dedicated instance pools and shared instance pools have a major impact on RAM (memory) usage, primarily through how they manage ArcSOC processes (the server processes that actually handle map/image service requests). Each ArcSOC process consumes a significant amount of RAM—typically 100–300+ MB depending on your data, symbology, and service complexity.

Dedicated Instance Pools (Older/Traditional Model)

• How it works: Every service runs in its own isolated pool of ArcSOC processes. You configure a minimum and maximum number of instances per service.
• RAM impact:
  • Higher overall RAM usage, especially on sites with many services.
  • The minimum number of instances (if set > 0) stays running 24/7, even when the service is completely idle. This keeps those ArcSOC processes in memory constantly.
  • If you have dozens or hundreds of services set to dedicated with min ≥ 1, you can quickly see very high baseline RAM consumption.
  • When demand spikes, additional instances (up to the max) spin up, further increasing RAM.
• Best for: High-traffic, mission-critical, or compute-intensive services that need guaranteed fast response and isolation (no sharing with other services).
• Drawback: Wastes RAM on low-use services. Many organizations see memory pressure or even out-of-memory issues when too many services are left on dedicated.

You can reduce RAM somewhat by setting min = 0 on low-use dedicated services (the service will spin down when idle), but this introduces a small “cold start” delay the next time someone uses it.

Shared Instance Pools (Recommended/Default in 11.5)

• How it works: All compatible map and image services share a single fixed pool of ArcSOC processes (default is usually 4 per machine; you can raise it in Site > Settings > Pooling). When a request comes in, it borrows an ArcSOC from the shared pool.
• RAM impact:
  • Significantly lower RAM usage for most deployments.
  • Idle/low-traffic services use almost no resources — they don’t keep dedicated ArcSOC processes running.
  • The shared pool itself has a small, predictable overhead: each shared ArcSOC caches information about services that have recently received requests. Memory rises gradually as more services get used, but levels off after ~50 services per recycle period.
  • Result: Far fewer total ArcSOC processes run on the server compared with dedicated mode, especially when you have many services.
• Best for: The majority of services — especially infrequently used ones (< 1 request per minute on average), cached map/image services, or sites with lots of published services.
• Default in 11.5: New sites and services published from ArcGIS Pro default to shared unless you change it.