抓哪个进程干坏事前要先停掉syslog
service syslog stop

打开block dump:
echo 1 > /proc/sys/vm/block_dump

统计:
dmesg | egrep "READ|WRITE|dirtied" | egrep -o '([a-zA-Z]*)' | sort | uniq -c | sort -rn | head
1423 kjournald
1075 pdflush
209 indexer
3 cronolog
1 rnald
1 mysqld

不要忘记在抓完之 后关掉block_dump和启动syslog:
echo 0 > /proc/sys/vm/block_dump
service syslog start


加个有人写了一个perl脚本来处理输出,能得到更直观的结果:

参考:http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

wget http://aspersa.googlecode.com/svn/trunk/iodump

echo 1 > /proc/sys/vm/block_dump

while true; do sleep 1; dmesg -c; done | perl iodump

root@kanga:~# while true; do sleep 1; dmesg -c; done | perl iodump
^C# Caught SIGINT.
TASK PID TOTAL READ WRITE DIRTY DEVICES
firefox 4450 4538 251 4287 0 sda4, sda3
kjournald 2100 551 0 551 0 sda4
firefox 28452 185 185 0 0 sda4
kjournald 782 59 0 59 0 sda3
pdflush 31 30 0 30 0 sda4, sda3
syslogd 2485 2 0 2 0 sda3
firefox 28414 2 2 0 0 sda4, sda3
firefox 28413 1 1 0 0 sda4
firefox 28410 1 1 0 0 sda4
firefox 28307 1 1 0 0 sda4
firefox 28451 1 1 0 0 sda4
posted @ 2012-07-18 10:17 小马歌 阅读(728) | 评论 (0)编辑 收藏
 

下面性能测试对比来自LevelDB官方,由 NoSQLFan 进行翻译整理。从结果上看,这不像某些田忌赛马式的性能对比,总体来说还是比较客观全面。通过多种场景下的不同性能测试结果的对比,我们也能对这三个数据库分别擅长和适用的场合有所了解。同时对其性能调优的方法理解也有一定的帮助。

原文链接:leveldb.googlecode.com

下面是对LevelDB、TreeDBSQLite3 这几个数据库的性能对比测试,分别使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3) 及 Kyoto Cabinet’s (version 1.2.67)这三个版本的数据库。

测试机器配置:six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288 KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz

文件系统:测试脚本分别跑在两台机器上,其文件系统一台为ext3(磁盘为 SATA Hitachi HDS721050CLA362),一台为ext4(配备磁盘 SATA Samsung HD502HJ)

性能测试源码:

基本测试

基本测试的条件如下:

  • 每个数据库使用4GB内存
  • 数据库都处于异步写模式(LevelDB’s sync option, TreeDB’s OAUTOSYNC option, SQLite3’s synchronous options 都关闭),也就是说写操作不用等数据真正写到磁盘上才返回。
  • Key 的长度为16字节
  • Value 的长度为100字节 (这个长度才能让数据库的压缩算法能够起作用,将数据压缩至50%大小左右)
  • 顺序读写时Key值递增变化
  • 随机读时生成随机的Key值

测试结果:



结果显示,在顺序读写和随机写上,LevelDB 在性能上都遥遥领先,在随机读上面 Kyoto Cabinet 引擎稍快一些。

在几种不同策略下进行写操作测试

A. Values 为长数据(数据长度为100,000字节)

LevelDB在Value较长时性能比较低,这是由于LevelDB对每一次写操作都会至少进行两次写动作,一次是写数据文件,另一次是写日志文件。这里慢的主要原因是LevelDB在进行这些操作时对值进行了过多的Copy。

B. 批量写操作

一次写操作写1000条100字节的数据,由于TreeDB不支持批量写入,故未对其进行对比测试

上面结果是由于LevelDB数据的组织方式,导致顺序写和随机写在性能上都变化不大。

C. 同步进行写操作

  • 对 LevelDB, 设置 WriteOptions.sync = true.
  • 对 TreeDB, 将 TreeDB’s OAUTOSYNC 选项开启.
  • 对 SQLite3, 设置 “PRAGMA synchronous = FULL”.

如果你看一下ext4文件系统下的测试数据,你会发现ext3和ext4在表现上非常不同。

D. 无压缩的写操作

LevelDB 和 TreeDB 都支持相应的数据压缩算法(LevelDB 使用的是 Snappy , TreeDB 使用的是 LZO),由于SQLite不支持压缩,所以这里的测试数据只是从上面的基本测试结果copy过来的。

LevelDB开启压缩比不开启压缩效率更高,而TreeDB则相反,这可能是由于TreeDB采用的压缩算法(LZO)与LevelDB采用的压缩算法(Snappy)相比计算代价更高。

E. 使用更大内存

将每个独立库的内存增大到128MB,对LevelDB来说,其中120MB用来做 write buffer,另外8MB用来做 cache(原来是2MB的 write buffer 和2MB的cache),对SQLite来说,我们不改变其page size,还是保持为1kb,但是我们增大其page数量从4k增加到128k,对TreeDB来说,我们同样不改变其page大小,也只是增大其cache,从4MB增大到128MB。

SQLite 在采用了大内存后性能变化并不大,而 LevelDB 和 TreeDB 的随机写性能却有显著提高。LevelDB 在增大内存后性能提升的原因是其write buffer 更大,从而减少了创建的sorted file的次数。减少了磁盘IO。而 TreeDB 的性能提升原因是由于其数据库的更大部分被映射到内存中了。

在几种不同策略下进行读操作测试

A. 大的Cache空间

我们分配128MB给每个数据库,对LevelDB来说,我们分配8MB给 write buffer,120MB给cache,对另外两个数据库,由于它们不支持区分 write buffer 和cache,所以统一将 cache size设置成128MB。

从结果可以看到,增大Cache在数据库读性能上都有所提升,其中最为显著的是TreeDB,其随机读性能大幅提升。主要是由于有足够的内存使得其所有读操作都几乎是在内存中进行。

B. 无压缩的读操作

下面结果是我们对预先无压缩状态写入的100万条key为16字节、value为100字节的数据后进行的读性能测试。同样的 SQLite 由于不支持压缩,所以下面数据是直接从其基本测试上copy过来的。

结果可以看到,取消压缩对读取性能提升不是特别大,当然,如果你的数据都在内存中的话,执行解压操作也不会对性能造成太大影响。

posted @ 2012-07-18 10:16 小马歌 阅读(680) | 评论 (0)编辑 收藏
 
dstat 是一个用来替换 vmstat, iostat, netstat, nfsstat 和 ifstat 这些命令的工具,是一个全能系统信息统计工具。

1) 安装:

yum install http://dag.wieers.com/rpm/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
yum install dstat

2) 使用:

[root@ha1 logs]# dstat
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
1   2  95   0   0   1|  26k   84k|   0     0 |   0     3B|9686  8092 
0  13  87   0   0   0|   0  1728k| 409k 2798k|   0     0 |3870  1152 
0  13  87   0   0   0|   0     0 | 473k 3198k|   0     0 |4225  1181 
0  13  87   0   0   0|   0     0 | 454k 3507k|   0     0 |4244  1403 
0  13  87   0   0   0|   0     0 | 440k 3055k|   0     0 |4071  1203 
0  13  87   0   0   0|   0     0 | 580k 2986k|   0     0 |3600  1154 
0  13  86   1   0   0|   0   200k| 430k 2388k|   0     0 |3727  1220 
0  13  87   0   0   0|   0     0 | 421k 2184k|   0     0 |3662  1305 
0  13  87   0   0   0|   0     0 | 643k 2216k|   0     0 |3536  1180 
0  13  87   0   0   0|   0     0 | 414k 2233k|   0     0 |3414  1129 
0  13  87   0   0   0|   0     0 | 547k 1978k|   0     0 |3802  1326 
0  13  86   1   0   0|   0   372k| 455k 2679k|   0     0 |3971  1351 
0  13  87   0   0   0|   0     0 | 397k 1918k|   0     0 |3763  1348 

[root@ha1 logs]# dstat -c --top-cpu -d --top-bio --top-latency
----total-cpu-usage---- -most-expensive- -dsk/total- ----most-expensive---- --highest-total--
usr sys idl wai hiq siq|  cpu process   | read  writ|  block i/o process   | latency process 
1   2  95   0   0   1|kipmi0       1.4|  26k   84k|init [3]     11k   38k|pdflush       227
0  13  86   0   0   0|kipmi0        13|   0   328k|kjournald     0   152k|nginx: worker   1
0  13  87   0   0   0|kipmi0        13|   0     0 |nagios        0    20k|                 
0  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0  8192B|ksoftirqd/6     3
1  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    16k|ksoftirqd/3     4
1  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    12k|ksoftirqd/0     3
1  13  86   1   0   0|kipmi0        13|   0   204k|nginx: work   0  8192B|ksoftirqd/7     5
1  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    12k|ksoftirqd/2     3
1  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    16k|ksoftirqd/5     3
0  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    12k|ksoftirqd/1     4
1  13  87   0   0   0|kipmi0        13|   0     0 |nginx: work   0    12k|ksoftirqd/4     5


dstat可以在linux下比较清析的显示CPU,内存,网络,磁盘等的统计信息。非常好用。

3) 更多信息

http://dag.wieers.com/home-made/dstat/
posted @ 2012-07-18 10:16 小马歌 阅读(216) | 评论 (0)编辑 收藏
 

现在apache用得越来越少了,大家都改用nginx。但有些东西还是比较依赖apache,如nagios。

想让nagios在nginx上运行,必需先让nginx支持perl和cgi解析的功能,需要用到fcgi-perl,安装方式参见我的上一篇blog:

在nginx上配置使用bugzilla

在这里就不多说了。

现在帖上perl的fast-cgi起来后,nginx的配置:

   server {
        listen       80;
        server_name  monitor.xxxx.com;

        root   /data1/www/monitor.xxxx.com;
        index  index.php index.html index.htm;

        access_log /data1/app/log/nginx/monitor.xxxx.com.log  combined;
        error_log  /data1/app/log/nginx/error-monitor.xxxx.com.log notice;

        allow 10.0.0.0/8;
        deny all;

        location ~ \.php$ {

            root  /data1/www/monitor.xxxx.com;

            fastcgi_pass   unix:/data1/app/tmp/php-cgi.sock;
            fastcgi_index  index.php;
            include        fastcgi.conf;
        }

        location /nagios/ {

            alias /usr/share/nagios/;
            index index.html index.htm index.php;

            auth_basic "Nagios Access";
            auth_basic_user_file htpasswd.users;

            location ~ \.php$ {
                root /usr/share;
                fastcgi_pass   unix:/data1/app/tmp/php-cgi.sock;
                fastcgi_index  index.php;
                include        fastcgi.conf;
            }

        }

        location ~ .*\.(pl|cgi)$ {
            rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;

            auth_basic "Nagios Access";
            auth_basic_user_file htpasswd.users;

            gzip off;
            include fastcgi_params;
            fastcgi_pass  127.0.0.1:8999;
            fastcgi_index index.cgi;
            fastcgi_param SCRIPT_FILENAME  /usr/lib64/nagios/cgi$fastcgi_script_name;
            fastcgi_param AUTH_USER $remote_user;
            fastcgi_param REMOTE_USER $remote_user;

        }


   }

 

然后重新生成认证文件htpasswd.users放在nginx的conf目录。重启nginx服务便可。

生成认证文件使用:

htpasswd -c htpasswd.users nagiosadmin

特别注意下面两个参数,一定要加上:

            fastcgi_param AUTH_USER $remote_user;
            fastcgi_param REMOTE_USER $remote_user;

否则进入nagios会提示没有认证。

posted @ 2012-07-17 17:47 小马歌 阅读(799) | 评论 (0)编辑 收藏
 

基于列存储的数据库的优点¶
a)对于聚集操作,比如求sum,明显基于列存储的要比基于行存储的快;
b)对于update操作,不须接触其他列值;
c)基于行存储的数据库在查询每行记录的多个列值更高效的条件是,row-size比较小,这样一次磁盘读取就可以获取整行;
d)基于行存储的数据库在insert一行的时候相对更高效,毕竟可一次写入一个连续空间,即一次single disk seek;

 

从实际情况上来看,基于行存储的数据库更适合OLTP(联机事务处理系统),基于列存储的数据库更适合OLAP(联机分析处理系统),比如数据仓库。除此之外,同一列必定是同一类型大小,基于列存储的数据库更容易使用高效的存储方式,与之相对,基于行存储的数据库则只能采用随机方式处理列值了。


Vertica 数据库的设计特点¶
a)它是基于列的存储结构,提高了连续的record处理的性能,但是在一般事务中增加了对单独record进行update和delete的开销;
b)“单独”更新(out-of-place updates)和混合存储结构,提高了查询、插入的性能,但增加了update和delete的开销;
c)压缩,减少存储开销和IO带宽开销;
d)完全无共享架构,降低对共享资源的系统竞争;

Vertica数据库运行在基于Linux的网格服务器上,目前应用于Amazon Elastic Compute Cloud的数据库管理系统。

 

The Vertica Analytic Databas¶
a)重申三大特点:压缩、基于列、表分解;
b)混合数据存储模式,当insert时候,按照写优先分配原则,实现insert与query的高并发操作;
c)自动化数据库结构设计工具,多节点集群系统,所有的数据都会保存在不止一个节点上,即所谓的k-safety,这样可防止单点故障造成的损失;
d)高性能,支持ACID,轻量级事务和并发控制更加适合load和query操作。Vertica的故障恢复模型是基于多节点拷贝,而不是传统的基于日志;
e)灵活部署;
f)监视和管理工具和API;

对于一个node上的vertica数据库,数据存储分为两个部分,一个是读优存储(read-optimized store,ROS),另一个是写优存储(write-optimized store,WOS),每次更新和插入的数据临时放在WOS部分,SQL查询会访问ROS部分,并且ROS存放已经经过压缩和排序的数据,这样就做到了读写并发两不误,通过tuple mover进程定期将WOS的数据压缩排序后拷贝到ROS区域。

对于多个node,一个表的schema首先会按列拆分为多个映射,将每个列排序保存在不同磁盘上。

Vertica数据库设计本身就适合基于列的查询,虽然一些基于行的数据库经过预处理和内部关系视图等操作也可以优化常见查询的速度,但仍和vertica能应付更多不同查询的高性能无法相比,尤其是vertica的的列主动压缩(aggressive compression)。主动压缩,简单的说就是将一个列不同的值的一维存储转换为二维元组(tuple),格式为<个数,列值>,这样的话,即使是date类型的百万条数据,一年最多也只有365个数对,好处不言而喻,节省空间、提高查询速度、方便聚集函数操作。另外,对应浮点数和时间这样的连续数值,也采用了某些处理方式实现了一些排序和压缩(具体没看懂)。

在读优存储(ROS)区域,除了排序压缩外,还有些别的优化处理。比如数据是致密填充(dense packed)的,即占用的磁盘分页内没有空闲,不用考虑后来insert的数据放哪的问题,因为那是tuple mover做的事情。另一个优化是,vertica会提前取出一大块数据用以减少多次磁盘扫描。 Vertica对于各节点上冗余存储的列数据可采用不同排序顺序存储,这样不但利用多拷贝实现了故障恢复,还利用多种排序顺序提高了查询速度,对于每一个给定的sql操作,vertica都会选择一个最合适的排序顺序。

DB designer 根据数据样本和查询样本将逻辑schema映射为多个物理schema,说白了就是将一个行映射拆分为多个行映射,同时保证每个查询的from部分都只来自一个映射。 k-safety,简单的说就是,对于数据库中的每一列,都会在k+1个节点上存储,这样即使k个节点坏掉了也没事。

Vertica开发,支持标准SQL语句,支持JDBC和ODBC,支持perl和python编程,支持PostgreSQL等数据库的应用代码向其平滑移植。但是vertica对于update这样的操作实在是笨拙。

posted @ 2012-07-17 17:46 小马歌 阅读(2496) | 评论 (0)编辑 收藏
 

在access.log中有大量400错误,并以每天几百M的速度增加,占用大量空间.
tail -f /opt/nginx/logs/access.log

    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    119.97.196.7 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    119.97.196.7 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    219.243.95.197 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:16 +0800] "-" 400 0 "-" "-"

网上大把的文章说是HTTP头/Cookie过大引起的,可以修改nginx.conf中两参数来修正.

    client_header_buffer_size 16k;
          large_client_header_buffers 4 32k;

修改后

    client_header_buffer_size 64k;
         large_client_header_buffers 4 64k;

没有效果,就算我把nginx0.7.62升到最新的0.8.54也没能解决.
在官方论坛中nginx作者提到空主机头不会返回自定义的状态码,是返回400错误.
http://forum.nginx.org/read.php?2,9695,11560

最后修正如下
改为原先的值

    client_header_buffer_size 16k;
         large_client_header_buffers 4 32k;

关闭默认主机的日志记录就可以解决问题

    server {
    listen *:80 default;
    server_name _;
    return 444;
    access_log   off;
         }

 

 

本文来自:http://blog.c1gstudio.com/archives/1153

posted @ 2012-07-17 17:45 小马歌 阅读(1613) | 评论 (0)编辑 收藏
 

from:http://www.linuxidc.com/Apache/index.htm 

BIND(Berkeley Internet Name Daemon) 
伯克利Internet域名服务 
官方站点:https://www.isc.org/ 
相关软件包 
bind-9.3.3-7.el5.i386.rpm


bind-utils-9.3.3-7.el5.i386.rpm 
bind-utils,提供了对DNS服务器的测试工具程序(如nslookup、dig等) 
bind-chroot-9.3.3-7.el5.i386.rpm 
bind-chroot,为bind提供一个伪装的根目录以增强安全性(将“/var/named/chroot/”文件夹作为BIND的根目录) 
caching-nameserver-9.3.3-7.el5.i386.rpm,为配置BIND作为缓存域名服务器提供必要的默认配置文件

BIND服务器端程序 
主要执行程序:/usr/sbin/named 
服务脚本:/etc/init.d/named 
默认监听端口:UDP和TCP的53 
主配置文件: /etc/named.conf 
保存DNS解析记录的数据文件位于:/var/named/ 
 

实验环境

两台虚拟机分别装好bind,主DNS服务器为ns1,IP192.168.0.100;从DNS服务器为ns2,IP192.168.0.200。为linuxidc.com搭建主DNS服务器和从DNS服务器。

配置主服务器
主配置文件/etc/named.conf 

 

  1. options {   
  2. directory "/var/named";   
  3. version "None of your business.";   
  4. };//这部分是全局选项   
  5. zone "." IN {   
  6. type hint;   
  7. file "named.ca";   
  8. };//根服务器   
  9. zone "localhost" IN {   
  10. type master;   
  11. file "local.zone";   
  12. };//本地正向解析   
  13. zone "9.16.172.in-addr.arpa" IN {   
  14. type master;   
  15. file "named.local";   
  16. }; //本地逆向解析   
  17. zone "linuxidc.com" IN {   
  18. type master;//区域类别,hint表示根区域、master表示主区域、slave表示辅助区域    forward 转发区域   
  19. file "linuxidc.com.zone";//区域文件存放的位置,这里用的是相对路径,存放在/var/named目录下   
  20. };//这部分就是我们要的  

linuxidc.com.zone文件的配置

 

  1. $TTL    86400   
  2. @               IN SOA  ns1.linuxidc.com. admin.linuxidc.com. ( //SOA(Start Of Authority,起始授权记录)记录    用于表示一个区域的主域名服务器是谁   
  3.                                         1234567890//serial 更新序列号用于标记地址数据库的变化,可以是10位以内的整数   
  4.                                         3H//从服务器刷新时间从域名服务器更新该地址数据库文件的间隔时间   
  5.                                         15M//重试延时,从域名服务器更新地址数据库失败以后,等待多长时间再次尝试   
  6.                                         1W//失效时间超过该时间仍无法更新地址数据库,则不再尝试   
  7.                                         1D )//缓存时间设置无效地址解析记录(该数据库中不存在的地址)的默认缓存时间   
  8.                 IN NS           ns1.linuxidc.com.   
  9.                 IN NS           ns2.linuxidc.com.   
  10.                 IN MX   10      mail.linuxidc.com.   
  11. ns1             IN A            172.168.9.222   
  12. ns2             IN A            172.168.9.111   
  13. www             IN A            172.16.9.1   
  14. ns              IN A            172.16.9.222   
  15. ns2             IN A            172.16.9.111   
  16. ftp             IN A            172.16.9.123   
  17. mail            IN A            172.16.9.1   
  18. www2            IN CNAME        www.linuxidc.com.  
  19.  
  20. //   
  21. SOA记录                起始授权记录   
  22. NS记录                声明本机的域名服务器   
  23. A记录                主机名转换成IP地址   
  24. PTR                    IP地址转换成主机名   
  25. MX记录                标识邮件服务器   
  26. CNAME                别名   
  27. NS记录和MX记录还需要在后面为其添加对应的A记录  
  28.  

OK,主DNS服务器就配置好了chkconfig检查下时候开机启动,到次主DNS服务器简单的配置完成

 

配置从DNS服务器,从DNS服务器只需要配置主配置文件就可以,区域文件会从主服务器同步过来

  1. options {   
  2. directory "/var/named";   
  3. version "None of your business.";   
  4. };//这部分是全局选项   
  5. zone "." IN {   
  6. type hint;   
  7. file "named.ca";   
  8. };//根服务器   
  9. zone "localhost" IN {   
  10. type master;   
  11. file "named.zone";   
  12. };//本地正向解析   
  13. zone "9.16.172.in-addr.arpa" IN {   
  14. type master;   
  15. file "named.local";   
  16. }; //本地逆向解析   
  17. zone "linuxidc.com" IN {   
  18. type slave;//区域类别,hint表示根区域、master表示主区域、slave表示辅助区域 forward 转发区域   
  19. file "slaves/linuxidc.com.zone";//区域文件存放的位置,这里因为权限的原因我们放在/var/named/slaves目录下   
  20. masters { 172.16.9.222; };//主DNS服务器的地址   
  21. };  
  22.  
caching-nameserver-9.3.3-7.el5.i386.rpm 提供了配置文件的参考和一些默认的区域文件

主从DNS服务器就简单的配置完成了

posted @ 2012-07-13 18:48 小马歌 阅读(1481) | 评论 (0)编辑 收藏
 

我们的各级干部要真正领悟了妥协的艺术,学会了宽容,保持开放的心态,就会真正达到灰度的境界,就能够在正确的道路上走得更远,走得更扎实。
文/任正非,华为技术有限公司总裁
华为的核心价值观中,很重要的一条是开放与进取,这条内容在行政管理团队的讨论中,有较长时间的争议。华为是一个有较强创新能力的公司,开放难道有这么重要吗?由于成功,我们现在越来越自信、自豪和自满,其实也在越来越自闭。
我们强调开放,更多一些向别人学习,我们才会有更新的目标,才会有真正的自我审视,才会有时代的紧迫感。
清晰的方向来自灰度
一个领导人重要的素质是方向、节奏。他的水平就是合适的灰度。坚定不移的正确方向来自灰度、妥协与宽容。
一个清晰方向,是在混沌中产生的,是从灰色中脱颖而出,方向是随时间与空间而变的,它常常又会变得不清晰。并不是非白即黑、非此即彼。合理地掌握合适的灰度,是使各种影响发展的要素,在一段时间和谐,这种和谐的过程叫妥协,这种和谐的结果叫灰度。
妥协一词似乎人人都懂,用不着深究,其实不然。妥协的内涵和底蕴比它的字面含义丰富得多,而懂得它与实践更是完全不同的两回事。我们华为的干部,大多比较年轻,血气方刚,干劲冲天,不大懂得必要的妥协,也会产生较大的阻力。
我们纵观中国历史上的变法,虽然对中国社会进步产生了不灭的影响,但大多没有达到变革者的理想。我认为,面对它们所处的时代环境,他们的变革太激进、太僵化,冲破阻力的方法太苛刻。如果他们用较长时间来实践,而不是太急迫、太全面,收效也许会好一些。其实就是缺少灰度。方向是坚定不移的,但并不是一条直线,也许是不断左右摇摆的曲线,在某些时段来说,还会划一个圈,但是我们离得远一些或粗一些来看,它的方向仍是紧紧地指着前方。
我们今天提出了以正现金流、正利润流、正的人力资源效率增长,以及通过分权制衡的方式,将权力通过授权、行权、监管的方式,授给直接作战部队,也是一种变革。在这次变革中,也许与二十年来的决策方向是有矛盾的,也将涉及许多人的机会与前途,我想我们相互之间都要有理解与宽容。
宽容是领导者的成功之道
为什么要对各级主管说宽容?这同领导工作的性质有关。任何工作,无非涉及到两个方面:一是同物打交道,二是同人打交道。
不宽容,不影响同物打交道。一个科学家,性格怪癖,但他的工作只是一个人在实验室里同仪器打交道,那么,不宽容无伤大雅。一个车间里的员工,只是同机器打交道,那么,即使他同所有人都合不来,也不妨碍他施展技艺制造出精美的产品。

但是,任何管理者,都必须同人打交道。有人把管理定义为“通过别人做好工作的技能”。一旦同人打交道,宽容的重要性立即就会显示出来。人与人的差异是客观存在的,所谓宽容,本质就是容忍人与人之间的差异。不同性格、不同特长、不同偏好的人能否凝聚在组织目标和愿景的旗帜下,靠的就是管理者的宽容。
宽容别人,其实就是宽容我们自己。多一点对别人的宽容,其实,我们生命中就多了一点空间。
宽容是一种坚强,而不是软弱。宽容所体现出来的退让是有目的有计划的,主动权掌握在自己的手中。无奈和迫不得已不能算宽容。
只有勇敢的人,才懂得如何宽容,懦夫决不会宽容,这不是他的本性。宽容是一种美德。
只有宽容才会团结大多数人与你一齐认知方向,只有妥协才会使坚定不移的正确方向减少对抗,只有如此才能达到你的正确目的。

没有妥协就没有灰度
坚持正确的方向,与妥协并不矛盾,相反妥协是对坚定不移方向的坚持。
当然,方向是不可以妥协的,原则也是不可妥协的。但是,实现目标过程中的一切都可以妥协,只要它有利于目标的实现,为什么不能妥协一下?当目标方向清楚了,如果此路不通,我们妥协一下,绕个弯,总比原地踏步要好,干嘛要一头撞到南墙上?
在一些人的眼中,妥协似乎是软弱和不坚定的表现,似乎只有毫不妥协,方能显示出英雄本色。但是,这种非此即彼的思维方式,实际上是认定人与人之间的关系是征服与被征服的关系,没有任何妥协的余地。
“妥协”其实是非常务实、通权达变的丛林智慧,凡是人性丛林里的智者,都懂得恰当时机接受别人妥协,或向别人提出妥协,毕竟人要生存,靠的是理性,而不是意气。
“妥协”是双方或多方在某种条件下达成的共识,在解决问题上,它不是最好的办法,但在没有更好的方法出现之前,它却是最好的方法,因为它有不少的好处。
妥协并不意味着放弃原则,一味地让步。明智的妥协是一种适当的交换。为了达到主要的目标,可以在次要的目标上做适当的让步。这种妥协并不是完全放弃原则,而是以退为进,通过适当的交换来确保目标的实现。相反,不明智的妥协,就是缺乏适当的权衡,或是坚持了次要目标而放弃了主要目标,或是妥协的代价过高遭受不必要的损失。
明智的妥协是一种让步的艺术,妥协也是一种美德,而掌握这种高超的艺术,是管理者的必备素质。
只有妥协,才能实现“双赢”和“多赢”,否则必然两败俱伤。因为妥协能够消除冲突,拒绝妥协,必然是对抗的前奏;我们的各级干部真正领悟了妥协的艺术,学会了宽容,保持开放的心态,就会真正达到灰度的境界,就能够在正确的道路上走得更远,走得更扎实。
坚决反对完美主义
什么是职业化?就是在同一时间、同样的条件,做同样的事的成本更低,这就是职业化。市场竞争,对手优化了,你不优化,留给你的就是死亡。思科在创新上的能力,爱立信在内部管理上的水平,我们现在还是远远赶不上的。要缩短这些差距,必须持续地改良我们的管理,不缩短差距,客户就会抛离我们。
的确,我们要有管理改进的迫切性,但也要沉着冷静,减少盲目性。我们不能因短期救急或短期受益,而做长期后悔的事。不能一边救今天的火,一边埋明天的雷。管理改革要继续坚持从实用的目的出发,达到适用目的的原则。
我们从一个小公司脱胎而来,小公司的习气还残留在我们身上。我们的员工也受二十年来公司早期的习惯势力的影响,自己的思维与操作上还不能完全职业化。这些都是我们管理优化的阻力。由于我们从小公司走来,相比业界的西方公司,我们一直处于较低水平,运作与交付上的交叉、不衔接、重复低效、全流程不顺畅现象还较为严重。
在管理改进中,要继续坚持遵循“七反对”的原则。坚决反对完美主义,坚决反对繁琐哲学,坚决反对盲目的创新,坚决反对没有全局效益提升的局部优化,坚决反对没有全局观的干部主导变革,坚决反对没有业务实践经验的人参加变革,坚决反对没有充分论证的流程进行实用。
我们不忌讳我们的病灶,要敢于改革一切不适应及时、准确、优质、低成本实现端到端服务的东西。但更多的是从管理进步中要效益。我们从来就不主张较大幅度的变革,而主张不断的改良,我们现在仍然要耐得住性子,谋定而后动。
因地制宜实事求是
西方的职业化,是从一百多年的市场变革中总结出来的,它这样做最有效率。穿上西装,打上领带,并非是为了好看。我们学习它,并非是完全僵化地照搬,难道穿上中山装就不行?
我们二十年来,有自己成功的东西,我们要善于总结出来,我们为什么成功,以后怎样持续成功,再将这些管理哲学的理念,用西方的方法规范,使之标准化、基线化,有利于广为传播与掌握并善用之,培养各级干部,适应工作。
只有这样我们才不是一个僵化的西方样板,而是一个有活的灵魂的管理有效的企业。看西方在中国的企业成功的不多,就是照搬了西方的管理,而水土不服。一个企业活的灵魂,就是坚持因地制宜实事求是。这两条要领的表现,就是不断提升效率。
我们从杂乱的行政管制中走过来,依靠功能组织进行管理的方法虽然在弱化,但以流程化管理的内涵,还不够丰富。流程的上、下游还没有有效“拉通”,基于流程化工作对象的管理体系还不很完善。组织行为还不能达到可重复、可预期、可持续化的可值得信赖的程度。人们还习惯在看官大官小的指令,来确定搬道岔。以前还出现过可笑的工号文化。

工作组是从行政管制走向流程管制的一种过渡形式,它对打破部门墙有一定好处,但它对破坏流程化建设有更大的坏处。而我们工作组满天飞,流程化组织变成了一个资源池,这样下去我们能建设成现代化管理体系吗?一般而言,工作组人数逐步减少的地方,流程化的建设与运作就比较成熟。
我们要清醒地认识到,面对未来的风险,我们只能用规则的确定来对付结果的不确定。只有这样我们才能随心所欲,不逾矩,才能在发展中获得自由。任何事物都有对立统一的两面,管理上的灰色,是我们生命之树。我们要深刻理解开放、妥协、灰度。
(本文来源:商界评论 ) 

 

posted @ 2012-07-12 09:48 小马歌 阅读(233) | 评论 (0)编辑 收藏
 

存在就是被需要。腾讯产品经理的要求有哪些呢?
以下各项指标均为5分制,括号里的分值是腾讯产品专家P4的基础要求。
【图文版】-点击图片查看大图
腾讯产品经理
【文字版】
一、素质
1、基本素质
学习/提炼能力(5分)
办公技能(5分)
执行力/IQ(5分)
关联专业知识(3分)
沟通能力/Trade off(5分)

二、关键素质
行业融入感/Ownership(5分)
技术理解(4分)
AQ/EQ(心态/胸怀)(4分)

三、能力
1、市场能力
对外商务沟通(BD\P3以上)(2分)

2、产品能力
市场/用户的调研与分析(4分)
行业认知(4分)
专业设计能力(4分)
用户需求理解/80/20/细节(4分)
产品规划(版本计划/节奏)(4分)

3、运营能力
运营数据分析(3分)
营销与推广策略(3分)
危机预测与控制/预见性(2分)
渠道管理(2分)

4、领导能力
项目管理(4分)
带人的能力/知识传递(3分)

扩展性阅读《腾讯产品经理视角》
一、产品
1、从产品的外延来说,
任何东西都可以被看作是产品,它的好坏取决于它被需要的程度,以及它满足外界需要的程度。
众人眼中成功的人必是很好的满足大众需要的人,这和“好坏”无关。
不被需要的东西,渐渐淡出历史而消亡,或者转化为新的被需要的方式。

2、从产品的内涵来说
产品/功能,就是一系列符合用户需求的功能的组合。
运营/营收,是指为了扩大用户群、提高用户活跃度,寻找合适商业模式并增加收入所采取的经营手段。(运营是有成本的,因此它要有极为明确的目标)

3、网站提供服务的模式有
产品贯穿,运营贯穿和相互贯穿。

二、腾讯产品经理定义
产品经理是产品的设计者、建造者、运营者,更是产品的第一个用户,他需要
1、进行市场调研,收集用户需求;
2、确定产品功能,制定产品规划;
3、负责或指导产品运营,并主持版本更新。
附:
运营者必须是一个冷静务实、重实验的科学家,无论何时何地,对运营者而言,总利润比市场份额、效率更为重要。
维持低成本是产品的事情,维持高售价是运营的事情。

4、产品经理的世界观
任何东西,都是产品,它的价值取决于它满足了多少外部的需求。

5、产品Sense,是产品经理的能力/经验的体验,目标是让产品用起来更爽。
提升产品Sense的唯一途径,是从用户(可以初期只是有需求的你和身边的人)的角度而不是从产品内部体系的角度,去确定用户需求,并对需求优先级进行排序。

6、产品经理最需要了解人的需求
吸引力
归属感
自由自在
掌握和驾驭感
乐趣与兴奋
爱和被爱
成为领导者
拥有智慧和知识
表现自我
和谐
尊重
安全
自我放纵
传统
自我感觉良好

7、产品规划流程
是对市场走势及客户需求进行分析,创建合理的市场细分规则,对要投资或取得领先地位的细分市场进行选择和优先排序,从而制定可执行的业务计划,并驱动新产品的开发。
主要过程有
1、用户需求收集 交付件:产品候选概念
2、市场分析 交付件:市场评估报告
3、制定规划 交付件:产品路标规划书
4、撰写策划 交付件:产品需求说明书
5、制定业务计划 交付件:业务计划、进入开发阶段

8、产品功能的优先级
产品本身的需求都是平等的,但产品在不同的阶段有不同的目标和现实情况,这是判定产品功能优先级的唯一标准。而不是满口“这是用户新提的需求,很紧急,这个大合作就差这个功能人家就答应了”

新产品上线
首要目标:吸引新用户,快速占领市场
功能侧重点:好用、方便、运营成本

平台期
首要目标:留住用户,稳定收入
功能侧重点:内容翻新,满足细分用户群体的需求

产品更新换代
首要目标:保留旧产品精髓,融入新的创意元素
功能侧重点:创新

posted @ 2012-07-06 10:19 小马歌 阅读(291) | 评论 (0)编辑 收藏
 

linux下添加,删除,修改,查看用户和用户组

1,创建组

groupadd test

增加一个test

2,修改组

groupmod -n test2 test

test组的名子改成test2

3,删除组

groupdel test2

删除 test2

4,查看组

a),查看当前登录用户所在的组 groups,查看apacheuser所在组groups apac

 一,组操作

1,创建组

 

groupadd test

 

增加一个test

 

2,修改组

 

groupmod -n test2  test

 

test组的名子改成test2

 

3,删除组

 

groupdel test2

 

删除 test2

 

4,查看组

 

a),查看当前登录用户所在的组 groups,查看apacheuser所在组groups apacheuser

 

b),查看所有组 cat /etc/group

 

c),有的linux系统没有/etc/group文件的,这个时候看下面的这个方法

 

cat /etc/passwd |awk -F [:] ‘{print $4}’ |sort|uniq | getent group |awk -F [:] ‘{print $1}’

 

这里用到一个命令是getent,可以通过组ID来查找组信息,如果这个命令没有的话,那就很难查找,系统中所有的组了.

 

二,用户操作

 

1,增加用户

 

查看复制打印?

[root@krlcgcms01 mytest]# useradd –help

Usage: useradd [options] LOGIN

 

Options:

-b, base-dir BASE_DIR       设置基本路径作为用户的登录目录

-c, comment COMMENT         对用户的注释

-d, home-dir HOME_DIR       设置用户的登录目录

-D, defaults                改变设置

-e, expiredate EXPIRE_DATE 设置用户的有效期

-f, inactive INACTIVE       用户过期后,让密码无效

-g, gid GROUP               使用户只属于某个组

-G, groups GROUPS           使用户加入某个组

-h, help                    帮助

-k, skel SKEL_DIR           指定其他的skel目录

-K, key KEY=VALUE           覆盖 /etc/login.defs 配置文件

-m, create-home             自动创建登录目录

-l,                           不把用户加入到lastlog文件中

-M,                           不自动创建登录目录

-r,                           建立系统账号

-o, non-unique              允许用户拥有相同的UID

-p, password PASSWORD       为新用户使用加密密码

-s, shell SHELL             登录时候的shell

-u, uid UID                 为新用户指定一个UID

-Z, –selinux-user SEUSER     use a specific SEUSER for the SELinux user mapping

[root@krlcgcms01 mytest]# useradd --help

Usage: useradd [options] LOGIN

 

Options:

 -b, --base-dir BASE_DIR       设置基本路径作为用户的登录目录

 -c, --comment COMMENT         对用户的注释

 -d, --home-dir HOME_DIR       设置用户的登录目录

 -D, --defaults                改变设置

 -e, --expiredate EXPIRE_DATE 设置用户的有效期

 -f, --inactive INACTIVE       用户过期后,让密码无效

 -g, --gid GROUP               使用户只属于某个组

 -G, --groups GROUPS           使用户加入某个组

 -h, --help                    帮助

 -k, --skel SKEL_DIR           指定其他的skel目录

 -K, --key KEY=VALUE           覆盖 /etc/login.defs 配置文件

 -m, --create-home             自动创建登录目录

 -l,                           不把用户加入到lastlog文件中

 -M,                           不自动创建登录目录

 -r,                           建立系统账号

 -o, --non-unique              允许用户拥有相同的UID

 -p, --password PASSWORD       为新用户使用加密密码

 -s, --shell SHELL             登录时候的shell

 -u, --uid UID                 为新用户指定一个UID

 -Z, --selinux-user SEUSER     use a specific SEUSER for the SELinux user mappinguseradd test

 

passwd test

 

增加用户test,有一点要注意的,useradd增加一个用户后,不要忘了给他设置密码,不然不能登录的。

 

2修改用户

 

usermod -d /home/test -G test2 test

 

test用户的登录目录改成/home/test,并加入test2组,注意这里是大G

 

gpasswd -a test test2 将用户test加入到test2

gpasswd -d test test2 将用户testtest2组中移出

 

3,删除用户

 

userdel test

 

test用户删除

 

4,查看用户

 

a),查看当前登录用户

 

[root@krlcgcms01 ~]# w

[root@krlcgcms01 ~]# who

 

b),查看自己的用户名

 

[root@krlcgcms01 ~]# whoami

 

c),查看单个用户信息

 

[root@krlcgcms01 ~]# finger apacheuser

[root@krlcgcms01 ~]# id apacheuser

 

d),查看用户登录记录

 

[root@krlcgcms01 ~]# last 查看登录成功的用户记录

[root@krlcgcms01 ~]# lastb 查看登录不成功的用户记录

 

e),查看所有用户

 

[root@krlcgcms01 ~]# cut -d : -f 1 /etc/passwd

[root@krlcgcms01 ~]# cat /etc/passwd |awk -F \: ‘{print $1}’

posted @ 2012-07-05 11:12 小马歌 阅读(188) | 评论 (0)编辑 收藏
仅列出标题
共95页: First 上一页 34 35 36 37 38 39 40 41 42 下一页 Last