Skip to content

优化 tomcat session和thread

Server Information
Tomcat Version :Apache Tomcat/6.0.16
JVM Version :1.6.0_10-beta-b24
JVM Vendor :Sun Microsystems Inc.
OS Name :Linux
OS Version :2.6.9-5.ELsmp
OS Architecture :i386

问题
应用为lucene全文搜索;
当php的缓存失效时会带来大量不经过squid的请求，导致半天搜索结果不出来，php占用大量cpu，系统一直满负载

解决方法
1.增加php缓存时间同时加上随机时间让请求分散
2.增加tomcat的并发能力

首先打开tomcat的管理功能方便查看状态
编辑conf/tomcat-users.xml增加用户






重启tomcat
请求http://localhost:8080/manager/html
可以看到当前各应用的session数，内存占用，线程数…

优化1:减少session生命周期
编缉conf/web.xml将默认的30分钟改成5分钟


5


也可以编辑各应用下的web.xml针对应用进行调整

优化2:增加线程数
编辑conf/server.xml,修改默认40到100


优化3:增加内存
优化tomcat 内存

优化后server status
JVM
Free memory: 589.87 MB Total memory: 1162.43 MB Max memory: 1162.43 MB
http-8080

Max threads: 100 Current thread count: 26 Current thread busy: 6
Max processing time: 7545 ms Processing time: 4180.072 s Request count: 14471 Error count: 142 Bytes received: 0.00 MB Bytes sent: 297.62 MB

Posted in Tomcat, 技术.

Tagged with , , .

rev="post-796" No comments

By C1G – 2009/08/04

linux 下安装 subversion(svn) 客户端

svn server 为只支持http://协议的windows;
test web server 为as4,现需安装svn客户端方便同步代码

网上找了下都是讲如何安装svn server的，我只需要一个支持http协议的客户端哈，不想装apache。

安装所需软件
apr,apr-util,sqlite,neon,subversion

1.下载软件

wget http://labs.xiaonei.com/apache-mirror/apr/apr-1.3.7.tar.gz
wget http://labs.xiaonei.com/apache-mirror/apr/apr-util-1.3.8.tar.gz
wget http://www.sqlite.org/sqlite-amalgamation-3.6.16.tar.gz
wget http://www.webdav.org/neon/neon-0.28.4.tar.gz
wget http://subversion.tigris.org/downloads/subversion-1.6.3.tar.bz2

2.安装apr

tar zxvf apr-1.3.7.tar.gz
cd apr-1.3.7
./configure -prefix=/usr/local/apr
make
make install
cat /etc/ld.so.conf
echo /usr/local/apr/lib >> /etc/ld.so.conf

3.安装apr-util

tar zxvf apr-util-1.3.8.tar.gz
cd apr-util-.1.3.8
./configure –prefix=/usr/local/apr-util –with-apr=/usr/local/apr/
make
make install
echo /usr/local/apr-util/lib >> /etc/ld.so.conf
ldconfig -v

4.安装sqlite

tar zxvf sqlite-amalgamation-3.6.16.tar.gz
cd sqlite-3.6.16/
configure –prefix=/usr/local/sqlite
make
make install

5.安装neon
不需要支持http协议可以略掉安装

tar zxvf neon-0.28.4.tar.gz
cd neon-0.28.4
./configure –prefix=/usr/local/neon –enable-shared
make
make install

方式二:解压后重命名为neon,移动至subversion编译目录
但subversion编译时好像找不到neon
报错如下

configure: checking neon library

An appropriate version of neon could not be found, so libsvn_ra_neon
will not be built. If you want to build libsvn_ra_neon, please either
install neon 0.28.4 on this system

or

get neon 0.28.4 from:
http://www.webdav.org/neon/neon-0.28.4.tar.gz
unpack the archive using tar/gunzip and rename the resulting
directory from ./neon-0.28.4/ to ./neon/

no suitable neon found

6.安装subversion

tar -jxvf subversion-1.6.3.tar.bz2
cd subversion-1.6.3
./configure –prefix=/usr/local/svn –with-apr=/usr/local/apr –with-apr-util=/usr/local/apr-util –with-sqlite=/usr/local/sqlite –with-neon=/usr/local/neon
make
make install

7.检查测试
安装后应该有三个模块

/usr/local/svn/bin/svn –version
svn，版本 1.6.3 (r38063)
编译于 Jul 30 2009，14:31:41

版权所有 (C) 2000-2009 CollabNet。
Subversion 是开放源代码软件，请参阅 http://subversion.tigris.org/ 站点。
此产品包含由 CollabNet(http://www.Collab.Net/) 开发的软件。

可使用以下的版本库访问模块:

* ra_neon : 通过 WebDAV 协议使用 neon 访问版本库的模块。
– 处理“http”方案
* ra_svn : 使用 svn 网络协议访问版本库的模块。 – 使用 Cyrus SASL 认证
– 处理“svn”方案
* ra_local : 访问本地磁盘的版本库模块。
– 处理“file”方案

导出项目

cd /opt/srv/
/usr/local/svn/bin/svn export –username c1g –password 123456 http://192.168.1.9/pub37

参考：
http://www.9say.com/2009/04/subversion-compile-with-ra-dav/

Posted in Subversion.

Tagged with , , .

rev="post-793" No comments

By C1G – 2009/07/30

redhat 系统内存为8G时，SWAP如何划分？

目前Red Hat推荐交换分区的大小应当与系统物理内存的大小保持线性比例关系。不过在小于2GB物理内存的系统中，交换分区大小应该设置为内存大小的两倍，如果内存大小多于2GB，交换分区大小应该是物理内存大小加上2GB。其原因在于，系统中的物理内存越大， 对于内存的负荷可能也越大。

但是，如果物理内存大小扩展到数百GB，这样做就没什么意义了。

实际上，系统中交换分区的大小并不取决于物理内存的量，而是取决于系统中内存的负荷。Red Hat Enterprise Linux 5可以在这样的情况下工作：完全没有交换分区，而且系统中匿名内存页和共享内存页小于3/4的物理内存量。在这种情况下，系统会将匿名内存页和共享内存页锁定在物理内存中，而使用剩余的物理内存来缓冲文件系统数据(pagecache)，当内存耗尽时， 系统内核只会回收利用这些pagecache内存。

考虑到以下情况：

1）安装系统时难以确定内存的负荷，如何设置交换分区大小

2）系统中物理内存越大，所需交换分区就会越少

因此，在Red Hat Enterprise Linux 5中，以下是设置合适的交换分区大小的规则：

小于等于4G物理内存的系统，至少设置2GB的交换分区

4G～16G物理内存的系统，至少设置4GB的交换分区

16G～64G物理内存的系统，至少设置8GB的交换分区

16G～256G物理内存的系统，至少设置16GB的交换分区

参考:
http://kbase.redhat.com/faq/docs/DOC-17162

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s2-diskpartrecommend-x86.html

Posted in LINUX, 技术.

Tagged with , .

rev="post-791" No comments

By C1G – 2009/07/27

解决dreamhost上传速度缓慢问题

dreamhost的下载速度还行，但是上传实在太慢了，
今天要传些文件到服务器，速度据然只有2～4K。。。
传了半天，中间又断了次。。。哭死

解决方法是先把文件上传到国外的中传服务器再wget回来
FileUrls提供上传一个文件，设置到期的期限（最长7天），给你一个下载链接，如果你需要的话可以为这个文件加上密码。

具体方法：
1.先把本地文件打包成xxx.zip
2.把xxx.zip上传至http://fileurls.com 上传大概有几十K
3.得到一个可以直接下载的url,在dh上wget http://fileurls.com/download.ashx?id=kprgdd

HTTP request sent, awaiting response… 200 OK
Length: 5,306,368 [application/octet-stream]

100%[==========================>] 5,306,368 227.49K/s ETA 00:00

02:54:39 (287.06 KB/s) – `download.ashx?id=kprgdd’ saved [5306368/5306368]

4.unzip xxx.zip
完成

Posted in Tools, 其它.

Tagged with , .

rev="post-787" No comments

By C1G – 2009/07/11

Nginx设置 Uchome 二级域名

UCenter Home 是一套康盛创想构建的社会化网络软件。

uchome域名为home.c1gstudio.com,其实应该算是开启三级域名了

1.在域名控制台增加a记录

*.home.c1gstudio.com ->ip

2.nginx server_name增加泛解析
nginx.conf

server_name home.c1gstudio.com *.home.c1gstudio.com;

检查配置文件语法
/opt/nginx/sbin/nginx -t
然后重启(lemp是自已写的控制脚本)
/opt/lemp reloadnginx

3.uchome后台开启二级域名功能
二级域名根域名里写”home.c1gstudio.com”
缓存更新
在个人用户里设置二级域名，过一会就可以访问了。
如：abc.home.c1gstudio.com会跳转到home.c1gstudio.com/space.php?domain=abc

参考:http://wiki.nginx.org/NginxChsHttpCoreModule

Posted in Nginx, 技术.

Tagged with , , .

rev="post-785" No comments

By C1G – 2009/07/10

Five Minutes程延辉 介绍开心农场架构

Five Minutes 公司程延辉（小名康天） 介绍开心农场架构，social game的技术挑战，支持千万级DAU的social game技术架构。这是一个对于开发者来说，非常精彩，非常有实用性指导的一次演讲，详细介绍了很多技术内幕。

Five Minutes 公司的著名social game 开心农场，目前非常受用户欢迎，包括国外的Facebook，国内的开心网都是如此，是全球最大的social game，台下热烈掌声。呵呵。开心农场这个游戏从介绍看，相当成功，最早是08年9月在xiaonei上线，而后在51等平台推广，包括Facebook。现在已经有1570万游戏用户了，其中包括50万的Facebook用户。

开心农场架构主要难点：1。如何存储大规模的用户数据千万级2。如果应对大量访问每天数亿请求量3。如果应对数据的频繁修改，每秒数万次数据修改。

解决的方式

优化：

1。负载均衡，web服务器平行扩展。

2。服务器性能优化。

3。异步处理，缓存数据接口，Linux内核参数优化，挖掘PHP的效率，用fastcgi模式运行php，用EAccelerator加速。固定不变数据做成php配置文件，用C开发PHP扩展等。

数据库性能优化：

1。数据库分库分表，所有数据全部设计成 key－》value形式，不用join。

2。使用INNODB，经常操作的数据表中所有字段尽量设计成数值型，用update替代INSERT和DELETE操作

异步处理：整个系统最关键的部分，

原则：把客户端暂时不需要的数据进行异步处理。

实例：讲非核心数据先写入memcached，异步更新到数据库，合并数据库更新操作，Feed和Notification的异步发送。

利用客户端资源：Flash屏蔽重复操作和不必要请求，Flash进行一些计算减轻服务器的复旦，例如好友排序等。Flash缓存一些数据。

social game ＝ social ＋ game。实时互动（大负载）和非实时互动（大负载）。

服务器角色：场景服务器，逻辑服务器，admin服务器，gateway，架构逻辑还是挺复杂的，每天处理亿级请求的架构，完全和百万级不一样！完全能够通过平行扩展的方式应对，gateway和场景服务器都完全可以增加。

Blue Whale是他们们正在开发的解决长连接的social game架构。

开心农场在现场招聘：需要C++,Python， Flash AS3程序员。

程延辉的演讲获得了在场热烈的掌声。
下载演讲ppt：Social Game的技术挑战.ppt

 

原文：http://blog.sina.com.cn/s/blog_6051dbbb0100du27.html

Posted in 技术, 网站架构.

Tagged with , , .

rev="post-781" 4 comments

By C1G – 2009/07/05

Twitter，架构的变迁[转]

Evan Weaver是Twitter服务团队的总工程师，他的主要工作是优化与伸缩性。在QCon London 2009上，他谈到了Twitter的架构，特别是在过去一年当中为提升Web站点性能所执行的优化。

Twitter使用的大部分工具都是开源的。其结构是用Rails作前端，C，Scala和Java组成中间的业务层，使用MySQL存储数据。所有的东西都保存在RAM里，而数据库只是用作备份。Rails前端处理展现，缓存组织，DB查询以及同步插入。这一前端主要由几部分客户服务粘合而成，大部分是C写的：MySQL客户端，Memcached客户端，一个JSON端，以及其它。

中间件使用了Memcached，Varnish用于页面缓存，一个用Scala写成的MQ，Kestrel和一个Comet服务器也正在规划之中，该服务器也是用Scala写成，当客户端想要跟踪大量的tweet时它就能派上用场。

Twitter是作为一个“内容管理平台而非消息管理平台”开始的，因此从一开始基于聚合读取的模型改变到现在的所有用户都需要更新最新tweet的消息模型，需要许许多多的优化。这一改动主要在于三个方面：缓存，MQ以及Memcached客户端。

缓存

每个tweet平均被126个用户跟踪，所以这里有着明显的缓存需求。在最初的配置中，只有API有着一个页面缓存，当每次从一个用户那里来了一个tweet时就会失效，而应用的其它部分都是无缓存的：

image

第一个架构改动是创建一个直写式向量缓存包含了一个tweet ID的数组，tweet ID是序列化的64位整数。这一缓存的命中率是99%。

第二个改动是加入另一个直写式行缓存，它包含了数据库记录：用户和tweets。这一缓存有着95%的命中率并且使用了Nick Kallen的名为Cache Money的Rails插件。Nick是Twitter的一名系统架构师。

第三个改动是引入了一个直读式的碎片缓存，它包含了通过API客户端访问到的tweets的序列化版本，这些tweets可以被打包成JSON，XML或者是Atom的格式，有着同样是95%的命中率。这一碎片缓存“直接消费向量，而且如果现在缓存了一个序列化的碎片，它不会加载你试图看到的该tweet的实际的行，因此它将在大量时间将数据库置于短路状态，”Evan这样说到。

还有另一个改动是为页面缓存创建一个单独的缓存池。根据Evan的说法，该页面缓存池使用了一个分代的键模式，而不是直接的失效，因为用户可以

发送HTTP的if-modified-since并且将任何他们想要的时间戳放入请求路径，我们需要将这一数组切片并只呈现给他们他们想要看到的tweets，但我们不想跟踪客户端所使用的所有可能的键值。这一分代的键模式有一个大问题，在于它不会删除所有失效的键值。每一个被加入的对应到人们所接收的tweets数目的页面都会向缓存推送有效的数据，最后变得我们的缓存仅仅只有五个小时的有效生命周期，因为所有的页面缓存都将流过。

当该页面缓存转移到其自己的池之后，缓存未命中降低了将近50%。

这是Twitter现在所使用的缓存模式：

image

因为80%的Twitter流量都来自API，因此还有额外的二层缓存，每一个最多将处理95%来自前一层的请求。整体的缓存改动总共有百分之二三十的优化，它带来了

10倍的容量提升，它本可以更多，但现在我们遇到了另一瓶颈…我们的策略是首先加入直读式缓存，确保它正确失效，然后再转移到直写式缓存并且在线修复，而不是当一个新的tweet ID进来时每次都要销毁。

消息队列

因为，平均来说一个用户有126个追随者，这就意味着每个tweet将有126个消息在队列里。同时，流量会有出现高峰的时候，就像在奥巴马就职的时候达到了每秒几百个tweet或者说是成千上万的消息在队列里，是正常流量的3倍。MQ应当去化解这一高峰并随着时间将其分散，这样就不用增加许多额外的硬件。Twitter的MQ很简单：基于Memcached的协议，job之间是无序的，服务器之间没有共享的状态，所有的东西都保存在RAM里，并且是事务性的。

第一版的MQ实现是用的Starling，以Ruby写成，伸缩性不佳，特别是Ruby的GC不是分代的。这将导致MQ在某一点上崩溃，因为GC完成工作时将会把整个队列处理中止。因此作出了将MQ移植到Scala上的决定，它有着更为成熟的JVM GC机制。现有的MQ仅仅只有1200行代码并且运行在3台服务器上。

Memcached客户端

Memcached客户端的优化目的是试图优化集群负载。现在的客户端用的是libmemcached，Twitter是其最重要的用户和其代码库最重要的贡献者。基于此，持续一年的碎片缓存优化带来了50倍的每秒页面请求服务增加。

image

因为请求来自的位置难以确定，处理请求最快的办法就是将预先计算好的数据存储在网络RAM上，而不是当需要的时候在每个服务器上都重新计算一次。这一方式被主流的Web 2.0站点所使用，它们几乎都是完全直接运行于内存之上。根据Evan的说法，下一步就是“既可伸缩的读持续了一年之后，(解决)可伸缩的写，然后就是多协同定位的问题”。

这一QCon的演示文件发布在Evan的站点上。

中文原文:http://www.infoq.com/cn/news/2009/06/Twitter-Architecture

查看英文原文：Twitter, an Evolving Architecture

Posted in 技术, 网站架构.

Tagged with , .

rev="post-778" No comments

By C1G – 2009/07/01

豆瓣网技术架构变迁[转]

概要
罗马不是一天建成的，豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中，豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

个人简介
洪强宁，2002年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度最佳技术应用网站。

关于会议
QCon全球企业开发大会（QCon Enterprise Software Development Conference）是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会，每年在伦敦、旧金山、北京、东京召开。自2007年3月份在伦敦召开首次举办以来，已经有包括金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

详细内容:

http://www.infoq.com/cn/presentations/hongqn-douban

Posted in 技术, 网站架构.

Tagged with , .

rev="post-776" No comments

By C1G – 2009/07/01

主流手机分辨率介绍[转]

我们的手机现在主要有两种分辨率： 220×176(?)、320×240(QVGA)。以后新的手机可能会有640×480(VGA)的分辨率。
220×176的分辨率到底叫什么？确实，查遍相关的资料也无法得知此规格的定义，查过ARM的一些资料，OV系列的一些资料等……应该认为220×176是非标准分辨率规格。
看到现在网络上以及我们论坛内对220×176的错误称谓，我觉得有必要统一一下该规格的称呼了……其实规定都是人定义的么，叫的多了就大家认同了……
 
不过，定义该规格时也必须要有充足的依据，现在，我把我对该系列的定义阐述如下：
1.       我们先来列举一下需要引用的几个分辨率规格：
规格                  宽           高          宽高比        像素点
QQCIF               88           72          1.2222          6336
Sub-QCIF         128          96          1.3333          12288
QQVGA            160         120         1.3333          19200
QCIF                 176          144         1.2222          25344
？                       208         176         1.1818          36608
？                       220         176         1.2500          38720
？                       240         176         1.3636          42240
QVGA                320         240         1.3333          76800
CIF                     352         288         1.2222          101376
VGA                   640         480         1.3333          307200
SVGA                 800         600         1.3333          480000
XGA                  1024        768         1.3333          786432
WXGA              1280        800         1.6000         1024000
UVGA                1280        960         1.3333         1228800
SXGA                1280        1024       1.2500         1310720
SXGA+              1400        1050       1.3333         1470000
USVGA              1600        1200       1.3333         1920000
WSUVGA+        1920       1080       1.7888         2073600
WSUVGA          1920       1200       1.6000          2304000
SUVGA               1920       1440       1.3333         2764800
UXGA                 2048       1536       1.3333         3145728
UWXGA             2560       1600       1.6000      4096000
USXGA               2560       2048       1.2500      5242880
上面的系列像素点相互的关系：
VGA＝QVGA*4=QQVGA*4*4;
CIF=QCIF*4=QQCIF*4*4;
Sub-QCIF大约是1/8CIF，近似等于1/2QCIF。
 
2.       所以再根据精确比对和计算后，可以看出220×176和VGA系列比较容易匹配。其关系是：
220×176近似等于1/8的VGA，近似等于1/2的QVGA。因此可以看做是Sub-QVGA
 
3.       在我们确定了220×176为Sub-QVGA的规格后，我们参考了其他的分辨率定义方案，又定义了以下两个分辨率名称：
  208×176(Sub-QVGA-)
  240×176(Sub-QVGA+)
 
4.       最后我们将以上定义的三个非标准分辨率名称(这几个都是现在主流的，但是非标准规格)，整理如下：
规格                    宽           高          宽高比        像素点
Sub-QVGA-       208         176         1.1818          36608
Sub-QVGA         220         176         1.2500          38720 
Sub-QVGA+       240         176         1.3636          42240
 
名词缩写解释：
  VGA：              Video Graphics Array
  QVGA：           Quarter Video Graphics Array
  QQVGA：        Quarter QVGA
  Sub-QVGA：   Sub Quarter QVGA
  CIF：                Common Intermediate Format
  QCIF：             Quarter Common Intermediate Format
  QQCIF：          Quarter QCIF
原文:http://blog.chinaunix.net/u/25864/showart_240954.html

Posted in Wap, 技术.

Tagged with , .

rev="post-773" No comments

By C1G – 2009/06/30

移动web设计：标准的选择[转]

移动web（mobile web）？WAP？
大家都说WAP，为什么我说移动web？主要是想和以前的某些习惯区分开来，首先，复习一下定义：
WAP：无线应用协议，是在无线网络环境中应用层通讯的一个开放国际标准，主要用于手机等移动设备访问国际互联网。而WAP网站则是使用WML编写的网站的俗称。
移动web：是指可以用移动设备访问的WWW内容、应用和服务。

很明显，移动web应该包含了WAP。所以，我把能用移动设备访问的网站或应用称为移动web。

开发标准
移动web是客户端技术，如果要开发移动网站，自然我们需要选择一款合适的标准语言。主要技术标准有：

  • WML——古典的移动web标准，使用WML
  • i-mode——一个小日本的标准，使用iHTML，我们可以忽略
  • OMA领导的xHTML mobile profile，使用xHTML
  • W3C领导的xHTML Basic，使用xHTML
  • 以及所谓的Full Web，也就是普通的HTML——从iPhone开始流行起来

他们的演进如下：

目前仍在演进的，就是有HTML, 和XML了（Flash Lite另外讨论）。

技术特点还是贴图直观一点，我用网易来举例：

WML：代码紧凑，适合无线传输，被良好的支持，有许多移动特性。但是需要独立开发，实现样式困难。


xHTML：适合无线传输，被广泛地支持，易于开发，易于界面设计，mobile profile有部分移动特性。



Full Web：适合桌面习惯，丰富的表现，不过需要设备有大量内存和渲染能力，传输比较慢。

支持情况：

  • wml：可以接入互联网的手机都支持（除了iPhone），而MID和上网本默认情况下不支持。
  • xHTML mp：近代手机都支持，只要拥有256色以上的屏幕的手机是绝对支持的，MID和桌面电脑也支持。
  • xHTML Basic：近代手机都支持，如果支持到它的设备，mobile profile页面也能良好的渲染，MID和桌面电脑也支持。
  • Full Web：近几年的设备支持，一般是智能机和较主流的设备，例如操作系统是Symbian, Mac OS, windows, Android等的设备以及部分第三方浏览器如Opera, Fennec, Skyfire等等。

如果

如果你有如下条件，使用wml：

  • 面向所有年代的手机都要有良好的兼容
  • 界面效果要求不高
  • 极小的数据传输
  • 额外的wml编写经验

如果你有如下条件，使用xHTML：

  • 面向近几年的移动设备和桌面设备
  • 需要良好的移动界面
  • 较小的移动数据传输带宽
  • 要求丰富的多媒体内容

如果你有如下条件，使用Full Web：

  • 面向高机能的智能设备
  • 没有时间开发移动版本的内容
  • 大量的带宽
  • 不要求移动特性

当然上面的条件有点以偏概全了，不代表必须这样做。还是要根据实际情况，决定使用合适的技术标准。

转自:http://bbs.blueidea.com/thread-2920054-1-1.html

Posted in Wap.

Tagged with , .

rev="post-770" No comments

By C1G – 2009/06/30