Kbase 32916: Corrective Measures for Error 748
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Solution ID: P2916
SYMPTOM(s):
The server or the system has no more resources. Try a larger -n. (748)
CAUSE:
Error 748 can be caused when: the -n setting is not high enough, the kernel parameters for semaphores might not be set correctly, or the services file might not be set up properly.
If you are connected to more than one database, the settings for each server startup will need verification.
When you see error 748, this means that an attempt was made to exceed the limit for the number of users making a connection to the database. If you feel you have received this error inappropriately, try the steps listed in the "Fix" section of this Solution.
FIX:
1. Check the -n value being set on the broker startup line.
If it is not found in the startup, the default value is normally 20.
2. Run promon against the database while it is running.
Choose option 6. Shared Resources, and verify that the -n displayed in promon matches the -n on the startup line.
If it does NOT match, then you have found the problem. Check your startup
scripts and make sure that you are using the right syntax when starting the
broker. Then try again.
3. If it does match, then you need to determine if the problem is with remote clients or local clients.
Remote clients are those that start a Progress session from a different system than the system running the broker for the database.
Local clients start Progress from the same machine that has the broker running for the database.
4. If the problem is with remote clients, check the setup of the services file.
Specifically, check the entry for the database that is having the problem. The correct syntax for the service should be:
For the startup line:
proserve demo -H sun1 -S demosv -N tcp
The services entries should look like this:
demosv 2500/tcp
demosv1 2501/tcp
demosv2 2502/tcp
demosv3 2503/tcp
demosv4 2504/tcp
You should allow 10 spaces for each service. The next
entry in this example should be:
nextdb 2510/tcp
nextdb1 2511/tcp
etc.
5. If this still does not solve the problem, OR if the users are local, check the settings of your kernel parameters dealing with semaphores. Please use the following formulas:
Out of all of the databases to be started on the system, take the largest -n setting from the broker startup line and use it in this formula:
SEMMSL = (-n) + 13
The 13 comes from 9 semaphores to start the broker, and 1 for each of the 4 remote client servers. 9 + 4 = 13.
Then you will need 1 for each user (-n).
SEMMNS = SEMMSL * number of db servers to be run on the system.
Set SEMMNS to the value of SEMMSL multiplied by the number of db servers (maximum) that you will be running on the system at one time.
SEMMNU = SEMMNS
Set the value of SEMMNU to equal the value of SEMMNS. You could probably set this to about 75% of SEMMNS, a conservative estimate, to make them
equal.
6. If you made any changes to your kernel, rebuild your
kernel and reboot your system.
7. If the problem still exists, please call Technical
Support