mirror of
https://github.com/asterisk/asterisk.git
synced 2025-09-02 11:06:31 +00:00
88579d2d7f
This enables setting cache_type classes to a round-robin queueing system
rather than the historic stack mechanism.
This should result in lower risk of connection drops due to shorter idle
times (the first connection to go onto the stack could in theory never
be used again, ever, but sit there consuming resources, there could be
multiple of these).
And with a queue rather than a stack, dead connections are guaranteed to
be detected and purged eventually.
This should end up better balancing connection_cnt with actual load
over time, assuming the database doesn't keep connections open
excessively long from it's side.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
UserNote: When using res_odbc it should be noted that back-end
connections to the underlying database can now be configured to re-use
the cached connections in a round-robin manner rather than repeatedly
re-using the same connection. This helps to keep connections alive, and
to purge dead connections from the system, thus more dynamically
adjusting to actual load. The downside is that one could keep too many
connections active for a longer time resulting in resource also begin
consumed on the database side.
(cherry picked from commit 49d87e4f81)
144 lines
6.1 KiB
Plaintext
144 lines
6.1 KiB
Plaintext
;;; odbc setup file
|
|
|
|
; ENV is a global set of environmental variables that will get set.
|
|
; Note that all environmental variables can be seen by all connections,
|
|
; so you can't have different values for different connections.
|
|
[ENV]
|
|
;INFORMIXSERVER => my_special_database
|
|
;INFORMIXDIR => /opt/informix
|
|
;ORACLE_HOME => /home/oracle
|
|
|
|
; All other sections are arbitrary names for database connections.
|
|
|
|
;
|
|
; The context name is what will be used in other configuration files, such
|
|
; as extconfig.conf and func_odbc.conf, to reference this connection.
|
|
[asterisk]
|
|
;
|
|
; Permit disabling sections without needing to comment them out.
|
|
; If not specified, it is assumed the section is enabled.
|
|
enabled => no
|
|
;
|
|
; This value should match an entry in /etc/odbc.ini
|
|
; (or /usr/local/etc/odbc.ini, on FreeBSD and similar systems).
|
|
dsn => asterisk
|
|
;
|
|
; Username for connecting to the database. The user defaults to the context name if unspecified.
|
|
;username => myuser
|
|
;
|
|
; Password for authenticating the user to the database. The default
|
|
; password is blank.
|
|
;password => mypass
|
|
;
|
|
; Build a connection at startup?
|
|
pre-connect => yes
|
|
;
|
|
; What should we execute to ensure that our connection is still alive? The
|
|
; statement should return a non-zero value in the first field of its first
|
|
; record. The default is "select 1".
|
|
;sanitysql => select 1
|
|
;
|
|
; The maximum number of connections to have open at any given time.
|
|
; This defaults to 1 and it is highly recommended to only set this higher
|
|
; if using a version of UnixODBC greater than 2.3.1.
|
|
;max_connections => 20
|
|
;
|
|
; When the channel is destroyed, should any uncommitted open transactions
|
|
; automatically be committed?
|
|
;forcecommit => no
|
|
;
|
|
; How should we perceive data in other transactions within the database?
|
|
; Possible values are read_uncommitted, read_committed, repeatable_read,
|
|
; and serializable. The default is read_committed.
|
|
;isolation => repeatable_read
|
|
;
|
|
; Is the backslash a native escape character? The default is yes, but for
|
|
; MS SQL Server, the answer is no.
|
|
;backslash_is_escape => yes
|
|
;
|
|
; How long (in seconds) should we attempt to connect before considering the
|
|
; connection dead? The default is 10 seconds, but you may wish to reduce it,
|
|
; to increase responsiveness.
|
|
;connect_timeout => 10
|
|
;
|
|
; When a connection fails, how long (in seconds) should we cache that
|
|
; information before we attempt another connection? This increases
|
|
; responsiveness, when a database resource is not working.
|
|
;negative_connection_cache => 300
|
|
;
|
|
; Enable query logging. This keeps track of the number of prepared queries
|
|
; and executed queries as well as the query that has taken the longest to
|
|
; execute. This can be useful for determining the latency with a database.
|
|
; The data can be viewed using the "odbc show" CLI command.
|
|
; Note that only successful queries are logged currently.
|
|
;logging => yes
|
|
;
|
|
; Slow query limit. If a query exceeds the given amount of time (in milliseconds)
|
|
; when executing then a WARNING message will be output to indicate that there
|
|
; may be a problem. Note that logging must be set to "yes" for this to occur. By
|
|
; default this is set to 5000 milliseconds (or 5 seconds). If you would like to
|
|
; disable the WARNING message it can be set to "0".
|
|
;slow_query_limit => 5000
|
|
;
|
|
; Set the type of connection cache. Historically res_odbc used a stack, resulting in
|
|
; a single connection being re-used frequently, whilst other connections could end up
|
|
; dying. Using a queue or round-robin strategy results in all connections being re-used
|
|
; and kept alive.
|
|
; Each strategy has pros and cons as debated on
|
|
; https://github.com/asterisk/asterisk/pull/1026. In summary, the stack results
|
|
; in a small number of connections remaining "hot" on the database side which
|
|
; could argumentatively maintain higher performance at the cost of longer-idle
|
|
; connections being timed out from the DB side, resulting in a short CPU spike on
|
|
; asterisk side when that "dead tail" is attempted to be used. The queue on the
|
|
; other hand will keep the load more spread over connections, resulting in them
|
|
; being kept active, avoiding the CPU spike on asterisk side to a much larger
|
|
; degree, at the cost of potentially keeping more connections (which could
|
|
; potentially be purged DB side) active.
|
|
; The default remains a stack to be backwards compatible, setting this value to
|
|
; any of rr, roundrobin or queue will result in a round-robin queue being used.
|
|
;cache_type => roundrobin
|
|
|
|
[mysql2]
|
|
enabled => no
|
|
dsn => MySQL-asterisk
|
|
username => myuser
|
|
password => mypass
|
|
pre-connect => yes
|
|
|
|
; Certain servers, such as MS SQL Server and Sybase use the TDS protocol, which
|
|
; limits the number of active queries per connection to 1.
|
|
[sqlserver]
|
|
enabled => no
|
|
dsn => mickeysoft
|
|
max_connections => 5
|
|
username => oscar
|
|
password => thegrouch
|
|
pre-connect => yes
|
|
sanitysql => select count(*) from systables
|
|
; forcecommit => no ; Default to committing uncommitted transactions?
|
|
; Note: this is NOT the autocommit flag; this
|
|
; determines the end result of transactions which
|
|
; are not explicitly committed or rolled back. By
|
|
; default, such transactions are rolled back if the
|
|
; call ends without an explicit commit.
|
|
; isolation => read_committed ; Isolation level; supported levels are:
|
|
; read_uncommitted, read_committed, repeatable_read,
|
|
; serializable. Note that not all databases support
|
|
; all isolation levels (e.g. Postgres only supports
|
|
; repeatable_read and serializable). See database
|
|
; documentation for further information.
|
|
;
|
|
; Many databases have a default of '\' to escape special characters. MS SQL
|
|
; Server does not.
|
|
backslash_is_escape => no
|
|
|
|
;
|
|
; If you are having problems with concurrency, please read this note from the
|
|
; mailing lists, regarding UnixODBC:
|
|
;
|
|
; http://lists.digium.com/pipermail/asterisk-dev/2009-February/036539.html
|
|
;
|
|
; In summary, try setting "Threading=2" in the relevant section within your
|
|
; odbcinst.ini.
|
|
;
|