<div dir="ltr">Hi, GemStone/S 64 Bit 3.7.5, Community Edition (20-session license), single Linux host, Pharo→GemStone via linked GCI (Seaside web app + a small linked-GCI worker fleet). I've read the SysAdmin Guide sections on SHR_PAGE_CACHE_NUM_PROCS and confirmed it is correctly derived: our stone log shows SHR_PAGE_CACHE_NUM_PROCS = 72 from STN_MAX_SESSIONS = 20 (+8 system + GC/AIO/free-frame). system.conf has STN_MAX_SESSIONS = 32767, clamped to 20 by the license (log: "exceeds license limit, using STN_MAX_SESSIONS = 20"). My symptom: a deploy-time linked-GCI login fails with 4039 ("...max sessions configuration or max processes on shared cache") even when the stone is freshly started with only the primary app session active (gslist shows Stone + cache + netldi + one app; ~17 of 20 session slots free). So it appears to be the "max processes on shared cache" branch, and I think this is exactly the guide's note (p.113): ▎ "Multi-threaded operations use additional slots for their working threads while they are executing. If you are close to your session limit, these operations may prevent other sessions from logging in." Questions: 1. On Community Edition, is the number of processes that can attach to the shared page cache effectively capped at the 20-session value (so explicitly setting SHR_PAGE_CACHE_NUM_PROCS higher in system.conf won't help)? The guide says the Max is "determined by STN_MAX_SESSIONS or file descriptor limits." 2. Do linked GCI logins and multi-threaded operations (e.g. our read-through warmup, GcGems) consume multiple cache-attach slots each — enough that a handful of linked sessions + a transient login exhausts the 72-slot table well before the 20 session slots? Is there a way to see per-login cache-slot consumption (an SPC Monitor statistic like SlotsTotalCount)? 3. Is switching our transient/deploy-time login from linked to RPC the right way to avoid the shared-cache-attach path during a deploy, given the app itself must remain linked? 4. Is STN_MAX_SESSIONS = 32767 (clamped) in any way harmful vs. setting it explicitly to 20, w.r.t. the derived SHR_PAGE_CACHE_NUM_PROCS? We'd rather configure this correctly than keep bouncing the stone. Thanks for any guidance. Tariq</div>