[ОТВЕТИТЬ]
15.04.2016 10:17
Diamondne
 
Столкнулся с вышеуказанной проблемой. Проблема появляется, только в рабочее время, когда работают все пользователи 13 ПК, и при условии заполнения выхода более 200 позиций (заполняю 150 - все ок). В не рабочее время заполнение пролетает даже на 1000 позиций.
Почитав про эту ошибку на форуме и не только пытался перестроить перераспределить память в oracle и настроить shell limits в ОС, но это ни к чему не привело (походу мозгов не хватает).
Поставил Оптимизатор-7, он поменял распределение памяти, но проблема не ушла.

Конфигурация:
1. Linux version 3.8.13-44.1.1.el6uek.x86_64 (mockbuild@ca-build44.us.oracle.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3)

2. Oracle 11.2.0.3.0 - 64bit

3. Память
total used free shared buffers cached
Mem: 16143640 12626248 3517392 5671732 35792 9461536
-/+ buffers/cache: 3128920 13014720
Swap: 16383996 328376 16055620

4. Ошибка в алерте:
ORA-04030: выход за пределы памяти процесса при попытке выделить 8168 байт (callheap,kdbmal allocation)
ORA-04030: выход за пределы памяти процесса при попытке выделить 56 байт (callheap,qesaAllocWrkArea:2)

5. Ограничения для пользователя oracle:
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 16384
oracle hard nproc 16384
oracle soft stack 10240
oracle hard stack 32768
oracle hard memlock 31943040
oracle soft memlock 31943040

6. pfile:

DRIBIN11.__db_cache_size=5419040768
DRIBIN11.__java_pool_size=33554432
DRIBIN11.__large_pool_size=100663296
DRIBIN11.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
DRIBIN11.__pga_aggregate_target=2147483648
DRIBIN11.__sga_target=5905580032
DRIBIN11.__shared_io_pool_size=0
DRIBIN11.__shared_pool_size=301989888
DRIBIN11.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/DRIBIN11/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/u01/app/oracle/oradata/DRIBIN11/controlfile/o1_mf_cjnsm4k8_.ctl','/u01/app/oracle/fast_recovery_area/DRIBIN11/controlfile/o1_mf_cjnsm4oo_.ctl'
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_domain=''
*.db_name='DRIBIN11'
*.db_recovery_file_dest_size=223745146880
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.deferred_segment_creation=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(protocol=TCP)'
*.nls_language='RUSSIAN'
*.nls_territory='RUSSIA'
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.open_cursors=300
*.pga_aggregate_target=34217728
*.processes=200
*.remote_login_passwordfile='EXCLUSIVE'
*.sec_case_sensitive_logon=FALSE
*.sessions=225
*.sga_max_size=5905580032
*.shared_pool_reserved_size=34217728
*.shared_pool_size=290000000
*.shared_servers=2
*.undo_tablespace='UNDOTBS1'
15.04.2016 10:18
Inima
 
если на сервере ничего больше нет, в 5м пункте лучше поставить unlimited
проблема не в базе, а в системе
15.04.2016 10:28
Diamondne
 
Прошу прощения, забыл добавить, что на сервере работают 2 виртуальные машины 1GB ОЗУ и 1.5GB ОЗУ. KSM не используется. Любые другие операции в СМ2000 (версия 1.033 сп 3) к такой ошибке не приводят. В других базах (менее больших) такой проблемы нет.
15.04.2016 10:29
Diamondne
 
Цитата:
Inima если на сервере ничего больше нет, в 5м пункте лучше поставить unlimited
проблема не в базе, а в системе
т.е. нужно вообще снять ограничения памяти для процессов, я вас правильно понял?
15.04.2016 11:48
Diamondne
 
Поставил:

oracle hard memlock unlimited
oracle soft memlock unlimited

Ошибка повторилась....
15.04.2016 11:53
OlegON
 
Поясню ситуацию.
Базе дали 6Гб+, она пытается их использовать.
В системе лимит меньше 6Гб, на который и налетает база. Еще и мусоросборник с виртуалками (очень зря).
Предполагаю, что после unlimited не перезагружался? Он не на ходу меняется...
15.04.2016 11:59
Diamondne
 
Цитата:
OlegON Поясню ситуацию.
Базе дали 6Гб+, она пытается их использовать.
В системе лимит меньше 6Гб, на который и налетает база. Еще и мусоросборник с виртуалками (очень зря).
Предполагаю, что после unlimited не перезагружался? Он не на ходу меняется...
Перезагружался... или мб я как-то не так меняю? просто правлю /etc/security/limits.conf
15.04.2016 12:49
OlegON
 
мб... перед стартом базы, от того пользователя, под каким база работает, надо выполнить
ulimit -a
будут видны текущие лимиты этого пользователя
15.04.2016 12:55
Diamondne
 
базу сейчас не остановить, на текущий момент все выглядит так:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 125934
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 10240
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
15.04.2016 13:05
akonev
 
/etc/security/limits.d/ надо ещё проверять. если там есть что-то, то оно "главнее" /etc/security/limits.conf
memlock задается в kB. получается 30G

sga_target не вмещается в shared
15.04.2016 13:16
Diamondne
 
Цитата:
akonev /etc/security/limits.d/ надо ещё проверять. если там есть что-то, то оно "главнее" /etc/security/limits.conf
memlock задается в kB. получается 30G

sga_target не вмещается в shared
в /etc/security/limits.d/ есть только 90-nproc.conf, а внутри только:

* soft nproc 1024
root soft nproc unlimited

Получается мне все-таки нужно уменьшать память, выделенную для бд oracle'а?
15.04.2016 13:24
akonev
 
SGA вместе с PGA нужно 8053063680.

увеличивай shmfs в /ets/fstab
15.04.2016 13:38
OlegON
 
нене, shmfs тут не при чем...
скорее всего тогда причина закопана в
sysctl -p
15.04.2016 13:57
Diamondne
 
Цитата:
OlegON нене, shmfs тут не при чем...
скорее всего тогда причина закопана в
sysctl -p
[root@server11ora ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmall = 4294967296
fs.file-max = 6815744
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmmax = 4398046511104
kernel.panic_on_oops = 1
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
15.04.2016 15:15
OlegON
 
ну, как бы неплохо и самому немного копать в указанном направлении...
kernel.shmmax = 4398046511104
4Гб дадено процессу...
15.04.2016 15:35
akonev
 
нееееее....

4Гб - это у меня: 4 294 967 296

тут 4 398 046 511 104 - 4Тб
15.04.2016 15:36
Diamondne
 
Цитата:
OlegON ну, как бы неплохо и самому немного копать в указанном направлении...
kernel.shmmax = 4398046511104
4Гб дадено процессу...
Спасибо, сегодня вечером поменяю (сейчас не получится сервер остановить), завтра постетим ..
15.04.2016 15:45
Diamondne
 
Цитата:
akonev нееееее....

4Гб - это у меня: 4 294 967 296

тут 4 398 046 511 104 - 4Тб
действительно, не посмотрел на разряды..
15.04.2016 15:55
akonev
 
мне очень интересно стало: pfile свежий? прям только что с spfile скопировано?
15.04.2016 16:13
Diamondne
 
Цитата:
OlegON предлагаю сделать так https://olegon.ru/showthread.php?t=15929
В моем случае лучше сделать 6ГБ ?
15.04.2016 16:16
Diamondne
 
Цитата:
akonev мне очень интересно стало: pfile свежий? прям только что с spfile скопировано?
сделал прям сейчас.

DRIBIN11.__db_cache_size=5452595200
DRIBIN11.__java_pool_size=33554432
DRIBIN11.__large_pool_size=67108864
DRIBIN11.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
DRIBIN11.__pga_aggregate_target=50331648
DRIBIN11.__sga_target=5905580032
DRIBIN11.__shared_io_pool_size=0
DRIBIN11.__shared_pool_size=301989888
DRIBIN11.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/DRIBIN11/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/u01/app/oracle/oradata/DRIBIN11/controlfile/o1_mf_cjnsm4k8_.ctl',$
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_domain=''
*.db_name='DRIBIN11'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=223808061440
*.deferred_segment_creation=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(protocol=TCP)'
*.nls_language='RUSSIAN'
*.nls_territory='RUSSIA'
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.open_cursors=300
*.pga_aggregate_target=34217728
*.processes=200
*.remote_login_passwordfile='EXCLUSIVE'
*.sec_case_sensitive_logon=FALSE
*.sessions=225
*.sga_max_size=5905580032
*.shared_pool_reserved_size=34217728
*.shared_pool_size=290000000
*.shared_servers=2
*.undo_tablespace='UNDOTBS1'
15.04.2016 16:25
akonev
 
Цитата:
Diamondne В моем случае лучше сделать 6ГБ ?
это точно будет лучше, чем нынешние 16Тб в shmall
установишь что-то адекватное и посмотришь как изменится shared memory
откуда она берется сейчас - не очень понятно
15.04.2016 17:30
Diamondne
 
Цитата:
OlegON предлагаю сделать так https://olegon.ru/showthread.php?t=15929
поправил на 6 ГБ, вечером перезагружу - посмотрим...

что интересно в /etc/sysctl.conf про эти значения написаны комменты:
# oracle-rdbms-server-11gR2-preinstall setting for kernel.shmmax is 4398046511104 on x86_64
# oracle-rdbms-server-11gR2-preinstall setting for kernel.shmall is 1073741824 on x86_64
15.04.2016 18:27
OlegON
 
Почему 6?! 8 минимум с твоими текущими настройками... Лимит по системе должен быть выше лимита по базе.
15.04.2016 18:51
Diamondne
 
Цитата:
OlegON Почему 6?! 8 минимум с твоими текущими настройками... Лимит по системе должен быть выше лимита по базе.
я, походу, не совсем правильно понимаю описание переменных... ок, исправлю...
15.04.2016 19:08
Diamondne
 
поправил на 9ГБ ... жду ребута

[root@server11ora ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmall = 2359296
fs.file-max = 6815744
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmmax = 9663676416
kernel.panic_on_oops = 1
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
15.04.2016 19:40
Diamondne
 
можете посоветовать, чем можно нагрузить БД? ... рабочий день закончен, юзеров нет.. а на "курящей бд" все летало и раньше
15.04.2016 19:46
OlegON
 
Открой сразу 13 супермагов и запусти выходы эти свои или еще какие-то сводные товарные отчеты с сортировками за большой период. И смотри на RES в столбце top/htop по oracle. Как вылезло за 6Гб - все поправил, значит... В базе лимиты не железные, она за них выходит на раз... Собственно, это не лимиты ни разу.
15.04.2016 20:28
Diamondne
 
вот что получилось в пике нагрузки:



Опции темы


Часовой пояс GMT +3, время: 11:32.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.