服务器性能优化澳门美高梅手机网站

啊是性质?

性能最浅的权衡目标虽是“时间”,CPU的使用率指的凡CPU用于统计的时日占比,磁盘使用率指的是磁盘操作的工夫占比。

当CPU使用率100%平时,意味着有有要来不及总计,响应时间长或逾期;

当磁盘使用率100%不时,意味着有一些要需要等待IO操作,响应时间吗会师增多或者逾期。

换言之,所有的操作皆以美之工夫内,就不存“性能优化“的题目。大家于条分缕析性能的时候,总是会首先要找到是什么招响应时间变慢了,对诺单机性能的分析,一般我们会用目光锁定在CPU和IO上,因为于应用程序一般分为CPU
bound型和IO。

bound型,即统计密集型或者读写密集型;至于内存,其性质因素往往也晤面呈现至CPU或者IO上,因为内存的筹划初衷就是是提升基本指令与应用程序的读写性能。

当内存不足,系统可能开展大量底交流操作,这时候磁盘可能变成瓶颈;而缺页、内存分配、释放、复制、内存地址空间映射等等问题还要或者滋生CPU的瓶颈;更严重的情是直接影响效果,这么些就是不仅是性的问题了。

属性优化并无是一个孤立的课题,除了应时间的考虑,大家往往还用综合功用完整性、安全性等等方面的题材。

       由于余先生在 V4.05
以后的本子就将停放 HTTP服务去丢了,所以固然这首而测试高达污染成了,你为访问不了。

属性分析的根基

性优化内需丰饶的基础知识:

  • 操作系统
    操作系统管理着应用程序所急需之有资源,例如CPU和IO,当其他一个组件出现问题,我们的剖析为是因操作系统的,例如文件系统类型,磁盘类型,磁盘raid类型都用操作系统管理和援助。

  • 网编程技术
    系统编程技术涉及到我们安利用系统资源,例如对IO的操作我们得接纳buffering
    I/O,也可选择Direct
    IO,可以使用一块的点子,也得以应用异步的主意,可以应用多进程,也足以利用多线程的章程。了解不同编程技术的规律,有利于问题的分析。

  • 应用程序
    譬如说数据库组件的数据类型、引擎、索引、复制、配置参数、备份、高可用等等都可能是性质问题的首恶。

推荐大家结合 Nginx 使用 fastdfs-nginx-module
模块,

属性分析的方法论

题目分析者,各种方法论如金字塔思维、5W2H、麦肯锡七步法等等。套用5W2H智,可以提议性能分析的多少个问题

  • What-现象之呈现是安的

  • When-哪一天发

  • Why-为啥会生出

  • Where-哪个地点有的题目

  • How
    much-耗费了有些资源,问题解决后可以压缩多少资源耗用

  • How to
    do-怎么化解问题

而是这么些只好为起方向,性能分析需要找到原因需要还具体的方,怎么解决一个题目为要更为具体的法。

布伦达n
Gregg以《性能的巅峰:洞悉系统、公司及讲统计》第二段中称到大气底格局,比较出色的假诺Use方法、负载特征归咎、性能监控、静态性能调优、延时分析、工具法等等。

内部工具法最实际,不过工具法也闹协调的克,如磁盘的饱和度,在磁盘使用率100%底下,磁盘的载荷可能还可持续增多。在实质上分析问题遭逢,负载特征归结更发生指导意义,静态跟踪以及动态跟踪让我们再次爱再直观发现题目。

搭建好fastdfs 系统后
就可以搭建web访问效果了。

CPU

粗粗思路来以下简单栽

认识CPU

CPU本身的架和根本调度器的架那里不举办详细描述,具体可以参照操作系统类书籍。不过仍然要了解一些概念:

  • 处理器

  • 硬件线程

  • CPU内存缓存

  • 钟频率

  • 每令周期数CPI和各国周期指令数IPC

  • CPU指令

  • 使用率

  • 用户时间/内核时间

  • 调度器

  • 运行班

  • 抢占

  • 多进程

  • 多线程

  • 字长

线程的状态分析主要是分析线程的时间用在什么地方,而线程状态的分类一般分为:

>  style="margin: 0px; padding: 0px; max-width: 100%">on-CPU:执行中,执行中的时间通常又分为用户态时间user和系统态时间sys。
>
>  style="margin: 0px; padding: 0px; max-width: 100%">off-CPU:等待下一轮上CPU,或者等待I/O、锁、换页等等,其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。

如果大量时间花在CPU上,对CPU的剖析能够迅速解释原因;如果系统时间大量处于off-cpu状态,定位问题就会费时很多。

### 分析方法与工具

在观察CPU性能的时候,按照负载特征归纳的方法,可以检查如下清单:

-   整个系统范围内的CPU负载如何,CPU使用率如何,单个CPU的使用率呢?

-   CPU负载的并发程度如何?是单线程吗?有多少线程?

-   哪个应用程序在使用CPU,使用了多少?

-   哪个内核线程在使用CPU,使用了多少?

-   中断的CPU用量有多少?

-   用户空间和内核空间使用CPU的调用路径是什么样的?

-   遇到了什么类型的停滞周期?

要回答上面的问题,使用系统性能分析工具最经济和直接,这里列举的工具足够回答上面的问题:

<table>
<thead>
<tr class="header">
<th>工具</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>uptime</td>
<td>平均负载</td>
</tr>
<tr class="even">
<td>vmstat</td>
<td>包括系统范围的CPU平均负载</td>
</tr>
<tr class="odd">
<td>top</td>
<td>监控每个进程/线程CPU用量</td>
</tr>
<tr class="even">
<td>pidstat</td>
<td>每个进程/线程CPU用量分解</td>
</tr>
<tr class="odd">
<td>ps</td>
<td>进程状态</td>
</tr>
<tr class="even">
<td>perf</td>
<td>CPU剖析和跟踪,性能计数器分析</td>
</tr>
</tbody>
</table>


上述问题中,调用路径和停滞周期的分析可以使用perf工具,也可以使用DTrace等更灵活的工具。

其中perf支持对各类内核时间的跟踪计数统计,可以使用perf
list查看。例如停滞周期分析可能十分复杂,需要对CPU和调度器架构有较系统的认识和了解。

停滞的周期可能发生在一级、二级或者三级缓存,如缓存未命中,也可能是内存IO和资源IO上的停滞周期,perf中有诸如L1-dcahce-loads,L1-icache-loads等事件的计数统计。

我们在压测mysql在某机型上的非原地更新性能时,分析mysql服务器延时情况时,分析了CPU上主要的函数调用。

使用perf
top能够看到调用次数的排名,但是调用关系不能展示出来。火焰图很清晰地提供了调用关系的视图(如下两图中的比例不同是因为perf
top加了-p参数,火焰图分析是针对整个系统)。





内存
----

### 认识内存

如前所述,内存是为提高效率而生,实际分析问题的时候,内存出现问题可能不只是影响性能,而是影响服务或者引起其他问题。同样对于内存有些概念需要清楚:

-   主存

-   虚拟内存

-   常驻内存

-   地址空间

-   OOM

-   页缓存

-   缺页

-   换页

-   交换空间

-   交换

-   用户分配器libc、glibc、libmalloc和mtmalloc

-   LINUX内核级SLUB分配器

### 分析方法与工具

Brendan在书中给出了一些问题,比如内存总线的平衡性,NUMA系统中,内存是否被分配到合适的节点中去等等,这些问题在实际分析问题的时候,并不能作为切入点,需要持续的分析。因此笔者简化为如下清单:

-   系统范围内的物理内存和虚拟内存使用率

-   换页、交换、oom的情况

-   内核和文件系统缓存的使用情况

-   进程的内存用于何处

-   进程为何分配内存

-   内核为何分配内存

-   哪些进程在持续地交换

-   进程或者内存是否存在内存泄漏?  


内存的分析工具如下:

<table>
<thead>
<tr class="header">
<th>工具</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>free</td>
<td>缓存容量统计信息</td>
</tr>
<tr class="even">
<td>vmstat</td>
<td>虚拟内存统计信息</td>
</tr>
<tr class="odd">
<td>top</td>
<td>监视每个进程的内存使用情况</td>
</tr>
<tr class="even">
<td>ps</td>
<td>进程状态</td>
</tr>
<tr class="odd">
<td>Dtrace</td>
<td>分配跟踪</td>
</tr>
</tbody>
</table>


除了DTrace,所有的工具只能回答信息统计,进程的内存使用情况等等,至于是否发生内存泄漏等,只能通过分配跟踪。

但是DTrace需要对内核函数有很深入的了解,通过D语言编写脚本完成跟踪。Perf也有一些诸如cache-miss、page-faults的事件用于跟踪,但是并不直观。

### 实际案例

关于内存泄漏,从监控和顶层观察很难发现问题,一般都是从底层程序代码来分析,案例中使用各种观察工具和跟踪工具都不能很确定原因所在,只能通过分析代码来排查问题。

最终发现是lua脚本语言分配内存速度快,包驱动的周期性服务的用法中,lua自动回收不能迅速释放内存,而是集中回收,如果频繁回收又可能带来CPU的压力。开发项目组最后采用的解决方式为分步回收,每次回收一部分内存,然后周期性全量回收。

IO
--

### 逻辑IO vs 物理IO

通常在讨论问题时,总是会分析IO的负载,IO的负载通常指的是磁盘IO,也就是物理IO,例如我们使用iostat获取的avgqu-sz、svctm和until等指标。

因为我们的读写最终都是来自或者去往磁盘的,关注磁盘的IO情况非常正确。但是我们在进行读写操作的时候,面向的对象大多数时候并不会直接面向磁盘,而是面向文件系统的,除非使用raw
io的方式。

如下图为通用的IO结构图,如果你想了解更详细,可以查看第二张图片。我们知道LINUX通过文件系统将所有的硬件设备甚至网络都抽象为文件来管理,
例如read()调用时,实际就是就是调用了vfs\_read函数,文件系统会确认请求的数据是否在页缓存中,如果不在内存中,于是将请求发送到块设备;

此时内核会先获取到数据在物理设备上的实际位置,然后将读请求发送给块设备的请求队列中,IO调度器会通过一定的调度算法,将请求发送给磁盘设备驱动层,执行真正的读操作。

在这一过程中可能发生哪些情况呢?如果应用程序执行的是大量的顺序读会怎样?随机读又会怎样?如果是顺序读,正确的做法就是进行预读,让请求的数据落到内存中,提升读效率。所以在应用程序发起一次读,从文件系统到磁盘的过程中,存在读放大的问题。



在写操作时同样存在类似的情况,应用程序发起对文件系统的IO操作,物理IO与应用程序之间,有时候会显得无关、间接、放大或者缩小。

无关:

-   其他的应用程序:磁盘IO来自其他的应用程序,如监控,agent等

-   其他用户:如同虚拟机母机下的其他用户

-   其他内核任务:如重建raid,校验等  


间接:

-   文件系统预读:增加额外的IO,但是可能预读的数据无用

-   文件系统缓冲:写缓存推迟或者合并回写磁盘,造成磁盘瞬时IO压力  


放大:

-   文件系统元数据:增大额外的IO

-   文件系统记录尺寸:向上对齐等增加了IO大小  


缩小:

-   文件系统缓存:直接读取缓存,而不需要操作磁盘

-   合并:一次性回写磁盘

-   文件系统抵消:同一地址更新多次,回写磁盘时只保留最后一次修改

-   压缩:减少数据量



### 文件系统分析与工具

与文件系统相关的术语如下:

-   文件系统

-   VFS

-   文件系统缓存

-   页缓存page cache

-   缓冲区高速缓存buffer cache

-   目录缓存

-   inode

-   inode缓存  


如下图为文件系统缓存的结构图,页缓存缓存了虚拟内存的页面,包括文件系统的页面,提升了文件和目录的性能。Linux将缓冲区高速缓存放入到了页缓存中,即page
cache包含buffer cache。

文件系统使用的内存脏页由内核线程写回磁盘,如图中的页面扫描器kswapd为后台的页面换出进程,当内存不足,超过一定时间(30s)或者有过多的脏页时都会触发磁盘回写。

文件系统延时指的是一个文件系统逻辑请求从开始到结束的时间,包括在文件系统、内核磁盘IO子系统以及等待磁盘设备响应的时间。同步访问时,应用程序会在请求时阻塞,等待文件系统请求结束,异步方式下,文件系统对其并无直接影响。

但是异步访问也分select、poll、epoll等方式,也就是所谓的异步阻塞、异步非阻塞。在异步方式下,一般是打印出用户层发起文件系统逻辑IO的调用栈,得到调用了哪个函数产生了IO。

Linux未提供查看文件系统延时的工具和接口,但是磁盘的指标信息却比较丰富,但是很多情况下,文件系统IO和磁盘IO之间并没有直接关系,例如应用程序写文件系统。

但是根本不关心数据什么时候写到磁盘了,而后台刷数据到磁盘时,可能造成磁盘IO负载增加,从磁盘角度,应用程序的写入可能受到影响了,而实际上应用程序并没有等待。

文件系统的分析可以试着回答下面的问题:

-   哪个应用程序在使用文件系统?

-   在对哪些文件进行操作?

-   在进行什么样的操作,读写比是多少,同步还是异步?

-   文件系统的缓存有多大,目前的使用情况?

-   有遇到什么错误吗?是请求不合法,还是文件系统自身的问题?  


其实上面的问题,除了能够看到系统的内存情况,页缓存和buffer
cache大小,能够看到哪些进程在进行读写操作,在读哪些文件,其他的比如应用程序对文件系统的读写比,同步还是异步,这些问题没有工具能给出明确的信息。当然我们可以通过跟踪应用程序的内核调用栈来发现问题,也可以在应用程序中输出日志来帮助分析。

### 磁盘分析与工具

在理解磁盘IO之前,同样我们需要理解一些概念,例如:

-   虚拟磁盘

-   扇区

-   I/O请求

-   磁盘命令

-   带宽

-   吞吐

-   I/O延时

-   服务时间

-   等待时间

-   随机IO/连续IO

-   同步/异步

-   磁盘接口

-   Raid  


对于磁盘IO,我们可以列出如下等问题来帮助我们分析性能问题:

-   每块磁盘的使用率是多少?

-   每块磁盘上有多长等待队列?

-   平均服务时间和等待时间时多少?

-   是哪个应用程序或者用户正在使用磁盘?

-   应用程序读写的方式是怎样的?

-   为什么会发起磁盘IO,内核调用路径是什么样的?

-   磁盘上的读写比是多少?

-   随机IO还是顺序IO?  


Linux对磁盘的性能分析工具主要如下:

<table>
<thead>
<tr class="header">
<th>工具</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>iostat</td>
<td>各种单个磁盘统计信息</td>
</tr>
<tr class="even">
<td>iotop、pidstat</td>
<td>按进程列出磁盘IO的使用情况</td>
</tr>
<tr class="odd">
<td>perf、Dtrace</td>
<td>跟踪工具</td>
</tr>
</tbody>
</table>


磁盘上是随机IO还是顺序IO,很多时候我们并没有很好的方式去判断,因为块设备回写磁盘的时候,随机IO可能已经被整理为顺序IO了。对于磁盘的分析同样可以使用perf跟踪事件或者DTrace设置探针。

在分析mysql在某机型上做非全cache非原地更新时,为什么单实例无法将机器性能压满的时候,我们在分析的过程中跟踪了块设备的内核事件。我们对比了多实例非原地更新和单实例非原地更新的时候,磁盘的操作情况。如下为非原地更新时跟踪的结果。

对结果分析后看到,单实例非原地更新时,将近30%是blk\_finish\_plug,有70%是blk\_queue\_bio,而多实例时正好相反,大量的blk\_finish\_plug和少量的blk\_queue\_bio(当然,这不是为什么性能压不满的原因)。

 

1.直设置nginx关于fastdfs集合的扩大模块
 fastdfs-nginx-module  
    或者直接装apache关于fastdfs集合的恢弘模块
 fastdfs-apache-module  

2.设置web软件后,通过配备nginx实现了fastdfs-nginx-module的功用

第一种(推荐).
下载nginx  和   插件fastdfs-nginx-module-master.zip   这半独软件

(假设nginx已经安装好了,需要再行编译一满,编译时拿插件装上)
(即便nginx使用yum安装的,需要下载yum相同版本安装包,重新编译)

这里从头开始安装:

解压:

# tar -zxvf nginx-1.13.5.tar.gz
# unzip fastdfs-nginx-module-master.zip 

安装nginx和fastdfs插件:
 ./configure –prefix=/usr/local/nginx
 –add-module=/home/packages/fastdfs-nginx-module-master/src

连报错:

报错: the HTTP rewrite module requires the PCRE
library.……
解决:yum install pcre-devel.x86_64

报错: the HTTP gzip module requires the zlib
library.……
解决:yum install
zlib-devel.x86_64

编译成功:

adding module in
/home/packages/fastdfs-nginx-module-master/src

 + ngx_http_fastdfs_module was
configured

Configuration summary

  + using system PCRE library

  + OpenSSL library is not used

  + using system zlib library

  nginx path prefix:
“/usr/local/nginx”

  nginx binary file:
“/usr/local/nginx/sbin/nginx”

  nginx modules path:
“/usr/local/nginx/modules”

  nginx configuration prefix:
“/usr/local/nginx/conf”

  nginx configuration file:
“/usr/local/nginx/conf/nginx.conf”

  nginx pid file:
“/usr/local/nginx/logs/nginx.pid”

  nginx error log file:
“/usr/local/nginx/logs/error.log”

  nginx http access log file:
“/usr/local/nginx/logs/access.log”

  nginx http client request body temporary
files: “client_body_temp”

  nginx http proxy temporary files:
“proxy_temp”

  nginx http fastcgi temporary files:
“fastcgi_temp”

  nginx http uwsgi temporary files:
“uwsgi_temp”

  nginx http scgi temporary files:
“scgi_temp”

继往开来设置:

# make

# make install

进去nginx安装目录,修改该配备文件:

# cd /usr/local/nginx/conf

# vi nginx.conf

充实以下内容:

 location /M00 {

            root
/home/yuqing/fastdfs/data;

            ngx_fastdfs_module;

        }

新建一个软连接:

# ln -s /home/yuqing/fastdfs/data
 /home/yuqing/fastdfs/data/M00

复制并修改mod_fastdfs.conf文件:

# cp mod_fastdfs.conf /etc/fdfs/

# vi /etc/fdfs/mod_fastdfs.conf

修改了此处:

tracker_server=10.0.0.42:22122

(复制这半独文件及fdfs配置文件,要无不可能访问nginx)

(# cp
/home/fastdfs-5.11/conf/http.conf /etc/fdfs/)
(# cp
/home/fastdfs-5.11/conf/mime.types /etc/fdfs/)

重启nginx:
# /usr/local/nginx/sbin/nginx -s stop;
# /usr/local/nginx/sbin/nginx

报错:浏览器不能访问
翻nginx错误日志 如下

 ERROR –
file: ini_file_reader.c, line: 631, include file “http.conf” not
exists, line: “#include http.conf”

 ERROR –
file: /home/packages/fastdfs-nginx-module-master/src/common.c, line:
163, load conf file “/etc/fdfs/mod_fastdfs.conf” fail, ret code:
2

解决:#
cp /home/fastdfs-5.11/conf/http.conf /etc/fdfs/

 ERROR – file: shared_func.c, line: 968, file /etc/fdfs/mime.types not
exist

解决:#
cp /home/fastdfs-5.11/conf/mime.types /etc/fdfs/

访问nginx
成功

脚看一下 mod_fastdfs.conf文件:

# connect timeout in seconds

# default value is 30s

connect_timeout=2

老是超时时间

# network recv and send timeout in
seconds

# default value is 30s

network_timeout=30

出殡接受数据 超时时间

# the base path to store log files

base_path=/tmp

日记文件 地点

# if load FastDFS parameters from tracker
server

# since V1.12

# default value is false

load_fdfs_parameters_from_tracker=true

是否打 tracket服务器读裁撤息

倘诺未打tracket服务器读裁撤息,以下三单参数生效

# storage sync file max delay
seconds

# same as tracker.conf

# valid only when
load_fdfs_parameters_from_tracker is false

# since V1.12

# default value is 86400 seconds (one
day)

storage_sync_file_max_delay =
86400

     
当load_fdfs_parameters_from_tracker设置也false时,本参数生效

协办文件最酷延迟时间,与tracker.conf文件被参数相同
默认是平等天

# if use storage ID instead of IP
address

# same as tracker.conf

# valid only when
load_fdfs_parameters_from_tracker is false

# default value is false

# since V1.13

use_storage_id = false

    是否拔取storage_id 

# specify storage ids filename, can use
relative or absolute path

# same as tracker.conf

# valid only when
load_fdfs_parameters_from_tracker is false

# since V1.13

storage_ids_filename =
storage_ids.conf
     storage_id的位置

# FastDFS tracker_server can ocur more
than once, and tracker_server format is

#  “host:port”, host can be hostname or
ip address

# valid only when
load_fdfs_parameters_from_tracker is true

tracker_server=10.0.0.42:22122

自tracket服务器读取信息,那多少个参数生效

tracket服务器地址、端口

# the port of the local storage
server

# the default value is 23000

storage_server_port=23000

    本storage server监听端口

# the group name of the local storage
server

group_name=group1

      group组名

# if the url / uri including the group
name

# set to false when uri like
/M00/00/00/xxx

# set to true when uri like
${group_name}/M00/00/00/xxx, such as group1/M00/xxx

# default value is false

url_have_group_name = false

url链接中是否含有
组名

类似 /M00/00/00/xxx
和group1/M00/00/00/xxx

假若采取true
即含有组名,需要改nginx配置文件
将  location /M00    改为     location /group1/M00 

# path(disk or mount point) count,
default value is 1

# must same as storage.conf

store_path_count=1

      存储路径数量,必须同 storage.conf文件一律

# store_path#, based 0, if store_path0
not exists, it’s value is base_path

# the paths must be exist

# must same as storage.conf

store_path0=/home/yuqing/fastdfs

#store_path1=/home/yuqing/fastdfs1

     存储路径地址、必须跟 storage.conf文件一律

# standard log level as syslog, case
insensitive, value list:

### emerg for emergency

### alert

### crit for critical

### error

### warn for warning

### notice

### info

### debug

log_level=info

    日志级别

# set the log filename, such as
/usr/local/apache2/logs/mod_fastdfs.log

# empty for output to stderr (apache and
nginx error_log file)

log_filename=

     设置日志的称,为空则记录及
http服务之一无是处日志里

# response mode when the file not exist
in the local file system

## proxy: get the content from other
storage server, then send to client

## redirect: redirect to the original
storage server (HTTP Header is Location)

response_mode=proxy

当文件在本地不在时时如何应对

  • proxy
    代理,从外存储服务器获取内容,然后发送给客户
  • redirect
     重定向旧存储服务器的http头

# the NIC alias prefix, such as eth in
Linux, you can see it by ifconfig -a

# multi aliases split by comma. empty
value means auto set by OS type

# this paramter used to get all ip
address of the local host

# default values is empty

if_alias_prefix=

????

强号用逗号分隔,空值表示自动安装系统项目

这参数用于获取本机的有所ip

# use “#include” directive to include
HTTP config file

# NOTE: #include is an include
directive, do NOT remove the # before include

#include http.conf

   使用#include指令 包含http配置文件

   
注意:#include
 这是一个含有指令,不要去 include前边的 #

# if support flv

# default value is false

# since v1.15

flv_support = true

   是否协助flv文件,默认不帮忙

# flv file extension name

# default value is flv

# since v1.15

flv_extension = flv

    flv文件之扩充名,默认是flv

# set the group count

# set to none zero to support multi-group
on this storage server

# set to 0  for single group only

# groups settings section as [group1],
[group2], …, [groupN]

# default value is 0

# since v1.14

group_count = 0

设置组的数
安没有0 ,补助四个group组在那蕴藏服务器上

设置0
为优异一个组

倘服务器上基本上个组,组的装置
就比如这么 [group1], [group2], …, [groupN]

默认是0,一组

# group settings for group #1

# since v1.14

# when support multi-group on this
storage server, uncomment following section

#[group1]

#group_name=group1

#storage_server_port=23000

#store_path_count=2

#store_path0=/home/yuqing/fastdfs

#store_path1=/home/yuqing/fastdfs1

   组1的设置

 
 若本存储服务器补助多组,废除下边的笺注

# group settings for group #2

# since v1.14

# when support multi-group, uncomment
following section as neccessary

#[group2]

#group_name=group2

#storage_server_port=23000

#store_path_count=1

#store_path0=/home/yuqing/fastdfs

组2的设置

若本存储服务器援助多组,撤除下边的诠释

次、直接以 web访问

这么些相比较简单,只需要将web根目录指定到
fastdfs的囤目录就得了

其三、web访问fastdfs 的几栽思路

3.1  只使用 组名
适用于图片量相当、group组多、每个group组都发备份

做客地址类似于  
picture.xxx.com/groupx/M00/……jpg

无非需要一个域名;
上传图片后 将回到的值 直接+域名  保存也图名 :picture.xxx.com/groupx/M00/……jpg

前端选拔一个nginx做反而朝代理+负载均衡
 配置如下:

upstream group1{

   server group1_storage1:80;
   server
group1_storage2:80;
}

upstream group2{

   server group2_storage1:80;
   server group2_storage2:80;
}

location /group1/M00{

proxy_pass http://group1;

}

location /group2/M00{

proxy_pass http://group2;

}

在意:group1 和 group2 中 机器要正确配置 nginx.conf  storage.conf 和
mod_fastdfs.conf 文件

nginx.conf中

 location /group1/M00 {

            root
/home/yuqing/fastdfs/data;

           
ngx_fastdfs_module;

        }

 特别注意  mod_fastdfs.conf文件中  这半桩 组名、url是否带有group名
group_name=
url_have_group_name =

3.2 只使用 域名 (已配备生产条件)
适用于图片于少,每个group组都是单机跑,没有备份的情景

拜地址类似于   picturex.xxx.com/M00/……jpg

待差不两个域名;
上传图片后 将回来的价值分开后 结合域名 生成图名   picture**x.xxx.com/M00/……jpg**

前端接纳一个nginx做反而朝代理
 配置如下:

upstream group1{

   server group1_storage1:80;
}

upstream group2{

   server group2_storage1:80;
}

location /group1/M00{

proxy_pass http://group1;

}

location /group2/M00{

proxy_pass http://group2;

}

瞩目:group1 和 group2 中 机器要正确配置
nginx.conf  storage.conf
是因为每组没有备份, mod_fastdfs.conf 也无用装了

nginx.conf中

 location /group1/M00 {

            root /home/yuqing/fastdfs/data;

        }

3.3 域名和组名同时使  

适用于图片量非凡、业务量基本上、group组多、每个group组都来备份

访地址类似于   picturex.xxx.com/groupx/M00/……jpg

单独待一个域名;
上传图片后 将回来的值+改动域名  保存也图名 :picture
x.xxx.com/groupx/M00/……jpg

以多单域名对应一个nginx
 做反而朝代理+负载均衡  配置如下:

 

upstream group1{

   server group1_storage1:80;
   server group1_storage2:80;
}

upstream group2{

   server group2_storage1:80;
   server group2_storage2:80;
}

server {
        listen       80;
        server_name  picture1.xxx.com;
       ……

location /group1/M00{

proxy_pass http://group1;

}

location /group2/M00{

proxy_pass http://group2;

}

}

server {
        listen      
80;

        server_name
 picture2.xxx.com;

       …… }

只顾:group1 和 group2 中 机器要正确配置 nginx.conf  storage.conf
和 mod_fastdfs.conf 文件

nginx.conf中

 location /group1/M00 {

            root /home/yuqing/fastdfs/data;

            ngx_fastdfs_module;

        }

 特别注意  mod_fastdfs.conf文件中  这有限桩 组名、url是否带有group名
group_name=
url_have_group_name =

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注