邢栋博客

邢栋博客,Action博客,记录工作和生活中的点点滴滴

Linux安装rz/sz命令及简单使用
Linux安装rz/sz命令及简单使用

wget https://ohse.de/uwe/releases/lrzsz-0.12.20.tar.gz
tar -zxvf lrzsz-0.12.20.tar.gz 
cd lrzsz-0.12.20
./configure
make && make install 

安装成功后这个时候 已经可以使用 lrz lsz 命令完成发送文件到本地或者本地文件上传到服务器
默认是把这两个命令安装到 /usr/local/bin/ 目录下的

cd /usr/bin
ln -s /usr/local/bin/lrz rz
ln -s /usr/local/bin/lsz sz

这个时候就可以使用 rz sz 命令了

sz命令发送文件到本地:
#sz filename
    rz命令本地上传文件到服务器:
#rz
    执行该命令后,在弹出框中选择要上传的文件即可。

说明:如果使用的是第三方的连接工具(SecureCRT),可以在第三方软件的设置里,设置上传和下载的目录。

nginx出现413 Request Entity Too Large错误

打开nginx主配置文件nginx.conf,一般在/usr/local/nginx/conf/nginx.conf这个位置,找到http{}段,修改或者添加

client_max_body_size   2m;

即可。




php.ini 配置参数详解及优化
php.ini 配置参数详解及优化

php解释器在php.ini文件中配置和调优。

内存
memory_limit = 128 
用于设定单个php进程可以使用的系统内存的最大值。
默认值是128M,这对大多数中小型php应用来说或许合适。可是如果运行的是微型php应用,可以降低这个值,例如设为64M,节省系统资源。

zend opcahce
确定要分配多少内存后,我们会配置php的zend opcache扩展。这个扩展用于缓存操作码。
每次http请求时,首先nginx把http请求转发给php-fpm,php-fpm再把请求交给某个php子进程处理。php进程找到相应的php脚本后,读取脚本,把php脚本编译成操作码(或字节码)格式,然后执行编译得到的操作码,生成响应。最后,把http响应发给nginx,nginx再把响应发给http客户端。这样的话每次http请求都要消耗很多资源。
我们可以缓存编译每个http脚本得到的操作码,加速这个处理过程。缓存后,我们可以从缓存中直接读取并执行预先编译好的操作码,不用每次处理http请求时都查找、读取和编译php脚本。
优化zend opcahce扩展的设置 
opcache.memory_consumption=64   //php7默认是64
opcache.interned_strings_buffer=16 //php7默认是4
opcache.max_accelerated_files=4000 //php7默认是2000
opcache.validate_timestamps=1 //php7默认是1
opcache.revalidate_freq=0 //php7默认是2
opcache.fast_shutdown=1 //php7默认是0

opcache.memory_consumption=64
为操作码缓存分配的内存量(单位MB)。分配的内存量应该够保存应用中所有php脚本编译得到的操作码。如果是小型的php应用,脚本数较少,可以设为较低的值,例如16M

opcache.interned_strings_buffer=16
用来存储驻留字符串的内存量(单位MB)。
php解释器在背后会找到相同字符串的多个实例,把这个字符串保存在内存中,如果再次使用相同的字符串,php解释器会使用指针,这样能节省内存。默认情况下,php驻留的字符串会隔离在各个php进程中。这个设置能让php-fpm进程池中的所有进程把驻留字符串存储到共享的缓冲区中,以便在php-fpm进程池中的多个进程之间引用驻留字符串。这样能节省内存。这个的默认值是4M,可以设为16M

opcache.max_accelerated_files=4000
操作码缓存中最多能存储多少个php脚本。这个设置的值可以在200-100000之间的任何数。这个值一定要比php应用中的文件数量大。

opcache.validate_timestamps=1
这个值设为1时,经过一段时间后php会检查php脚本的内容是否变化。检查的时间间隔由opcache.revalidate_freq设置指定。如果这个设置的值为0,php不会检查php脚本的内容是否变化,我们必须手动清除缓存的操作码。建议开发环境中设为1,生产环境设为0 


opcache.revalidate_freq=0
这个设置多久(单位是秒)检查一次php脚本的内容是否变化。缓存的好处是不用每次都重新编译php脚本。这个设置用于确定在多长时间内认为操作码是新的。 在这段时间之后,php会检查php脚本的内容是否有变化。如果有变化,php会重新编译脚本,再次缓存。

opcache.fast_shutdown=1
这个设置能让操作码使用更快的停机步骤,把对象析构和内存释放交给zend Enginer的内存管理器去完成。


文件上传

这个应该都懂
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
如果需要上传更大的文件,需要调整nginx配置中的client_max_body_size参数


最长执行时间
这个参数用于设定单个php进程在终止之前最长可以运行多少时间。
max_execution_time = 5  //默认是30
在php脚本中可以调用set_time_limit()函数来覆盖这个值。

如果需要运行更长的时间,则要在单独的进程中运行。
比如要生成报告,把结果制作成pdf文件,这个任务大概需要10分钟完成。我们要单独编译一个php文件,为create.php
<?php
exec('echo "create.php"|at now');
echo 'report pending...';
?>


处理会话
session.save_handle = 'memcached'
session.save_path = '127.0.0.1:11211'

缓存输出
如果在较少的块中发送更多的数据,而不是在较多的块中发送较少的数据,那么网络的效率会更多。也就是说,在较少的片段中把内容传递给访问者的浏览器,能减少http请求总数。
因此,我们要让php缓冲输出。默认情况下,php已经启用了输出缓冲功能。php缓冲4096字节的输出之后才会把其中的内容发送给web服务器。推荐设置
output_buffering = 4096
implicit_flush = false


真实路径缓存
php会缓存应用使用的真是路径,这样每次包含或导入文件时就无需不断搜素包含路径了。这个缓存叫真实缓存路径。如果运行的是大型php文件(Drupal和Composer组件等),使用了大量文件,增加php真实路径缓存的大小就能得到更好的性能。
真实路径缓存的默认大小是16K。这个缓存所需要的准确大小不容易确定,不过可以使用一个小技巧。首先,增加真实路径缓存的大小,设为特别大的值,例如256K。然后在这个php脚本的末尾加上print_r(realpath_cache_size());输出真实路径缓存的真正大小。最后,把真实路径缓存的大小改为这个真正的值。我们可以在php.ini文件中设置真实路径缓存的大小:
realpath_cache_size = 64K

php-fpm.conf 配置参数详解及优化
php-fpm.conf 配置参数详解及优化

emergency_restart_threshold = 10
在指定的一段时间内,如果失效的php-fpm子进程数超过这个值,php-fpm主进程优雅重启
emergency_restart_interval = 1m   
设定emergency_restart_threshold 设置采用的时间跨度,s(econds), m(inutes), h(ours), or d(ays)


user = www
拥有这个php-fpm进程池中子进程的系统用户。要把这个设置的值设为运行php应用的非根用户的用户名。

group = www
拥有这个php-fpm进程池中子进程的系统用户组。要把这个设置的值设为运行php应用的非根用户的所属的用户组名。

listen = 127.0.0.1:9000
php-fpm进程池监听的ip地址和端口号,让php-fpm只接受nginx从这里传入的请求。127.0.0.1:9000让指定的php-fpm进程池监听从本地端口9000进入的连接。
可以使用任何不需要特殊权限(大于1024)且没被其他系统进程占用的端口号。

listen.allowed_clients = 127.0.0.1
可以向这个php-fpm进程池发送请求的ip地址(一个或多个)。为了安全,把这个设置为127.0.0.1,即只有当前设备能把请求转发给这个php-fpm进程池。默认情况下,这个是被注释掉的。


pm.max_children = 51
这个设置设定任何时间点php-fpm进程池中最多能有多少个进程。这个设置没有绝对正确的值,应该测试你的php应用,确定每个php进程需要使用多少个内存,然后把这个设置设为设备可能内存能容纳的php进程总数。对大多数中小型php应用来说,每个php进程要使用5-15M内存,假如我们使用的设备为这个php-fpm进程池分配了512可用的内存,每个进程大约10M,就是51个进程。


pm.start_servers = 3
php-fpm启动时php-fpm进程池中立即可用的进程数。同样的,这个设置也没有绝对的正确值。对大多数中小型php应用来说,设置2或者3。这么做是为了先准备好的三个进程,等待请求进入,不让php应用的头几个http请求等待php-fpm初始化进程中的进程。


pm.min_spare_servers = 2
php应用空闲时php-fpm进程池中可以存在的进程数量最小值。这个设置的值一般与php.start_servers设置的值一样,用于确保新进入的http请求无需等待php-fpm在进程中重新初始化进程。


pm.max_spare_servers = 4
php应用空闲时php-fpm进程池中可以存在的进程数量最大值。这个设置的值一般比php.start_servers设置的值要大些,用于确保新进入的http请求无需等待php-fpm在进程池中重新初始化进程。

pm.max_requests = 1000
回收进程之前,php-fpm进程池中各个进程最多能处理的http请求数量。这个设置有助于避免php扩展或者库因编写拙劣而导致不断泄漏内存。建议设置未1000,可根据应用的需求做调整。

slowlog = /path/to/slowlog.log
这个设置的值是一个日志文件在系统文件中的绝对路径。这个日志文件拥有记录处理时间超过N秒的http请求信息,比便找出php应用的瓶颈,进行调试。php-fpm进程池属于的用户和用户组必须有这个文件的写入权限。

request_slowlog_timeout = 5s
如果当前http请求的处理时间超过指定的值,就把请求的回溯信息写入slowlog设置指定的文件。把这个设置的值设置为多少,取决于你认为多长时间算久。一开始,可以设置为5s,s(econds), m(inutes), h(ours), or d(ays)


nginx大流量负载调优(转)
nginx大流量负载调优

优化nginx包括两方面:
1.是自己重写nginx代码(比如tengine)、本身nginx的代码已经足够优秀,如果不是每秒几千的请求,就忽略这个部分吧。
2.另一个就是和优化nginx的配置,这是中小型网站可以重点优化的部分。

nginx的配置文件是一种声明式定义,控制nginx的每一个细节。
所谓负载调优,就是提高单台机器处理效率,降低单台机器的负载。
为了提高单台机器的处理效率,cpu的处理速度是足够快的,我们能解决的就是降低磁盘I/O、网络I/O,减少内存使用。
降低单台机器的负载我们能做的就是负载均衡,把流量打到多台机器处理。

nginx推荐优化内容:
1.open files数量优化
ulimit -a查看系统参数
其中
open files (-n) 1024
表示系统同时最多能打开的文件数,linux下的所有设备都可以认为是文件,包括网络连接,如果同时超过1024个连接,那么nginx的日志就会报“24: Too many open files”
多以优化的第一步就是设置open files为ulimit
修改/etc/profile,增加
ulimit -n 65535

2.Worker Processes数量优化
通常来说设置一个cpu核心对应一个worker processer,最多不超过4个,提高worker process的值是为了提高计算能力,但一般在越到cpu瓶颈前,你会遇到别的瓶颈(如网络问题)。
只有当你要处理大量静态文件的磁盘I/O时,worker进程是单线程的,所以这个读取文件的阻塞IO会降低CPU的处理速度,这是可以增加worker进程数量,其它情况是不需要的。

3.worker进程连接数优化(Worker Connections)
默认情况下这个值是worker_connections 1024,也就是说考虑到keep-alive超时65秒,每个浏览器平均消耗两个链接(chrome会同时打开多个连接来提到加载速度)。
那么默认情况下nginx平均每秒能处理1024/65/2=8,那么8*86440=64w,差不多相当于每天有60万ip。
多以普通网站默认值就可以了,如果你的流量一直提升,可以考虑增加这个值为2048或者更高。

3. CPU Affinity
用来设置worker进程使用哪个cpu核心处理请求并且一直使用这个cpu核心。如果你不知道cpu调度,最好别碰这个,操作系统比你更懂如何调度。

4. Keep Alive
Keep alive 没有数据传输的情况下保持客户端和服务端的连接,也就是保持空连接一段时间,避免重现建立链接的时间消耗。nginx处理空连接的效率非常高,1万个空连接大约消耗2.5M内存。如果流量非常大的网站,减少建立连接的时间开销是非常客观的。keep alive的值设置在10-20s之间比较合理。

5. tcp_nodelay 和 tcp_nopush优化
这两个指令影响nginx的底层网络,它们决定操作系统如何处理网络层buffer和什么时候把buffer内容刷新给终端用户。如果你不懂,就可以保持这两个指令默认不变,对nginx性能影响不明显。

6. access日志优化
默认情况下,access日志会记录所有请求到日志文件,写操作会增加IO操作,如果不需要统计信息,可以使用百度统计或者cnzz统计,完全可以关闭日志,来减少磁盘写,或者写入内存文件,提高IO效率。

7. Error日志优化
错误日志会记录运行中的错误,如果设置的太低,会记录的信息太多,会产生大量IO,推荐设置为warn,这样可以记录大部分信息,而不会有太多IO

8. Open File Cache
nginx会读文件系统的许多文件,如果这些文件的描述符能够缓存起来,那么会提高处理效率。详见http://wiki.nginx.org/HttpCoreModule#open_file_cache

9. Buffers size优化
buffer的大小是你需要调优最重要参数。如果buffer size太小就会到导致nginx使用临时文件存储response,这会引起磁盘读写IO,流量越大问题越明显。
client_body_buffer_size 处理客户端请求体buffer大小。用来处理POST提交数据,上传文件等。client_body_buffer_size 需要足够大以容纳如果需要上传POST数据。
fastcgi_buffers,proxy_buffers 处理后端(PHP,Apache)响应。如果这个buffer不够大,同样会引起磁盘都系IO。需要注意的是它们有一个上限值,这个上限值受 fastcgi_max_temp_file_size 、 proxy_max_temp_file_size控制。

10.磁盘IO
如果能把数据全放到内存,不使用磁盘就可以完全去掉磁盘IO。 默认情况下操作系统也会缓存频繁访问的数据以降低IO。所以预算足够的情况加,加大内存。

11.网络IO
假设我们没有了磁盘IO,所有数据都在内存,那么我们的读IO大概有3-6gbps。这种情况下,如果你网络差,一样会很慢。所以尽可能提高网络带宽,压缩传输数据。
网络带宽买你能买的起的最大带宽,nginx的gzip模块可以用来压缩传输数据,通常gzip_comp_level 设为 4-5,再高就是浪费cpu了。同时也可以采用css,js压缩技术,当然这些技术就与nginx优化无关了。。

绝招
如果你还想提高nginx处理能力,只能祭出大杀器了。别优化了,加机器吧。一点点优化是没有用的,不如扩展机器来的快些。

ps

说道系统的扩展性通常有scale、和extension,区别是前者是数量上扩展,后者是功能上扩展。


原文地址:http://www.nginx.cn/2212.html


nginx与apache(转)
1、nginx相对于apache的优点:
轻量级,同样起web 服务,比apache占用更少的内存及资源抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能高度模块化的设计,编写模块相对简单社区活跃,各种高性能模块出品迅速啊
apache 相对于nginx 的优点:
rewrite ,比nginx 的rewrite 强大,动态页面,模块超多,基本想到的都可以找到,少bug ,nginx 的bug 相对较多,超稳定 
存在就是理由,一般来说,需要性能的web 服务,用nginx 。如果不需要性能只求稳定,那就apache 吧。后者的各种功能模块实现得比前者,例如ssl 的模块就比前者好,可配置项多。这里要注意一点,epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由,但并不是所有的情况下都是epoll 大获全胜的,如果本身提供静态服务的就只有寥寥几个文件,apache 的select 模型或许比epoll 更高性能。
2、作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下,Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型.
Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多.
作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器), Last.fm 描述了成功并且美妙的使用经验.
Nginx 是一个安装非常的简单 , 配置文件非常简洁(还能够支持perl语法), Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动. 你还能够不间断服务的情况下进行软件版本的升级 .
3、Nginx 配置简洁, Apache 复杂
Nginx 静态处理性能比 Apache 高 3倍以上
Apache 对 PHP 支持比较简单,Nginx 需要配合其他后端用
Apache 的组件比 Nginx 多
现在 Nginx 才是 Web 服务器的首选
4、最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程
5、nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式.
apache有先天不支持多核心處理負載雞肋的缺點,建議使用nginx做前端,後端用apache。大型網站建議用nginx自代的集群功能
6、nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没有问题,apache重启的时候发现配置出错了,会很崩溃,改的时候都会非常小心翼翼现在看有好多集群站,前端nginx抗并发,后端apache集群,配合的也不错。
7、nginx处理动态请求是鸡肋,一般动态请求要apache去做,nginx只适合静态和反向。
8、nginx是很不错的前端服务器,负载性能很好,在老奔上运行nginx,用webbench模拟10000个静态文件请求毫不吃力。apache对php等语言的支持很好,此外apache有強大的支持网路,发展时间相对nginx更久,
9、Nginx优于apache的主要两点:1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡;其他的当然,Nginx可能会比apache支持更高的并发,但是根据NetCraft的统计,2011年4月的统计数据,Apache依然占有62.71%,而Nginx是7.35%,因此总得来说,Aapche依然是大部分公司的首先,因为其成熟的技术和开发社区已经也是非常不错的性能。
10、你对web server的需求决定你的选择。大部分情况下nginx都优于APACHE,比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端Cache、维持连接等等。在Apache+PHP(prefork)模式下,如果PHP处理慢或者前端压力很大的情况下,很容易出现Apache进程数飙升,从而拒绝服务的现象。
11、可以看一下nginx lua模块,apache比nginx多的模块,可直接用lua实现apache是最流行的,why?大多数人懒得更新到nginx或者学新事物
12、对于nginx,我喜欢它配置文件写的很简洁,正则配置让很多事情变得简单运行效率高,占用资源少,代理功能强大,很适合做前端响应服务器
13、Apache在处理动态有优势,Nginx并发性比较好,CPU内存占用低,如果rewrite频繁,那还是Apache吧
webbench安装测试
wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install


[root@Action webbench-1.5]# webbench --help
webbench [option]... URL
  -f|--force               Don't wait for reply from server.
  -r|--reload              Send reload request - Pragma: no-cache.
  -t|--time <sec>          Run benchmark for <sec> seconds. Default 30.
  -p|--proxy <server:port> Use proxy server for request.
  -c|--clients <n>         Run <n> HTTP clients at once. Default one.
  -9|--http09              Use HTTP/0.9 style requests.
  -1|--http10              Use HTTP/1.0 protocol.
  -2|--http11              Use HTTP/1.1 protocol.
  --get                    Use GET request method.
  --head                   Use HEAD request method.
  --options                Use OPTIONS request method.
  --trace                  Use TRACE request method.
  -?|-h|--help             This information.
  -V|--version             Display program version.

例子
webbench -c 并发数 -t 运行测试时间 URL
webbench -c 1000 -t 60 http://www.baidu.com/index.php

linux centos编译node报错

linux centos编译node报错
WARNING: C++ compiler too old, need g++ 4.8 or clang++ 3.4 (CXX=g++)
我查看了我的版本是
[root@Action node-v4.2.3]# g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

于是我只好安装4.8版本,从网上找到了方法
这里我用的是root用户
cd ~
http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.8.1/gcc-4.8.1.tar.gz
tar zxvf gcc-4.8.1.tar.gz
cd gcc-4.8.1
./contrib/download_prerequisites  //下载所需要的依赖包
cd ..
mkdir gcc-build-4.8.1
../gcc-4.8.1/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
make 
make install

//如果是64位系统,则下面为lib64/
cp ~/gcc-build-4.8.1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.18 /usr/lib 
ln -sf /usr/lib/libstdc++.so.6.0.18 /usr/lib/libstdc++.so.6
下面查看版本
g++ --version
[root@Action gcc.4.8.1]# g++ --version
g++ (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


优惠券
广告位-淘宝
最新微语