Linux 内存管理

╰+哭是因爲堅強的太久メ 2022-06-18 12:47 220阅读 0赞

简单说，程序在一般情况下总是能获取到其申请的内存空间，当物理内存不足时，系统会使用swap来交换部分内存数据以维持内存开销，如果swap也耗尽，内核中的OOM killer 便会按照其算法选择并kill掉若干（一般是1个）进程以释放内存空间。

oom killer 工作原理

1.  [\_alloc\_pages -> out\_of\_memory() -> select\_bad\_process() -> badness()][alloc_pages -_ out_of_memory_ -_ select_bad_process_ -_ badness]

oom killer首先对正在运行的所有程序进行评分（oom\_badness()），根据这个评分决定哪一个或几个程序会被kill掉。评分指标：

memory consumption \#内存消耗

process ownership \#进程的宿主

process age (older kenerls only) \#运行时间

CPU time used (older kernels only)\#cpu 使用周期

process nice value (older kernels only)\#优先级

process flags \#进程状态

oom\_adj/oom\_score\_adj setting \#oom 配置

oom killer在决策过程中的考虑：

1) we lose the minimum amount of work done

2) we recover a large amount of memory

3) we don't kill anything innocent of eating tons of memory

4) we want to kill the minimum amount of processes (one)

5) we try to kill the process the user expects us to kill, this

algorithm has been meticulously tuned to meet the principle

of least surprise ... (be careful when you change it)

而对于一个数据库服务器来说，mysql 占用的内存一般是最高的，如果用户或者其他应用程序以较高的优先级使用内存，在内存耗尽时mysql被oom killer kill掉的概率是最大的。  
可以从下面几个方面去避免这样的情况发生：

1.       内存分配

对于db和应用程序共用服务器的情况，需要对内存有一个明确的分配管理，以避免内存竞争，保证正常情况下不会有内存耗尽从而进程被oom-killer干掉的情况发生。

2.       db buffer的配置

mysql 使用的总内存是可控的（大量的连接以及临时表的情况除外），影响mysql内存占用的相关配置：

主buffer。Myisam的key\_buffer\_size,innodb\_buffer\_pool

线程独享buffer，如read\_buffer\_size 和 sort\_buffer\_size，如果max\_connection 设置的比较大，短时间的大量连接同样会占用大量的内存然后导致内存耗尽。

临时表的配置，参加另一篇博客。临时表往往会导致内存的大量消耗。

存储引擎的专用内存配置，如innodb的log buffersize和innodb\_dict\_size\_limit，如果innnodb表特别多，innodb 元数据占用空间也会很大。

Mysql 内存计算公式：

1.          @@key\_buffer\_size \+ @@query\_cache\_size \+ @@tmp\_table\_size  
    
2.          + @innodb\_buffer\_pool\_size \+ @innodb\_additional\_mem\_pool\_size  
    
3.          + @innodb\_log\_buffer\_size  
    
4.          + @@max\_connections \* (  
    
5.          @@read\_buffer\_size \+ @@read\_rnd\_buffer\_size \+ @@sort\_buffer\_size  
    
6.          + @@join\_buffer\_size \+ @@binlog\_cache\_size \+ @thread\_stack  
    
7.          )

3.       crontab脚本以及临时任务

一般我们的统计计算脚本或者备份脚本会在凌晨运行，这些脚本会读取大量的数据到内存中，也可能造成内存的竞争，可降低其优先级。

4.       oom killer 配置

除了对db和应用的内存占用控制外，也可以修改oom killer 配置来干涩其决策。

查看当前mysql 的oom\_score值：

1.          xchliu@AY1301300558264084667:/etc/cron.d$ cat /proc/$(pidof mysqld)/oom\_score  
    
2.          110

当前配置mysql的值：

1.          xchliu@AY1211280808464774829:~$ cat /proc/$(pidof mysqld)/oom\_score\_adj  
    
2.          0

修改配置：

1.          xchliu@AY1301300558264084667:~$ echo '-20' > /proc/$(pidof mysqld)/oom\_score\_adj

5.       overcommit 优化，内存过度使用的配置。

1.          xchliu@AY1301300558264084667:~$ ls \-l /proc/sys/vm/overcommit\_\*  
    
2.          -rw\-r\-\-r\-\- 1 root root 0 Mar 27 13:52 /proc/sys/vm/overcommit\_memory  
    
3.          -rw\-r\-\-r\-\- 1 root root 0 Mar 27 13:52 /proc/sys/vm/overcommit\_ratio

overcommit\_memory  接受的值：

0 – The default value. Linux kernel uses predefined heuristics when deciding whether to allow memory overcommit or not.

1 – Always allow overcommit. Back to the past when Linux was doing it by default.

2 – Prevents overcommit when certain limit is exceeded.

如果overcommit\_ratio=20，而系统的swap=1G，物理内存为2G，那么系统最高可分配2G+1G\*20%=2.2G的内存。

作为db 服务器，数据库的稳定性是最重要的，Mysql 被oom killer 干掉的情况也是我们最不想看到，要避免这样的情况的发生，一方面要对系统的内存有清晰的分配策略；  
另一方面，对于mysql本身需要配置适当的内存。对于多个服务共存的情况，系统资源的竞争不仅是在内存上面，cpu、io、net 都会出现，解决的思路为：合理规划，优化个体。

参考：

linux 内存管理：[http://www.tldp.org/LDP/tlk/mm/memory.html][http_www.tldp.org_LDP_tlk_mm_memory.html]

oom killer 工作原理：[http://linux-mm.org/OOM\_Killer][http_linux-mm.org_OOM_Killer]

[alloc_pages -_ out_of_memory_ -_ select_bad_process_ -_ badness]: http://linux-mm.org/PageAllocation#AllocPages
[http_www.tldp.org_LDP_tlk_mm_memory.html]: http://www.tldp.org/LDP/tlk/mm/memory.html
[http_linux-mm.org_OOM_Killer]: http://linux-mm.org/OOM_Killer