Вообщем переодически сервер дохнет по: The WebLogic Server encountered a critical failure java.lang.OutOfMemoryError: Metaspace Reason: There is a panic condition in the server. The server is configured to exit on panic И хотя это гавно пишет типа Reason: There is a panic condition in the server. The server is configured to exit on panic чёт ни хуя он ни куда не exit.... Вообщем т.к разбираться с тем чем он жрётся нет ни времени ни желания (оно обязательно появится)... как вариант можно приделать костыль... костыль будет заключаться в ребуте сервера при возникновении этой ошибки. Что значит для этого надо... Желания и понимание что так жить нельзя, и вообще... Делаем новый модуль называем скажем: Reboot-OOMMetaSpace Идём в в новый модуль делаем Policy: Называем его OOM-Metaspace и говорит что это Server log: Жмём next в Configuration Policy пишем: log.logMessage.contains('java.lang.OutOfMemoryError: Metaspace'...
1. В OVD есть адаптер: Microsoft AD
2. В weblogic уже добавлен OVD Provider
3. Пользователи вытаскиваются просто пиздец как долго...
Пару ссылок:
http://docs.oracle.com/cd/E25054_01/core.1111/e10108/ovd.htm
http://fusionsecurity.blogspot.ru/2012/11/oamovd-jvm-tuning.html
http://fusionsecurity.blogspot.ru/2012/09/virtual-directory-performance-tuning.html
Итак
1. Открываем opmn.xml и правим start-option как показано ниже:
# vi /opt/oracle/ovdmiddleware/asinst_1/config/OPMN/opmn/opmn.xml
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms256m -Xmx256m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/ovdmiddleware/asinst_1/diagnostics/logs/OVD/ovd1/ovdGClog.log -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
2. # /opt/oracle/ovdmiddleware/asinst_1/bin/opmnctl stopall
# /opt/oracle/ovdmiddleware/asinst_1/bin/opmnctl startall
3. # tail -f ovdGClog.log
2014-04-14T13:15:55.472+0400: 2.007: [GC [PSYoungGen: 65600K->4880K(76480K)] 65600K->4880K(251264K), 0.0117770 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]
2014-04-14T13:15:56.345+0400: 2.880: [GC [PSYoungGen: 70480K->5072K(76480K)] 70480K->5072K(251264K), 0.0130290 secs] [Times: user=0.02 sys=0.02, real=0.01 secs]
2014-04-14T13:15:58.327+0400: 4.862: [GC [PSYoungGen: 70672K->7650K(76480K)] 70672K->7650K(251264K), 0.0139700 secs] [Times: user=0.05 sys=0.00, real=0.01 secs]
2014-04-14T13:16:24.074+0400: 30.609: [GC [PSYoungGen: 73250K->10855K(76480K)] 73250K->11953K(251264K), 0.0227300 secs]
4. Видим что всё супер.
5. Всё таки сделаем те настройки которые предлагают в посте на выходе получаем:
# vi /opt/oracle/ovdmiddleware/asinst_1/config/OPMN/opmn/opmn.xml
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms1024m -Xmx1024m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/ovdmiddleware/asinst_1/diagnostics/logs/OVD/ovd1/ovdGClog.log -XX:+UseConcMarkSweepGC -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
6. Перезапускаем opmnctl, в ovdGClog.log:
2014-04-14T13:39:29.805+0400: 2.316: [GC 2.316: [ParNew: 68160K->4609K(76672K), 0.0185560 secs] 68160K->4609K(1040064K), 0.0186480 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]
2014-04-14T13:39:30.944+0400: 3.455: [GC 3.455: [ParNew: 72769K->3810K(76672K), 0.0290320 secs] 72769K->8182K(1040064K), 0.0291110 secs] [Times: user=0.10 sys=0.00, real=0.03 secs]
2014-04-14T13:39:33.430+0400: 5.941: [GC 6.239: [ParNew: 71970K->5413K(76672K), 0.0156380 secs] 76342K->9785K(1040064K), 0.0157430 secs]
[oracle@fmw ovd1]$ tail -f access.log
[2014-04-14T16:29:48.275+04:00] [octetstring] [NOTIFICATION] [OVD-20043] [com.octetstring.accesslog] [tid: 17] [ecid: 0000KLWDjxmDkZI6yrzW6G1JIx7w0000XX,0] conn=994 op=3,101 SRCH base=dc=adssl,dc=ovd scope=2 filter=(&(uid=FF)(objectclass=person)) requestedAttributes=[description] sizelimit=1,000 timelimit=0 typesOnly=FALSE
[2014-04-14T16:29:51.831+04:00] [octetstring] [NOTIFICATION] [OVD-20044] [com.octetstring.accesslog] [tid: 17] [ecid: 0000KLWDjxmDkZI6yrzW6G1JIx7w0000XX,0] conn=994 op=3,101 RESULT err=0 tag=0 nentries=1 etime=3,556 dbtime=0 mem=175,319,040/249,692,160
Вообщем тут мы видим что на обработку запроса тратится просто пиздец как до хера времени а именно 3.5 секунды что очень долго!
etime=<time in milli seconds> refers to the time consumed by OVD and the Target data source to process the given query issued to OVD. (http://fusionsecurity.blogspot.ru/2012/09/virtual-directory-performance-tuning.html)
Для того что бы это etime стал вменяемым (в моём случае достаточно) надо поправить параметр <referals>false</referals>.
В файле /opt/oracle/oammiddleware/asinst_1/config/OVD/ovd1/adapters.os_xml
Или снять галочку:
В odsm.
После этого в видим улучшение ситуации:
[2014-04-14T17:22:19.675+04:00] [octetstring] [NOTIFICATION] [OVD-20043] [com.octetstring.accesslog] [tid: 22] [ecid: 0000KLWPlMRDkZI6yrzW6G1JIy3f0000Fm,0] conn=4 op=6,287 SRCH base=dc=adssl,dc=ovd scope=2 filter=(&(uid=АА)(objectclass=person)) requestedAttributes=[description] sizelimit=1,000 timelimit=0 typesOnly=FALSE
[2014-04-14T17:22:19.678+04:00] [octetstring] [NOTIFICATION] [OVD-20044] [com.octetstring.accesslog] [tid: 22] [ecid: 0000KLWPlMRDkZI6yrzW6G1JIy3f0000Fm,0] conn=4 op=6,287 RESULT err=0 tag=0 nentries=1 etime=3 dbtime=0 mem=204,783,784/251,396,096
Наглядно можно увидеть в grid например:
Для того что бы вышеописанные данные были доступны в access.log надо поправить логирование:
$ pwd
/opt/oracle/oammiddleware/asinst_1/config/OVD/ovd1
$ cat ovd-logging.xml
<?xml version='1.0' encoding='UTF-8'?>
<logging_configuration>
<log_handlers>
<log_handler name='OVDHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='/opt/oracle/oammiddleware/asinst_1/diagnostics/logs/OVD/ovd1/diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='format' value='ODL-Text'/>
<property name='encoding' value='UTF-8'/>
</log_handler>
<log_handler name='OVDAccessHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='/opt/oracle/oammiddleware/asinst_1/diagnostics/logs/OVD/ovd1/access.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='format' value='ODL-Text'/>
<property name='encoding' value='UTF-8'/>
</log_handler>
</log_handlers>
<loggers>
<logger name='com.octetstring.vde' level='NOTIFICATION:1' useParentHandlers='false'>
<handler name='OVDHandler'/>
</logger>
<logger name='com.octetstring.accesslog' level='NOTIFICATION:1' useParentHandlers='false'>
<handler name='OVDAccessHandler'/>
</logger>
</loggers>
</logging_configuration>
Если в diagnostic логе OAM присутствует ошибка:
[2018-11-06T16:00:02.586+03:00] [WLS_OAM1] [WARNING] [LIBOVD-40066] [oracle.ods.virtualization.engine.backend.jndi.adapter1] [tid: [ACTIVE].ExecuteThread: '2' for queue: 'weblogic.kernel.Def
ault (self-tuning)'] [userId: <anonymous>] [ecid: 26390a0c8bae5db8:57017763:15f9cefdfc8:-8000-000000000d690d3a,0] [APP: oam_server#11.1.2.0.0] Remote Server Failure:ovd-test.local:6501.[[
javax.naming.NamingException: LDAP response read timed out, timeout used:15000ms.; remaining name 'dc=ovd,dc=test,dc=local'
at com.sun.jndi.ldap.Connection.readReply(Connection.java:485)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:639)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:562)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1985)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1847)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1772)
то это является жопой... и короче надо сделать основные настройки OVD.
Как вариант проблема может быть и не в OVD а в LDAP который находится за OVD, это надо проверять. Но тут мы считаем что проблема конкретно в OVD.
Первое что надо сделать это блять почитать доку...
Где это делать:
Идём в em http://ovdhost.local:7002/em
Заходим в Listner выбираем наш т.е тот который на порту 6501, жмём Edit
и увеличиваем количество thread:
Как говорит дока:
Tune the Work Queue Capacity based on the expected maximum number of concurrent clients to a given LDAP Listener.
Но тут есть нюанс... если создать Local Store Adapter то разваливается мониторинг OVD и к сожалению мы не можем посмотреть по метрикам сколько у нас concurrent clients.
Поэтому дествует по expected и это где то 2000 в моём случае.
Ну тут тупо в odsm в настройка адаптера поправить количество коннектов.
Max Pool Connections
2. В weblogic уже добавлен OVD Provider
3. Пользователи вытаскиваются просто пиздец как долго...
Пару ссылок:
http://docs.oracle.com/cd/E25054_01/core.1111/e10108/ovd.htm
http://fusionsecurity.blogspot.ru/2012/11/oamovd-jvm-tuning.html
http://fusionsecurity.blogspot.ru/2012/09/virtual-directory-performance-tuning.html
OVD jvm tuning
(в моём случае не понадобилось всё это.. но ради интереса было проделано)Итак
1. Открываем opmn.xml и правим start-option как показано ниже:
# vi /opt/oracle/ovdmiddleware/asinst_1/config/OPMN/opmn/opmn.xml
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms256m -Xmx256m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/ovdmiddleware/asinst_1/diagnostics/logs/OVD/ovd1/ovdGClog.log -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
2. # /opt/oracle/ovdmiddleware/asinst_1/bin/opmnctl stopall
# /opt/oracle/ovdmiddleware/asinst_1/bin/opmnctl startall
3. # tail -f ovdGClog.log
2014-04-14T13:15:55.472+0400: 2.007: [GC [PSYoungGen: 65600K->4880K(76480K)] 65600K->4880K(251264K), 0.0117770 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]
2014-04-14T13:15:56.345+0400: 2.880: [GC [PSYoungGen: 70480K->5072K(76480K)] 70480K->5072K(251264K), 0.0130290 secs] [Times: user=0.02 sys=0.02, real=0.01 secs]
2014-04-14T13:15:58.327+0400: 4.862: [GC [PSYoungGen: 70672K->7650K(76480K)] 70672K->7650K(251264K), 0.0139700 secs] [Times: user=0.05 sys=0.00, real=0.01 secs]
2014-04-14T13:16:24.074+0400: 30.609: [GC [PSYoungGen: 73250K->10855K(76480K)] 73250K->11953K(251264K), 0.0227300 secs]
4. Видим что всё супер.
5. Всё таки сделаем те настройки которые предлагают в посте на выходе получаем:
# vi /opt/oracle/ovdmiddleware/asinst_1/config/OPMN/opmn/opmn.xml
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms1024m -Xmx1024m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/ovdmiddleware/asinst_1/diagnostics/logs/OVD/ovd1/ovdGClog.log -XX:+UseConcMarkSweepGC -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
6. Перезапускаем opmnctl, в ovdGClog.log:
2014-04-14T13:39:29.805+0400: 2.316: [GC 2.316: [ParNew: 68160K->4609K(76672K), 0.0185560 secs] 68160K->4609K(1040064K), 0.0186480 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]
2014-04-14T13:39:30.944+0400: 3.455: [GC 3.455: [ParNew: 72769K->3810K(76672K), 0.0290320 secs] 72769K->8182K(1040064K), 0.0291110 secs] [Times: user=0.10 sys=0.00, real=0.03 secs]
2014-04-14T13:39:33.430+0400: 5.941: [GC 6.239: [ParNew: 71970K->5413K(76672K), 0.0156380 secs] 76342K->9785K(1040064K), 0.0157430 secs]
OVD response time
[oracle@fmw ovd1]$ pwd
/opt/oracle/oammiddleware/asinst_1/diagnostics/logs/OVD/ovd1[oracle@fmw ovd1]$ tail -f access.log
[2014-04-14T16:29:48.275+04:00] [octetstring] [NOTIFICATION] [OVD-20043] [com.octetstring.accesslog] [tid: 17] [ecid: 0000KLWDjxmDkZI6yrzW6G1JIx7w0000XX,0] conn=994 op=3,101 SRCH base=dc=adssl,dc=ovd scope=2 filter=(&(uid=FF)(objectclass=person)) requestedAttributes=[description] sizelimit=1,000 timelimit=0 typesOnly=FALSE
[2014-04-14T16:29:51.831+04:00] [octetstring] [NOTIFICATION] [OVD-20044] [com.octetstring.accesslog] [tid: 17] [ecid: 0000KLWDjxmDkZI6yrzW6G1JIx7w0000XX,0] conn=994 op=3,101 RESULT err=0 tag=0 nentries=1 etime=3,556 dbtime=0 mem=175,319,040/249,692,160
Вообщем тут мы видим что на обработку запроса тратится просто пиздец как до хера времени а именно 3.5 секунды что очень долго!
etime=<time in milli seconds> refers to the time consumed by OVD and the Target data source to process the given query issued to OVD. (http://fusionsecurity.blogspot.ru/2012/09/virtual-directory-performance-tuning.html)
Для того что бы это etime стал вменяемым (в моём случае достаточно) надо поправить параметр <referals>false</referals>.
В файле /opt/oracle/oammiddleware/asinst_1/config/OVD/ovd1/adapters.os_xml
Или снять галочку:
После этого в видим улучшение ситуации:
[2014-04-14T17:22:19.675+04:00] [octetstring] [NOTIFICATION] [OVD-20043] [com.octetstring.accesslog] [tid: 22] [ecid: 0000KLWPlMRDkZI6yrzW6G1JIy3f0000Fm,0] conn=4 op=6,287 SRCH base=dc=adssl,dc=ovd scope=2 filter=(&(uid=АА)(objectclass=person)) requestedAttributes=[description] sizelimit=1,000 timelimit=0 typesOnly=FALSE
[2014-04-14T17:22:19.678+04:00] [octetstring] [NOTIFICATION] [OVD-20044] [com.octetstring.accesslog] [tid: 22] [ecid: 0000KLWPlMRDkZI6yrzW6G1JIy3f0000Fm,0] conn=4 op=6,287 RESULT err=0 tag=0 nentries=1 etime=3 dbtime=0 mem=204,783,784/251,396,096
Наглядно можно увидеть в grid например:
Для того что бы вышеописанные данные были доступны в access.log надо поправить логирование:
$ pwd
/opt/oracle/oammiddleware/asinst_1/config/OVD/ovd1
$ cat ovd-logging.xml
<?xml version='1.0' encoding='UTF-8'?>
<logging_configuration>
<log_handlers>
<log_handler name='OVDHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='/opt/oracle/oammiddleware/asinst_1/diagnostics/logs/OVD/ovd1/diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='format' value='ODL-Text'/>
<property name='encoding' value='UTF-8'/>
</log_handler>
<log_handler name='OVDAccessHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='/opt/oracle/oammiddleware/asinst_1/diagnostics/logs/OVD/ovd1/access.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='format' value='ODL-Text'/>
<property name='encoding' value='UTF-8'/>
</log_handler>
</log_handlers>
<loggers>
<logger name='com.octetstring.vde' level='NOTIFICATION:1' useParentHandlers='false'>
<handler name='OVDHandler'/>
</logger>
<logger name='com.octetstring.accesslog' level='NOTIFICATION:1' useParentHandlers='false'>
<handler name='OVDAccessHandler'/>
</logger>
</loggers>
</logging_configuration>
OVD Cache plugin
Как оно работает описано в доке
Основные параметры из доки:
4.2.12.1 Configuration Parameters
The following is a list and description of the Cache plug-in configuration parameters:
storeallattrs
Controls whether the Cache plug-in silently requests all attributes. Supported values are 0 (disable) or 1 (enable). By default, the storeallattrs parameter is disabled (0).
bysubject
Indicates whether cache results are shared between subjects. Supported values are 0 or 1. A value of 0 indicates results are shared between subjects and a value of 1 indicates that results are not shared between subjects. The default value is 1.
maintenanceinterval
The amount of time (in seconds) between when the cache manager checks for expired queries. The default value is 60.
size
The maximum number of entries that may be cached at any one time. The default value is 10000.
maximumage
The maximum age (or time), in seconds, that any query/entry can be stored in the cache. The default value is 600.
maxresultsize
The maximum number of entries that may be cached for any particular query. The default setting is 1000.
trimsize
When the maximum cache size is exceeded, this parameter indicates the amount by which the cache manager must reduce the balance. The default value is 10000.
Проверим скорость работы на Join Adaptere
Join`ним DB+AD (Bind adapter AD)
Деплоим плагин Cache Plugin на Join Adapter с следующими параметрами:
size=10000
maxresultsize=10000
maintenanceinterval=10
maximumage=600
1. Вытащим всех пользователей, атрибуты distinguishedName:
time ldapsearch -H ldap://test1:6501 -x -D "cn=orcladmin" -w lalal -b "dc=join" -s sub -a always -z 10000 '(uid=*)' "distinguishedName"
# numResponses: 9458
# numEntries: 9457
real 0m11.333s
user 0m0.255s
sys 0m0.375s
2. Вытащим еще раз всех пользователей, атрибут distinguishedName:
time ldapsearch -H ldap://test1:6501 -x -D "cn=orcladmin" -w lalal -b "dc=join" -s sub -a always -z 10000 '(uid=*)' "distinguishedName"
# numResponses: 9458
# numEntries: 9457
real 0m1.969s
user 0m0.161s
sys 0m0.213s
Из минусов... если мы хотим изменить какой либо атрибут в AD то надо это делать через OVD (можно использовать Apache directory studio), иначе cache plugin не будет помечать запрос как expired и запрос будет хранится в кэше время указанное параметром maximumage
Basic Tuning Considerations
https://docs.oracle.com/cd/E27559_01/doc.1112/e28552/ovd.htm#ASPER129Если в diagnostic логе OAM присутствует ошибка:
[2018-11-06T16:00:02.586+03:00] [WLS_OAM1] [WARNING] [LIBOVD-40066] [oracle.ods.virtualization.engine.backend.jndi.adapter1] [tid: [ACTIVE].ExecuteThread: '2' for queue: 'weblogic.kernel.Def
ault (self-tuning)'] [userId: <anonymous>] [ecid: 26390a0c8bae5db8:57017763:15f9cefdfc8:-8000-000000000d690d3a,0] [APP: oam_server#11.1.2.0.0] Remote Server Failure:ovd-test.local:6501.[[
javax.naming.NamingException: LDAP response read timed out, timeout used:15000ms.; remaining name 'dc=ovd,dc=test,dc=local'
at com.sun.jndi.ldap.Connection.readReply(Connection.java:485)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:639)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:562)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1985)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1847)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1772)
то это является жопой... и короче надо сделать основные настройки OVD.
Как вариант проблема может быть и не в OVD а в LDAP который находится за OVD, это надо проверять. Но тут мы считаем что проблема конкретно в OVD.
Первое что надо сделать это блять почитать доку...
1. Tuning Worker Threads
Вообщем это количество тредов которые будут обслуживать запросы к OVD. По умолчанию это 10. Oracle предалагает задать по 10 тредов на ядро. Для тестовых сред предпологается что этого достаточно, для прод нужно увеличивать.Где это делать:
Идём в em http://ovdhost.local:7002/em
Заходим в Listner выбираем наш т.е тот который на порту 6501, жмём Edit
и увеличиваем количество thread:
2. Tuning Work Queue Capacity
На этой же странице:
Tune the Work Queue Capacity based on the expected maximum number of concurrent clients to a given LDAP Listener.
Но тут есть нюанс... если создать Local Store Adapter то разваливается мониторинг OVD и к сожалению мы не можем посмотреть по метрикам сколько у нас concurrent clients.
Поэтому дествует по expected и это где то 2000 в моём случае.
3. Max Pool Connections
A tuning parameter that enables you to control how many simultaneous connections can be made to a single server. For production environments, Oracle suggests starting with a value of 10 connections, then making adjustments as needed. (Default is 10 connections.)
Тут опять же можно орентироваться на нерабочии метрики =(. Про них напишу когда нить , когда разберусь чё с ними за гавно.
Комментарии
Отправить комментарий