Category: Linux

对LINUX服务器网卡进行带宽限制的办法：

1、安装iproute
yum -y install iproute

2、限制eth0网卡的带宽为100kbit：
/sbin/tc qdisc add dev eth0 root tbf rate 500kbit latency 50ms burst 15kb

　　3、解除eth0网卡的带宽限制：
/sbin/tc qdisc del dev eth0 root tbf

      4、列出已有的策略：

tc -s qdisc ls dev eth0

　　5、启动时自动加载带宽限制策略：

vim /etc/rc.local

加入： /sbin/tc qdisc add dev eth0 root tbf rate 500kbit latency 50ms burst 15kb

 参考资料：http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/

PS:转载请注明出处，谢谢！

dd命令可以轻易实现创建指定大小的文件，如

dd if=/dev/zero of=test bs=1M count=1000

会生成一个1000M的test文件，文件内容为全0（因从/dev/zero中读取，/dev/zero为0源）

但是这样为实际写入硬盘，文件产生速度取决于硬盘读写速度，如果欲产生超大文件，速度很慢

在某种场景下，我们只想让文件系统认为存在一个超大文件在此，但是并不实际写入硬盘

则可以
dd if=/dev/zero of=test bs=1M count=0 seek=100000

此时创建的文件在文件系统中的显示大小为100000MB，但是并不实际占用block，因此创建速度与内存速度相当

seek的作用是跳过输出文件中指定大小的部分，这就达到了创建大文件，但是并不实际写入的目的

当然，因为不实际写入硬盘，所以你在容量只有10G的硬盘上创建100G的此类文件都是可以的

1.导出整个数据库
　　mysqldump -u 用户名 -p 数据库名 > 导出的文件名

　　mysqldump -u wcnc -p smgp_apps_wcnc > wcnc.sql

2.导出一个表

　　mysqldump -u 用户名 -p 数据库名 表名> 导出的文件名

　　mysqldump -u wcnc -p smgp_apps_wcnc users> wcnc_users.sql

3.导出一个数据库结构

　　mysqldump -u wcnc -p -d –add-drop-table smgp_apps_wcnc >d:wcnc_db.sql

　　-d 没有数据 –add-drop-table 在每个create语句之前增加一个drop table

4.导入数据库

　　常用source 命令

　　进入mysql数据库控制台，

　　如mysql -u root -p

　　mysql>use 数据库

　　然后使用source命令，后面参数为脚本文件(如这里用到的.sql)

　　mysql>source d:wcnc_db.sql （注：如果写成source d:\wcnc_db.sql，就会报语法错误）

vim乱码解决方法：
在根目录下新建一个.vimrc文件，在里面写上
let &termencoding=&encoding
set fileencodings=utf-8,gbk,ucs-bom,cp936

今天一个客户域名PING不通，检查了半天没有发现什么异常，NS设置没有问题，服务器上NS服务也都在跑。

后来才想到下午启用了IPTABLES，该不会是把DNS端口封掉了吧。。

果断进服务器service iptables stop，果然可以访问了。

打开防火墙配置文件：vim /etc/sysconfig/iptables

加两条防火墙规则：

–A RH-Firewall-1-INPUT -p tcp -m tcp –dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m udp –dport 53 -j ACCEPT

保存退出后service iptables restart

再试，就OK了。。

顺便说下，禁止PING加上这句就可以了。

-A RH-Firewall-1-INPUT -p icmp –icmp-type any -j DROP

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。下面详细介绍它的使用方法。
top – 01:06:48 up 1:22, 1 user, load average: 0.06, 0.60, 0.48
Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 191272k total, 173656k used, 17616k free, 22052k buffers
Swap: 192772k total, 0k used, 192772k free, 123988k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1379 root 16 0 7976 2456 1980 S 0.7 1.3 0:11.03 sshd
14704 root 16 0 2128 980 796 R 0.7 0.5 0:02.72 top
1 root 16 0 1992 632 544 S 0.0 0.3 0:00.90 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
统计信息区
前五行是系统整体的统计信息。第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：
01:06:48
当前时间
up 1:22
系统运行时间，格式为时:分
1 user
当前登录用户数
load average: 0.06, 0.60, 0.48
系统负载，即任务队列的平均长度。
三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。
第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：
Tasks: 29 total
进程总数
1 running
正在运行的进程数
28 sleeping
睡眠的进程数
0 stopped
停止的进程数
0 zombie
僵尸进程数
Cpu(s): 0.3% us
用户空间占用CPU百分比
1.0% sy
内核空间占用CPU百分比
0.0% ni
用户进程空间内改变过优先级的进程占用CPU百分比
98.7% id
空闲CPU百分比
0.0% wa
等待输入输出的CPU时间百分比
0.0% hi

0.0% si

最后两行为内存信息。内容如下：
Mem: 191272k total
物理内存总量
173656k used
使用的物理内存总量
17616k free
空闲内存总量
22052k buffers
用作内核缓存的内存量
Swap: 192772k total
交换区总量
0k used
使用的交换区总量
192772k free
空闲交换区总量
123988k cached
缓冲的交换区总量。
内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，
该数值即为这些内容已存在于内存中的交换区的大小。
相应的内存再次被换出时可不必再对交换区写入。
进程信息区
统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。
序号
列名
含义
a
PID
进程id
b
PPID
父进程id
c
RUSER
Real user name
d
UID
进程所有者的用户id
e
USER
进程所有者的用户名
f
GROUP
进程所有者的组名
g
TTY
启动进程的终端名。不是从终端启动的进程则显示为 ?
h
PR
优先级
i
NI
nice值。负值表示高优先级，正值表示低优先级
j
P
最后使用的CPU，仅在多CPU环境下有意义
k
%CPU
上次更新到现在的CPU时间占用百分比
l
TIME
进程使用的CPU时间总计，单位秒
m
TIME+
进程使用的CPU时间总计，单位1/100秒
n
%MEM
进程使用的物理内存百分比
o
VIRT
进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
p
SWAP
进程使用的虚拟内存中，被换出的大小，单位kb。
q
RES
进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
r
CODE
可执行代码占用的物理内存大小，单位kb
s
DATA
可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
t
SHR
共享内存大小，单位kb
u
nFLT
页面错误次数
v
nDRT
最后一次写入到现在，被修改过的页面数。
w
S
进程状态。
D=不可中断的睡眠状态
R=运行
S=睡眠
T=跟踪/停止
Z=僵尸进程
x
COMMAND
命令名/命令行
y
WCHAN
若该进程在睡眠，则显示睡眠中的系统函数名
z
Flags
任务标志，参考 sched.h
默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通过下面的快捷键来更改显示内容。
更改显示内容
通过 f 键可以选择显示的内容。按 f 键之后会显示列的列表，按 a-z 即可显示或隐藏对应的列，最后按回车键确定。
按 o 键可以改变列的显示顺序。按小写的 a-z 可以将相应的列向右移动，而大写的 A-Z 可以将相应的列向左移动。最后按回车键确定。
按大写的 F 或 O 键，然后按 a-z 可以将进程按照相应的列进行排序。而大写的 R 键可以将当前的排序倒转。
命令使用
1． 工具（命令）名称
top
2．工具（命令）作用
显示系统当前的进程和其他状况； top是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户终止该程序为止. 比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定.
3．环境设置
在Linux下使用。
4．使用方法
4．1使用格式
top [-] [d] [p] [q] [c] [C] [S] [s] [n]
4．2参数说明
d 指定每两次屏幕信息刷新之间的时间间隔。当然用户可以使用s交互命令来改变之。
p 通过指定监控进程ID来仅仅监控某个进程的状态。
q该选项将使top没有任何延迟的进行刷新。如果调用程序有超级用户权限，那么top将以尽可能高的优先级运行。
S 指定累计模式
s 使top命令在安全模式中运行。这将去除交互命令所带来的潜在危险。
i 使top不显示任何闲置或者僵死进程。
c 显示整个命令行而不只是显示命令名
4.3其他
　　下面介绍在top命令执行过程中可以使用的一些交互命令。从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。
　　Ctrl+L 擦除并且重写屏幕。
　　h或者? 显示帮助画面，给出一些简短的命令总结说明。
　　k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
　　i 忽略闲置和僵死进程。这是一个开关式命令。
　　q 退出程序。
　　r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
　　S 切换到累计模式。
　　s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
　　f或者F 从当前显示中添加或者删除项目。
　　o或者O 改变显示项目的顺序。
　　l 切换显示平均负载和启动时间信息。
　　m 切换显示内存信息。
　　t 切换显示进程和CPU状态信息。
　　c 切换显示命令名称和完整命令行。
　　M 根据驻留内存大小进行排序。
　　P 根据CPU使用百分比大小进行排序。
　　T 根据时间/累计时间进行排序。
W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。

In one of our previous articles here, we had written about eAccelerator and metioned that it should significantly reduce the server load while increasing its speed from 1 to 10 times. But during the evaluation of eAccelerator under 1000+ http req/sec. conditions, we have noticed that Apache repeatedly launches child processes untill it reaches the MaxClients server limit and causes abnormal load averages to bring multi-core and multi-cpu performance servers on their knees just in seconds. When we debug the issue, we have noticed that all complaints in gdb backtraces were somehow about nothing but Zend.

We know eAccelerator has been reported to work with Zend many times but we realised that they do not actually accord well even when the requests only go over 50 – 60 per second. Just imagine the view when you get thousands of them. Previously in our related article, while discussing the initial configuration of eAccelerator, we’ve told that you might load it either as a Zend extension or alternatively as a PHP extension in your php.ini file. Now we explicitly recommend you not to load it as a Zend extension. Instead, prefer the straight PHP extension way with;
extension=”eaccelerator.so”

Do not install Zend Optimizer with eAccelerator if you don’t use scripts encoded with Zend Encoder. So also disable Zend optimization right behind the eAccelerator configuration lines with;
zend_optimizer.optimization_level=0

and just in case put your whole eAccelerator configuration lines at the top of your php.ini file as Zend Optimizer must be loaded after eAccelerator inside php.ini. Incidentally, for those who run the older version of eaccelerator, it’s vital to upgrade it to the latest one as old versions have a spinlock bug that leads into deadlock under heavy loads. Then, restart the apache and observe the new attitudes. Although you’ll gain some increase in the number of requests that are being responded without a fatal crash, there’re still two important things to take care of: “stat()” system calls and the compression.

stat() is a Unix system call that returns data on the size and the parameters associated with a file. On every single hit eAccelerator will check the modification time of a script to see if it’s changed and needs to be recompiled. Each time, this is done by the stat calls which consume time and add a serious overhead to the system which precludes the response to mass requests. You must skip these expensive calls which are enabled by default;
eaccelerator.check_mtime = “0”

When you disable this check, remember that you have to manually clean the eAccelerator cache when you update a file.

Compression also requires an additional cpu activity. While it’s essential for the complete http part, it’s not meaningful for the codes that are going to be cashed. And if we’re talking about skinning a flint here, then disable this feature also;
eaccelerator.compress = “0”

According to our observations, following all these configuration modifications, now the system can handle 100 http req/sec. effectively reducing the overall load at nearly %80. But if your requests grow, this brilliant savings will probably turn into a crash. In our opinion, eaccelerator is very well suited for the web servers that serve utmost 100 http req/sec. which approximately corresponds to ~1000 concurrent users (depending on the type of your web application), not for more.

Those who will take a chance on xcache as an alternative to eaccelerator won’t gain a victory above 100 requests per second, because most probably your web server will become unresponsive with a lot of processes in lockf state. We’ve also tested xcache under same pressures.

But this is not a case of this-cache or that-cache situation, it clearly seems to be a case of locking mechanism used. My impression is that we need to enable semaphore locks instead of default fcntl under certain loads. As FreeBSD doesn’t support pthread mutex locking, our next resort shall be a marginal one if semaphores don’t really help. That is spinlocks which is still considered experimental within APC (Alternative PHP Cache). Install APC from ports by enabling IPC SHM (shared memory) and spinlocking, try the configuration below and see what happens if locking is an issue for you, too. But before, you need to make sure that your “kern.ipc.shmmax” value has been set large enough in/etc/sysctl.conf to handle the shm_size below.
extension=apc.so
apc.enabled=1
apc.shm_segments=1
apc.shm_size=128
apc.file_update_protection=0
apc.stat=0
apc.ttl=0