[Glass] Community Edition: SHR_PAGE_CACHE_NUM_PROCS bounds concurrent logins below 20-session cap with linked GCI — right approach?

[Tariq Hamid]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20260725/1486ec84/attachment.htm>