Hello all, I'm just wondering if anyone has tried the new "increaseto" parameter in 10.1C. This appears to be a cool new tool for increasing memory parameters on the DB at run time. The issue I'm having is that it seems to want to kill off all the connected processes before it will work (see below). I'm assuming this means that the client processes must be restarted for this to work. Unfortunately I can't find any documentation on the kbase, forums and very little in the manual. Is anyone able to point me in the right direction or is this a query for tech support. Trying a "recheck" simply reproduces the same user list on the DB.
Ta
Muz
muz$ proutil sports -C increaseto -B 20000 -L 50000 -bibufs 100 -aibufs 100
OpenEdge Release 10.1C as of Sat Feb 9 15:12:57 EST 2008
Waiting for Broker connection to newly added shared memory segments. (14269)
Usr Name Type Pid
9 aaa ABL 8590
10 xxx ABL 5668
12 bbb ABL 28789
14 aaa ABL 8509
15 xxx ABL 22991
18 aaa ABL 8529
19 aaa ABL 8553
20 ddd ABL 21705
21 eee ABL 26897
22 bbb ABL 16386
24 eee ABL 28339
The database connections above have not attached to recently added shared memory segments.
Do you wish to recheck? (y/n)
n
Increase Params aborted because of shared memory allocation issue. (13977)
yes, if the database server is started in shared-memory (proserve sports2000)
and if the application client is connected in shared memory (mpro sports2000)
the "increaseto" parameter can't be used.
I reproduce the same error:
Increase Params aborted because of shared memory allocation issue. (13977)
but it works ...
... if you start the database in tcp/ip (proserve sports2000 -S 25000)
and use a network client connection (mpro sports2000 -H dbhost -S 25000):
Waiting for Broker connection to newly added shared memory segments. (14269)
Usr Name Type Pid
1 rares SRV 5946
The database connections above have not attached to recently added shared memory segments.
Do you wish to recheck? (y/n)
y
Increase Params increasing lock table size (-L) from 8192 to 50016. (13979)
Increase Params increasing buffer pools size (-B) from 3000 to 20000. (13980)
Increase Params increasing bi buffer pool (-bibufs) from 20 to 100. (13981)
Increase Params increasing ai buffer pool (-aibufs) from 20 to 100. (13982)
That question at the end ... trying pausing for a while and answering yes. I haven't tried it but my understanding is that as soon as the client does something with shared memory, it will attach and drop off the list. Your only real problem here is someone going off to lunch with their client left doing nothing. Then you get blocked. But, if you try it a few times, pretty soon you should be down to just the sleepers and you can go figure out who they are and rap their fingers.
Yes I tried that "yes" lots of times but it didn't work. Probably because some were AppServer agents .. not sure. Anyway it looks to me like the clients need to be killed off - unfortunately
If you have Appserver agents that are the cause, the root issue is not the limitations in increase to, but the problems in the AppServer code. If sessions, AppServer or self service clients are properly designed, then there is a clean, short period in which they are actively connecting to shared memory to actually do anything to the database. Of course, even the best of circumstances doesn't cure the out to lunch syndrome, where there is a connection, but no activity ... which is normally not a problem. For out to lunch users ... of which, I am sure we have all known plenty ... the real solution is disconnecting the session, but I haven't thought about it in terms of AppServer sessions. In a way, I suppose that a stateless AppServer session is like an end-user session which is normally out to lunch or at least sleeping. I suppose, that if there were sessions that did not wake over any reasonable interval, this means that you have more sessions initialized than is needed for the traffic since some are not being used in any reasonable interval.
Since I also tried at midnight - no activity - it could be a 4GL bug .. maybe
Well, the obvious question is whether or not you got a list of sessions which had not yet attached and, if so, what were those sessions and what were they doing.
It does make me wonder if there is a potential problem, one which might be more apparent with AppServer. If a user session where the user leaves the session in a static state and goes to lunch presents a block and one needs to either kill that session or wait for it to become active, then it would seem like an inactive AppServer session might present the same issues. If so, then trying to make the change at midnight could be the worst time to try. I might also mean that having excess agents would provide a more or less permanent obstacle.
Might one come up with a tool that systematically exercised all agents?
It looks as though those are all self service connections. As was already replied, self service connections will attempt to connect to the newly added shared memory segment the next time they "cross the DBMS line". In other words, they need to be active to do this.
All servers will connect to the newly added shared memory segments within 3 seconds. This includes shared memory connected app servers, secondary brokers, "regular" servers, etc.
Realize that once the self service connections have connected to the database they downgrade their suid privileges and only have their user privileges. If the user privileges are not sufficient to connect to the newly added shared memory segment then the increaseto cannot continue until they logoff. The new shm segments have the same permissions as the .db file of the database. (It is my understanding that increaseto does not support the group uid as does the CONNECT statement - that has been filed as a bug).
In your example, you exited the increaseto. At the point you exited, the increaseto has allocated a new shared memory segment but wass not using it yet. If over time, those self service connections disconnect and re-connect, they will be connected to this newly added shm segment (as will any other new connection), even after the increaseto was cancelled. If you were to re-run the increase to at a later time, chances are that it will complete without a problem because all self service connections are probably connected to the newly added shm segement.