记得一年前发现很多手机上传的照片经过打水印后会损坏图片，后来经过多方搜索，终于找到了解决方案，当时解决后就没做一下记录，时隔一年，终于又要用到，可一时找不到解决方法，突然想起当年打包（rpm）时还留下源码，于是去jpeg-6b下的源代码进行md5比对，终于找到jdmarker.c该文件做过一些修改，赶紧记录：
修改如下：
/*
* WARNMS2(cinfo, JWRN_EXTRANEOUS_DATA, cinfo->marker->discarded_bytes, c);
*/
其实就是注释掉这段代码而已。
做DNS要更新各SP的网段，下面简单的总结一下早上获取教育网的经过。
其实很简单，首先去教育网官方去获取最新的IP段：
只要下载：http://www.nic.edu.cn/RS/ipstat/ 这个url里的数据，然后进行分析（可惜这个url必须在教育网内才可以正常访问）。
内容如下：
web 2.0海量小文件cache集群探讨(原创)
msn:gusingchen@hotmail.com
在互联网快速发展的背景下，特别是we2.0，网络上的数据内容呈几何级的增长，而其中增长最快并且最容易给技术架构带来挑战的就是数目庞大的小文件，如 何来解决这种高并发，大流量，小文件，热点不集中的问题，经过我们大量研究，实践之后，总结出这种海量小文件，高并发所存在的关键问题和解决方案。
我们先对比一下在web1.0的解决方案和web2.0的我们碰到的困难。
Web1.0
1、源数据量小，单台squid即可达到很高的命中率。
2、请求量大，用lvs+squid或者dns轮询即可解决问题。
3、squid服务器磁盘IO压力大，用超大内存做cache。
web 2.0
目前的瓶颈:
1、源数据数量很大，导致squid hash table 索引效率不高，Cache 命中率低。
为了提高对文件的访问效率，往往会在前端配置一个稍大容量的缓存。但由于小文件的数量极其庞大，应用对这些文件访问的随机性非常高，使得Cache 命中率极低，缓存失去了应有的作用，导致应用需要直接到后端存储系统上读取数据，给存储系统带来了极大的压力。刚开始就是我们也采用了昂贵的高端存储系统 NetApp，但是在用户高并发访问的情况下，存储系统经常出现长时间无响应的严重故障。
2、源数据容量巨大，海量文件检索效率低，从而也导致单台squid命中率很低。
有些频道数据容量会超过200T，单台squid只是杯水车薪，频繁的cache置换更是加剧了cache效率低下，再加上现有的存储系统无法有效管理海 量小文件，并且在单个目录下存放文件的数量有一定的限制，一旦文件数到达了一定规模之后，文件的检索速度就急剧下降。我们只能通过多级目录来组织存放大量 的小文件，随着目录深度的增加，文件的检索开销进一步增大，检索效率随之下降。
3、大量的cache导致的磁盘IO问题
由于目前单台cache容量已经达到上百G，文件系统瓶颈、磁盘IO问题也很快凸显。
4、压力过大导致的hit ratio抖动
cache 删除，写操作达到一定的比例,同时如果压力较高，会导致hit ratio呈线性下降。即使cache没down，但也因为命中率的下降而失去应有的作用。
5、特殊集群下的单台失效问题
在类url hash的集群下，单台cache失效会导致hash rehash，那么整个集群的squid命中率都会被冲击。
如何来解决这些问题，思路如下：
1、优化squid hash table 索引算法,
需要修改源squid代码
2、cache集群，用类url hash的方法，以增加cache容量
1)、wccp: cisco的路由器均有此功能
2)、carp: ISA,squid自身的7层调度协议
3)、url hash: nginx haproxy等7层代理
3、选择合适的文件系统
XFS使用更多的内存来作为自己的高速缓存，以尽可能的延迟零散的写操作，尽可能的执行批量写操作。
4、选择更合理的磁盘搭配策略，比如Raid策略或者单盘策略等
Raid 5，10 带来了不错的安全性，但是会导致磁盘IO效率低下，不做Raid的单盘性能最高，更适合单台服务器多squid进程模式。
5、集群下的单台cache失效的接管，以免单点故障，提高可用性。
针对以上分析，我们大量尝试了开源的一些产品，像LVS，Nginx，Squid，XFS等。
具体的软件组合和架构如下：
（1）、web服务器的选择，目前，大多数web服务器的处理能力有限，互联网广泛上使用的web服务器如Apache，其并发能力往往在2000以下， 这是由web服务器自身的设计模式（如多进程，无IO缓存等）决定的。因此，在较大规模的访问情况下，通常会表现出用户访问网站慢，web 服务器负载高。为什么选择Nginx? use linux epoll, sendfile and aio to improve the performanc，我们主要利用的是Nginx的第三方模块ngx_http_upstream_hash_module做反向代理。
部分代码如下：
upstream img{
server squid1:81;
server squid2:81;
hash $request_uri;
hash_again 0; # default 0
hash_method crc32; # default “simple”
}
server {
listen 80;
server_name images.gx.com;
location / {
proxy_pass http://img;
(３)负载均衡软件，我们选择了LVS+HA，用DR模式。目前我们运行环境中的LVS（2.6的内核），普通很稳定。我们主要用Heartbeat+ldirectord。
(4) 适合处理小文件的文件系统XFS。XFS 最佳表现之一在于：象 ReiserFS 一样，它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据，并且，通常仅当内存不足时，才会命令将数据写到磁盘时。当它将数据清仓（flushing）到磁盘时，其它 IO 操作在很大程度上似乎不受影响。
(5)其它优化
在客户端和服务器做大量有效的缓存策略;用更小的并且可缓存的图片（单张图片尽量不要超过200K）;尽量减少http请求;开起 keepalive减少tcp连接开销;优化tcp参数;起用多域名分域名策略;减少cookie影响等。
(6)关于优化题外：大配置和架构没有问题的前提下，有money的话应该首选硬件优化方案而不是软件细节优化。
整个架构如下图
后端存储垂直分割的规则如下(按00-ff散列)：
location ~ ^/[0-1][0-f]/ {
proxy_pass http://192.168.3.12;
}
location ~ ^/[2-3][0-f]/ {
proxy_pass http://192.168.3.11;
}
……..
以上这个架构的优化在于：
实现了高可用性，最大程度上防止单点，又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。
充分发挥机器的性能，架构可扩展性，层次分明。
最后，很重要的二点，1）要通过性能分析和监控，来找到系统瓶颈的临界点和薄弱点。监控分析是一切优化的重点，要以数据事实来调整策略。2）架构的负荷如果已经超过设计负荷的5~10倍，就要考虑重新设计系统的架构，我们这里仅仅讨论某一阶段的架构设计。
部份资料来源http://bbs.be10.com,http://www.dbanotes.net,http://ourlinux.net,特别感谢http://jsqyy.51.com,他在squid方面深有研究。
推荐一个站点：http://www.websiteoptimization.com/services/analyze/
可以分析网页的执行效率同时会给出诸多改进的地方，不错！
感谢laurence的推荐:)
3、4年前热衷架设yum和apt服务器，过后很久没在做过，现在都忘了，今天因为要用到，所以就做个笔记：
yum-3(印象中yum-2以前)以前是用：yum -arch /opt/rhel/rpms/ 来建立repo。
yum-3以后建立repo必须用createrepo：
rpm -Uvh createrepo-0.4.11-3.el5.noarch.rpm
createrepo -v /opt/rhel/5.2/os/
cat /etc/yum.repos.d/rhel.5.2.repo
[os]
name=Server1 Server Repository
baseurl=http://apt.ourlinux.net/rhel/5.2/os/
#baseurl=file:///opt/rhel/5.2/os/
gpgcheck=0
英文地址：http://developer.yahoo.com/performance/rules.html
中文地址：http://www.dudo.org/article.asp?id=218
我们在前面的几节中分别讲了提高网站性能中内容、服务器、JavaScript和CSS等方面的内容。除此之外，图片和Coockie也是我们网站中几乎不可缺少组成部分，此外随着移动设备的流行，对于移动应用的优化也十分重要。这主要包括：
Coockie:
图片：
移动应用：
英文地址：http://developer.yahoo.com/performance/rules.html
中文地址：http://www.dudo.org/article.asp?id=216
在第一部分和第二部分中我们分别介绍了改善网站性能中页面内容和服务器的几条守则，除此之外，JavaScript和CSS也是我们页面中经常用到的内容，对它们的优化也提高网站性能的重要方面：
CSS：
JavaScript
英文地址：http://developer.yahoo.com/performance/rules.html
中文地址：http://www.dudo.org/article.asp?id=215
在本系列的第一节中，讲了提高网站性能中网站“内容”有关的10条原则。除了在网站在内容上的改进外，在网站服务器端上也有需要注意和改进的地方，它们包括：
英文地址：http://developer.yahoo.com/performance/rules.html
中文地址：http://www.dudo.org/article.asp?id=214
Yahoo!的Exceptional Performance团队为改善Web性能带来最佳实践。他们为此进行了一系列的实验、开发了各种工具、写了大量的文章和博客并在各种会议上参与探讨。最佳实践的核心就是旨在提高网站性能。
Excetional Performance团队总结出了一系列可以提高网站速度的方法。可以分为7大类34条。包括内容、服务器、cookie、CSS、JavaScript、图片、移动应用等七部分。
其中内容部分一共十条建议：
一、内容部分