NUMA导致的MySQL服务器SWAP问题分析与解决方案

作者: 云计算机网 分类: 云安全 发布时间: 2017-05-14 06:10

【SWAP产生原理】

先从swap产生的原理来分析,由于linux内存管理比较复杂,下面以问答的方式列了一些重要的点,方便大家理解:

1、swap是如何产生的

swap指的是一个交换分区或文件,主要是在内存使用存在压力时,触发内存回收,这时可能会将部分内存的数据交换到swap空间。

2、内存回收的机制

lt;1gt;Linux内核使用cache对部分文件进行缓存,提升文件读写效率。所以 引入了kswapd进程进行周期性检查,保证剩余内存空间。

lt;2gt;当内存分配没有足够的空间时,直接内存回收。

3、内存回收如何实现

这部分实现非常复杂,简单来说,内存回收操作主要针对内存的文件页和匿名页,这些页都通过LRU链表来管理。

其中anon的匿名页内存主要回收手段是swap,文件页释放方式是写回和清空。

4、讲几个重要的概念

lt;1gt;内存节点node,在NUMA的情况下,CPU访问不同位置的内存,会有本地内存和远端内存之分,这两个就是不同的节点。

lt;2gt;内存分区 zone,linux对内存节点做了进一步划分,将一个节点划分为不同的区。内存管理的逻辑以zone为单位。

lt;3gt;内存水位标记,分为high、low、min

通过下图可以比较直观的了解

5、内存回收行为

lt;1gt;当系统剩余内存低于low时,kswapd开始起作用进行内存回收,直到内存达到high水位。

lt;2gt;当剩余内存达到min时就会触发直接回收。

lt;3gt;当触发全局回收,并且file+freelt;=high时,一定会进行针对匿名页的swap。

下面举例:

在数据库做全备份时cache大量使用,剩余可用空间不足,触发内存回收,

上图是/proc/zoneinfo的部分内容,可以看到满足了file+freelt;=high的条件,同一时间触发了swap,将内存匿名页的数据写入交换区

有大量的文件页cache,为什么会出现file+freelt;=high的情况,分析下来全备文件缓存时,node 0的nr_inactive_file很低,大部分非活动的文件页都分布在node 1上,是由于开启NUMA导致的。

【关闭NUMA的方案】

1、 在mysqld_safe脚本中加上numactl ndash;interleave all来启动mysqld

2、 Linux Kernel启动参数中加上numa=off,需要重启服务器

3、 在BIOS层面关闭NUMA

4、 MySQL 5.6.27/5.7.9开始引用innodb_numa_interleave选项

对于2、3、4关闭NUMA的方案比较简单,不做详细描述,下面重点描述下1方案

【开启numa interleave访问的步骤】

1、 yum install numactl -y

2、修改/usr/bin/mysqld_safe文件

cmd="`mysqld_ld_preload_text`$NOHUP_NICENESS"下新增一条脚本

  • 怎么解决Serv-U域离线的问题,首先我们先了解是什么原因导致了Serv-U域离线,接下来就来看看Serv-U域离线的解决办法。

    一. IIS服务冲突导致

    原来因为在Windows Server 安装了IIS,系统内IIS服务是开启状态,并且IIS服务中有一个默认FTP站点。而默认端口是21,SERV-U内的默认端口也是21,恰好是冲突的,(可以通过修改iis或serv_u的服务端口即可)。
    [解决方法]于是,我把IIS服务中的FTP服务停止(或者更改IIS中FTP服务的端口,亦或更改Serv-U的默认端口),就可以正常使用SERV-U了。

    弄完了之后,并不是所有的都好用。我发现Serv-U仍然提示域正离线。简单思考一下,就能想明白。个人觉得,因为IIS服务中的FTP停止了,但是Serv-U域中的状态仍然没有进行刷新或者称之为更新改变。所以我们只需要改变一下Serv-U的当前状态或者退出Serv-U重新登录即可。

    其实还有个重要问题就是注册信息,你看看你的Serv-U是否已经注册成功的。

    二.权限设置不正确

    如果我们简历FTP空间了。SERV-U里相应的权限都设置了。可是FTP还是登录不上传不了文件,检查SERV-U指认的磁盘和目录权限,如果在权限账户里没有serv这个账户我们就手动添加一个并设置相应的读写权限即可。

    三.Serv-U域自动离线

    很奇怪,后来几天自建的FTP,Serv-U域总是一开机就自动离线,重新填写域IP,应用之后,就正常了。但是重启之后,又挂掉,造成FTP连接不上。
    查看Serv-U日志:

    Wed 29Apr09 07:58:56 - SERVER IS NOT LISTENING ON IP 172.16.88.202: Trying to use non-existent IP address?
    正常情况应该是这样:

    Wed 29Apr09 09:07:24 - FTP Server listening on port number 21, IP 172.16.88.202, 127.0.0.1
    再查看windows的事件日志,应用程序相关事件:

    FTP Server listening on port number 43958, IP 127.0.0.1
    SERVER IS NOT LISTENING ON IP 172.16.88.202: Trying to use non-existent IP address?
    在系统相关事件日志:


    您的计算机未能为网络地址是 0015600F1E28 的网卡从 网络续订其地址(从 DHCP 服务器)。出现了以下错误:
    信号灯超时时间已到。 计算机将继续试图从网络地址(DHCP)服务器获取地址。据此,我认为是DHCP分配IP地址出现问题,所以造成Serv-U域自动离线。于是,我把Serv-U域IP地址改为使用任何可用的IP地址。

    据此,我认为是DHCP分配IP地址出现问题,所以造成Serv-U域自动离线。于是,我把Serv-U域IP地址改为使用任何可用的IP地址。

    这样更换任何IP,FTP都可以正常服务。
    但是DHCP获取IP地址倒底出了什么问题,还是没弄清楚。

  • 相关推荐:

  • 怎么解决Serv
  • FTP服务器的部署以及维护
  • 关于FTP服务器的权限问题
  • FTP上的具体应用和管理办
  • 熟悉并灵活应用FTP的内部
  • 谁拿了我的屠龙刀? 看
  • 病毒传播渠道再变革:
  • 安全回忆录:铺天盖地的
  • 新病毒冒充播放器逃脱杀
  • 病毒里的F117 隐秘躲避
  • 网站内容禁止违规转载,转载授权联系中国云计算网