Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Здравствуй ALL;
Что есть -
Сервер с ОС-ю:
$ uname -a
Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Релиз ОС-и:
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Oracle SE:
SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle9i Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
Конфиг сервера: прилагаю в файле init.ora;

Что с этим происходит: недели две назад начали поступать жалобы на долгий коннект в БД.
Используется толстый клиент. Т.е.: oracle-client по на машинах пользователей + вот это самое клиентское приложение которое долго подключается в БД.

После подкл. работа с БД выполняется нормально (Что наводит на некоторые мысли...)
Как это выглядит - пример tns-пинга (tns-пинга, не подкл.,... что, опять же, наводит на мысли..) - в файлике nagr1.JPG.
Безопасники потребовали стереть из картинки доменное имя и service_name, поэтому поясняю: в верхней части картинки делается tnsping алиаса смотрящего на сервер в БД, а в нижней части картинки демонстрируют что связь до той же машины (куда смотрит tns-алиас) есть и не медленная.
Клиенты открывают tcp-соед. на дефолтный листнер, который на порту 1521

Первые мысли были, конечно, на работу сети, например DNS-сервис. Эти подозрения отмели, после рассмотрения клиентских трейсов.

Дальше.
Протрейсил попытки соединения клиента с сервером.
В трейсе увидел что задержки возникают на этапе связи с листнером (на что и были намёки ранее).
Трассировку клиента прикладываю: clientsqlnet_3684_5.trc

Перемесился на серверную сторону, стал рассматривать работу листнера.
Серверные конфиги - в файлах sqlnet.ora + listener.ora
При работе с листнером заметил такую странное поведение - иногда подвисает (и иногда - надолго) утилита lsnrctl.
Причём подвисает тоже странно - выводит инфу о недефаултных листнерах (их там ещё два сконфигурировано), а на отчёте о деф. листнере - виснет.
Ещё заметил что утилита ps - тоже виснет, если спросить примерно так: ps -aux | grep tnsl
Опять же, подвисает именно на строке с инфой о деф. листнере.

Дальше начал трейсить и рассматривать работу листнера.
Обнаружилось наличие ожиданий, их много.
Ожидания это что я так называю - значительный временной промежуток между таймстампами в двух соседних строчках трейса, относящихся к выполнению какой то процедуры.

Наиболее значительные ожидания расписываю в файлике - listener_dealys.rtf
Весь трейс, если понадобится - выложу.
Есть аналогичные данные за вчера за полный день, в нём - такие же ожидания;
Ограничения на ОС-учётку oracle из под которой на сервере работает ПО и в т.ч. листнер:
core file size          (blocks, -c) 102400
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 540672
max locked memory (kbytes, -l) 38654705664
max memory size (kbytes, -m) unlimited
open files (-n) 327679
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Кол-во сессий в oracle не велико, дефицита ресурса session в БД не наблюдается.
В пике, в течение суток, листнер обслуживает максимум 750 реквестов на соединение за 10-ти минутный интервал, это судя по данным listener.log-a
Неопознанных ошибок в listener.log не увидел, всё банальное "TNS:listener received no CONNECT_DATA from client", да "TNS:listener has not received client's request in time allowed";

Atop ничего подозрительного по утилизации системных ресурсов не показал, ну только что io-посистема интенсивно читает-пишет.
Свапа нет и небыло, cpu-не перегружено, csw-особенных скачков не заметил, в системе выполняется, в течение суток, максимум 800 процессов.
Это все по данным atop за вчера-позавчера.
Сам процесс tnslistener (который дефаултный) ресурсов практически не потребляет, что тоже наводит на мысль такую что вот эти вот его зависания - это так он чего то ждёт.

Естественно, в плане поиска информации по этому вопросу - погуглил по данным трейса. На металинк сходил. Пока безрезультатно.

Итого,.. мои вопросы: что это такое (я про свои т.н. "ожидания" листнера)? Стоит ли этого (я про свои т.н. "ожидания" листнера) бояться?
Если стоит - то как это вылечить (=где почитать как это вылечить)?
Если не стоит этого боятся - тогда чего ждут клиенты при обращениях к листнеру?

К сообщению приложен файл. Размер - 0Kb
29 апр 10, 11:55    [8707314]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Клиентский трейс

К сообщению приложен файл (analyze.txt - 72Kb) cкачать
29 апр 10, 12:05    [8707401]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Выдержка, про клиентский sqlnet.ora

[26-APR-2010 16:44:12] -> PARAMETER TABLE LOAD RESULTS FOLLOW <-
[26-APR-2010 16:44:12] Successful parameter table load
[26-APR-2010 16:44:12] -> PARAMETER TABLE HAS THE FOLLOWING CONTENTS <-
[26-APR-2010 16:44:12] TCP.NODELAY = yes
[26-APR-2010 16:44:12] SQLNET.EXPIRE_TIME = 10
[26-APR-2010 16:44:12] LOG_DIRECTORY_CLIENT = /var/log/oracle
[26-APR-2010 16:44:12] LOF_FILE_CLIENT = sqlnet_client.log
[26-APR-2010 16:44:12] TRACE_TIMESTAMP_SERVER = TRUE
[26-APR-2010 16:44:12] TRACE_TIMESTAMP_CLIENT = TRUE
[26-APR-2010 16:44:12] TNSPING.TRACE_LEVEL = support
[26-APR-2010 16:44:12] NAMES.DIRECTORY_PATH = (TNSNAMES, ONAMES, HOSTNAME)
[26-APR-2010 16:44:12] TNSPING.TRACE_DIRECTORY = c:\temp
[26-APR-2010 16:44:12] TRACE_UNIQUE_CLIENT = ON
[26-APR-2010 16:44:12] LOG_FILE_SERVER = sqlnet_server.log
[26-APR-2010 16:44:12] SQLNET.AUTHENTICATION_SERVICES = (NTS)
[26-APR-2010 16:44:12] TRACE_FILE_CLIENT = clientsqlnet.trc
[26-APR-2010 16:44:12] TRACE_LEVEL_CLIENT = 16
[26-APR-2010 16:44:12] TRACE_DIRECTORY_CLIENT = c:\temp
[26-APR-2010 16:44:12] LOG_DIRECTORY_SERVER = /var/log/oracle
[26-APR-2010 16:44:12] --- PARAMETER SOURCE INFORMATION ENDS ---
29 апр 10, 12:07    [8707415]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Серверный sqlnet.ora
# Разрешение алиасов
NAMES.DIRECTORY_PATH=(TNSNAMES,LDAP)
#NAMES.DIRECTORY_PATH=(TNSNAMES)

# Интервал в минутах для проверки активности клиент-серверного соединения (0 - запрет ) со стороны сервера.
SQLNET.EXPIRE_TIME=10

# Задержка очистки буферов стека TCP/IP
TCP.NODELAY=yes

# Перенаправить лог-файлы Oracle *SQLNet
LOG_DIRECTORY_CLIENT=/var/log/oracle
LOG_FILE_CLIENT=sqlnet_client.log
LOG_DIRECTORY_SERVER=/var/log/oracle
LOG_FILE_SERVER=sqlnet_server.log

listener.ora
# Каталог лог-файлов
LOGGING_LISTENER = ON
LOG_DIRECTORY_LISTENER = /var/log/oracle
LOG_FILE_LISTENER = listener.log
#
LOGGING_MTS_1522 = ON
LOG_DIRECTORY_MTS_1522 = /var/log/oracle
LOG_FILE_MTS_1522 = listener_mts_1522.log
#
LOGGING_MTS_1523 = ON
LOG_DIRECTORY_MTS_1523 = /var/log/oracle
LOG_FILE_MTS_1523 = listener_mts_1523.log

# Трейс файлы
TRACE_LEVEL_LISTENER=SUPPORT
#TRACE_DIRECTORY_LISTENER = /var/log/oracle
TRACE_DIRECTORY_LISTENER=/db/u13/trace/20100429/
TRACE_FILE_LISTENE=listener.trc
#
TRACE_LEVEL_MTS_1522 = ON
TRACE_DIRECTORY_MTS_1522 = /var/log/oracle
TRACE_FILE_MTS_1522 = listener_mts_1522.trc
#
TRACE_LEVEL_MTS_1523 = ON
TRACE_DIRECTORY_MTS_1523 = /var/log/oracle
TRACE_FILE_MTS_1523 = listener_mts_1523.trc

# Время на установления соединения в базу, в секундах
INBOUND_CONNECT_TIMEOUT_LISTENER = 1
#INBOUND_CONNECT_TIMEOUT_LISTENER_1524 = 1
INBOUND_CONNECT_TIMEOUT_MTS_1522 = 1
INBOUND_CONNECT_TIMEOUT_MTS_1523 = 1

# Прослушиватель по-умолчанию
LISTENER =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = db1.qqq.ru))
)

# Прослушиватели для сервера MTS
MTS_1522 =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1522))
)
#
MTS_1523 =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1523))
)
29 апр 10, 12:47    [8707691]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Серверный конфиг:
*.audit_file_dest='/var/log/oracle/billing/audit'
*.audit_sys_operations=TRUE
*.audit_trail='OS'
*.background_dump_dest='/var/log/oracle/billing/bdump'
*.compatible='9.2.0.4.0'
*.control_files='/db/u11/oradata/billing/ctrl00.ctl','/db/u12/oradata/billing/ctrl01.ctl','/db/u13oradata/billing/ctrl03.ctl'
*.core_dump_dest='/var/log/oracle/billing/cdump'
*.db_block_checking='true'
*.db_block_size=8192
*.db_cache_advice='ON'
*.db_cache_size=1073741824
*.db_domain='samara.qqq.ru'
*.db_file_multiblock_read_count=64
*.db_keep_cache_size=0
*.db_name='billing'
*.db_recycle_cache_size=0
*.db_writer_processes=4
*.disk_asynch_io=TRUE
*.dispatchers='(protocol=tcp)(listener=mts_1522)(dispatchers=2)','(protocol=tcp)(listener=mts_1523)(dispatchers=2)'
*.filesystemio_options='ASYNCH'
*.global_names=FALSE
*.hash_area_size=134217728
*.hash_join_enabled=TRUE
*.java_pool_size=125829120
*.job_queue_processes=10
*.large_pool_size=234881024
*.lock_sga=TRUE
*.log_archive_dest='/db/u13/archive/billing'
*.log_archive_format='%T_%S.arclog'
*.log_archive_start=TRUE
*.log_buffer=104857600
*.log_checkpoint_interval=10000
*.log_checkpoint_timeout=0
*.log_checkpoints_to_alert=TRUE
*.max_dispatchers=5
*.max_dump_file_size='100M'
*.max_shared_servers=350
*.nls_date_format='DD.MM.RR'
*.nls_language='AMERICAN'
*.nls_numeric_characters='.,'
*.nls_territory='CIS'
*.open_cursors=1500
*.open_links_per_instance=34
*.open_links=17
*.optimizer_index_caching=90
*.optimizer_index_cost_adj=15
*.optimizer_mode='RULE'
*.pga_aggregate_target=24696061952
*.pre_page_sga=TRUE
*.processes=900
*.query_rewrite_enabled='TRUE'
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_limit=TRUE
*.service_names='...'
*.session_cached_cursors=700
*.sga_max_size=2147483648
*.shared_pool_size=637534208
*.shared_servers=100
*.sort_area_retained_size=134217728
*.sort_area_size=671088640
*.star_transformation_enabled='FALSE'
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_retention=7200
*.undo_tablespace='UNDOTBS'
*.user_dump_dest='/var/log/oracle/billing/udump'
*.workarea_size_policy='AUTO'
29 апр 10, 12:50    [8707715]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8131
senieur
Выдержка, про клиентский sqlnet.ora
[26-APR-2010 16:44:12]  -> PARAMETER TABLE LOAD RESULTS FOLLOW <-
[26-APR-2010 16:44:12] Successful parameter table load
[26-APR-2010 16:44:12]  -> PARAMETER TABLE HAS THE FOLLOWING CONTENTS <-
[26-APR-2010 16:44:12]   TCP.NODELAY = yes
[26-APR-2010 16:44:12]   SQLNET.EXPIRE_TIME = 10
[26-APR-2010 16:44:12]   LOG_DIRECTORY_CLIENT = /var/log/oracle
[26-APR-2010 16:44:12]   LOF_FILE_CLIENT = sqlnet_client.log
[26-APR-2010 16:44:12]   TRACE_TIMESTAMP_SERVER = TRUE
[26-APR-2010 16:44:12]   TRACE_TIMESTAMP_CLIENT = TRUE
[26-APR-2010 16:44:12]   TNSPING.TRACE_LEVEL = support
[26-APR-2010 16:44:12]   NAMES.DIRECTORY_PATH = (TNSNAMES, ONAMES, HOSTNAME)
[26-APR-2010 16:44:12]   TNSPING.TRACE_DIRECTORY = c:\temp
[26-APR-2010 16:44:12]   TRACE_UNIQUE_CLIENT = ON
[26-APR-2010 16:44:12]   LOG_FILE_SERVER = sqlnet_server.log
[26-APR-2010 16:44:12]   SQLNET.AUTHENTICATION_SERVICES = (NTS)
[26-APR-2010 16:44:12]   TRACE_FILE_CLIENT = clientsqlnet.trc
[26-APR-2010 16:44:12]   TRACE_LEVEL_CLIENT = 16
[26-APR-2010 16:44:12]   TRACE_DIRECTORY_CLIENT = c:\temp
[26-APR-2010 16:44:12]   LOG_DIRECTORY_SERVER = /var/log/oracle
[26-APR-2010 16:44:12] --- PARAMETER SOURCE INFORMATION ENDS ---

При оформлении кода используйте, пожалуйста, тег SRC данного форума.
Этим вы повысите свои шансы на получение ответа.
29 апр 10, 12:56    [8707789]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
Ну и вот, собственно, то что я углядел из трейса листнера и то что вызывает у меня беспокойство;
Это данные за несколько утренних часов 27.04.2010;
Вчера трейсил весь день работу листнера.
И снова увидел такие же задержки:
1) "sntpcall: detaching from parent with additional fork" -> "sntpcall: result string is NTP0 13021"
2) "nsevwait: waiting for transport event (1 thru 4)..." -> "nsevwait: 1 newly-posted event(s)"
Времена задержек разные, от нескольких секунд, до 2-3 минут, больше времени занимают события типа 1)

Каких то других, значительных, задержек в работе листнера по его трейсу не обнаружил.

К сообщению приложен файл (listener_dealys.rtf - 15Kb) cкачать
29 апр 10, 12:58    [8707813]     Ответить | Цитировать Сообщить модератору
 Re: Пролонгированный коннект к БД  [new]
senieur
Member

Откуда: Пермь
Сообщений: 29
up
30 апр 10, 07:57    [8712183]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить