Resolved Idle Session don't refresh (Something different)

[chrisds]

Hi guys,

Need help on this :

Situation :

1. When login QAD connection manager shows only 20 even when i put min 30 session.
2. When user opens up 2 maintenance menus, the session shows 18 idle and 2 busy. And it doesn't create new idles to 20.

Database Start up Parameters (DB version OpenEdge 10.2c. OS - Redhat Enterprise 6.6 (64 bit):

$DLC/bin/_mprosrv /home/mfg/mfgsvr/db/rksgprod -L 100000 -c 350 -B 6400 -S rksgprod -H rk.erp -N TCP -n 100 -Mn 20 -Ma 5 -Mi 3 -Mpb 48 -minport 1125 -maxport 60000

What i have done :

I guessed it could max up to 20 users. So increased the -Mn from 10 to 20 and increase -n from 50 to 100. It still give me max 20 idle session. Where did i go wrong ?
I've checked through the forums but all off it shows how to get idle. So my case is i got idle session - 20 from the start but it doesn't create new idles after some menus are opened.

Any help will be good.
Thanks.

Christopher

 

[chrisds]

Another info is overnight all the idles go missing leaving i have to restart the services.

 

[chrisds]

Guys i found the problem. I found the semaphores memory allocation are not sufficient. so i increased from 50 to 500.

cps = 50 10
instances = UNLIMITED
per_source = 500

It works now. thanks.

 

[Rob Fitzpatrick]

I don't know anything about QAD or its connection manager. However:

• OpenEdge 10.2C doesn't exist. 10.2B perhaps? Which service pack?
  • FYI, 10.2B was released 14 years ago and retired four years ago. You should think about upgrading.
• I don't know how you or your application define an "idle" session but that is not an OpenEdge database or client concept. Either a client is connected to a database and occupies one record in its connection table, or it isn't; "idleness", whatever that means, isn't a consideration.
  I am reading between the lines that you want to ensure that some minimum number of remote clients will be able to connect to the database?
• Your primary broker parameters don't make sense and should be adjusted based on your business needs. Though it is not clear to me what those are.
  • -B 6400
    This is 25 MB of buffer pool for a database with 4 KB block size, or 50 MB for an 8 KB database. This is miniscule, and will likely result in a very low ratio of logical to physical reads. So either your database is similarly miniscule, or this is a non-production database and performance doesn't matter, or your buffer pool is far too small. Though your database name suggests that this is production.
  • This primary broker is also acting as a login broker for remote connections (4GL? SQL? Both?). The -ServerType parameter is unspecified, which is a worst practice. If there are both 4GL and SQL clients in use, each should have its own login broker. If there is only one client type in use, the appropriate -ServerType should be specified on the broker.
  • It seems you are making changes to client/server parameters somewhat haphazardly in hopes of solving a connection problem or changing what you see in your application. It is better to follow a methodology. This is mine, at a high level:
    • Determine which client types will be remotely connecting to the database: 4GL, SQL, or both.
      • Plan for one login broker for each client type. Each broker gets its own static port (-S).
    • Determine the maximum number of concurrent remote connections desired for each client type.
    • For the 4GL login broker, choose a desired value for maximum clients per server (-Ma). Prior to v12, I typically go with 5 to 10. Then based on the maximum number of clients, calculate how many servers will be needed (-Mpb). For example if you want a maximum of 40 concurrent remote 4GL connections, and you choose -Ma 5, -Mbp should be 8 (40 divided by 5).
      Prior to v12, 4GL servers are single-threaded. For a given maximum client count, a lower -Mpb and higher -Ma means more work for a given server to do and more potential for clients' query latency to increase during busy periods.
    • In v12+, 4GL servers are multi-threaded by default; having many won't help performance. A -Mpb of 1 or 2 should suffice.
    • SQL servers are multi-threaded. Again, -Mpb 1 or 2 should suffice for any client count, unless it is an old buggy release and SQL servers are dying frequently. The main reason for having -Mpb higher than 1, when using multi-threaded servers, is to minimize the disruption caused when a server dies and all of its client connections die as well.
    • -Mn 20
      -Mn is a primary broker parameter. It is the total maximum of servers, across all brokers, as well as the count of secondary login brokers (i.e. brokers with a -m3 parameter). If there is only one login broker, which is the primary broker, then -Mn and -Mpb should be equal.
      You have -Mn 20, and it was originally 10, but you have -Mpb 48 on the primary broker. This doesn't make sense. This broker can't spawn 48 servers because -Mn limits the database to 20 servers in total. If this is the only login broker, set -Mpb to 20. If there are other login brokers, set -Mn to the sum of the -Mpb values of all brokers, plus the number of secondary brokers.
    • -minport 1125 -maxport 60000
      The -minport and -maxport are login broker parameters. They should be specified on each login broker, with unique ranges. The number of ports from minport to maxport, inclusive, should be at least -Mpb, as each server is bound to a port within this range when it is spawned. In your case, you need 20 ports in this range, not 58876 ports. Your maxport is far too high. Also, port numbers above 32000 are used dynamically by the OS for local ports of outbound connections, so you shouldn't use that range for database brokers or servers. Set -maxport to a reasonable value.
      Also, ensure that none of the ports in your -minport/-maxport range are in use or defined in the /etc/services file, as this will prevent OpenEdge from using them.
    • -Mi 3
      I prefer to set -Mi (minimum clients per server) to 1, to more evenly distribute the connection load between servers when there is a partial client load.
  • -n 100
    This is a primary broker parameter. It specifies the total number of concurrent database connections allowed, excluding brokers, servers, backup, and shutdown. So it includes self-service ABL clients, remote ABL and SQL clients, page writers, utilities, daemons, watchdog, etc. The fact that you are doubling its size when an error occurred suggests there wasn't a lot of planning that went into choosing the initial value.
    For example if you want to allow up to 100 remote 4GL connections (-Mn 20 * -Ma 5), your -n should be higher than 100.
  • Other parameters?
    Have you shown all of the parameters on the primary broker? If so, you are using default settings for important parameters (e.g. -spin, -bibufs, -aibufs, -omsize, -lruskips, -MemCheck, -DbCheck, -tablerangesize, -indexrangesize, etc.) that probably should not be set at default values in a production database.