찾다
데이터 베이스MySQL 튜토리얼AIX6.1/11.2.0.3数据库上关于SWAP的一个BUG

昨天去南京某客户那里调优新上线的业务数据库,在查看alert.log日志时发现在过去的一段时间里,每过几个小时或间隔一段时间,就会报类以下的内容: Thu Aug 21 09:01:26 2014WARNING: Heavy swapping observed on system in last 5 mins.pct of memory swappe

昨天去南京某客户那里调优新上线的业务数据库,在查看alert.log日志时发现在过去的一段时间里,每过几个小时或间隔一段时间,就会报类似以下的内容:
Thu Aug 21 09:01:26 2014 WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [8.42%] pct of memory swapped out [2.16%]. Please make sure there is no memory pressure and the SGA and PGA are configured correctly. Look at DBRM trace file for more details.
Thu Aug 21 14:56:27 2014 WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [5.40%] pct of memory swapped out [8.63%]. Please make sure there is no memory pressure and the SGA and PGA are configured correctly. Look at DBRM trace file for more details.
......
Sat Oct 18 22:13:48 2014 WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [7.76%] pct of memory swapped out [0.33%]. Please make sure there is no memory pressure and the SGA and PGA are configured correctly. Look at DBRM trace file for more details.
客户的环境是IBM P570,AIX 6.1,安装了Oracle 11.2.0.3单实例数据库,物理内存64G,仅仅分配了20G给SGA,采用memory自动管理
查阅了一下MOS,发现是AIX平台上的一个bug,相关文档为:[1508575.1]
对应的数据库和平台:
Oracle Database - Enterprise Edition - Version 11.2.0.3 to 11.2.0.3 [Release 11.2] IBM AIX on POWER Systems (64-bit)
症状:

There is new warning message in alert.log in 11.2.0.3 similar to

WARNING: Heavy swapping observed on system in last 5 mins.
pct of memory swapped in [2.08%] pct of memory swapped out [0.12%].
Please make sure there is no memory pressure and the SGA and PGA
are configured correctly. Look at DBRM trace file for more details.

On AIX platform this message can be seen even when there is no virtual memory swapping at all. --物理内存足够,而且根本没有使用swap交换空间

You may compare the vmstat from AIX level with DBRM trace file entries to see the differences.


原因:

The issue is caused by unpublished Bug:14731911.

Swap usage messages are based on statistics that do not reflect the actual usage.

The v$osstat does not reflect proper stats for the swap space paging.

解决方法:

Apply Patch:11801934 on top of your IBM AIX on POWER Systems (64-bit) platform.

P.S: Bug is port-specific. --这个bug是针对端口指定的平台的

The issue is fixed in patchset 11.2.0.4 and release 12.1. --说是在12.1的patch中修复了,但实际上12.1还是会有这个问题,会有ora-700错误,详见文档:[ID 1919850.1]

来看一下BUG:14731911的描述:

Bug 属性


B - Defect
2 - Severe Loss of Service 11.2.0.3
96 - Closed, Duplicate Bug 212 - IBM AIX on POWER Systems (64-bit)
2012-10-8
2014-10-11 11801934
11.2.0.3 Port-Specific
Oracle 与此 Bug 相关的知识, 补丁程序和 Bug
\

相关产品


Oracle Database Products Oracle Database Suite
Oracle Database 5 - Oracle Database - Enterprise Edition
\
Hdr: 14731911 11.2.0.3 RDBMS 11.2.0.3 VOS PRODID-5 PORTID-212 11801934
Abstract: FALSE SWAP WARNING MESSAGES PRINTED TO ALERT.LOG ON AIX
 
*** 10/08/12 04:52 am ***
  
  
  BUG TYPE CHOSEN
  ===============
  Code
  
  SubComponent: Virtual Operating System
  ======================================
  DETAILED PROBLEM DESCRIPTION
  ============================
  Oracle process seems to check wrong OS local statistic (which include also
  FILESYSTEM caching etc.)
  
  Alert log shows WARNING: Heavy swapping observed on system in last 5 mins.
  pct of memory swapped in [2.08%] pct of memory swapped out [0.12%].
  Please make sure there is no memory pressure and the SGA and PGA 
  are configured correctly. Look at DBRM trace file for more details.
  
  but this is not reflected at OS level.
  
  DIAGNOSTIC ANALYSIS
  ===================
  1. nmon shows virtual memory swapping does not occur at all - see attached file --nmon根本没有监控到swap动作
  
  2. Oracle Database Server is 11.2.0.3 and contains fix for 10220118
  
  3. Server configuration
  real mem: 144GB
  lowest value of fre memory : 87,65 GB --剩余内存充足
  
  4. DBRM seems to use a wrong OS statistics - trace file is attached
  
  WORKAROUND?
  ===========
  No
  
  TECHNICAL IMPACT
  ================
  Wrong diagnostic analyze.
  Message is bothering customer's DBA when in fact the warning message is
  misleading
  
  RELATED ISSUES (bugs, forums, RFAs)
  ===================================
  http://myforums.oracle.com/jive3/thread.jspa?threadID=1104581 
  10220118
  
  HOW OFTEN DOES THE ISSUE REPRODUCE AT CUSTOMER SITE?
  ====================================================
  Always
  
  DOES THE ISSUE REPRODUCE INTERNALLY?
  ====================================
  No
  
  EXPLAIN WHY THE ISSUE WAS NOT TESTED INTERNALLY.
  ================================================
  Unavailable Data Volume
  
  IS A TESTCASE AVAILABLE?
  ========================
  No
  
  Link to IPS Package:
  ====================
  not available

DBRM(Database Resource Manager)是11gR2中新特性中出现的后台进程,会在alert.log告警日志中反映OS操作系统最近5分钟是否有剧烈的swap活动,而在AIX平台上,由于BUG:14731911的存在,oracle的这个进程谎报了内存进行了swapin和swapout动作。我们知道,只有当物理内存真的不够用的情况下,才会去用swap(通常会配置成物理内存的2倍),而swap是非常耗费性能的(从物理磁盘读写)。但是个人认为这个bug的危害性并不大,仅仅只是在alert.log日志中报了一个WARNING,并没有因为这个影响导致对数据库更加负面的影响,因此是否打补丁到11.2.0.4就见仁见智了,如果想让alert.log平安无事,那么就可以升级一下patch。当然了,如果真的是因为OS内存吃紧造成的swap动作,就要区别对待了,因为此时的确会对数据库造成严重影响。要区分是否真的内存不足而非系统误报,那么主要还是通过nmon,topas,vmstat等监控工具来进行分析(linux下还可以用free监控)

对于AIX平台,其实还有另一个bug,只不过是unpublished base bug,而不是port-specific bug

AIX Platform

If your Platform is IBM-AIX then this is not the only possible reason for this alert log message.
For IBM AIX on POWER Systems (64-bit), there is also next known port-specific bug:
Bug 14731911 - FALSE SWAP WARNING MESSAGES PRINTED TO ALERT.LOG ON AIX
with unpublished base bug:
Bug 11801934 : WRONG PAGE-IN AND PAGE-OUT OS VM STATS IN AIX.

在vmware平台中的这个WARNING信息,如果不是bug引起,则很有可能和ora-04031/ora-04030相关,这个就严重多了

VMWare

Under VMWare, the messages may perhaps indicate a more serious issue, even when no memory related ORA-4031/ORA-4030 errors are reported.
Under circumstances, an instance in a virtual machine may be simply terminated by PMON due to error 471 without further errors in the alert log.
The OS logs may in such case report an out of memory condition like below:

[root@vmh ~]# grep Kill /var/log/messages*
/var/log/messages-20140629:Jun 27 18:29:06 vmh-msfc-dodp02 kernel: [1895074.304941] Out of memory: Kill process 42094 (oracle) score 391 or sacrifice child
/var/log/messages-20140629:Jun 27 18:29:06 vmh-msfc-dodp02 kernel: [1895074.305203] Killed process 42094, UID 303, (oracle) total-vm:189081588kB, anon-rss:27412kB, file-rss:109612

通常解决OS内存swap问题有以下几种方案:

1. 诊断是否存在内存泄露的进程,解决内存泄露 2. 调优SGA/PGA,减少oracle对内存的占用 3. 利用/proc/sys/vm/drop_caches,暂时释放一些cache的内存(Linux) 4. 调整系统VM内存管理参数, 例如Linux上sysctl.conf中的以下几个参数:


vm.min_free_kbytes:Raising the value in /proc/sys/vm/min_free_kbytes will cause the system to start reclaiming memory at an earlier time than it would have before.

vm.vfs_cache_pressure:At the default value of vfs_cache_pressure = 100 the kernel will attempt to reclaim dentries and inodes at a “fair” rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes.


vm.swappiness:default 60,Apparently /proc/sys/vm/swappiness on Red Hat Linux allows the admin to tune how aggressively the kernel swaps out processes'memory. Decreasing the swappiness setting may result in improved Directory performance as the kernel holds more of the server process in memory longer before swapping it out.

设置以下值,以减少OOM(Out Of Memory)的可能性:

# Oracle-Validated setting for vm.min_free_kbytes is 51200 to avoid OOM killer
vm.min_free_kbytes = 51200
vm.swappiness = 40
vm.vfs_cache_pressure = 200


성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
MySQL : 세계에서 가장 인기있는 데이터베이스 소개MySQL : 세계에서 가장 인기있는 데이터베이스 소개Apr 12, 2025 am 12:18 AM

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 주로 데이터를 신속하고 안정적으로 저장하고 검색하는 데 사용됩니다. 작업 원칙에는 클라이언트 요청, 쿼리 해상도, 쿼리 실행 및 반환 결과가 포함됩니다. 사용의 예로는 테이블 작성, 데이터 삽입 및 쿼리 및 조인 작업과 같은 고급 기능이 포함됩니다. 일반적인 오류에는 SQL 구문, 데이터 유형 및 권한이 포함되며 최적화 제안에는 인덱스 사용, 최적화 된 쿼리 및 테이블 분할이 포함됩니다.

MySQL의 중요성 : 데이터 저장 및 관리MySQL의 중요성 : 데이터 저장 및 관리Apr 12, 2025 am 12:18 AM

MySQL은 데이터 저장, 관리, 쿼리 및 보안에 적합한 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1. 다양한 운영 체제를 지원하며 웹 응용 프로그램 및 기타 필드에서 널리 사용됩니다. 2. 클라이언트-서버 아키텍처 및 다양한 스토리지 엔진을 통해 MySQL은 데이터를 효율적으로 처리합니다. 3. 기본 사용에는 데이터베이스 및 테이블 작성, 데이터 삽입, 쿼리 및 업데이트가 포함됩니다. 4. 고급 사용에는 복잡한 쿼리 및 저장 프로 시저가 포함됩니다. 5. 설명 진술을 통해 일반적인 오류를 디버깅 할 수 있습니다. 6. 성능 최적화에는 인덱스의 합리적인 사용 및 최적화 된 쿼리 문이 포함됩니다.

MySQL을 사용하는 이유는 무엇입니까? 혜택과 장점MySQL을 사용하는 이유는 무엇입니까? 혜택과 장점Apr 12, 2025 am 12:17 AM

MySQL은 성능, 신뢰성, 사용 편의성 및 커뮤니티 지원을 위해 선택됩니다. 1.MYSQL은 효율적인 데이터 저장 및 검색 기능을 제공하여 여러 데이터 유형 및 고급 쿼리 작업을 지원합니다. 2. 고객-서버 아키텍처 및 다중 스토리지 엔진을 채택하여 트랜잭션 및 쿼리 최적화를 지원합니다. 3. 사용하기 쉽고 다양한 운영 체제 및 프로그래밍 언어를 지원합니다. 4. 강력한 지역 사회 지원을 받고 풍부한 자원과 솔루션을 제공합니다.

InnoDB 잠금 장치 (공유 잠금, 독점 잠금, 의도 잠금, 레코드 잠금, 갭 잠금, 차세대 자물쇠)를 설명하십시오.InnoDB 잠금 장치 (공유 잠금, 독점 잠금, 의도 잠금, 레코드 잠금, 갭 잠금, 차세대 자물쇠)를 설명하십시오.Apr 12, 2025 am 12:16 AM

InnoDB의 잠금 장치에는 공유 잠금 장치, 독점 잠금, 의도 잠금 장치, 레코드 잠금, 갭 잠금 및 다음 키 잠금 장치가 포함됩니다. 1. 공유 잠금을 사용하면 다른 트랜잭션을 읽지 않고 트랜잭션이 데이터를 읽을 수 있습니다. 2. 독점 잠금은 다른 트랜잭션이 데이터를 읽고 수정하는 것을 방지합니다. 3. 의도 잠금은 잠금 효율을 최적화합니다. 4. 레코드 잠금 잠금 인덱스 레코드. 5. 갭 잠금 잠금 장치 색인 기록 간격. 6. 다음 키 잠금은 데이터 일관성을 보장하기 위해 레코드 잠금과 갭 잠금의 조합입니다.

열악한 MySQL 쿼리 성능의 일반적인 원인은 무엇입니까?열악한 MySQL 쿼리 성능의 일반적인 원인은 무엇입니까?Apr 12, 2025 am 12:11 AM

MySQL 쿼리 성능이 좋지 않은 주된 이유는 인덱스 사용, 쿼리 최적화에 의한 잘못된 실행 계획 선택, 불합리한 테이블 디자인, 과도한 데이터 볼륨 및 잠금 경쟁이 포함됩니다. 1. 색인이 느리게 쿼리를 일으키지 않으며 인덱스를 추가하면 성능이 크게 향상 될 수 있습니다. 2. 설명 명령을 사용하여 쿼리 계획을 분석하고 Optimizer 오류를 찾으십시오. 3. 테이블 구조를 재구성하고 결합 조건을 최적화하면 테이블 설계 문제가 향상 될 수 있습니다. 4. 데이터 볼륨이 크면 분할 및 테이블 디비전 전략이 채택됩니다. 5. 높은 동시성 환경에서 거래 및 잠금 전략을 최적화하면 잠금 경쟁이 줄어들 수 있습니다.

Composite Index와 여러 단일 열 인덱스를 언제 사용해야합니까?Composite Index와 여러 단일 열 인덱스를 언제 사용해야합니까?Apr 11, 2025 am 12:06 AM

데이터베이스 최적화에서 쿼리 요구 사항에 따라 인덱싱 전략을 선택해야합니다. 1. 쿼리에 여러 열이 포함되고 조건 순서가 수정되면 복합 인덱스를 사용하십시오. 2. 쿼리에 여러 열이 포함되어 있지만 조건 순서가 고정되지 않은 경우 여러 단일 열 인덱스를 사용하십시오. 복합 인덱스는 다중 열 쿼리를 최적화하는 데 적합한 반면 단일 열 인덱스는 단일 열 쿼리에 적합합니다.

MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)Apr 10, 2025 am 09:36 AM

MySQL 느린 쿼리를 최적화하려면 SlowQueryLog 및 Performance_Schema를 사용해야합니다. 1. SlowQueryLog 및 Set Stresholds를 사용하여 느린 쿼리를 기록합니다. 2. Performance_schema를 사용하여 쿼리 실행 세부 정보를 분석하고 성능 병목 현상을 찾고 최적화하십시오.

MySQL 및 SQL : 개발자를위한 필수 기술MySQL 및 SQL : 개발자를위한 필수 기술Apr 10, 2025 am 09:30 AM

MySQL 및 SQL은 개발자에게 필수적인 기술입니다. 1.MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템이며 SQL은 데이터베이스를 관리하고 작동하는 데 사용되는 표준 언어입니다. 2.MYSQL은 효율적인 데이터 저장 및 검색 기능을 통해 여러 스토리지 엔진을 지원하며 SQL은 간단한 문을 통해 복잡한 데이터 작업을 완료합니다. 3. 사용의 예에는 기본 쿼리 및 조건 별 필터링 및 정렬과 같은 고급 쿼리가 포함됩니다. 4. 일반적인 오류에는 구문 오류 및 성능 문제가 포함되며 SQL 문을 확인하고 설명 명령을 사용하여 최적화 할 수 있습니다. 5. 성능 최적화 기술에는 인덱스 사용, 전체 테이블 스캔 피하기, 조인 작업 최적화 및 코드 가독성 향상이 포함됩니다.

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
WWE 2K25 : Myrise에서 모든 것을 잠금 해제하는 방법
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

ZendStudio 13.5.1 맥

ZendStudio 13.5.1 맥

강력한 PHP 통합 개발 환경

Atom Editor Mac 버전 다운로드

Atom Editor Mac 버전 다운로드

가장 인기 있는 오픈 소스 편집기

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

MinGW - Windows용 미니멀리스트 GNU

MinGW - Windows용 미니멀리스트 GNU

이 프로젝트는 osdn.net/projects/mingw로 마이그레이션되는 중입니다. 계속해서 그곳에서 우리를 팔로우할 수 있습니다. MinGW: GCC(GNU Compiler Collection)의 기본 Windows 포트로, 기본 Windows 애플리케이션을 구축하기 위한 무료 배포 가능 가져오기 라이브러리 및 헤더 파일로 C99 기능을 지원하는 MSVC 런타임에 대한 확장이 포함되어 있습니다. 모든 MinGW 소프트웨어는 64비트 Windows 플랫폼에서 실행될 수 있습니다.

맨티스BT

맨티스BT

Mantis는 제품 결함 추적을 돕기 위해 설계된 배포하기 쉬운 웹 기반 결함 추적 도구입니다. PHP, MySQL 및 웹 서버가 필요합니다. 데모 및 호스팅 서비스를 확인해 보세요.