用ps -eLf | grep java | wc 查看系统里运行的java线程数
用top H可以按线程排序CPU和内存的占用及相应的线程ID
用killall -3 (unix only) 或 jstack -l 可以Dump出Java的线程，然后根据线程ID（转换成16进制后对应thread dump的nid）查看线程的堆栈

安装脚本

#!/bin/sh
apt-get install rsync xinetd

sed -in-place -e s/RSYNC_ENABLE=false/RSYNC_ENABLE=inetd/ /etc/default/rsync

cp rsync /etc/xinetd.d/rsync
cp rsyncd.conf /etc/rsyncd.conf
cp rsyncd.secrets /etc/rsyncd.secrets
chmod 600 /etc/rsyncd.secrets
/etc/init.d/xinetd restart

配置文件内容如下：
rsync


service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
log_on_failure += USERID
}


rsyncd.conf


max connections = 2
log file = /var/log/rsync.log
timeout = 300

[etc]
comment = etc
path = /etc
read only = no
list = yes
uid = root
gid = root
auth users = user
secrets file = /etc/rsyncd.secrets

rsyncd.secrets


user:pass


使用方法：

rsync -tvzrp –password-file ./rsync.password  /etc/hosts user@dest_host::etc

如果代码文件里即有GBK又有UTF-8编码，且又没有enca的情况下，可以用shell，iconv，php稍微搞一下：

1）用PHP写一个测试文件编码的小程序
vi ~/bin/detect_encoding

#!/usr/bin/php -n
<?php

$file=fopen(‘php://stdin’,'r’);
$s = ”;
while (!feof($file)) {
$buffer = fgets($file,4096);
$s.=$buffer;
}
fclose($file);
echo mb_detect_encoding($s,”ASCII,UTF-8,GBK”);

2 )  找出所有GBK编码的文件：
for f in `find . -name “*.java”`; do ~/bin/detect_encoding < $f; echo ” $f”; done | grep CP936 | cut -b 6- > tmp_list

3）用iconv批量转
for i in `cat tmp_list`; do iconv -f GBK -t UTF-8 $i > tmp; mv tmp $i; done

–搞定–

安装方法：

wget http://www.percona.com/mysql/xtrabackup/xtrabackup-0.8.tar.gz
tar zxf xtrabackup-0.8.tar.gz
cd xtrabackup-0.8
./configure
make
make install

使用命令：

sudo ./innobackupex-1.5.1 –user=root –stream=tar backup/ –slave-info –databases=broad | gzip > backup/broad.gz

备注：

innobackupex: You must use -i (–ignore-zeros) option for extraction of the tar stream.

为了确定重新部署是否产生内存泄漏（垃圾收集清除不干净，消耗内存越来越多），一个有效的检查方法就是undeploy后，容器为Web Application创建的class loader应该会消失，如果没有的话，那就肯定有内存泄漏了，这时还可以用Profiler工具查看是哪些对象仍然被引用了，比如下图：

容器用的是Jetty，重新部署三次后undeploy，仍然能看到三个WebAppClassLoader对象，每个对象都是因为有org.dom4j.DocumentFactory对象被引用了，引用者就是一个ThreadLocal对象并绑定到了容器创建的一个定时服务线程上（所以不能释放掉）。Dom4J是一个比较好用的XML解析器，估计也是用ThreadLocal来做cache提高性能，搜索一下dom4j memory leak，还真有人报告过这个问题。解决的方法则是升级Dom4J到1.6.1以上，新版本已经解决了这个问题。。。

下面的图是解决内存泄漏后的一次重新部署，可以清楚看到垃圾收集启动了一次，清除干净了内存，WebAppClassLoader对象还是只有一个。

常见的造成内存泄漏的原因：

JDBC Driver Manager

在全局的DriverManager注册了 driver后不注销掉会引起内存泄漏，解决方法是在ServletContextListener的contextDestroyed（）方法内使用下列代码：

try {
    Enumeration drivers = DriverManager.getDrivers();
    while(drivers.hasMoreElements()) {
        Driver driver = drivers.nextElement();
        if (driver.getClass().getClassLoader() == getClass().getClassLoader()) {
             DriverManager.deregisterDriver(driver);
        }
    }
} catch (SQLException e) {
    e.printStackTrace();
}

Hibernate
Hibernate 3用的cglib也有ThreadLocal内存泄漏，升级到3.2.5以后才修正了这个问题。

开发时候为了提高效率，我们总希望重新编译的类能立刻生效，或重新部署应用而不重新启动应用服务器—所谓的”热部署“

无论是用Resin, Tomcat，Jetty， 如果你试图不重新启动应用服务器，而重新部署你的应用(WebApp)，多来几次后就可能会出现：”java.lang.OutOfMemoryError: PermGen space”的错误。

PermGen 是JVM用来保存类定义和常量池的保留空间，缺省是64M，虽然你可以通过 -XX:MaxPermSize启动参数来增加PermGen空间，但这也只是允许你多reload几次，而不能根本解决问题。

问题主要原因是出在Class loader上，Tomcat是按下面的关系来创建Webapp的Class Loader（详见：http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html)

      Bootstrap
          |
       System
          |
       Common
       /     \
  Webapp1   Webapp2 ...

通过这种方式，应用服务器可以把不同的Webapp严格区分开来，Webapp1中载入的class在Webapp2可以不可见，但在System或Common里载入的则都可见，实际应用中，Tomcat或Resin的lib目录下jar库可以被所有webapp调用。

当你重新部署一个应用时候，容器一般是把原来供这个Webapp的class loader设成null，并为应用重新创建一个class loader来装载应用使用的类。理想情况下当然是希望之前的class loader能够完全被垃圾收集。但实际情况下如果你的应用使用了别的class loader（如System)，对象被上层class loader引用后不能被释放，那应用的class loader就不能干净地被垃圾收集了。例如下面的代码：

private static final ThreadLocal cache = new ThreadLocal();
cache.set(yourObject);

因为ThreadLocal对象绑定在当前线程，而该线程由应用服务器本身创建（使用了更高层的Class Loader)，原来的应用就再也不能被垃圾收集干净了。

From: http://hurvitz.org/blog/2008/06/linkedin-architecture

Linedin是美国最大的职业人士网络，我也有一个帐号：http://www.linkedin.com/in/hugozhu

网站的一些数据：

Site Statistics

• 22 million members
• 4+ million unique visitors/month
• 40 million page views/day
• 2 million searches/day
• 250K invitations sent/day
• 1 million answers posted
• 2 million email messages/day

Software

• Solaris (running on Sun x86 platform and Sparc)
• Tomcat and Jetty as application servers
• Oracle and MySQL as DBs
• No ORM (such as Hibernate); they use straight JDBC
• ActiveMQ for JMS. (It’s partitioned by type of messages. Backed by MySQL.)
• Lucene as a foundation for search
• Spring as glue

今天的架构：

使用到的Java技术：

他们在实践中的一些经验教训：

• Centralizing updates into a single service leaves a single point of
  failure
• Be prepared to spend time tuning the HttpConnectionManager
  (timeouts, max connections)
• While the system was stabilizing, it was affecting all users; should
  have rolled the new service out to a small subset!
• Don’t use “Least Frequently Used” (LFU) in a large EHCache—very
  bad performance! (改用LRU–Least Recently Used)

给JVM分配多大的内存合适？
32位系统—2G
64位系统—3G

-Over-

虽然不是很建议这样做，但有时候还是迫不得已的：

Maven to bypass (skip) unit tests:  mvn -DskipTests=true install

因为项目需求，快速搭建了一下嵌入OSGi容器到Web框架的演示工程，重点测试了一下在大流量下切换服务提供者是否稳定有效。代码放在：http://github.com/hugozhu/osgi_demo

OSGi使用是Host方式还是Embed方式要看项目需求，要了解你的扩展点在哪里，如果盲目选择Host方式，一些不需要扩展的地方也要按OSGi的方式来实现，项目周期就可能被拉长，风险就变大了。演示工程采用的是Embed方式，在这个框架上可以实现接口提供通过Web安装或更新组件（Bundle）及相关的管理功能，同时又可以很灵活的和已经存在的项目集成，只需要把扩展点的组件通过OSGi容器来管理而少量的迁移代码。