寻觅生命中的那一片浅草......

每月存档 十月, 2015

mysqldump引起MySQL内存飙升事例一则

最近有台MySQL,在运行一段时间后,res和virt内存都会去到很高,res会占到物理内存的90%,最终导致业务异常

期间做过的尝试:

  • 用tcpcopy来把生产环境的流量导到测试服,但MySQL内存并无异常
  • 将innodbfilepertable=1修改为innodbfilepertable=0,运行1天后,内存飙升还是比较厉害

上面的措施都没有用。

下面这个,不确定有没有试过,也记录下吧

mysqldump -q,就是把数据尽快写到磁盘,而不是存在内存

最后是同事看监控,发现在凌晨,MySQL备份后,内存才飙升,我们最后定位到MySQL内存异常的原因是以下2个:

  • xxx_db下表太多:近2W了,一个区服就一个表来寸配置
  • 由于表太多,下面的指令把整个库的表结构导出来的时候,估计会把整个结构先写入内存,但理论上,这个表结构不会大
mysqldump -d $1 > $1_db_struc.sql

解决办法:

  • 不导整个库的结构,一个表一个表地导(这个也是目前的做法),或者直接就不导结构,因为都是一样的
  • 减少表数量,我们后来把它改为了这种方式,单个表存所有区服的信息

vsftpd禁止删除

实现可以写,不可以删除的功能

vi vsftpd.conf

加入

cmds_denied=DELE,RMD

完整ftp命令参考:RawFTP

启动MySQL时预热buffer_pool

MySQL5.6加入了一个把buffer_pool dump到磁盘的功能,加快MySQL重启后,数据的预热速度,我们用的Percona Server 5.5也加入了这个功能主要有以下几点:

  • 只dump页表的号码到磁盘,而不是数据 ,所以,即使你buffer_pool很大,实际dump出来的数据很小,文件存放在MySQL的数据目录
  • 可以设置固定时间间隔自动dump
  • 设置关闭时自动dump,开启时自动restore
  • innodb_buffer_pool_restore_at_startup=600,每10分钟保存buffer_pool到磁盘,这个只是保存了磁盘上数据的索引,并不是真正的数据,否则这个文件会非常大
  • innodb_blocking_buffer_pool_restore=1,在MySQL启动时,阻塞启动过程,直到buffer_pool预热后才通知系统已经启动成功
#!/bin/bash

# change online  
mysql -uroot -pxxx <<EOF
set @@global.innodb_buffer_pool_restore_at_startup=600;
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;
EOF

手动dump和restore

可以在MySQL启动后,select一个表的数据,然后查看buffer pool的page数量,手动把buffer pool dump到磁盘,再重启MySQL,看它是否会restore

一些命令:

# 查看buffer pool的数据大小
show status like 'innodb_buffer_pool_pages_data';
# 手动dump
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;
#手动restore
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA

用GoAccess分析Nginx日志

适合单次分析

简介

如果你想统计下以下数据,命令行工具GoAccess是非常适合的

  • 不同页面的访问
  • 不同Referrers
  • 不同来源IP
  • 404,浏览器,操作系统

 

日志格式

GoAccess用的是apache的格式定义,内置了4种格式,如果你用的是Nginx默认的日志格式,那么这里可以选”NCSA Combined Log Format”,也可以自定义,默认定义文件在:

~/.goaccessrc

你也可以在其他地方定义,然后通过-p指定日志格式定义文件

假设有一条日志格式是:

0.025 - 192.168.15.41 - - [08/Jan/2014:18:14:35 +0800] "GET /Game.php?agentName=kk&serverID=3 HTTP/1.1" 200 5803 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" -

分别代表处理时间、这个-是人为定义上去的、请求来源IP、这个-字段,是获取远程用户,这里没有,所以是-、这里的-是NCSA标准格式里的、请求时间、请求的URL、http响应码、发送的数据大小、引用来源,这里是空,所以是-、客户端版本等信息、最后一个列是让代理请求客户端IP的,这里是空,所以也是-

那么日志定义文件应该是这样:

color_scheme 0
date_format %d/%b/%Y
log_format %T - %h %^[%d:%^] "%r" %s %b "%R" "%u"
log_file /data/logs/web._php_only.log-20131212

分析

可以把分析结果输出到终端,也可以输出为html,json等格式

命令:

goaccess -f  /data/logs/web._php_only.log-20131212 > ur.html

这里有一个需要注意,由于一些接口的特点,每次请求的URL里有个加密串,造成每次请求的URL都是唯一的,goaccess无法统计它,这时可以加-q参数,忽略掉URL问号后面的参数。

命令

goaccess -q -f /data/logs/web._php_only.log-20131212

用Nginx的proxy_cache加速gitbucket

最近访问gitbucket,基本都要5-6s才能打开,在服务器上看java进程占用CPU500%,通过下面的proxy_cache配置,把图片等静态资源缓存起来,可以实现gitbucket秒开,CPU使用降到30%左右,效果非常明显

创建目录并给予Nginx运行用户权限

mkidr /data/cache/nginx
chown -R www.www /data/cache/nginx

http段配置

定义cache的存放路径

http{
proxy_cache_path /data/cache/nginx levels=1:2 keys_zone=cache:512m inactive=1d  max_size=60g;
# 下面省略其他配置
....
....
}

修改虚拟主机配置

# 注意下面的配置要放在location / {这个目录配置之前
location ~ \.(gif|png|txt|css|png|jpe?g|ico|js)$ { 
     proxy_pass http://localhost:8088;
     proxy_hide_header       Set-Cookie;
     proxy_ignore_headers    Set-Cookie Expires Cache-Control;

     proxy_redirect    off;
     proxy_buffering on;
     proxy_buffer_size  128k;
     proxy_buffers 100  128k;

     proxy_cache cache;
     proxy_cache_key $uri;
     proxy_cache_use_stale error timeout invalid_header;
     proxy_cache_valid 200 301 302 60h;
     expires 30d;
}

 

2015年十月
« 9月   11月 »
 1234
567891011
12131415161718
19202122232425
262728293031