存档

2015年5月 的存档

Centos通过某台服务器中继上网

2015年5月28日 没有评论

转自贝贝的blog,略有补充,贝贝的原贴地址:http://www.thinkingquest.net/articles/449.html

有两个补充之处:
1、GATEWAY配置
Centos的GATEWAY配置不仅在ifcfg-eth0中,也可能在/etc/sysconfig/network中。ifcfg-eth0中对单个网卡有效,network配置的是全局,作用范围不同。
原理都是改GATEWAY。

2、转发配置:
修改/proc/sys/net/ipv4/ip_forward是临时性的,是内核的当前运行状态,永久的改动位于:
/etc/sysctl.conf的

net.ipv4.ip_forward = 1

改完后执行以下命令生效

#sysctl -p

生效后,/proc/sys/net/ipv4/ip_forward会自动变为/etc/sysctl.conf中net.ipv4.ip_forward的值。

下面附上贝贝的原文(我这访问只能绑host访问贝贝的blog,原文转过来更方便)。
--------我是分隔线,以下是引用的全文----------

几个vps(虚拟主机),只有一个拥有公网ip地址,所有的vps都拥有内网ip地址。其它的vps需要通过拥有公网ip的这个vps进行公网访问,以方便yum安装软件等需求。

在没有公网ip的vps上需要进行的设置:

/etc/sysconfig/network-scripts/ifcfg-eth0 文件中: GATEWAY=10.x.x.x

service network restart

到此完成。

接下来是拥有公网ip的那台vps上进行设置:

echo “1” > /proc/sys/net/ipv4/ip_forward

注意,这条命令是临时开启系统的转发功能,系统重启后会恢复为默认设置。 可以通过在/etc/rc.d/rc.local中加入上述命令,使之在系统启动时被执行。

打开iptables的nat功能:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

到此设置完成。

其它vps应该可以访问公网了。

分类: 工作 标签: , , ,

MySQL动态调整索引一例

2015年5月18日 没有评论

缘起:线上发现一条慢查询日志,耗时32秒,对用户来说此次访问直接失败。

原因:用户长期未上线,拉群离线消息时扫描了几千万行数据。

现状:主键为消息唯一编号msgId,用户拉消息时,使用msgId > xxxx来拉,正常用户间隔较近,基本上耗时为毫秒。间隔越大,时间越长。

修改:当前msgId差值小于200w时,用主键索引。超出时,强制使用群编号groupId索引。msgId差值200w时用主键索引耗时为5秒左右。差值4000w时强制使用groupId索引,耗时600毫秒左右。

结论:用默认方案hold绝大多数的case,当特例出现时,强制使用另一个索引,确保用户可用。

分类: 工作 标签: , ,

tcpdump和strings的组合用法

2015年5月8日 没有评论

tcpdump是抓包工具,strings是输出可见字符工具,组合应用会有比较漂亮的用法。

1、用来监控当前服务器上对MySQL的访问。

tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings

2、用户监控当前服务器上对Redis的访问。

tcpdump -i eth0 -s 0 -l -w - dst port 6379 | strings

只要是有明文传输的地方,都可以这么用。

分类: 工作 标签: , , ,

MySQL禁用查询缓存

2015年5月6日 没有评论

查看当前MySQL的查访缓存方面的参数:

show variables like '%query_cache%';

得到结果如下,说明查询缓存是开启的:

mysql> show variables like '%query_cache%';
+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| have_query_cache             | YES       | 
| query_cache_limit            | 1048576   | 
| query_cache_min_res_unit     | 4096      | 
| query_cache_size             | 134217728 | 
| query_cache_type             | ON        | 
| query_cache_wlock_invalidate | OFF       | 
+------------------------------+-----------+
6 rows in set (0.00 sec)

再查看查询缓存相关的统计状态

mysql> show status like '%Qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 11        | 
| Qcache_free_memory      | 133522200 | 
| Qcache_hits             | 17197     | 
| Qcache_inserts          | 3954      | 
| Qcache_lowmem_prunes    | 0         | 
| Qcache_not_cached       | 34251     | 
| Qcache_queries_in_cache | 271       | 
| Qcache_total_blocks     | 575       | 
+-------------------------+-----------+
8 rows in set (0.00 sec)

一般认为Qcache_hits至少是Qcache_inserts的三倍才可能有效果,最好能达到10倍。这个是四倍多,不太好确定查询缓存是否有效果。

从业务形态上,相同查询出现的几率比较低,更多的是写入和更新操作。还是决定禁用之。

SET GLOBAL query_cache_size = 0;

这个最彻底,可以实时生效。因为query_cache_type只对新开的连接有效,已有连接无效。

后续效果待观察。