報錯：
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的數據。

為了登錄部分效率考慮，用戶名和密碼拆到一個庫中，因為這部分讀取并不是特別頻繁，所以目前用主備方式，備的目的是主掛掉至少不會讓用戶無法登錄，頂多無法注冊而已。

用戶的基本資料字段是固定的，但容量有些大，訪問也比較頻繁。之前用戶沒有中間層，所以拆庫來提高效率?，F在有中間層，拆庫的意義也變了，領導不希望任何一臺機器故障影響到所有用戶，影響部分用戶還是勉強可接受的。實際上隨著用戶的不斷增加，即便是使用中間層也會有壓力，畢竟中間層只是幫數據庫擋了讀取的壓力，而讀寫比例通常情況下是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的安裝路徑，再調用對應路徑下的解釋器程序完成操作。