报错：
log4j:ERROR Document root element "log4j:configuration",  must match DOCTYPE root "null".
解决：
Try adding this to the second line (the line below <?xml ...?>)...
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">



Log4J的数据库写入方式就是一个鸡肋，没有使用连接池，也不支持addBatch。
只是把用户输出的log现在一个ArrayList中保存，当其数量达到了BufferSize，才启动写日志。参看其源代码（JDBCAppender.java）

可以考虑把org.apache.log4j.jdbc.JDBCAppender换掉。参考

log4j日志异步化大幅提升系统性能
http://wiki.springside.org.cn/display/SpringSide3/Log
springside3.*中log4j和java.util.concurrent的结合使用
把重要的业务日志异步批量写入数据库 LOG4J
用log4j把日志异步写入数据库中
log4j中再次看ThreadLocal用法

1，subeclipse可使用relocate(重新定位)
在SVN资源库的view里，选中原来的地址，右键“重新定位”。来源

2，修改hosts文件
192.168.40.43   svnserver
使用svnserver这个名字取代具体的ip。前提是端口不变。
来源

3，
http://blog.csdn.net/jerryrt/article/details/4267860
找到SVN的meta数据，发现都是明文，UNIX世界伟大的地方就在此，三分钟内处理完毕。

#!/bin/bash

for SVN_META in `find . -type f -name "entries"`
do
        echo processing $SVN_META ...
        cat $SVN_META | sed -e 's/3322/.org/homeunix/.net/g' >$SVN_META.tmp
        mv -vf $SVN_META.tmp $SVN_META
done

我使用的是SecureCRT5.5
SecureCR下的文件传输协议有ASCII、Xmodem、Zmodem
文件传输协议
文件传输是数据交换的主要形式。在进行文件传输时，为使文件能被正确识别和传送，我们需要在两台计算机之间建立统一的传输协议。这个协议包括了文件的识别、传送的起止时间、错误的判断与纠正等内容。常见的传输协议有以下几种：

ASCII：这是最快的传输协议，但只能传送文本文件。

Xmodem：这种古老的传输协议速度较慢，但由于使用了CRC错误侦测方法，传输的准确率可高达99.6%。

Ymodem：这是Xmodem的改良版，使用了1024位区段传送，速度比Xmodem要快。

Zmodem：Zmodem采用了串流式（streaming）传输方式，传输速度较快，而且还具有自动改变区段大小和断点续传、快速错误侦测等功能。这是目前最流行的文件传输协议。

除以上几种外，还有Imodem、Jmodem、Bimodem、Kermit、Lynx等协议，由于没有多数厂商支持，这里就略去不讲。
SecureCRT可以使用linux下的zmodem协议来快速的传送文件.

你只要设置一下上传和下载的默认目录就行
options->session options ->Terminal->Xmodem/Zmodem 下
在右栏directory设置上传和下载的目录

 使用Zmodem从客户端上传文件到linux服务器
1.在用SecureCRT登陆linux终端.
2.选中你要放置上传文件的路径，在目录下然后输入rz命令,SecureCRT会弹出文件选择对话框，在查找范围中找到你要上传的文件，按Add按钮。然后OK就可以把文件上传到linux上了。
或者在Transfer->Zmodem Upoad list弹出文件选择对话框，选好文件后按Add按钮。然后OK窗口自动关闭。然后在linux下选中存放文件的目录，输入rz命令。liunx就把那个文件上传到这个目录下了。

使用Zmodem下载文件到客户端：
sz filename
zmodem接收可以自行启动.下载的文件存放在你设定的默认下载目录下.

又记：
rz，sz是Linux/Unix同Windows进行ZModem文件传输的命令行工具windows端需要支持ZModem的telnet/ssh客 户端，SecureCRT就可以用SecureCRT登陆到Unix/Linux主机（telnet或ssh均可）O 运行命令rz，即是接收文件，SecureCRT就会弹出文件选择对话框，选好文件之后关闭对话框，文件就会上传到当前目录 O 运行命令sz file1 file2就是发文件到windows上（保存的目录是可以配置） 比ftp命令方便多了，而且服务器不用再开FTP服务了

StackOverflowError  当应用程序递归太深而发生堆栈溢出时抛出
Jamon（Java Application Monitor）是一款免费的、高性能的、线程安全的Java程序，它使得开发人员能够容易地完成对生产环境应用程序的监控。

Java保证读和写32位数或者更小的值是原子操作，也就是说可以在一步完成，因而不可能被打断，因此这样的读和写不需要同步。以下的代码是线程安全(thread safe)的：

public class Example{
　 private int value; // More code here...
　 public void set (int x){
　　 // NOTE: No synchronized keyword
　　 this.value = x;
　 }
}

不过，这个保证仅限于读和写，下面的代码不是线程安全的：

public void increment (){
　 // This is effectively two or three instructions:
　 // 1) Read current setting of ’value’.
　 // 2) Increment that setting.
　 // 3) Write the new setting back.
　 ++this.value;
}

算法：统计最近一分钟的请求数量http://www.iteye.com/problems/46542

含农药比较多的：黄瓜、草莓、油菜、豇豆、韭菜、洋葱、西红柿、圆白菜(洋白菜)、空心菜、小白菜、菠菜、西兰花、芹菜
含农药比较少的：胡萝卜、土豆、蒿子秆、茼蒿、香菜、生菜、冬瓜、南瓜、辣椒、苋菜、红薯

http://www.china.com.cn/news/env/2010-08/17/content_20728649.htm
http://www.kaixin001.com/repaste/106224292_4954518156.html

1，下载Django-1.2.5
2，tar xzvf Django-1.2.5.tar.gz
3，在Django-1.2.5目录下执行：sudo python setup.py install
4，/usr/www下执行： django-admin.py startproject easydjango
5，/usr/www/easydjango下执行： python  manage.py runserver

分库可以在model中加入
  establish_connection :your_connection
  self.abstract_class = true
实现.
分表应该也可以用类似的方法:
set_table_name

Rails遗留数据库访问之二分库分表
Rails遗留数据库访问之一动态ORM
Rails中实现分表（1）垂直分表
项目中遇到的问题（二）（动态创建MODEL）
Rails是否可以这样解决这个辣手的问题?
Rails中如何支持数据库分表啊

http://stackoverflow.com/questions/44145/database-sharding-and-rails
http://stackoverflow.com/questions/5981724/multiple-database-tables-within-one-ar-model-in-rails-3
https://github.com/aglasgall/rails-sharding
http://www.engineyard.com/blog/2009/a-quick-primer-on-sharding-for-ruby-on-rails/
http://blog.sphereinc.com/2010/04/its-boring-to-scale-with-ruby-on-rails/
http://kovyrin.net/2010/04/16/dbcharmer-rails-can-scale/
https://www.ruby-toolbox.com/categories/Active_Record_Sharding
https://www.ruby-toolbox.com/projects/octopus
https://www.ruby-toolbox.com/projects/data_fabric

how RoR scales
I've said it before, but it bears repeating: There's nothing interesting about how Ruby on Rails scales. We've gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty.

Take state out of the application servers and push it to database/memcached/shared network drive (that's the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy).

In a setup like that, you can add almost any number of web and app servers without changing a thing.

Scaling the database is the "hard part", but still a solved problem. Once you get beyond what can be easily managed by a decent master-slave setup (and that'll probably take millions and millions of pageviews per day), you start doing partitioning.

Users 1-100K on cluster A, 100K-200K on cluster B, and so on. But again, this is nothing new. LiveJournal scales like that. I hear eBay too. And probably everyone else that has to deal with huge numbers.

So the scaling part is solved. What's left is judging whether the economics of it are sensible to you. And that's really a performance issue, not a scalability one.

If your app server costs $500 per month (like our dual xeons does) and can drive 30 requests/second on Rails and 60 requests/second on Java/PHP/.NET/whatever (these are totally arbitrary numbers pulled out of my...), then you're faced with the cost of $500 for 2.6 million requests/day on the Rails setup and $250 for the same on the other one.

Now. How much is productivity worth to you? Let's just take a $60K/year programmer. That's $5K/month. If you need to handle 5 million requests/day, your programmer needs to be 10% more productive on Rails to make it even. If he's 15% more productive, you're up $250. And this is not even considering the joy and happiness programmers derive from working with more productive tools (nor that people have claimed to be many times more productive).

Of course, the silly math above hinges on the assumption that the whateverstack is twice as fast as Rails. That's a very big if. And totally dependent on the application, the people, and so on. Some have found Rails to be as fast or faster than comparable "best-of-breed J2EE stacks".

The point is that the cost per request is plummeting, but the cost of programming is not. Thus, we have to find ways to trade efficiency in the runtime for efficiency in the "thought time" in order to make the development of applications cheaper. I believed we've long since entered an age where simplicity of development and maintenance is where the real value lies.

其实正如zhangc之前说，理论的问题都清楚，关键还是实践！

firebody 写道：
java 代码
 

   1. 以前用hibernate主要是做一些表的映射、关联，更深层的应用就没有了，所以也没什么经验，拿个具体的情况来分析一下吧。   
   2.   
   3. 目前主要数据库是mysql，由于数据库存储限制：   
   4. 1、通常会把用户名和密码放一个库(负载相对较少，但也要依赖cache)。   
   5. 2、用户基本资料拆开多台DB按用户名或ID hash，用户扩展信息也拆开多台。   
   6. 3、用户积分因为太敏感，甚至使用了oracle来保证效率和稳定性(事实证明它比mysql慢。。它的C++绑定也更不稳定)。   
   7. 4、用户发帖是保存在文件的，数据库只保存文件链接发帖人等简单信息。   
   8. 5、用户之间的消息是放数据库的，当然也是按用户名hash到多台，这时候要查询我给别人的消息和别人给我的消息，就得从2个表里面查，因为你给别人的消息是按别人的用户名hash到某一台上，别人给你的是按你的用户名hash的，所以增加一条消息就得往2个库各写一条。   
   9.   
  10. 以上列举了一部分应用，当然由于库拆得比较散，基本上每个库都会有冗余字段。   
  11.   
  12. 上面这种情况下，能不能分析一下hibernate和ActiveRecord用得比较舒服的部分？   
  13.   
  14. 我在用rails的时候，ActiveRecord对于多数据库支持并不好，即使是有这样的方案也是非方的技巧。分表情况下表之间的关联基本上没法做，如果没有关联，ActiveRecord的意义只是帮我们生成SQL？   
  15.   
  16. 多级目录不是最大的问题，也不是阻碍性能的问题，俺只想找个最后的理由把RoR不适用这个项目说得更充分些。。。  

 

谢谢你能够提供更多的信息来参与讨论， 针对你提到的2），这样的情况下，按照我的理解，现有的java的orm框架无法针对不同库的表作映射。 activeRecord应该也没有考虑到这种情况。

不知道你们作出的分库的依据是什么，我觉得更合理的分库依据应该根据负载压力和模块独立性来分离，比如你提到的消息发送应该是统一的模块，按照用户名hash到不同的库的话，对于业务层开发带来一定的复杂度。

分表的话，java的orm有些策略可以绕着解决，比如用继承策略来解决。但是也是比较别扭。 不过，我更想了解的是你们作出的分表的依据是什么？

这样的情况下，模型的关联映射在现有的orm框架下确实太牵强了，即使用了，收到的效果也是很小的，模型也会随之退化到单实体+基本类型外键的维护上来，如果让我选择的话，基本上也是选择spring的jdbcTemplate了。

如果觉得java orm是促进开发效率的一个基本前提的话，那么在系统架构选择上，特别是数据库架构设计上，可能还要更慎重一些，因为不同于数据库底层开发，orm对于数据库的要求会有一些苛刻。为了最大化获得模型映射的效果，有一些建议不知道是否合理：

*  在考虑访问压力的情况下，尽量按照耦合紧密的原则分库，使得某一个库的表关联能够作充分的模型映射，而对于少数的外库关联仍然需要做手工的维护，不过已经简化到最小。

*  因为数据量大而分表的话，可以采用多态映射关联来做和多表的关联。


基本上分库主要原因都是和容量或性能有关，上亿用户，每个用户只保存一个用户名和密码，也有好几G的数据。

为了登录部分效率考虑，用户名和密码拆到一个库中，因为这部分读取并不是特别频繁，所以目前用主备方式，备的目的是主挂掉至少不会让用户无法登录，顶多无法注册而已。

用户的基本资料字段是固定的，但容量有些大，访问也比较频繁。之前用户没有中间层，所以拆库来提高效率。现在有中间层，拆库的意义也变了，领导不希望任何一台机器故障影响到所有用户，影响部分用户还是勉强可接受的。实际上随着用户的不断增加，即便是使用中间层也会有压力，毕竟中间层只是帮数据库挡了读取的压力，而读写比例通常情况下是10:1左右。

用户扩展信息，这个是一对多的，一个用户可自定义不同的字段，通常是用户有修改时更新一下，读取压力并不大，同样是因为中间把把读取压力都挡掉了，但容量非常大。

当然也考虑过如果有中间层，是不是数据库不用拆得这么细，目前也做过一些合并工作，不过意义并不大，因为所有数据库容量加起来以T计，不管是备份还是扩容甚至修复硬件故障都会影响用户很长时间，现在拆得这么细，通常一个点的故障只会影响一部分用户的一部分功能。目前硬件故障还是会经常有的，比如某国外品牌的服务器故障率非常高。扩容也是经常会有的，文件每天上传量就超过2T，每月都增加存储。数据库差不多每3月-6月都要重新拆分一次，因为容量。


分库分表最佳实践大总结
一、随着企业业务的增长，访问量和用户等数据的增加，传统的关系数据库已经不能满足需求

分表分库就成了节省成本、和良好扩展性的必然选择

网上也有很多开源的分表分库的软件,也公司自己开发实现

而终其原理和步骤都无外乎三步:

  即首先sql解析路由，再根据路由确定分片，然后结果集合并

  所遇到的分表分库的难点大都是对分布式事务的支持，分片后的分页

和排序等

二、实现方式大都在两个层面：

即在应用层 代表有hibernate shards,ibatis shards,guzz 等

和 在jdbc之下 对应用层完全透明的 如amoeba


三、那么企业在分表分库的实践中该如何选择呢？

假如您是一开始就想全新的分表分库 公司没打算做自己的分表分库框架，那么推荐用guzz,

这个类似于hibernate 和 ibatis的框架,很多网站都在用,缺点是技术团队需要重新学习一套框架

跟旧的系统很难兼容；


假如您的系统很乱，分表分库规则很简单，并且数据库是mysql

推荐用amoeba ，虽然有oracle版本，但目前不是很成熟；


假如您的技术团队一直用hibernate ,或企业现在的很多项目现在都用hibernate做的

那么推荐用hibernate shards，这个类似hibernate，学习成本低，能跟

hibernate兼容

目前国内有在hibernate  shards上封装的成功案例,

缺点是list查询时遍历所有数据片，而不是根据sql规则确定的数据片。

这个bug及在hibernate shards上如何扩展问题我已解决,附件是解决的架构图，

需要源代码的或详细可以联系我；


ibatis shards跟hibernate shards类似，也可借鉴本人所设计的架构

思想 欢迎有志之士详聊


附:
一、hibernate shards
优点：
1、实现跟其他成熟框架的集成如spring
等
2、能利用公司现有的hibernate的技术优势
3、目前国内有成功案例在hibernate  shards上封装
的商业软件
4、能够快速开发
缺点:
1、暂不支持垂直分区
2、list查询遍历所有表分片

Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters, ...).
JspTest
ServletRunner


容器外的JSP页面测试技术
http://home.so-net.net.tw/idealist/Test/cactus.html

#!/usr/bin/python是告诉操作系统执行这个脚本的时候，调用/usr/bin下的python解释器；
#!/usr/bin/env python这种用法是为了防止操作系统用户没有将python装在默认的/usr/bin路径里。当系统看到这一行的时候，首先会到env设置里查找python的安装路径，再调用对应路径下的解释器程序完成操作。