最近做了一次MySQL所谓的”海量数据”查询性能分析.
表结构
| dt |
dt2 |
dt3 |
it |
it2 |
it3 |
|
| id |
id |
id |
id |
id |
id |
int PK |
|
|
ext1 |
|
|
ext1 |
varchar(256) |
| time |
time |
time |
time |
time |
time |
int/datetime KEY |
|
ext2 |
ext2 |
|
ext2 |
ext2 |
varchar(128) |
说明, MyISAM引擎, dt表示时间字段使用datetime类型, it表示时间字段使用int类型.
初始数据
首先生成100K个UNIX时间戳(int), 然后随机选取10M次, 每一次往6个表里插入一条记录(当time字段是datetime类型时, 做类型转换). 所以每一个表都有10M条记录. ext1和ext2字段会用随机的字符串填充.
Continue reading »
Written by ideawu
at 2011-05-21 10:18:05 | tags: MySQL
今天, 和部门的同事一起分享了Web服务器的核心内幕, 把PPT奉上, 大家喜欢可以下载. 本PPT的出发点和许多所谓的XX源码分析非常不同.
Written by ideawu
at 2011-04-29 18:06:54
最近在设计一种网络服务器架构, 最重要的一点是把耗时操作委托给工作进程(或者线程)来做, 所以考察一下 fastcgi. 大概看了下 lighttpd 的 mod_fastcgi 的源码, 没想到立即被卡住了. 根据我的想法, PHP 等 fastcgi 程序(php-cgi 进程)监听网络, 然后 mod_fastcgi 只需要 connect 这些进程即可, 奇怪的是, 我竟然看到了 listen! -
fcgi_spawn_connection() 函数:
fcgi_fd = socket(socket_type, SOCK_STREAM, 0);
if (-1 == connect(fcgi_fd, fcgi_addr, servlen)) {
close(fcgi_fd);
fcgi_fd = socket(socket_type, SOCK_STREAM, 0);
/* create socket */
bind(fcgi_fd, fcgi_addr, servlen);
listen(fcgi_fd, 1024);
switch ((child = fork())) {
case 0: {
// child process
if(fcgi_fd != FCGI_LISTENSOCK_FILENO) {
close(FCGI_LISTENSOCK_FILENO);
dup2(fcgi_fd, FCGI_LISTENSOCK_FILENO);
close(fcgi_fd);
}
/* exec the cgi */
execve(arg.ptr[0], arg.ptr, env.ptr);
exit(errno);
}
}
我很奇怪, mod_fastcgi 为什么要监听网络连接? 谁会连接它? 问了同事, 同事说可能是 fastcgi 进程要连接它, 可问题是 fastcgi 进程怎么知道连接什么地方, 更不用说, fastcgi 协议里没有提到要 fastcgi 进程主动连接 Web Server 一说.
Continue reading »
Written by ideawu
at 2010-08-29 18:00:51
不同于Windows平台的高效的线程机制, Linux/Unix系统早期通过多进程来解决Web大规模并发访问量的问题. 而随着Linux内核的改进, 单纯增加进程数量的方式也慢慢被弃用, 转而使用单进程异步IO接口, 比如epoll(Linux), kqueue(BSD).
单进程异步IO接口可以简单理解为, 进程把大量的socket连接交给内核管理, 一旦连接中有数据需要处理, 则激活进程进行处理. 这样, 一个进程同时打开的socket(也即文件描述符)就有成千上万个.
Linux系统默认的单个进程所能打开的最大文件描述符一般是1024(可通过ulimit -n命令查询), 这就导致了文件描述符被用完的情况出现. 所以, 要开发能处理高并发请求的Web系统, 必须修改操作系统的最大文件描述符.
即使使用的是Apache这样的多进程Web服务器, 也有可能被最大文件描述符限制给绊倒, 因为后端可能使用的是fastcgi, memcached这些应用. 比如memcached, 一般使用的就是单进程异步IO接口, fastcgi的PHP脚本与其连接时, 将保持TCP长连接, 也是会消耗大量的文件描述符.
所以, 运行在Linux之上的高性能Web系统, 一定要扩大进程的最大文件描述符限制, 这是有很惨痛经验教训的.
Written by ideawu
at 2010-03-14 10:59:04
大规模Web应用系统, 几乎都会遇到数据库瓶颈问题. 在早期, 通过数据库配置优化, 表优化, 索引优化等软件方法, 可以解决一些问题. 马上, 数据库瓶颈迫使不得不把MySQL和Apache单独部署到不同的机器, 形成Web服务器(Web Server)和数据库服务器(DB Server)的物理分离, 这样就能解决大部分的问题. 但是, 在继续发展时, 一台Web服务器和一台数据库服务器也不能满足高并发的访问量了.
这时, 问题首先是计算能力的问题, 也就是硬件不够用的问题. 所以, 需要上多台Web服务器和多台数据库服务器.
有时候, 网站可以纵向切分, 这样, 任何两台服务器(一台Web Server + 一台DB Server)单独配置, 便能运行一个应用. 比如某两台运行着论坛程序, 某两台运行着新闻程序.
很多情况下, 并不能纵向切分, 每一台的Web Server的角色和功能都是一样的, 没有差别, DB Server也是一样. 理想的情况下, 同种压力的SQL语句平均分布到每一台DB Server, 那就能解决高并发数据库请求问题了
dbproxy的作用便是如此: 合理地分配数据库请求给所有的DB Server, 使得在请求的数量等于或者小于所有DB Server的计算能力总和时, 服务能够正常运行.
Continue reading »
Written by ideawu
at 2010-03-10 23:51:47
大规模Web应用有两个要解决的问题: 高可用性和负载均衡. Keepalived可以提供IP层的高可用性, 一旦某一台机器的网络出现问题, 另一台服务器会立即(几秒或者更少的时间)使用出故障的服务器的IP进行工作. 具体的工作原理会在我学习之后, 发布在后期的文章中.
现在有两台虚拟机ServerA和ServerB. 两个对外提供Web服务器的虚IP(VIP)192.168.200.100和192.168.200.200, 虚IP用在keepalived的配置中, 网卡接口配置有内网IP.
ServerA:
eth0: 192.168.200.128
VIP: 192.168.200.100
ServerB:
eth0: 192.168.200.129
VIP: 192.168.200.200

如果两台服务器都正常地提供网络服务, 那么, 发往192.168.200.100的服务请求会被ServerA处理, 发往192.168.200.200的服务请求会被ServerB处理. 假设只有ServerB出现故障, 那么, 所有的请求都由ServerA进行处理. 当只有ServerA出现故障时, 也是同理.
安装Ubuntu Linux Server
本文使用的Linux为Ubuntu 9.04 服务器版, 请到http://www.ubuntu.com.cn/getubuntu/download-server/下载. 需要安装gcc, make开发环境.
Continue reading »
Written by ideawu
at 2009-07-16 23:09:45
|
|
Recent Comments