开启配置HTTP压缩（GZip）
在IIS7中配置Gzip压缩相比IIS6来说实在容易了许多，而且默认情况下就是启用GZip压缩的。如果没有，则可以再功能视图下找到“压缩”项，进入之后就会看到“静态内容压缩”和“动态内容压缩”两个选项，勾上即可。
配置启用压缩的文件类型及其他选项
当开启GZip压缩之后，IIS并不是对所有内容都启用了压缩，而是有选择的进行压缩。遗憾的是，我们无法直接在IIS7管理器中配置这些压缩选项。我们首先需要在C:\Windows\System32\inetsrv\config文件夹下找到applicationhost.config文件，打开之后找到如下一节内容：
IIS实际上是根据MIME类型来决定是否启用HTTP压缩的，以及压缩比之类的选项。可以看出，图片默认情况下是不被压缩的，这是因为图片的压缩比太低了。
我们注意到，对于Javascript来说，上面对不同的mime类型配置了不同的压缩方式。Javascript有三种常见的Mime类型，text/javascript，application/x-javascript，application/javascript。这三种类型都是合法的，在现代浏览器中也不存在什么差别。但是由于IIS7中Js文件的mime类型默认被设置为application/x-javascript，也就是说对于js文件，使用的是动态内容压缩而不是静态内容压缩，因此会导致js文件有时经过压缩的，有时却没有压缩。
静态压缩及动态压缩的区别
IIS7中的HTTP压缩分为“静态内容压缩”和“动态内容压缩”，其实这两个名字第一次接触很费解。什么是动态内容什么又是静态内容？实际上，准确的翻译应该是“静态压缩”和“动态压缩”。这两个词反应了IIS的压缩行为。对于配置在staticTypes节中的mime类型，将会启用静态压缩，也就是说，当文件第一次被请求的时候，IIS会将其压缩，然后放入临时文件夹中，下次再有人请求此文件时直接从临时文件夹中取出压缩后的版本而不用重新执行压缩的过程。配置在dynamicTypes一节中的mime类型的http请求都将启用动态压缩，即每一次请求，主机都会对请求的内容——可能是存放在文件系统中的静态文件，也可能是ISAPI返回的内容——进行压缩，而不会对其进行缓存。这个压缩比率因主机性能不同而会有所调整，所以我们在请求js文件的时候才会发现js文件有时压缩有时不压缩的情况。
显而易见，静态压缩会占用一定的存储空间，但是速度快，而动态压缩不占用存储空间，但是占用CPU时间，而且压缩比不恒定。而对于经过ISAPI的请求，则不能使用静态压缩方式。例如对于WCF返回的内容。
一、目的
在使用CentOS6.3版本linux系统的时候，发现根目录(/)的空间不是很充足，而其他目录空间有很大的空闲，所以本文主要是针对现在已有的空间进行调整。首先，先来查看一下系统的空间分配情况：
1
2
3
4
5
6
7
8
| [root@CentOS-78 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_centos-lv_root
50G 14G 34G 30% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 37M 423M 8% /boot
/dev/mapper/vg_centos-lv_home
404G 670M 382G 1% /home |
下面的详细步骤部分将从vg_centos-lv_home分区下取出100G的空间添加到/vg_centos-lv_root分区上去。
二、详细步骤
1、卸载vg_centos-lv_home分区
1
2
3
4
5
6
7
8
9
10
11
12
| [root@CentOS-78 /]# umount /home
[root@CentOS-78 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_centos-lv_root
50G 14G 34G 30% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 37M 423M 8% /boot
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/mapper/vg_centos-lv_home' first. |
这一步设定vg_home-lv_home大小没有成功，系统提示我们先运行下面的命令，操作如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| [root@CentOS-78 /]# e2fsck -f /dev/mapper/vg_centos-lv_home
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg_centos-lv_home: 1386/26836992 files (0.9% non-contiguous), 1855856/107344896 blocks
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/vg_centos-lv_home to 73924608 (4k) blocks.
Begin pass 2 (max = 43)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 3276)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 266)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/mapper/vg_centos-lv_home is now 73924608 blocks long.
[root@CentOS-78 /]# mount /home
[root@CentOS-78 /]#
[root@CentOS-78 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_centos-lv_root
50G 14G 34G 30% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 37M 423M 8% /boot
/dev/mapper/vg_centos-lv_home
278G 663M 263G 1% /home
[root@CentOS-78 /]#
[root@CentOS-78 /]# lvreduce -L 282G /dev/mapper/vg_centos-lv_home
WARNING: Reducing active and open logical volume to 282.00 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lv_home? [y/n]: y
Reducing logical volume lv_home to 282.00 GiB
Logical volume lv_home successfully resized
[root@CentOS-78 /]# |
查看一下lv目前的情况
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| [root@CentOS-78 /]# vgdisplay
--- Volume group ---
VG Name vg_centos
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 465.27 GiB
PE Size 4.00 MiB
Total PE 119109
Alloc PE / Size 86472 / 337.78 GiB
Free PE / Size 32637 / 127.49 GiB
VG UUID 1k4ooN-RFV9-uyf1-uMYf-aERG-YaGs-ZNoSD6 |
Free PE / Size指定的应该是现在可在分配的空间。
4、增加vg_centos-lv_root分区的大小
将可用的空间添加到vg_centos-lv_root分区上面：
1
2
3
4
5
6
7
8
9
10
11
12
| [root@CentOS-78 /]# lvextend -L +127.40G /dev/mapper/vg_centos-lv_root
Rounding up size to full physical extent 127.40 GiB
Extending logical volume lv_root to 177.40 GiB
Logical volume lv_root successfully resized
[root@CentOS-78 /]#
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_root
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_centos-lv_root is mounted on /; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 12
Performing an on-line resize of /dev/mapper/vg_centos-lv_root to 46504960 (4k) blocks.
The filesystem on /dev/mapper/vg_centos-lv_root is now 46504960 blocks long. |
5、再次查看分区大小
1
2
3
4
5
6
7
8
| [root@CentOS-78 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_centos-lv_root
175G 14G 153G 9% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 37M 423M 8% /boot
/dev/mapper/vg_centos-lv_home
278G 663M 263G 1% /home |
我们发现vg_centos-lv_root分区的空间已经增加了125G，之所以比lv_home减少的空间要多25G主要是由于我们把系统所有的可用的空间都加在了lv_root分区。
三、所遇到的问题
1、在卸载/home目录的时候失败
可先执行如下fuser命令，然后再umount即可：
1
2
| [root@CentOS-78 /]# fuser -m /home
[root@CentOS-78 /]# |
2、设定完lv_home的大小，再次mount该分区时，发现用df命令无法看到给分区，此时只要在mount一次即可
3、在设定lv_root的大小时，不要把Free PE / Size的空间全部都用上，这很可能会出现Free PE空间不足的现象，建议保留一点Free PE的空间。
最近在研究一些深度学习框架和大数据可视化的应用，经常会编译一些文件，而yum的默认地址下载太慢，所以用国内比较稳定的阿里云源。
参考
http://mirrors.aliyun.com/help/centos?spm=5176.bbsr150321.0.0.d6ykiD
话不多说，上命令
1、备份
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
2、下载新的CentOS-Base.repo 到/etc/yum.repos.d/
CentOS 5
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repo
CentOS 6
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo
CentOS 7
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
3、之后运行yum makecache生成缓存
option http-server-close
假设你有一台HAProxy前端与十个不同的后端通信，且这十个后端不支持HTTP keep-alive。这个设置让HAProxy在客户端和前端之间保持一个持久的连接，并在所有后端服务器之间轮询HTTP请求。当然，要发挥这个设置的功效的话需要客户端同样启用keep-alive。
timeout client 30s
timeout server 30s
这两个设置一起用来设置 HAProxy发送请求的超时时长。实际上，HAProxy等待服务器返回信息给客户端需要多久呢？大多数应用都有某种最大延迟时间，因此你需要添加超时时长。对我们来说，API等待响应的最长时间是30秒，所以每个内部服务根据自身的服务级等级协议（SLA）都应该设置低于30秒的超时时长。注意：如果服务器缓慢地以流的方式传输一个字节，也就是每29秒传输一个字节的话，你将不能触发读超时，所以你可能需要有一个单独的线程监控这样的请求，以保证在适当的时间内完成传输。你还应当把客户端和服务端的超时时长设置为相同的值-即套接口上所期望的读超时时长。
timeout connect 3100
这是一个不同于客户端和服务端超时时长的超时时长！它是HAProxy应当用来试图连接主机所花费的时长。在RWilio以前的日子里，它设置为与服务器超时时长30秒相同的值，因此如果主机宕机的话，HAProxy将试图连接同一个主机30秒。当服务器和客户端主机位于同一个机器上或者在同一个局域网内（或者AZ主机的附近）的时候，这样的连接通常发生在毫秒级。我们允许在进一步处理默认的重传窗口时等待3秒，并且允许有小量的缓冲。
不像服务器超时时长，连接超时时长隐含着客户端的重新连接请求是安全的这层意思。
retries 2
option redispatch
当我说30秒的连接超时时长意味着HAProxy将在30秒内试图进行一次未连接上的连接的时候，我撒谎了。实践证明： 默认情况下,HAProxy将试图进行3次连接请求。因此30秒的连接超时实际上是120秒的连接超时，这违反了服务级别协议，而且意味着我们给客户兑现的是空头支票。
如果第一台主机关机了，那么通常假设HAProxy自动给第二台主机发送请求。不过这仅仅在HAProxy对这个主机进行健康检查后并标记这台主机已经关机的情况下才是这样的。如果一台主机关机了而且对它的健康检查花费了20秒，那么这时你正在对这台主机进行可能的20秒的无效请求。重新分发选项让最终的连接请求发送给另一台下游主机上，因此不同主机发送各自的请求在某种程度上保护了已经不健康的主机。
这两个设置混合在一起缩减重试次数到2，并且这也意味着在放弃这个连接并对另一台主机进行连接之前，我们试图对这台主机进行连接的最大超时时长只有8秒。
option httpchk GET /healthcheck
默认情况下，HAProxy只是对主机打开了一个TCP连接来检查这台主机是否启动。这种ping只能检测这台主机是否关机，不过不能确定它是不健康的（磁盘损坏，网络连接不正常）。httpchk选项将给位于后端的终端节点发送HTTP请求。后端可以进行自检，并回答自身是否健康。注意健康检查应当是相当保守的一种做法，而且通常还扩大了单台主机健康的范围。健康检查未通过将使HAProxy给这台主机不发送任何包，而且如果所有的主机同时都“不健康”，那么你将没有任何后端可依赖了。 我希望这篇文章对你有帮助-我已经在 这儿发布了HAProxy配置的所有更新版本。至于其他问题， 可以阅读手册，这样可以让服务器在性能、可靠性、可用性和稳定性方面得到很大的提高。希望这篇概览能够节省你的时间。
