关于Linux 下kernel.shmmax 。

viadeazhu

mark下。

huanhuanlove

我汗  还是得出个具体的结论来

jinxino_o

1. 
   
2. [root@rac01 ~]# cat /etc/sysctl.conf | grep kernel.shmmax
   
3. kernel.shmmax = 20971520
   
4. [root@rac01 ~]# ipcs -sa
   
5. 
   
6. ------ Shared Memory Segments --------
   
7. key        shmid      owner      perms      bytes      nattch     status                           
   
8. 0x00000000 65537      oracle    640        4194304    27                     
   
9. 0x00000000 98306      oracle    640        20971520   27                     
   
10. 0x00000000 131075     oracle    640        20971520   27                     
    
11. 0x00000000 163844     oracle    640        20971520   27                     
    
12. 0x00000000 196613     oracle    640        20971520   27                     
    
13. 0x00000000 229382     oracle    640        20971520   27                     
    
14. 0x00000000 262151     oracle    640        20971520   27                     
    
15. 0x00000000 294920     oracle    640        20971520   27                     
    
16. 0xd2776b04 327689     oracle    640        20971520   27                     
    
17. 
    
18. ------ Semaphore Arrays --------
    
19. key        semid      owner      perms      nsems            
    
20. 0xfafd7074 360449     oracle    640        104      
    
21. 
    
22. ------ Message Queues --------
    
23. key        msqid      owner      perms      used-bytes   messages
    
24.    
    
25. 因为kernel.shmmax设置过小,导致分配了多个共享内存段
    
26. 下边改大一些:
    
27. [root@rac01 ~]# cat /etc/sysctl.conf | grep kernel.shmmax
    
28. kernel.shmmax = 2147483648
    
29. [root@rac01 ~]# sysctl -p
    
30. [root@rac01 ~]# su - oracle
    
31. [oracle@rac01 ~]$ export ORACLE_SID=myrac1
    
32. [oracle@rac01 ~]$ sqlplus '/as sysdba'
    
33. 
    
34. SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 16 05:50:00 2009
    
35. 
    
36. Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    
37. 
    
38. 
    
39. Connected to:
    
40. Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    
41. With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP
    
42. and Data Mining Scoring Engine options
    
43. 
    
44. SQL> startup force
    
45. ORACLE instance started.
    
46. 
    
47. Total System Global Area  167772160 bytes
    
48. Fixed Size                  1218316 bytes
    
49. Variable Size             104859892 bytes
    
50. Database Buffers           58720256 bytes
    
51. Redo Buffers                2973696 bytes
    
52. Database mounted.
    
53. Database opened.
    
54. SQL> quit
    
55. Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    
56. With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP
    
57. and Data Mining Scoring Engine options
    
58. [oracle@rac01 ~]$ exit
    
59. logout
    
60. 再看一下:
    
61. [root@rac01 ~]# ipcs -sa
    
62. 
    
63. ------ Shared Memory Segments --------
    
64. key        shmid      owner      perms      bytes      nattch     status                           
    
65. 0xd2776b04 360449     oracle    640        171966464  27                     
    
66. 
    
67. ------ Semaphore Arrays --------
    
68. key        semid      owner      perms      nsems            
    
69. 0xfafd7074 491521     oracle    640        104      
    
70. 
    
71. ------ Message Queues --------
    
72. key        msqid      owner      perms      used-bytes   messages
    
73. 只有一个内存段分配了
    

复制代码

对于性能的影响,其实就跟磁盘的碎片一个道理,碎片越多,性能越低,但是普通的操作看不出差别,经常整理碎片的人应该更能理解这个问题吧!
另外上边的
0x00000000 65537      oracle    640        4194304    27                     
0x00000000 98306      oracle    640        20971520   27                     
也能回答楼主的对于1.2G是否会分配2G的问题了,1.2G还是1.2G,只不过一个没分那么大而已.

jinxino_o

汗!3年前的帖子,忘看时间就回复了......

Yong Huang

原帖由 jinxino_o 于 2009-11-15 21:44 发表
对于性能的影响,其实就跟磁盘的碎片一个道理,碎片越多,性能越低,但是普通的操作看不出差别,经常整理碎片的人应该更能理解这个问题吧!

The impact of too many fragments for a shared memory segment on performance is not nearly as big a problem as that of tablespace fragmentation. According to Steve Adams (see his little O'Reilly book), when you have multiple shared memory segment fragments, starting up the instance and creating a new server process will be slightly slower. There's no other negative effect.

Yong Huang

jinxino_o

看到版主的回复,相比而言,更想多跟版主学学英语!

oracle_lch

我挖呀！   木乃伊快出来了

ZALBB

Yong Huang 发表于 2009-11-17 03:23
The impact of too many fragments for a shared memory segment on performance is not nearly as big ...

版主，有无测试数据证明你的说法？

Yong Huang

ZALBB 发表于 2014-11-24 21:25
版主，有无测试数据证明你的说法？

No. I've never tested it. Theoretically, there should be difference in time because each shmget() call takes time, but the difference may be too small to measure.

ZALBB

Yong Huang 发表于 2014-11-25 23:38
No. I've never tested it. Theoretically, there should be difference in time because each shmget()  ...

明白，谢谢。