hp-ux記憶體不足導致交換
客戶反映一臺32G的HP-UX經常swap,但,分給Oracle的SGA+PGA記憶體僅僅23個G,並且,該機器上沒有跑其他的應用,理論上不應該導致交換。
glance了一下:
未命名.jpg
發現FileCache佔用了8.3Gb的記憶體,導致了記憶體交換。
對於HP-UX 11i Version 3,可以修改初始化引數filecache_max來控制FileCache佔總記憶體的百分比
NAME
filecache_max, filecache_min — maximum or minimum amount of physical memory used for caching file I/O data
VALUES
Failsafe
filecache_min: approximately 5% of physical memory
filecache_max: approximately 5% of physical memory
Default
filecache_min: approximately 5% of physical memory
filecache_max: approximately 50% of physical memory
The defaults are computed and adjusted automatically, based on the amount physical memory on the system.
The current default value, when displayed by kctune, will be expressed as the current value used internally by the system (representing bytes). The displayed value will vary as the internal value is automatically adjusted.
Allowed values
Minimum filecache_min: not less than the equivalent of 1 megabyte
Minimum filecache_max: not less than the equivalent of 1 megabyte
Maximum filecache_min: not greater than the equivalent of 70% of physical memory
Maximum filecache_max: not greater than the equivalent of 90% of physical memory
See Restrictions on Changing below.
Values can be specified as:
1) Default
2) A percentage of total physical memory:
A positive whole number followed by a percent symbol (for example, 70%).
3) A constant value:
A positive whole number that represents number of bytes of physical memory, optionally followed by a multiplier suffix, where K=1000, KB=1024, M=1000000, MB=(1024*1024), and GB=(1024*1024*1024).
Recommended values
It is recommended that these tunables are left in the automatic (default) state, to allow the system to better balance the memory usage among filesystem I/O-intensive processes and other types of processes.
DESCRIPTION
These tunables control the amount of physical memory that can be used for caching file data during file system I/O operations.
The amount of physical memory that is specified by the filecache_min tunable is reserved and guaranteed to be available for file caching.
The amount of physical memory used for file caching can grow beyond filecache_min, up to filecache_max, depending on I/O load and competing requests for physical memory.
When these tunables are set to default, or set to a percent value, they automatically adjust with Online Addition or Deletion (OL*) of physical memory, as appropriate.
Who Is Expected to Change These Tunables?
The automatic (default) state should be appropriate for most environments.
You must set these tunables to a constant value (not default or percent) if you want to specify file cache limits with finer granularity than percent of physical memory (for example, a minimum size or fixed size of <1% of physical memory).
You must set these tunables to a constant value (not default or percent) if you do not want the limits of the file cache to adjust with OL* of physical memory.
To discriminate in favor of deterministic I/O on systems with large file I/O activity, or on the contrary, to discriminate in favor of better performance of non-I/O-intensive processes, you can consider changing the values of these tunables, keeping in mind the side effects as described below.
To determine a reasonable value for the cache size you should consider the file I/O-intensive applications on your system, and the size of their working set. Depending on the type of applications, the working set size can be based on the size of a transaction, or data size in given unit of time. For example, for a conservative value of filecache_min in megabytes, you can use the following formula:
MB = number-of-system-processes * largest-application-record-length-in-MB * number-of-records-in-working-set
Only those processes that actively use disk I/O for file data should be included in the calculation. All others can be excluded. Here are some examples of what processes should be included in or excluded from the calculation.
Include:
NFS daemons, text formatters, database management applications, text editors, compilers, and so on, that access or use source and/or output files stored in one or more file systems mounted on the system.
Exclude:
X-display applications, hpterm, rlogin, login shells, system daemons, telnet or uucp connections, and so on. These processes use very little, if any, disk I/O for file data.
Restrictions on Changing
These tunables are dynamic and automatic.
The system rounds the specified tunable value(s) down to the closest physical page boundary.
The amount of physical memory represented by filecache_min must be equal to or less than the memory represented by tunable filecache_max.
Setting these tunables to a constant value will de-couple them from OL* events.
Tuning up of the filecache_min parameter may fail if there is not enough free physical memory to satisfy the request.
These tunables, filecache_min and filecache_max, must both be set to a relative state (either default of percent state), or must both be set to a constant value. For example, the following are acceptable settings:
# kctune filecache_min=100MB filecache_max=100MB
# kctune filecache_min=15% filecache_max=65%
# kctune filecache_min=Default filecache_max=65%
The following will result in an error:
# kctune filecache_min=10% filecache_max=1GB
ERROR: The specified units for the values of filecache_min and filecache must be consistent: both as relative (percentage or default) or both as constant value.
If filecache_min is currently set to default, the following is acceptable:
# kctune filecache_max=Default
# kctune filecache_max=40%
But the following will result in an error:
# kctune filecache_max=1GB
See other restrictions in the Allowed values section above.
When Should the Value of These Tunables Be Raised?
Low system performance at initialization time and/or on a system with filesystem I/O-intensive processes may be an indication that the values of these tunables are too low. If there is a large number of processes actively and constantly using file data I/O, you should raise the value of filecache_min for more deterministic I/O. In most cases, especially when the file data I/O is expected to peak only occasionally, it is recommended that the value of the maximum limit, filecache_max, is raised instead.
What Are the Side Effects of Raising the Values?
The amount of memory reserved for the minimum file cache size, dictated by filecache_min, cannot be used on the system for other purposes. Be careful not to raise this value so high that it can eventually cause memory pressure and overall system performance degradation.
When Should the Values of These Tunables Be Lowered?
The value of the minimum limit, filecache_min, can be lowered to allow a larger percentage of memory to be used for purposes other than filesystem I/O caching, depending on competing requests. By lowering the value of filecache_max, a larger amount of memory is available for other purposes, without competing with file I/O requests.
What Are the Side Effects of Lowering the Values?
If there are many competing requests for physical memory, and the file cache tunables are set to too low a value, very high demand on file I/O operations can eventually cause filesystem I/O performance degradation.
EXAMPLES
Set the file cache minimum to 10% of physical memory:
# kctune filecache_min=10%
Set a fixed size file cache of 1 gigabyte:
# kctune filecache_min=1GB filecache_max=1GB
Set the file cache minimum to 15% of physical memory, and the maximum to 65% of the physical memory:
# kctune filecache_min=15% filecache_max=65%
WARNINGS
All HP-UX kernel tunable parameters are release specific. These parameters may be removed or have their meaning changed in future releases of HP-UX.
Other tunable parameters related to sizing the buffer cache that existed in previous HP-UX releases are now obsolete. The tunables filecache_min and filecache_max should be used to set limits to the file cache. Note that, on any given system, the optimum values of these two new tunables are not necessarily equivalent to the optimum values of the obsolete tunable values in the older systems. You should first determine if the new default values yield acceptable performance on your system, before attempting to change the values of the new file cache tunables.
Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tunable values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see HP-UX Release Notes at
AUTHOR
filecache_max and filecache_min were developed by HP.
glance了一下:
未命名.jpg
發現FileCache佔用了8.3Gb的記憶體,導致了記憶體交換。
對於HP-UX 11i Version 3,可以修改初始化引數filecache_max來控制FileCache佔總記憶體的百分比
NAME
filecache_max, filecache_min — maximum or minimum amount of physical memory used for caching file I/O data
VALUES
Failsafe
filecache_min: approximately 5% of physical memory
filecache_max: approximately 5% of physical memory
Default
filecache_min: approximately 5% of physical memory
filecache_max: approximately 50% of physical memory
The defaults are computed and adjusted automatically, based on the amount physical memory on the system.
The current default value, when displayed by kctune, will be expressed as the current value used internally by the system (representing bytes). The displayed value will vary as the internal value is automatically adjusted.
Allowed values
Minimum filecache_min: not less than the equivalent of 1 megabyte
Minimum filecache_max: not less than the equivalent of 1 megabyte
Maximum filecache_min: not greater than the equivalent of 70% of physical memory
Maximum filecache_max: not greater than the equivalent of 90% of physical memory
See Restrictions on Changing below.
Values can be specified as:
1) Default
2) A percentage of total physical memory:
A positive whole number followed by a percent symbol (for example, 70%).
3) A constant value:
A positive whole number that represents number of bytes of physical memory, optionally followed by a multiplier suffix, where K=1000, KB=1024, M=1000000, MB=(1024*1024), and GB=(1024*1024*1024).
Recommended values
It is recommended that these tunables are left in the automatic (default) state, to allow the system to better balance the memory usage among filesystem I/O-intensive processes and other types of processes.
DESCRIPTION
These tunables control the amount of physical memory that can be used for caching file data during file system I/O operations.
The amount of physical memory that is specified by the filecache_min tunable is reserved and guaranteed to be available for file caching.
The amount of physical memory used for file caching can grow beyond filecache_min, up to filecache_max, depending on I/O load and competing requests for physical memory.
When these tunables are set to default, or set to a percent value, they automatically adjust with Online Addition or Deletion (OL*) of physical memory, as appropriate.
Who Is Expected to Change These Tunables?
The automatic (default) state should be appropriate for most environments.
You must set these tunables to a constant value (not default or percent) if you want to specify file cache limits with finer granularity than percent of physical memory (for example, a minimum size or fixed size of <1% of physical memory).
You must set these tunables to a constant value (not default or percent) if you do not want the limits of the file cache to adjust with OL* of physical memory.
To discriminate in favor of deterministic I/O on systems with large file I/O activity, or on the contrary, to discriminate in favor of better performance of non-I/O-intensive processes, you can consider changing the values of these tunables, keeping in mind the side effects as described below.
To determine a reasonable value for the cache size you should consider the file I/O-intensive applications on your system, and the size of their working set. Depending on the type of applications, the working set size can be based on the size of a transaction, or data size in given unit of time. For example, for a conservative value of filecache_min in megabytes, you can use the following formula:
MB = number-of-system-processes * largest-application-record-length-in-MB * number-of-records-in-working-set
Only those processes that actively use disk I/O for file data should be included in the calculation. All others can be excluded. Here are some examples of what processes should be included in or excluded from the calculation.
Include:
NFS daemons, text formatters, database management applications, text editors, compilers, and so on, that access or use source and/or output files stored in one or more file systems mounted on the system.
Exclude:
X-display applications, hpterm, rlogin, login shells, system daemons, telnet or uucp connections, and so on. These processes use very little, if any, disk I/O for file data.
Restrictions on Changing
These tunables are dynamic and automatic.
The system rounds the specified tunable value(s) down to the closest physical page boundary.
The amount of physical memory represented by filecache_min must be equal to or less than the memory represented by tunable filecache_max.
Setting these tunables to a constant value will de-couple them from OL* events.
Tuning up of the filecache_min parameter may fail if there is not enough free physical memory to satisfy the request.
These tunables, filecache_min and filecache_max, must both be set to a relative state (either default of percent state), or must both be set to a constant value. For example, the following are acceptable settings:
# kctune filecache_min=100MB filecache_max=100MB
# kctune filecache_min=15% filecache_max=65%
# kctune filecache_min=Default filecache_max=65%
The following will result in an error:
# kctune filecache_min=10% filecache_max=1GB
ERROR: The specified units for the values of filecache_min and filecache must be consistent: both as relative (percentage or default) or both as constant value.
If filecache_min is currently set to default, the following is acceptable:
# kctune filecache_max=Default
# kctune filecache_max=40%
But the following will result in an error:
# kctune filecache_max=1GB
See other restrictions in the Allowed values section above.
When Should the Value of These Tunables Be Raised?
Low system performance at initialization time and/or on a system with filesystem I/O-intensive processes may be an indication that the values of these tunables are too low. If there is a large number of processes actively and constantly using file data I/O, you should raise the value of filecache_min for more deterministic I/O. In most cases, especially when the file data I/O is expected to peak only occasionally, it is recommended that the value of the maximum limit, filecache_max, is raised instead.
What Are the Side Effects of Raising the Values?
The amount of memory reserved for the minimum file cache size, dictated by filecache_min, cannot be used on the system for other purposes. Be careful not to raise this value so high that it can eventually cause memory pressure and overall system performance degradation.
When Should the Values of These Tunables Be Lowered?
The value of the minimum limit, filecache_min, can be lowered to allow a larger percentage of memory to be used for purposes other than filesystem I/O caching, depending on competing requests. By lowering the value of filecache_max, a larger amount of memory is available for other purposes, without competing with file I/O requests.
What Are the Side Effects of Lowering the Values?
If there are many competing requests for physical memory, and the file cache tunables are set to too low a value, very high demand on file I/O operations can eventually cause filesystem I/O performance degradation.
EXAMPLES
Set the file cache minimum to 10% of physical memory:
# kctune filecache_min=10%
Set a fixed size file cache of 1 gigabyte:
# kctune filecache_min=1GB filecache_max=1GB
Set the file cache minimum to 15% of physical memory, and the maximum to 65% of the physical memory:
# kctune filecache_min=15% filecache_max=65%
WARNINGS
All HP-UX kernel tunable parameters are release specific. These parameters may be removed or have their meaning changed in future releases of HP-UX.
Other tunable parameters related to sizing the buffer cache that existed in previous HP-UX releases are now obsolete. The tunables filecache_min and filecache_max should be used to set limits to the file cache. Note that, on any given system, the optimum values of these two new tunables are not necessarily equivalent to the optimum values of the obsolete tunable values in the older systems. You should first determine if the new default values yield acceptable performance on your system, before attempting to change the values of the new file cache tunables.
Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tunable values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see HP-UX Release Notes at
AUTHOR
filecache_max and filecache_min were developed by HP.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/19423/viewspace-672883/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 記憶體不足導致安裝時報錯ORA-3113(二)記憶體
- 記憶體不足導致安裝時報錯ORA-3113(一)記憶體
- win10更新失敗提示記憶體不足怎麼回事_win10記憶體不足導致更新失敗如何修復Win10記憶體
- 避免PHP-FPM記憶體洩漏導致記憶體耗盡PHP記憶體
- Allowed memory size 記憶體不足記憶體
- android Handler導致的記憶體洩露Android記憶體洩露
- 記一次排序導致的記憶體危機排序記憶體
- 電腦記憶體不足怎麼辦? 虛擬記憶體不足的解決辦法記憶體
- Android-Fragment 切換造成記憶體溢位,導致記憶體增長AndroidFragment記憶體溢位
- SQL Server 記憶體洩露(memory leak)——遊標導致的記憶體問題SQLServer記憶體洩露
- 共享記憶體段未釋放導致資料庫記憶體被耗盡記憶體資料庫
- Volley中listener導致的記憶體洩露記憶體洩露
- 系統記憶體不足導致oracle程式被誤殺terminating the instance due to error 822記憶體OracleError
- win10記憶體不足怎麼解決_win10記憶體不足怎麼辦Win10記憶體
- 一個導致JVM實體記憶體消耗大的BugJVM記憶體
- 異常連線導致的記憶體洩漏排查記憶體
- 日誌導致jvm記憶體溢位相關問題JVM記憶體溢位
- 修改記憶體導致Ora-27100錯誤記憶體
- vertica記憶體不足的解決方案記憶體
- pycharm提示記憶體不足怎麼辦PyCharm記憶體
- mongodb記憶體不足怎麼解決?MongoDB記憶體
- 記憶體不足(OutOfMemory)的除錯分析記憶體除錯
- PCI-5565系列反射記憶體卡 反射記憶體交換機反射記憶體
- 記一次記憶體溢位導致的生產事故記憶體溢位
- SQL Server 記憶體洩露”(memory leak)的案例—遊標導致的記憶體問題SQLServer記憶體洩露
- HP-UX作業系統的記憶體UX作業系統記憶體
- HP-UX環境下檢視記憶體UX記憶體
- 記憶體回收導致關鍵業務抖動案例分析-論雲原生OS記憶體QoS保障記憶體
- win10遊戲記憶體不足怎麼辦_win10玩遊戲提示記憶體不足處理方法Win10遊戲記憶體
- win10記憶體不足會黑屏嗎_win10電腦記憶體不足黑屏了怎麼辦Win10記憶體
- 一次JVM記憶體問題導致的線上事故JVM記憶體
- 作業系統HugePage配置導致記憶體驟降探究作業系統記憶體
- w10老顯示記憶體不足怎麼解決 w10記憶體總是顯示記憶體不足處理方法記憶體
- Linux記憶體不足的處理方法Linux記憶體
- 解決ORACLE共享記憶體不足的方法Oracle記憶體
- 海信電視記憶體不足怎麼辦?記憶體
- 記一次Orika使用不當導致的記憶體溢位記憶體溢位
- 可能會導致.NET記憶體洩露的8種行為記憶體洩露