Polaroid Photo

Pictures from 虚写人生[周锋]-服务器架构与运维

虚写人生[周锋]-服务器架构与运维

没有最好，只有更好！

Choose a Topic:

周五
25
十一 '11

用tilt来做堡垒机

Part of 周 锋's adventure in 04-系统技术, 07-运维与监控

上次测试了一家商用的堡垒机器后，印象特别深刻，发现堡垒机器做行为审计真的是做的极致了，但是价格好贵啊，刚好碰上公司开源节流的时候，项目就给XX掉了！后来很是心痛，这样的事情是否有开源的呢？后来我组的一位同事花了不少时间在研究这个东西，他偶尔发现了一个特别好用的可以替代堡垒机方案的开源软件：TILT (Terminal Interaction Logging Tool)，其官方网站是http://sourceforge.net/projects/tilt/reviews/下边就来讲讲安装和部署：
1.下载源码：

wget http://down.hiphp.com/ports/tilt/tilt-0.1.1.gz

2.修改源码:

#ifdef TELNET
#define EXE "/usr/bin/telnet_bak"
#define CHILDNAME "TELNET"
#endif
#ifdef SSH
#define EXE "/usr/bin/ssh_bak"
#define CHILDNAME "SSH"
#endif
#ifdef BASH
#define EXE "/bin/bash_bak"
#define CHILDNAME "BASH"
#endif

#ifndef DEBUG
#define LOGPATH "/var/log/tilt"
#else
#define LOGPATH "."
#endif

3.安装：

tar -zxvf tilt-0.1.1.gz 
cd tilt-0.1.1 
./configure --prefix=/usr/local/tilt-0.1.1
make
make install

4.命令使用：

# ./dumplog -h
Usage: ./dumplog [OPTION]... [FILE]...
Dump logs generated by TILT in a human readable form
 
  -s            Print in real time equivalent to -m1
  -m NUM        Print NUM times faster than real time
  -h            Print with human readable time stamps at the beginning of
                  each new line this overrides -t
  -t            Print time stamps as seconds since 1970-01-01 00:00:00 UTC
                  at the beginning of each new line
  -r            attempt to resize the terminal to the recorded size
  -S, --start   start dump at time offset
  -E, --end     end dump at time offset
  -e, --grep    only print lines that match the regexp
  -i,           ignore case in regexp
  -p,           attempt to remove backspaces from each line in regexp match
  -c,           attempt to remove backspaces from each line and cisco line wraps in regexp match
  -H,           print each match with filename
  -?, --help    display this help and exit

Start discussion »

周四
30
十二 '10

263.COM开始跳转了

Part of 周 锋's adventure in 01-web服务器

操作到一半，我觉得还是有必要记录下这个算是历史性的时刻，263.COM从今天起全站将跳转到GANJI.COM了，真是无限感叹啊！做了这么多年，虽然看惯了花开花落，但是这次还是有颇多感慨，不知道收回后的263.COM将以什么样新的面貌再次出现，期待中……

Start discussion »

周一
1
十一 '10

对于大日志包进行分割的N种方法

Part of 周 锋's adventure in 04-系统技术

对于大日志包进行分割的N种方法
(源自：杨志刚 博客 http://yangzhigang.cublog.cn)

前言：
网站一个主要域名的日志包，解压缩之后有10多个G，当日志分析系统处理此日志包时，需要的分析时间过长，而且如分析过程中出错，要清空数据后再分析，所以需要将日志进行分割成多个日志包，通过多个日志分析系统并发分析，本文主要记录一下我测试的分割过程。

说明：
本文采用一个50M大小的日志文件进行测试。
日志文件名：log.txt.gz。
文件行数：208363

方法1：（split分割）

语法：split  [-< 行数>][-b < 字节>][-C < 字节>][-l < 行数>][要切割的文件][输出文件名]
# gunzip log.txt.gz             //一定要先解压，否则分割的文件是不能cat/zcat显示；
# wc -l log.txt                 //计算一个文件的总行数；
 208363 log.txt
# split -l 120000 log.txt newlog    //通过指定行数，将日志分割成两个文件；
# du -sh *
50M     log.txt
29M     newlogaa
22M     newlogab
# file *                         //分割后的文件与原文件属性一样
log.txt:  ASCII text, with very long lines, with CRLF line terminators
newlogaa: ASCII text, with very long lines, with CRLF line terminators
newlogab: ASCII text, with very long lines, with CRLF line terminators
# gzip newlogaa newlogab         //将分割后的文件进行压缩，以便传输

另一种方法，通过大小分割（# split -C 26000000 log.txt newlog），-C（大C）是按大小分，并尽量保持按行，-c（小c）就可能分将一行分到不同文件中。测试-C（大C）没有问题，相对-l(按行)来说，统计一个大文件的字节要比统计行数要快得多。用-C（大C）还是-l，请按实际情况而定。
Continue reading "对于大日志包进行分割的N种方法" »

Start discussion »

周一
1
十一 '10

Linux输出重定向小结

Part of 周 锋's adventure in 07-运维与监控

最近/var空间老是报警，起因是/var/spool/clientmqueue下文件数量太多导致占用空间很大，此空间下存放了大量的crontab运行而发送给root的邮件，可以用以下步骤解决：

1、首先删除此目录下的三天前的文件: find ./ -atime +3 -exec rm {} \;
2、在所有运行的crontab脚本后添加日志重定向 >/dev/null 2>&1

对于LINUX的重定向，转一篇比较好的说明文字：

Linux Shell 环境中支持输入输出重定向，用符号<和>来表示。0、1和2分别表示标准输入、标准输出和标准错误信息输出，可以用来指定需要重定向的标准输入或输出，比如 2>a.txt 表示将错误信息输出到文件a.txt中。
同时，还可以在这三个标准输入输出之间实现重定向，比如将错误信息重定向到标准输出，可以用 2>&1来实现。
Linux下还有一个特殊的文件/dev/null，它就像一个无底洞，所有重定向到它的信息都会消失得无影无踪。这一点非常有用，当我们不需要回显程序的所有信息时，就可以将输出重定向到/dev/null。
如果想要正常输出和错误信息都不显示，则要把标准输出和标准错误都重定向到/dev/null， 例如：

# ls 1>/dev/null 2>/dev/null

还有一种做法是将错误重定向到标准输出，然后再重定向到 /dev/null，例如：

# ls >/dev/null 2>&1

注意：此处的顺序不能更改，否则达不到想要的效果，此时先将标准输出重定向到 /dev/null，然后将标准错误重定向到标准输出，由于标准输出已经重定向到了/dev/null，因此标准错误也会重定向到/dev/null，于是一切静悄悄:-)

Start discussion »

周二
12
十 '10

MySQL中SQL优化和架构设计的一些简单想法[转]

Part of 周 锋's adventure in 02-数据库技术

普通MySQL运行，数据量和访问量不大的话，是足够快的，但是当数据量和访问量剧增的时候，那么就会明显发现MySQL很慢，甚至down掉，那么就要考虑优化我们的MySQL了。
优化无非是从三个角度入手：
第一个是从硬件，增加硬件，增加服务器
第二个就是对我们的MySQL服务器进行优化，增加缓存大小，开多端口，读写分开
第三个就是我们的应用优化，建立索引，优化SQL查询语句，建立缓存等等
我就简单的说说SQL查询语句的优化。因为如果我们Web服务器比数据库服务器多或者性能优良的话，我们完全可以把数据库的压力转嫁到Web服务器上，因为如果单台MySQL，或者 Master/Slave 架构的数据库服务器都负担比较重，那么就可以考虑把MySQL的运算放到Web服务器上去进行。当然了，如果你Web服务器比数据库服务器差，那就把压力放在数据库服务器上吧，呵呵。
Continue reading "MySQL中SQL优化和架构设计的一些简单想法[转]" »

Start discussion »

周一
23
八 '10

万变不离其中的排错方法->32位系统文件不能过2G

Part of 周 锋's adventure in 04-系统技术, 07-运维与监控

今天周一刚一上班，发现我的CACTI登录后老是502错误，于是登录系统开始排查：
1、我首先看了下系统版本

[root@sdb1 log]# cat /etc/redhat-release 
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
[root@sdb1 log]# uname -a
Linux sdb1 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux

2、我看到系统是32位系统，于是想是不是有日志文件超过2G了，于是我把Nginx的日志，FastCGI的日志都清理了一遍，问题依然存在。
3、我把FastCGI和Nginx都重启了一遍，问题也依然存在。
4、没有办法，我把Nginx的的debug日志打开，查看日志错误提示

(104: Connection reset by peer) while reading response header from upstream

5、好熟悉的日志啊，我以前肯定处理过，但是不记得了于是开始GOOGLE，按照网上提示说修改内存大小，修改超时时间，重启FastCGI,问题依然存在。
6、从这个时候起我开始怀疑是不是有人修改了配置，于是开始把Nginx和FastCGI的配置跟正常机器都核对了一遍，没有发现问题。
7、目光终于开始转向到Cacti目录。

du -sh cacti/log
2.1G    log

8、就是他了，清理后登录正常。

echo > cacti.log

9、最后总结就是万变不离其中，一开始就想到了，只是排查的过程有点曲折，但是能解决问题就是王道。

Start discussion »

周三
18
八 '10

Linux下php的mssql扩展安装

Part of 周 锋's adventure in 01-web服务器

1、下载源码FreeTDS

wget ftp://ftp.ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz

2、安装FreeTDS

tar -zxvf freetds-stable.tgz
cd freetds-0.82
 ./configure --prefix=/usr/local/webserver/freetds-0.82 --with-tdsver=8.0 --enable-msdblib
make
make install
vi /usr/local/webserver/freetds/etc/freetds.conf

输入以下内容(经过测试本步骤可以忽略)：

[global]
        # TDS protocol version
;       tds version = 4.2
 
        # Whether to write a TDSDUMP file for diagnostic purposes
        # (setting this to /tmp is insecure on a multi-user system)
;       dump file = /tmp/freetds.log
;       debug flags = 0xffff
 
        # Command and connection timeouts
;       timeout = 10
;       connect timeout = 10
 
        # If you get out-of-memory errors, it may mean that your client
        # is trying to allocate a huge buffer for a TEXT field.
        # Try setting 'text size' to a more reasonable limit
        text size = 64512
 
        host = mssql.yourdomain.com
        port = 1433
        tds version = 8.0
        client charset = UTF-8

Continue reading "Linux下php的mssql扩展安装" »

Start discussion »

周二
17
八 '10

Linux下redis安装部署

Part of 周 锋's adventure in 03-Cache与存储

1、下载源代码

http://code.google.com/p/redis/downloads/list

下载redis-1.2.6.tar.gz 将下载包拷贝到/usr/local/webserver/redis-1.2.6/下

2、安装

tar -zxvf redis-1.2.6.tar.gz
ce redis-1.2.6
make

3、调整内存
如果内存情况比较紧张的话，需要设定内核参数：

echo 1 > /proc/sys/vm/overcommit_memory

这里说一下这个配置的含义：

/proc/sys/vm/overcommit_memory
该文件指定了内核针对内存分配的策略，其值可以是0、1、2。
0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2，表示内核允许分配超过所有物理内存和交换空间总和的内存
Continue reading "Linux下redis安装部署" »

Start discussion »

周四
8
七 '10

用Xmanager远程连接RedHat5桌面

Part of 周 锋's adventure in 07-运维与监控 | Tags:

环境要求
1.客户端利用xmanager3.0连接服务器可以看到和本机登录一样的图形界面
2.允许root远程连接登录
3.注意重要一点，REDHAT需要反向访问PC机器的6000-6010端口，请确认这点。

相关配置文件介绍
1./usr/share/gdm/defaults.conf—- GNOME管理默认的配置文件
2./etc/inittab—init进程的主配置文件
3./etc/gdm/custom.conf—GNOME的自定义配置文件

服务器配置
1.改变defaults.conf文件权限,默认是只读

chmod 700 /usr/share/gdm/defaults.conf

2.做如下配置—编辑/usr/share/gdm/defaults.conf

Enable=true
DisplaysPerHost=10
Port=177
AllowRoot=true
AllowRemoteroot=true
AllowRemoteAutoLogin=false

3.做如下配置—编辑 /etc/gdm/custom.conf

[xdmcp]
Enable=1

4.做如下配置—编辑 /etc/inittab(不要修改原来设置,在最后新增一行如下记录)
x:5:respawn:/usr/sbin/gdm #此设置经过试验可以不加
5.重新加载GNOME桌面配置

init 3;init 5

总结：还是记录下吧，经过实测是没有问题的，为了以前的记忆差点把GOOGLE给搜烂了。

Start discussion »

周三
30
六 '10

深入探讨Varnish缓存命中率

Part of 周 锋's adventure in 03-Cache与存储

也许你还在为刚才动态内容获得7336.76 reqs/s的吞吐率感到振奋，等等，理想和现实是有差距的，你要忍受现实的残酷，别忘了，我们压力测试中的动态内容都处于全缓存情况下，也就是每次请求都命中缓存，这在现实中往往是不可能的。
首先，缓存区空间大小是有限的，而我们的站点可能有大量的内容需要被缓存，而不像前边压力测试时只有一个内容。一旦缓存区被装满，那么缓存管理器便会淘汰一些它认为不再需要的缓存内容，比如通过LRU（最近最少使用算法）将使用频率较低的缓存内容淘汰出去，但是，这里判断“不常使用”的标准是不严格的，也许被淘汰的内容就是你将要访问的下一个内容，这便影响了它的命中率。
其次，缓存的过期时间也影响到它的命中率，假如有效期很短，为10秒，那么最少10秒便会有一次无法命中。
还有，有些内容可能根本没有被代理服务器缓存，比如这些内容包含了set-cookie等不可缓存的HTTP头信息，导致反向代理不会缓存它们，并且在浏览器请求它们的时候也不会去缓存区查找。这是影响命中率的一个重要因素，但往往被我们所忽略。
幸运的是，这些问题我们都可以轻松的解决，前提是，我们需要了解反向代理缓存的实时工作状态，比如Varnish便提供了一个命令行的状态监控程序varnishstat，我们打开它，便看到了当前时刻的状态，如下：

client_conn           9908723        94.05 Client connections accepted
client_drop                 0         0.00 Connection dropped, no sess/wrk
client_req           16433490       155.99 Client requests received
cache_hit             8751732        83.07 Cache hits
cache_hitpass           42592         0.40 Cache hits for pass
cache_miss            7573389        71.89 Cache misses
backend_conn          3889845        36.92 Backend conn. success
backend_unhealthy          220         0.00 Backend conn. not attempted
backend_busy                0         0.00 Backend conn. too many
backend_fail             4536         0.04 Backend conn. failures
backend_reuse         3780212        35.88 Backend conn. reuses
backend_toolate       3866687        36.70 Backend conn. was closed
backend_recycle       7646677        72.58 Backend conn. recycles
backend_unused              0         0.00 Backend conn. unused
fetch_head                 57         0.00 Fetch head
fetch_length           155097         1.47 Fetch with Length
fetch_chunked         7508522        71.27 Fetch chunked
fetch_eof                   0         0.00 Fetch EOF
fetch_bad                   0         0.00 Fetch had bad headers
fetch_close              3982         0.04 Fetch wanted close
fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
fetch_zero                  0         0.00 Fetch zero len
fetch_failed                0         0.00 Fetch failed
n_sess_mem               1033          .   N struct sess_mem
n_sess                    633          .   N struct sess
n_object              1016443          .   N struct object
n_vampireobject             0          .   N unresurrected objects
n_objectcore          1017564          .   N struct objectcore
n_objecthead           982903          .   N struct objecthead
n_smf                 2647421          .   N struct smf
n_smf_frag             622470          .   N small free smf
n_smf_large                 3          .   N large free smf
n_vbe_conn                 12          .   N struct vbe_conn
n_wrk                    8000          .   N worker threads
n_wrk_create             8000         0.08 N worker threads created
n_wrk_failed                0         0.00 N worker threads not created
n_wrk_max               11021         0.10 N worker threads limited
n_wrk_queue                 0         0.00 N queued work requests
n_wrk_overflow           2441         0.02 N overflowed work requests
n_wrk_drop                  0         0.00 N dropped work requests
n_backend                   4          .   N backends
n_expired             6344546          .   N expired objects
n_lru_nuked            183957          .   N LRU nuked objects
n_lru_saved                 0          .   N LRU saved objects
n_lru_moved           3692170          .   N LRU moved objects
n_deathrow                  0          .   N objects on deathrow
losthdr                    84         0.00 HTTP header overflows
n_objsendfile               0         0.00 Objects sent with sendfile
n_objwrite           15466812       146.81 Objects sent with write
n_objoverflow               0         0.00 Objects overflowing workspace
s_sess                9906155        94.03 Total Sessions
s_req                16433490       155.99 Total Requests
s_pipe                     37         0.00 Total pipe
s_pass                 108252         1.03 Total pass
s_fetch               7667658        72.78 Total fetch
s_hdrbytes         7187255662     68221.35 Total header bytes
s_bodybytes      111592032839   1059230.32 Total body bytes
sess_closed           1905544        18.09 Session Closed
sess_pipeline               0         0.00 Session Pipeline
sess_readahead              0         0.00 Session Read Ahead
sess_linger          15277717       145.02 Session Linger
sess_herd            13547370       128.59 Session herd
shm_records        1028855796      9765.89 SHM records
shm_writes           77957008       739.97 SHM writes
shm_flushes            131005         1.24 SHM flushes due to overflow
shm_cont               144281         1.37 SHM MTX contention
shm_cycles                427         0.00 SHM cycles through buffer
sm_nreq              15306717       145.29 allocator requests
sm_nobj               2024948          .   outstanding allocations
sm_balloc         13595295744          .   bytes allocated
sm_bfree          40091795456          .   bytes free
sma_nreq                    0         0.00 SMA allocator requests
sma_nobj                    0          .   SMA outstanding allocations
sma_nbytes                  0          .   SMA outstanding bytes
sma_balloc                  0          .   SMA bytes allocated
sma_bfree                   0          .   SMA bytes free
sms_nreq                14062         0.13 SMS allocator requests
sms_nobj                    0          .   SMS outstanding allocations
sms_nbytes                487          .   SMS outstanding bytes
sms_balloc            6844837          .   SMS bytes allocated
sms_bfree             6846298          .   SMS bytes freed
backend_req           7668789        72.79 Backend requests made
n_vcl                       1         0.00 N vcl total
n_vcl_avail                 1         0.00 N vcl available
n_vcl_discard               0         0.00 N vcl discarded
n_purge                740577          .   N total active purges
n_purge_add            905392         8.59 N new purges added
n_purge_retire         164815         1.56 N old purges deleted
n_purge_obj_test     13397373       127.17 N objects tested
n_purge_re_test  131875330367   1251759.15 N regexps tested against
n_purge_dups           240655         2.28 N duplicate purges removed
hcb_nolock                  0         0.00 HCB Lookups without lock
hcb_lock                    0         0.00 HCB Lookups with lock
hcb_insert                  0         0.00 HCB Inserts
esi_parse                   0         0.00 Objects ESI parsed (unlock)
esi_errors                  0         0.00 ESI parse errors (unlock)
accept_fail              2553         0.02 Accept failures
client_drop_late            0         0.00 Connection dropped late
uptime                 105352         1.00 Client uptime

Continue reading "深入探讨Varnish缓存命中率" »

Start discussion »

« Earlier Entries
下一页 »