我有一台旧的、遗留的服务器,其交换功能存在奇怪的问题。
- Linux 版本:Red Hat Enterprise Linux 服务器版本 5.6 (Tikanga)
- 内核版本:2.6.18-238.el5
- 服务器是虚拟的。
- 服务器有2个虚拟插座。
我知道交换分区太小,打算添加一个交换文件,但是,重启几个小时后,情况是这样的:
free -m
total used free shared buffers cached
Mem: 15922 15806 116 0 313 13345
-/+ buffers/cache: 2147 13775
Swap: 2047 2042 4
Oracle 数据库已安装,但几乎未使用。我想了解为什么内存分配会这样。我的意思是 13345 已缓存,意味着可用。为什么要填充交换?
以前的系统管理员将 swappiness 配置为:3.
大页面是未配置。
我看到了一些类似的帖子,但没有解决方案。答案在这里:linux redhat 5.4 - 在内存仍然可用时进行交换谈论了 numa,所以我深入挖掘了一下(我是一名 dba,而不是 sysadmin,所以如果我错过了什么,很抱歉)。
grep NUMA=y /boot/config-`uname -r`
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_ACPI_NUMA=y
dmesg | grep -i numa
NUMA: Using 63 for the hash shift.
因此,问题是:我如何理解这台机器为什么要交换?
更新 使用:vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 2090852 122224 324056 13679328 320 0 498 1898 1088 3555 32 10 56 2 0
1 0 2090724 139740 324068 13680984 64 0 76 932 1028 3534 7 2 90 2 0
0 0 2090724 132416 324068 13681436 0 0 16 240 1016 3401 3 1 96 1 0
4 0 2090660 116916 324084 13683404 0 0 72 1396 1070 3617 11 9 80 1 0
0 0 2090420 126544 324084 13687008 128 0 188 1872 1068 3436 35 8 56 2 0
更新 3
ipcs -ma
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x61a4d538 5210113 oracle 660 4096 0
0xba8cafdc 5242883 oracle 660 4096 0
0x16621634 5308420 oracle 660 4096 0
0xc15f3dac 5373957 oracle 660 4096 0
------ Semaphore Arrays --------
key semid owner perms nsems
0x24690d60 98304 oracle 660 125
0x24690d61 131073 oracle 660 125
0x24690d62 163842 oracle 660 125
0x24690d63 196611 oracle 660 125
0x24690d64 229380 oracle 660 125
0x24690d65 262149 oracle 660 125
0x24690d66 294918 oracle 660 125
0x24690d67 327687 oracle 660 125
0x24690d68 360456 oracle 660 125
0x6285541c 491529 oracle 660 125
0x6285541d 524298 oracle 660 125
0x6285541e 557067 oracle 660 125
0x6285541f 589836 oracle 660 125
0x62855420 622605 oracle 660 125
0x62855421 655374 oracle 660 125
0x62855422 688143 oracle 660 125
0x62855423 720912 oracle 660 125
0x62855424 753681 oracle 660 125
0xaee7ccbc 884754 oracle 660 125
0xaee7ccbd 917523 oracle 660 125
0xaee7ccbe 950292 oracle 660 125
0xaee7ccbf 983061 oracle 660 125
0xaee7ccc0 1015830 oracle 660 125
0xaee7ccc1 1048599 oracle 660 125
0xaee7ccc2 1081368 oracle 660 125
0xaee7ccc3 1114137 oracle 660 125
0xaee7ccc4 1146906 oracle 660 125
0xfb4a455c 1277979 oracle 660 125
0xfb4a455d 1310748 oracle 660 125
0xfb4a455e 1343517 oracle 660 125
0xfb4a455f 1376286 oracle 660 125
0xfb4a4560 1409055 oracle 660 125
0xfb4a4561 1441824 oracle 660 125
0xfb4a4562 1474593 oracle 660 125
0xfb4a4563 1507362 oracle 660 125
0xfb4a4564 1540131 oracle 660 125
------ Message Queues --------
key msqid owner perms used-bytes messages
答案1
如果您没有遇到大量活动页面调度(vmstat 中的 si/so),则无需担心。内核选择将未主动使用的程序代码位放入交换区,以便它可以将更多 DB 文件保留在 RAM 中(缓存在空闲空间中)。
这是我发现的一篇有关交换以及为什么使用交换并不总是坏事的优秀文章。https://chrisdown.name/2018/01/02/in-defence-of-swap.html
答案2
不好。如果你除了偶然的事情之外还有什么,si
那你基本上超出“良好交换”的范围。而且您的系统一直在这样做。SwapIn 意味着某个程序正在等待,这可能意味着用户(本地或远程用户)的运行速度变慢。
我非常赞成这种好的交换方式。这意味着主要so
将膨胀的内容从您宝贵的 RAM 中推出;由于膨胀的内容会停留在磁盘上,因此没有人会使用它们,除非进行非常偶然的交换活动。
您遇到了我之前见过的 Oracle 的一个有趣的问题:Oracle 不知何故将其 SGA 报告为“缓存”(如果我没记错的话,因为它是匿名的mmap
)。但是由于是匿名的,它不是系统可以随时丢弃的内存,因此它不是free
!恰恰相反 - 它被大量使用。Oracle 在读取数据文件时通常还会使用实际剩余的系统缓存,这会对缓存造成很大的内存压力(愚蠢的默认行为)。
free
因此,这是许多误导您认为所有“缓存”都应视为“免费”的情况之一。该经验法则仅适用于大多数只读文件服务器。(我认为这就是为什么作者free
将“缓存”设置为“已使用”的原因多于暗示“缓存”是“空闲”的那行。)
swappiness
只要系统的交换空间占用率达到 100%,就根本不要进行任何调整。这...不明智。
我敢打赌你的 SGA 不会是 2 GB,但可能更像是 10 GB 甚至更多。我认为,如果你将 SGA 配置为 6 GB,你会看到交换引脚会减少,并且推送到交换的内容会少得多。随着你一步步增加它,你会看到压力如何增加。