#
問題解決，解決方法如下：以secureCRT為例，菜單：選項-->會話選項...-->(類別)終端->外觀-->字符編碼，選擇UTF-8，然后確定。。。
安裝和設置 OpenSSH Server： sudo apt-get install openssh-server
然后確認sshserver是否啟動了： ps -e |grep ssh
如果看到sshd那說明ssh-server已經啟動了。
如果沒有則可以這樣啟動： sudo /etc/init.d/ssh start
ssh-server配置文件位于/ etc/ssh/sshd_config
在這里可以定義SSH的服務端口，默認端口是22，你可以自己定義成其他端口號，如222。
然后重啟SSH服務：
sudo /etc/init.d/ssh stop
sudo /etc/init.d/ssh start
然后通過Xshell等軟件連接。Name為新建連接的名稱，選擇協議類型（Protocol）為“SSH”，Host為服務器的IP地址，端口（Port Number）為SSH協議的連接端口（默認為22），其他選項按照默認設置。
我在ubuntu12.04系統實際操作中執行了sudo apt-get install openssh-server之后按照提示安裝成功。之后直接ssh localhost成功，然后外部機器就可以直接ssh過來了
1.啟動Rad Hat 9.0(圖形界面方式登陸)，并且以管理員的身份登陸。不用管理員身份不能安裝。2.在VMware虛擬機的菜單中點擊：虛擬機->安裝VMware 工具->install。3.Red Hat 9.0自動掛載VMware Tools的虛擬光驅,并顯示在桌面。4.進去VMware Tools的虛擬光驅里，把VMwareTools-5.5.1-19175.tar.gz復制到/tmp目錄。5.進去/tmp目錄，把VMwareTools-5.5.1-19175.tar.gz解壓到當前目錄下的一個文件夾中（VMwareTools-5文件夾）。6.同時按住Ctrl+Alt+F1三個鍵，進入字符界面，并以root身份登陸。7.輸入以下命令：cp /tmp/VMwareTools-5/vmware-tools-distrib（進入vmware-tools-distrib目錄）。8.輸入：./vmware-install.pl（執行vmware-install.pl文件）。9.然后一路“回車”，能yes的就yes，就OK。10. 輸入reboot命令(重新啟動)。11.大功告成。
安裝完Ubuntu后忽然意識到沒有設置root密碼，不知道密碼自然就無法進入根用戶下。到網上搜了一下，原來是這麼回事。Ubuntu的默認root密碼是隨機的，即每次開機都有一個新的root密碼。我們可以在終端輸入命令 sudo passwd，然后輸入當前用戶的密碼，enter，終端會提示我們輸入新的密碼并確認，此時的密碼就是root新密碼。修改成功后，輸入命令 su root，再輸入新的密碼就ok了。
摘要: 博客分類： 開發安全框架Shiro 授權即訪問控制，它將判斷用戶在應用程序中對資源是否擁有相應的訪問權限。 如，判斷一個用戶有查看頁面的權限，編輯數據的權限，擁有某一按鈕的權限，以及是否擁有打印的權限等等。 一、授權的三要素 授權有著三個核心元素：權限、角色和用戶。 權限 權限是Apache Shiro安全機制最核心的元素。它在...
閱讀全文
mysql-bin文件是數據庫的操作日志，例如UPDATE一個表，或者DELETE一些數據，即使該語句沒有匹配的數據，這個命令也會存儲到日志文件中，還包括每個語句執行的時間，也會記錄進去的。
這樣做主要有以下兩個目的：1：數據恢復：如果你的數據庫出問題了，而你之前有過備份，那么可以看日志文件，找出是哪個命令導致你的數據庫出問題了，想辦法挽回損失。2：主從服務器之間同步數據 主服務器上所有的操作都在記錄日志中，從服務器可以根據該日志來進行，以確保兩個同步。處理方法分兩種情況：
1：只有一個mysql服務器，那么可以簡單的注釋掉這個選項就行了。
vi /etc/my.cnf把里面的log-bin這一行注釋掉，重啟mysql服務即可。
2：如果你的環境是主從服務器，那么就需要做以下操作了。
A：在每個從屬服務器上，使用SHOW SLAVE STATUS來檢查它正在讀取哪個日志。
B：使用SHOW MASTER LOGS獲得主服務器上的一系列日志。
C：在所有的從屬服務器中判定最早的日志，這個是目標日志，如果所有的從屬服務器是更新的，就是清單上的最后一個日志。
D：清理所有的日志，但是不包括目標日志，因為從服務器還要跟它同步。
清理日志方法為：
PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2008-12-19 21:00:00';
如果你確定從服務器已經同步過了，跟主服務器一樣了，那么可以直接RESET MASTER將這些文件刪除。
查看mysql關于mysql-bin的配置
show variables like '%max_binlog_size%'
max_binlog_size 1073741824 默認大小為1G
但是mysql-bin文件過多會占用大量的磁盤空間，所以要對日志文件進行清理，方法如下：
1、
禁止方法: vi /etc/my.cnf把里面的#log-bin=mysql-bin注釋掉,重啟mysql服務即可.2、mysql> reset master;或flush logs; (清除日志文件)3、mysql> set global expire_logs_days=2；只保留兩天的mysql-bin日志4、刪除ablelee.000003之前的而沒有包含ablelee.000003
mysql> purge binary logs to 'ablelee.000003';
當磁盤大小超過標準時會有報警提示，這時如果掌握df和du命令是非常明智的選擇。
df可以查看一級文件夾大小、使用比例、檔案系統及其掛入點，但對文件卻無能為力。
du可以查看文件及文件夾的大小。
兩者配合使用，非常有效。比如用df查看哪個一級目錄過大，然后用df查看文件夾或文件的大小，如此便可迅速確定癥結。
下面分別簡要介紹
df命令可以顯示目前所有文件系統的可用空間及使用情形，請看下列這個例子：
以下是代碼片段： [yayug@yayu ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3.9G 300M 3.4G 8% /
/dev/sda7 100G 188M 95G 1% /data0
/dev/sdb1 133G 80G 47G 64% /data1
/dev/sda6 7.8G 218M 7.2G 3% /var
/dev/sda5 7.8G 166M 7.2G 3% /tmp
/dev/sda3 9.7G 2.5G 6.8G 27% /usr
tmpfs 2.0G 0 2.0G 0% /dev/shm |
參數 -h 表示使用「Human-readable」的輸出，也就是在檔案系統大小使用 GB、MB 等易讀的格式。
上面的命令輸出的第一個字段（Filesystem）及最后一個字段（Mounted on）分別是檔案系統及其掛入點。我們可以看到 /dev/sda1 這個分割區被掛在根目錄下。
接下來的四個字段 Size、Used、Avail、及 Use% 分別是該分割區的容量、已使用的大小、剩下的大小、及使用的百分比。 FreeBSD下，當硬盤容量已滿時，您可能會看到已使用的百分比超過 100%，因為 FreeBSD 會留一些空間給 root，讓 root 在檔案系統滿時，還是可以寫東西到該檔案系統中，以進行管理。
du：查詢文件或文件夾的磁盤使用空間
如果當前目錄下文件和文件夾很多，使用不帶參數du的命令，可以循環列出所有文件和文件夾所使用的空間。這對查看究竟是那個地方過大是不利的，所以得指定深入目錄的層數，參數：--max-depth=，這是個極為有用的參數！如下，注意使用“*”，可以得到文件的使用空間大小.
提醒：一向命令比linux復雜的FreeBSD，它的du命令指定深入目錄的層數卻是比linux簡化，為 -d。
以下是代碼片段： [root@bsso yayu]# du -h --max-depth=1 work/testing
27M work/testing/logs
35M work/testing [root@bsso yayu]# du -h --max-depth=1 work/testing/*
8.0K work/testing/func.php
27M work/testing/logs
8.1M work/testing/nohup.out
8.0K work/testing/testing_c.php
12K work/testing/testing_func_reg.php
8.0K work/testing/testing_get.php
8.0K work/testing/testing_g.php
8.0K work/testing/var.php [root@bsso yayu]# du -h --max-depth=1 work/testing/logs/
27M work/testing/logs/ [root@bsso yayu]# du -h --max-depth=1 work/testing/logs/*
24K work/testing/logs/errdate.log_show.log
8.0K work/testing/logs/pertime_show.log
27M work/testing/logs/show.log |
值得注意的是，看見一個針對du和df命令異同的文章：《du df 差異導致文件系統誤報解決》。
du 統計文件大小相加
df 統計數據塊使用情況
如果有一個進程在打開一個大文件的時候,這個大文件直接被rm 或者mv掉，則du會更新統計數值，df不會更新統計數值,還是認為空間沒有釋放。直到這個打開大文件的進程被Kill掉。
如此一來在定期刪除 /var/spool/clientmqueue下面的文件時，如果沒有殺掉其進程，那么空間一直沒有釋放。
使用下面的命令殺掉進程之后，系統恢復。
fuser -u /var/spool/clientmqueue
http://www.yayu.org/look.php?id=162
查看linux文件目錄的大小和文件夾包含的文件數
統計總數大小
du -sh xmldb/
du -sm * | sort -n //統計當前目錄大小 并安大小 排序
du -sk * | sort -n
du -sk * | grep guojf //看一個人的大小
du -m | cut -d "/" -f 2 //看第二個/ 字符前的文字
查看此文件夾有多少文件 /*/*/* 有多少文件
du xmldb/
du xmldb/*/*/* |wc -l
40752
解釋：
wc [-lmw]
參數說明：
-l :多少行
-m:多少字符
-w:多少字
http://linux.chinaitlab.com/command/734706.html
Linux:ls以K、M、G為單位查看文件大小
#man ls
……
-h, --human-readable
print sizes in human readable format (e.g., 1K 234M 2G)
……
# ls
cuss.war nohup.out
# ls -l
total 30372
-rw-r--r-- 1 root root 31051909 May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
# ls -lh
total 30M
-rw-r--r-- 1 root root 30M May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
# ll -h
total 30M
-rw-r--r-- 1 root root 30M May 24 10:07 cuss.war
-rw------- 1 root root 0 Mar 20 13:52 nohup.out
碰到問題先別急，按下面的思路去套，先一步步地定位問題、細化問題。
千萬別在論壇、群里問，我的機器好慢怎么回事？我的機器內存泄露了怎么回事？
這類大而空的問題一點意義都沒有，其實誰都不知道。你要做的是用下面的思路、方法、工具去定位它
------------------------------
解決問題思路
Java程序問題（運行慢）
先通過 top 查看整個CPU資源使用情況；
通過top -Hp pid查看java進程的每一個線程占用CPU的情況；
如果有一個線程占用CPU過高，有兩種可能：
沒有內存了，Java垃圾回收線程不停地運行嘗試回收內存，但是每次無法收回，確認：
jstat -gcutil pid 1s 觀察10多秒鐘就能發現了，看是不是內存使用率接近100%了
類似于死循環（hash沖突攻擊），就是一個線程一直占用一個核的所有CPU資源（其實一個線程總是暫用一個核超過50%的資源都是不太正常的），解決：
用我課堂的checkPerf腳本，定位這個線程具體執行的任務（能具體到某一行），對應看代碼解決。
如果有很多線程，每個線程占用的CPU都不多，那基本是正常的。
如果死鎖：
jstack -l pid 多執行幾次，統計一下stack中總是在等待哪些鎖，可以對鎖id進行排序統計（sort uniq grep）
上面列出來的都是明顯的瓶頸，最可怕的是哪里都沒有明顯的瓶頸，哪里都要偷一點點資源走，這是可以試試JProfiler這樣更專業一點的工具，同時要配合自己對業務的了解來解決。
Java內存的問題，如果有內存泄露（就是執行完fgc/old gc后不能回收的內存不斷地增加）：
快速解決：jmap -histo:live pid 來統計所有對象的個數（String/char/Integer/HashEntry 這樣的對象很多很正常，主要是盯著你們公司的包名下的那些對象）
每隔一分鐘執行一次上面的命令，執行5次以上，看看你們公司報名下的對象數量哪個在一直增加，那基本上就是這個對象引起了泄露；
用課堂上的工具HouseMD來動態監控創建這個對象的地方（一般來說很多時候創建了這些對象把他們丟到一個HashMap然后就不管了），分析一下有沒有釋放！
上面的方法實在沒法定位就用: jmap -dump 導出整個內存（耗時間，需要很大的內存的機器才能對這個導出文件進行分析，會將JVM鎖住一段時間）
在Eclipse的插件EMA中打開這個文件（2G的物理文件需要4G以上的內存，5G以上的需要將近20G的內存來分析了）
盯著你們公司報名的那些對象，看看引用關系，誰拿著這些對象沒釋放（是否是必要的）
MySQL 數據庫的性能問題
大部分情況下是磁盤IO的問題（索引沒建好、查詢太復雜）；
索引問題的話分析慢查詢日志，explain 他們挨個解決。
偶爾也有數據庫CPU不夠的情況，如果并發高CPU不夠很正常，如果并發不高，那很可能就是group by/order by/random之類的操作嚴重消耗了數據庫的CPU
mysql -e "show full processlist" | grep -v Sleep | sort -rnk6 查看那些SQL語句執行的太長
拿出這個SQL語句分析他們的執行計劃: explain SQL 然后改進；
分析慢查詢日志，統計top10性能殺手的語句，挨個explain他們，然后改進（具體改進辦法具體分析，這里只談思路）
總結一下數據庫問題就只有這三招：show full processlist/分析慢查詢日志/explain（然后建好聯合索引）
mysql：http:x//mirrors.sohu.com/mysql/MySQL-5.5/mysql-5.5.14.tar.gz
cmake：http://www.cmake.org/cmake/resources/software.html
首先要安裝cmake
#tar zxf cmake-2.8.5.tar.gz
#cd cmake-2.8.5
#./bootstrap
#make
#make install
依據源碼安裝mysql
useradd mysql
tar zxf mysql-5.5.14.tar.g
cd mysql-5.5.14
CFLAGS="-O3" CXX=gcc
CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti"
cmake . -LH|more //CMake下查看MySQL的編譯配置
/usr/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/mysql \
-DMYSQL_UNIX_ADDR=/opt/mysql/mysql.sock \
-DDEFAULT_CHARSET=utf8 \
-DDEFAULT_COLLATION=utf8_general_ci \
-DWITH_EXTRA_CHARSETS=all \
-DWITH_MYISAM_STORAGE_ENGINE=1 \
-DWITH_INNOBASE_STORAGE_ENGINE=1 \
-DWITH_READLINE=1 \
-DENABLED_LOCAL_INFILE=1 \
-DMYSQL_DATADIR=/opt/mysql/data \
-DMYSQL_TCP_PORT=3306 \
make; make install
cd /opt
chown -R mysql:mysql mysql
cd /opt/mysql
chmod 777 data
./scripts/mysql_install_db
./scripts/mysql_install_db --user=mysql --datadir=/opt/mysql/data
update mysql.user set password=PASSWORD('1234') where User='root';
flush privileges;
show variables like 'character_set_%'; 字符集查看
redhat需要裝的庫
yum -y install patch make gcc gcc-c++ gcc-g77 flex bison file
yum -y install libtool libtool-libs autoconf kernel-devel
yum -y install libjpeg libjpeg-devel libpng libpng-devel libpng10 libpng10-devel gd gd-devel
yum -y install freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel
yum -y install glib2 glib2-devel bzip2 bzip2-devel libevent libevent-devel
yum -y install ncurses ncurses-devel curl curl-devel e2fsprogs
yum -y install e2fsprogs-devel krb5 krb5-devel libidn libidn-devel
yum -y install openssl openssl-devel vim-minimal nano sendmail
yum -y install fonts-chinese gettext gettext-devel
yum -y install ncurses-devel
yum -y install gmp-devel pspell-devel
yum -y install unzip
注意：如果忘記先安裝庫，在cmake的時候報錯了，得先把庫安裝一遍，然后刪除/opt/mysql-5.6.21/CMakeCache.txt重新cmake一遍就行了.
mysql剛剛裝好root初始密碼是空的，直接回車就行了
修改授權以便遠程機器能夠訪問
在安裝mysql的機器上運行：
1、d:\mysql\bin\>mysql -h localhost -u root //這樣應該可以進入MySQL服務器
2、mysql>GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION //賦予任何主機訪問數據的權限
3、mysql>FLUSH PRIVILEGES //修改生效
4、mysql>EXIT //退出MySQL服務器
眾所周知，Spring的事務控制是基于AOP來實現的，一個聲明了事務管理的方法（如某個Service的方法）在執行時會被攔截，攔截時執行的“附加”操作集中在：
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(MethodInvocation)
作為一個環繞切面，該方法主要負責在目標方法執行前開始一個事務，在方法執行結束后提交事務。
我們先來深入了解一下事務是如何創建的。從方法createTransactionIfNecessary()上可以看到，創建事務的主要方法是：
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(TransactionDefinition)
作為抽象類的方法，getTransaction()只處理了一些通用性的檢查和設置，實質性的創建事務和開啟事務操作都是通過分別調用抽象方法：
org.springframework.transaction.support.AbstractPlatformTransactionManager.doGetTransaction()
和
org.springframework.transaction.support.AbstractPlatformTransactionManager.doBegin(Object,TransactionDefinition)
來完成的，也就是說這些關鍵性的工作必須由各具體事務管理器來實現，對于hibernate的事務管理器來說，獲取事務對象的方法如下：
開始事務的方法如下：
以上是關于事務開始部分的代碼，下面我們來看一下事務提交時的代碼：
同樣的，從方法commitTransactionAfterReturning()我們可以看出執行事務提交的方法主要通過回調
org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(DefaultTransactionStatus)
來實現的。
補充：
關于方法
org.springframework.transaction.support.TransactionSynchronizationManager.getResource(Object key)
如該方法的注釋所說，它主要是通過給定的key找到對應的資源，特別之處是這些資源實例是綁定在線程上的，也就是spring保證一個線程上一個key對應一個資源實例，不同的線程上綁定的是不同的資源實例。對應到Hibernate上來說，key是sessionFactory,資源是sessionHolder！
作者：bluishglc
轉自：
http://www.2cto.com/kf/201207/142772.html