情境描述：
公司同事的Gmail已滿,但該同事又不想把信收到PC
因為想要雲端作業
解決方法，新增一「john.0」帳號，將john中所有信件移到「john.0」中，
如果之後要看舊的信件，就到john.0帳號中去看。
帳號:john
新增帳號:john.0
用Gmail登入到john帳號
點選「設定」->「轉寄和 POP/IMAP」
設定POP 下載，
選擇「對所有郵件啟用 POP 功能 (包括已經下載的郵件)」 & 當郵件以 POP 存取後「刪除Gmail副本」
然後按「儲存變更」
用Gmail登入到john.0帳號
點選「設定」->「帳戶和匯入」
設定以 POP3 檢查郵件：
點選「新增POP3電子郵件帳戶」
新增john帳號，然後點選「立即檢查郵件」
等所有信件都從john帳號中下載到john.0後
刪除john帳號
再用Gmail登入到john帳號
點選「設定」->「轉寄和 POP/IMAP」
設定POP 下載，
選擇「停用 POP」 & 當郵件以 POP 存取後「在收信匣保留Gmail副本」
最後再按儲存變更即可
2010年5月31日 星期一
[Debug]URL Rewrite escape dot
Question
RewriteRule ^(rank/review_express/ranking)-([^a-z]{1}[^.]+)\.htm$ rewrite/rewriteVerUrlRewriteCommon?rewrite_filename=$1&rewrite_params=$2 [QSA,L]
一直無法解析成功
原來是Server上的/rank/review_express/ranking的目錄被刪除了,新增完後就ok了
RewriteRule ^(rank/review_express/ranking)-([^a-z]{1}[^.]+)\.htm$ rewrite/rewriteVerUrlRewriteCommon?rewrite_filename=$1&rewrite_params=$2 [QSA,L]
一直無法解析成功
原來是Server上的/rank/review_express/ranking的目錄被刪除了,新增完後就ok了
2010年5月26日 星期三
TCP Tuning for Busy Apache Webserver on CentOS5
Recently I was in a situation where a very busy webserver was not responding. Strangely, top showed plenty of CPU available. The server was essentially just sitting there. What do do?
Upon further investigation, it turned out that the network queue was saturated. So many incoming connections were being attempted that they were falling off the end. Some TCP tuning was in order. Fortunately the server was not memory-starved so allocating more memory to the network stack was not a problem. Here's what ended up in /etc/sysctl.conf and turned the server back into a faithful workhorse.
# Kernel tuning settings for CentOS5,
# busy webserver with lots of free memory.
# Big queue for the network device
net.core.netdev_max_backlog=30000
# Lots of local ports for connections
net.ipv4.tcp_max_tw_buckets=2000000
# Bump up send/receive buffer sizes
net.core.rmem_default=262141
net.core.wmem_default=262141
net.core.rmem_max=262141
net.core.wmem_max=262141
# Disable TCP selective acknowledgements
net.ipv4.tcp_sack=0
net.ipv4.tcp_dsack=0
# Decrease the amount of time we spend
# trying to maintain connections
net.ipv4.tcp_retries2=5
net.ipv4.tcp_fin_timeout=60
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
# Increase the number of incoming connections
# that can queue up before dropping
net.core.somaxconn=256
# Increase option memory buffers
net.core.optmem_max=20480
There are plenty of other sysctl options to tune, but the above made the most difference.
And netstat -s is your friend.
摘自：http://www.sysarchitects.com/node/69
Upon further investigation, it turned out that the network queue was saturated. So many incoming connections were being attempted that they were falling off the end. Some TCP tuning was in order. Fortunately the server was not memory-starved so allocating more memory to the network stack was not a problem. Here's what ended up in /etc/sysctl.conf and turned the server back into a faithful workhorse.
# Kernel tuning settings for CentOS5,
# busy webserver with lots of free memory.
# Big queue for the network device
net.core.netdev_max_backlog=30000
# Lots of local ports for connections
net.ipv4.tcp_max_tw_buckets=2000000
# Bump up send/receive buffer sizes
net.core.rmem_default=262141
net.core.wmem_default=262141
net.core.rmem_max=262141
net.core.wmem_max=262141
# Disable TCP selective acknowledgements
net.ipv4.tcp_sack=0
net.ipv4.tcp_dsack=0
# Decrease the amount of time we spend
# trying to maintain connections
net.ipv4.tcp_retries2=5
net.ipv4.tcp_fin_timeout=60
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
# Increase the number of incoming connections
# that can queue up before dropping
net.core.somaxconn=256
# Increase option memory buffers
net.core.optmem_max=20480
There are plenty of other sysctl options to tune, but the above made the most difference.
And netstat -s is your friend.
摘自：http://www.sysarchitects.com/node/69
Linux Tuning Parameters
Using all the resources available to you?
Many default settings in Linux suck
Font server for X Windows is running as a daemon by default, but do you need it?
Check out these tunings that can give you lots of computing juice...
Kernel Network Disk I/O Others
Kernel
To successfully run enterprise applications, such as a database server, on your Linux distribution, you may be required to update some of the default kernel parameter settings. For example, the 2.4.x series kernel message queue parameter msgmni has a default value (for example, shared memory, or shmmax is only 33,554,432 bytes on Red Hat Linux by default) that allows only a limited number of simultaneous connections to a database. Here are some recommended values (by the IBM DB2 Support Web site) for database servers to run optimally:
- kernel.shmmax=268435456 for 32-bit
- kernel.shmmax=1073741824 for 64-bit
- kernel.msgmni=1024
- fs.file-max=8192
- kernel.sem="250 32000 32 1024"
Shared Memory
To view current settings, run command:
# more /proc/sys/kernel/shmmax
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 268435456 > /proc/sys/kernel/shmmax
To set it to a new value permanently (so it survives reboots), modify the sysctl.conf file:
...
kernel.shmmax = 268435456
...
Semaphores
To view current settings, run command:
# more /proc/sys/kernel/sem
250 32000 32 1024
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 500 512000 64 2048 > /proc/sys/kernel/sem
Parameters meaning:
SEMMSL - semaphores per ID
SEMMNS - (SEMMNI*SEMMSL) max semaphores in system
SEMOPM - max operations per semop call
SEMMNI - max semaphore identifiers
ulimits
To view current settings, run command:
# ulimit -a
To set it to a new value for this running session, which takes effect immediately, run command:
# ulimit -n 8800
# ulimit -n -1 // for unlimited; recommended if server isn't shared
Alternatively, if you want the changes to survive reboot, do the following:
- Exit all shell sessions for the user you want to change limits on.
- As root, edit the file /etc/security/limits.conf and add these two lines toward the end:
user1 soft nofile 16000
user1 hard nofile 20000
** the two lines above changes the max number of file handles - nofile - to new settings.
- Save the file.
- Login as the user1 again. The new changes will be in effect.
Message queues
To view current settings, run command:
# more /proc/sys/kernel/msgmni
# more /proc/sys/kernel/msgmax
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 2048 > /proc/sys/kernel/msgmni
# echo 64000 > /proc/sys/kernel/msgmax
Network
Gigabit-based network interfaces have many performance-related parameters inside of their device driver such as CPU affinity. Also, the TCP protocol can be tuned to increase network throughput for connection-hungry applications.
Tune TCP
To view current TCP settings, run command:
# sysctl net.ipv4.tcp_keepalive_time
net.ipv4.tcp_keepalive_time = 7200 // 2 hours
where net.ipv4.tcp_keepalive_time is a TCP tuning parameter.
To set a TCP parameter to a value, run command:
# sysctl -w net.ipv4.tcp_keepalive_time=1800
A list of recommended TCP parameters, values, and their meanings:
Tuning Parameter Tuning Value Description of impact
------------------------------------------------------------------------------
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle 1 Reuse sockets in the time-wait state
---
net.core.wmem_max 8388608 Increase the maximum write buffer queue size
---
net.core.rmem_max 8388608 Increase the maximum read buffer queue size
---
net.ipv4.tcp_rmem 4096 87380 8388608 Set the minimum, initial, and maximum sizes for the
read buffer. Note that this maximum should be less
than or equal to the value set in net.core.rmem_max.
---
net.ipv4.tcp_wmem 4096 87380 8388608 Set the minimum, initial, and maximum sizes for the
write buffer. Note that this maximum should be less
than or equal to the value set in net.core.wmem_max.
---
timeout_timewait echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout Determines the time that must elapse before
TCP/IP can release a closed connection and reuse its resources.
This interval between closure and release is known as the TIME_WAIT
state or twice the maximum segment lifetime (2MSL) state.
During this time, reopening the connection to the client and
server cost less than establishing a new connection. By reducing the
value of this entry, TCP/IP can release closed connections faster, providing
more resources for new connections. Adjust this parameter if the running application
requires rapid release, the creation of new connections, and a low throughput
due to many connections sitting in the TIME_WAIT state.
Disk I/O
Choose the Right File System
Use 'ext3' file system in Linux.
- It is enhanced version of ext2
- With journaling capability - high level of data integrity (in event of unclean shutdown)
- It does not need to check disks on unclean shutdown and reboot (time consuming)
- Faster write - ext3 journaling optimizes hard drive head motion
# mke2fs -j -b 2048 -i 4096 /dev/sda
mke2fs 1.32 (09-Nov-2002)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=2048 (log=1)
Fragment size=2048 (log=1)
13107200 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
1600 block groups
16384 blocks per group, 16384 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
2048000, 3981312, 5619712, 10240000, 11943936
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Use 'noatime' File System Mount Option
Use 'noatime' option in the file system boot-up configuration file 'fstab'. Edit the fstab file under /etc. This option works the best if external storage is used, for example, SAN:
# more /etc/fstab
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sdc2 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
/dev/sda /database ext3 defaults,noatime 1 2
/dev/sdb /logs ext3 defaults,noatime 1 2
/dev/sdc /multimediafiles ext3 defaults,noatime 1 2
Tune the Elevator Algorithm in Linux Kernel for Disk I/O
After choosing the file system, there are several kernel and mounting options that can affect it. One such kernel setting is the elevator algorithm. Tuning the elevator algorithm helps the system balance the need for low latency with the need to collect enough data to efficiently organize batches of read and write requests to the disk. The elevator algorithm can be adjusted with the following command:
# elvtune -r 1024 -w 2048 /dev/sda
/dev/sda elevator ID 2
read_latency: 1024
write_latency: 2048
max_bomb_segments: 6
The parameters are: read latency (-r), write latency (-w) and the device affected.
Red Hat recommends using a read latency half the size of the write latency (as shown).
As usual, to make this setting permanent, add the 'elvtune' command to the
/etc/rc.d/rc.local script.
Others
Disable Unnecessary Daemons (They Take up Memory and CPU)
There are daemons (background services) running on every server that are probably not needed. Disabling these daemons frees memory, decreases startup time, and decreases the number of processes that the CPU has to handle. A side benefit to this is increased security of the server because fewer daemons mean fewer exploitable processes.
Some example Linux daemons running by default (and should be disabled). Use command:
#/sbin/chkconfig --levels 2345 sendmail off
#/sbin/chkconfig sendmail off
Daemon
Description
apmd
Advanced power management daemon
autofs
Automatically mounts file systems on demand (i.e.: mounts a CD-ROM automatically)
cups
Common UNIX� Printing System
hpoj
HP OfficeJet support
isdn
ISDN modem support
netfs
Used in support of exporting NFS shares
nfslock
Used for file locking with NFS
pcmcia
PCMCIA support on a server
rhnsd
Red Hat Network update service for checking for updates and security errata
sendmail
Mail Transport Agent
xfs
Font server for X Windows
Shutdown GUI
Normally, there is no need for a GUI on a Linux server. All administration tasks can be achieved by the command line, redirecting the X display or through a Web browser interface. Modify the 'inittab' file to set boot level as 3:
To set the initial runlevel (3 instead of 5) of a machine at boot,
modify the /etc/inittab file as shown:
摘自：http://www.performancewiki.com/linux-tuning.html
Many default settings in Linux suck
Font server for X Windows is running as a daemon by default, but do you need it?
Check out these tunings that can give you lots of computing juice...
Kernel Network Disk I/O Others
Kernel
To successfully run enterprise applications, such as a database server, on your Linux distribution, you may be required to update some of the default kernel parameter settings. For example, the 2.4.x series kernel message queue parameter msgmni has a default value (for example, shared memory, or shmmax is only 33,554,432 bytes on Red Hat Linux by default) that allows only a limited number of simultaneous connections to a database. Here are some recommended values (by the IBM DB2 Support Web site) for database servers to run optimally:
- kernel.shmmax=268435456 for 32-bit
- kernel.shmmax=1073741824 for 64-bit
- kernel.msgmni=1024
- fs.file-max=8192
- kernel.sem="250 32000 32 1024"
Shared Memory
To view current settings, run command:
# more /proc/sys/kernel/shmmax
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 268435456 > /proc/sys/kernel/shmmax
To set it to a new value permanently (so it survives reboots), modify the sysctl.conf file:
...
kernel.shmmax = 268435456
...
Semaphores
To view current settings, run command:
# more /proc/sys/kernel/sem
250 32000 32 1024
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 500 512000 64 2048 > /proc/sys/kernel/sem
Parameters meaning:
SEMMSL - semaphores per ID
SEMMNS - (SEMMNI*SEMMSL) max semaphores in system
SEMOPM - max operations per semop call
SEMMNI - max semaphore identifiers
ulimits
To view current settings, run command:
# ulimit -a
To set it to a new value for this running session, which takes effect immediately, run command:
# ulimit -n 8800
# ulimit -n -1 // for unlimited; recommended if server isn't shared
Alternatively, if you want the changes to survive reboot, do the following:
- Exit all shell sessions for the user you want to change limits on.
- As root, edit the file /etc/security/limits.conf and add these two lines toward the end:
user1 soft nofile 16000
user1 hard nofile 20000
** the two lines above changes the max number of file handles - nofile - to new settings.
- Save the file.
- Login as the user1 again. The new changes will be in effect.
Message queues
To view current settings, run command:
# more /proc/sys/kernel/msgmni
# more /proc/sys/kernel/msgmax
To set it to a new value for this running session, which takes effect immediately, run command:
# echo 2048 > /proc/sys/kernel/msgmni
# echo 64000 > /proc/sys/kernel/msgmax
Network
Gigabit-based network interfaces have many performance-related parameters inside of their device driver such as CPU affinity. Also, the TCP protocol can be tuned to increase network throughput for connection-hungry applications.
Tune TCP
To view current TCP settings, run command:
# sysctl net.ipv4.tcp_keepalive_time
net.ipv4.tcp_keepalive_time = 7200 // 2 hours
where net.ipv4.tcp_keepalive_time is a TCP tuning parameter.
To set a TCP parameter to a value, run command:
# sysctl -w net.ipv4.tcp_keepalive_time=1800
A list of recommended TCP parameters, values, and their meanings:
Tuning Parameter Tuning Value Description of impact
------------------------------------------------------------------------------
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle 1 Reuse sockets in the time-wait state
---
net.core.wmem_max 8388608 Increase the maximum write buffer queue size
---
net.core.rmem_max 8388608 Increase the maximum read buffer queue size
---
net.ipv4.tcp_rmem 4096 87380 8388608 Set the minimum, initial, and maximum sizes for the
read buffer. Note that this maximum should be less
than or equal to the value set in net.core.rmem_max.
---
net.ipv4.tcp_wmem 4096 87380 8388608 Set the minimum, initial, and maximum sizes for the
write buffer. Note that this maximum should be less
than or equal to the value set in net.core.wmem_max.
---
timeout_timewait echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout Determines the time that must elapse before
TCP/IP can release a closed connection and reuse its resources.
This interval between closure and release is known as the TIME_WAIT
state or twice the maximum segment lifetime (2MSL) state.
During this time, reopening the connection to the client and
server cost less than establishing a new connection. By reducing the
value of this entry, TCP/IP can release closed connections faster, providing
more resources for new connections. Adjust this parameter if the running application
requires rapid release, the creation of new connections, and a low throughput
due to many connections sitting in the TIME_WAIT state.
Disk I/O
Choose the Right File System
Use 'ext3' file system in Linux.
- It is enhanced version of ext2
- With journaling capability - high level of data integrity (in event of unclean shutdown)
- It does not need to check disks on unclean shutdown and reboot (time consuming)
- Faster write - ext3 journaling optimizes hard drive head motion
# mke2fs -j -b 2048 -i 4096 /dev/sda
mke2fs 1.32 (09-Nov-2002)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=2048 (log=1)
Fragment size=2048 (log=1)
13107200 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
1600 block groups
16384 blocks per group, 16384 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
2048000, 3981312, 5619712, 10240000, 11943936
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Use 'noatime' File System Mount Option
Use 'noatime' option in the file system boot-up configuration file 'fstab'. Edit the fstab file under /etc. This option works the best if external storage is used, for example, SAN:
# more /etc/fstab
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sdc2 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
/dev/sda /database ext3 defaults,noatime 1 2
/dev/sdb /logs ext3 defaults,noatime 1 2
/dev/sdc /multimediafiles ext3 defaults,noatime 1 2
Tune the Elevator Algorithm in Linux Kernel for Disk I/O
After choosing the file system, there are several kernel and mounting options that can affect it. One such kernel setting is the elevator algorithm. Tuning the elevator algorithm helps the system balance the need for low latency with the need to collect enough data to efficiently organize batches of read and write requests to the disk. The elevator algorithm can be adjusted with the following command:
# elvtune -r 1024 -w 2048 /dev/sda
/dev/sda elevator ID 2
read_latency: 1024
write_latency: 2048
max_bomb_segments: 6
The parameters are: read latency (-r), write latency (-w) and the device affected.
Red Hat recommends using a read latency half the size of the write latency (as shown).
As usual, to make this setting permanent, add the 'elvtune' command to the
/etc/rc.d/rc.local script.
Others
Disable Unnecessary Daemons (They Take up Memory and CPU)
There are daemons (background services) running on every server that are probably not needed. Disabling these daemons frees memory, decreases startup time, and decreases the number of processes that the CPU has to handle. A side benefit to this is increased security of the server because fewer daemons mean fewer exploitable processes.
Some example Linux daemons running by default (and should be disabled). Use command:
#/sbin/chkconfig --levels 2345 sendmail off
#/sbin/chkconfig sendmail off
Daemon
Description
apmd
Advanced power management daemon
autofs
Automatically mounts file systems on demand (i.e.: mounts a CD-ROM automatically)
cups
Common UNIX� Printing System
hpoj
HP OfficeJet support
isdn
ISDN modem support
netfs
Used in support of exporting NFS shares
nfslock
Used for file locking with NFS
pcmcia
PCMCIA support on a server
rhnsd
Red Hat Network update service for checking for updates and security errata
sendmail
Mail Transport Agent
xfs
Font server for X Windows
Shutdown GUI
Normally, there is no need for a GUI on a Linux server. All administration tasks can be achieved by the command line, redirecting the X display or through a Web browser interface. Modify the 'inittab' file to set boot level as 3:
To set the initial runlevel (3 instead of 5) of a machine at boot,
modify the /etc/inittab file as shown:
摘自：http://www.performancewiki.com/linux-tuning.html
my.cnf優化
對於單台運行的WEB服務器,建議加上:
skip-locking
skip-name-resolve
skip-networking
在PHP鏈接數據庫時使用”LOCALHOST”.這樣 MySQL客戶端庫將覆蓋之並嘗試連接到本地套接字. (
我們可以從PHP.INI中
代碼:
; Default socket name for local MySQL connects.If empty, uses the built- in ; MySQL defaults. mysql.default_socket = /tmp/mysql.sock
看出默認情況下UNIX 將訪問/tmp/mysql.sock)
以下是部分選項解釋:
my.cnf默認是不存在的.你可以在/usr/local/share/mysql/下看到:
my-huge.cnf
my-innodb-heavy-4G.cnf
my-large.cnf
my-medium.cnf
my-small.cnf
等文件.將其中合適你機器配置的文件拷貝到/etc/my.cnf或mysql data目錄/my.cnf(/var/db/mysql)下或~/.my.cnf.文件內都有詳細的說明
比如我是在freebsd下用ports裝的,copy其中一個文件到/usr/local/etc 這個目錄下即可
————————————–
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip-name-resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。
注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
代碼:
# > SHOW VARIABLES LIKE '%query_cache%' ; # > SHOW STATUS LIKE 'Qcache%' ;
如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip- networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
———————–
update:
記錄兩個,今天在cu上看到有兩個人問起bsd下mysq的安裝問題,make install 後無法啟動mysql,如下:
1.在mysql的log裡看到如下的錯誤:
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
解決辦法如下:
#/usr/local/bin/mysql_install_db2.在log裡發現如下:
/usr/local/libexec/mysqld: Can't find file: './mysql/host.frm'
出現這個問題是執行mysql_install_db後權限的問題,解決辦法如下:
# chown -R mysql:mysql /var/db/mysql/之後就可以用mysqld_safe來啟動了,不過首先記得給root加密碼
摘自：http://dev.firnow.com/course/7_databases/mysql/Mysqljs/2008829/138802.html
skip-locking
skip-name-resolve
skip-networking
在PHP鏈接數據庫時使用”LOCALHOST”.這樣 MySQL客戶端庫將覆蓋之並嘗試連接到本地套接字. (
我們可以從PHP.INI中
代碼:
; Default socket name for local MySQL connects.If empty, uses the built- in ; MySQL defaults. mysql.default_socket = /tmp/mysql.sock
看出默認情況下UNIX 將訪問/tmp/mysql.sock)
以下是部分選項解釋:
my.cnf默認是不存在的.你可以在/usr/local/share/mysql/下看到:
my-huge.cnf
my-innodb-heavy-4G.cnf
my-large.cnf
my-medium.cnf
my-small.cnf
等文件.將其中合適你機器配置的文件拷貝到/etc/my.cnf或mysql data目錄/my.cnf(/var/db/mysql)下或~/.my.cnf.文件內都有詳細的說明
比如我是在freebsd下用ports裝的,copy其中一個文件到/usr/local/etc 這個目錄下即可
————————————–
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip-name-resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。
注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
代碼:
# > SHOW VARIABLES LIKE '%query_cache%' ; # > SHOW STATUS LIKE 'Qcache%' ;
如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip- networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
———————–
update:
記錄兩個,今天在cu上看到有兩個人問起bsd下mysq的安裝問題,make install 後無法啟動mysql,如下:
1.在mysql的log裡看到如下的錯誤:
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
解決辦法如下:
#/usr/local/bin/mysql_install_db2.在log裡發現如下:
/usr/local/libexec/mysqld: Can't find file: './mysql/host.frm'
出現這個問題是執行mysql_install_db後權限的問題,解決辦法如下:
# chown -R mysql:mysql /var/db/mysql/之後就可以用mysqld_safe來啟動了,不過首先記得給root加密碼
摘自：http://dev.firnow.com/course/7_databases/mysql/Mysqljs/2008829/138802.html
百萬記錄級MySQL數據庫及Discuz!論壇優化
Discuz MYSQL 數據庫 性能：
最近，幫一個朋友優化一個擁有20萬主題，100萬帖子，3萬多會員，平均在線人數2000人的Discuz!論壇，採用 Linux2.6+Apache2+mod_php5+MySQL5，服務器配置為雙至強+4G內存，優化前，系統平均負載（load average）基本維持在10以上，MySQL的CPU佔用率基本在90%以上，優化後，系統平均負載降到0.5以下，MySQL的CPU佔用率很少有超過10%的時候。優化前YSlow得分只有35分，優化後YSlow得分86分。現將優化的過程和經驗做一個記錄：
首先，對 Apache進行優化，編輯httpd.conf，設置HostnameLookups、KeepAlive、MaxKeepAliveRequests 以及KeepAliveTimeout四個參數，調整MaxSpareServers、ServerLimit、MaxClients以及 MaxRequestsPerChild參數，還可以考慮棄用prefork而採用worker MPM。設置mod_deflate及mod_expires模塊，不過注意Discuz!不能對PHP文件開啟Expires，否則會出現問題。另外還可以考慮開啟mod_cache和mod_mem_cache模塊。另外利用cronolog按天對日誌進行輪循截斷，如果日誌特別大，也可以按小時截斷。另外再加上Awstats對日誌進行分析，並用gzip對日誌進行壓縮，自動刪除1個月前的日誌。
其次，對PHP進行優化，編輯 php.ini，調整output_buffering、zlib.output_compression及max_execution_time、 max_input_time、memory_limit等參數，並安裝Xcache和Zend Optimizer。
然後對MySQL 進行優化。首先重新靜態編譯MySQL，使其只支持MyISAM和Memory兩種引擎，並按Discuz!編碼選擇只支持UTF-8或者GBK字符集。編輯my.cnf，設置skip-locking、skip-external-locking、skip-networking和skip-name- resolve，根據內存和數據庫狀態具體調整key_buffer_size、query_cache_size、 query_cache_limit、max_allowed_packet、table_cache、thread_cache_size、 sort_buffer_size、read_buffer_size、read_rnd_buffer_size、join_buffer_size、 tmp_table_size、max_tmp_tables、back_log、max_connections、wait_timeout的參數。
對數據庫進行優化，將threads和posts表中部分未索引的字段增加索引，並將supersite數據庫表從bbs數據庫獨立出去。修改discuz!配置文件，設置開啟pconnect。
對 Discuz！設置進行優化。進入Discuz!系統設置，修改頁面緩存設置中的緩存有效期和緩存係數，修改服務器優化中的禁止瀏覽器緩衝和頁面Gzip 壓縮，修改防盜鏈設置中下載附件來路檢查，用JSMin自動對js文件進行縮減（Discuz! 6.1的common.js原文件29.3k，經JSMin縮減後為24.1k，再經deflate後為7.3k），修改attachments.php 文件，將：
//dheader(』Cache-control: max-age=31536000′);
//dheader(』Expires: 『.gmdate(』D, d M Y H:i:s', $timestamp + 31536000).』 GMT');
前的註釋去掉。修改模板目錄下adv.htm，去掉與Insenz有關的代碼。
通過查看MySQL的status，可以看出優化後，長時間運行的Key_read_ratio基本保持在0.05%以下，Threads_cache_hitrate保持在99.9%以上。個人感覺，Discuz!將Session保存在數據庫中，極大地降低了 Query Cache的命中率，如果需要進一步優化，可以考慮修改Discuz!源碼，將Session保存到Memcache中。
優化之後用Siege做並發壓力測試，在200並發下，基本沒有任何錯誤。如果將來人數更多，可以考慮將平台遷移到Ngix+PHP FastCGI上。
下面是用Siege在300並發下的測試結果：
#siege -c 300 -b -r 35 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 10500 hits
Availability: 100.00 %
Elapsed time: 52.68 secs
Data transferred: 65.67 MB
Response time: 1.27 secs
Transaction rate: 199.32 trans/sec
Throughput: 1.25 MB/sec
Concurrency: 253.07
Successful transactions: 10500
Failed transactions: 0
Longest transaction: 24.88
Shortest transaction: 0.00
500並發下的測試結果：
#siege -c 500 -b -r 20 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 9979 hits
Availability: 99.79 %
Elapsed time: 86.52 secs
Data transferred: 82.66 MB
Response time: 3.30 secs
Transaction rate: 115.34 trans/sec
Throughput: 0.96 MB/sec
Concurrency: 381.07
Successful transactions: 9979
Failed transactions: 21
Longest transaction: 34.80
Shortest transaction: 0.00
摘自：http://www.dk101.com/index.php/125562/viewspace-42577.html
最近，幫一個朋友優化一個擁有20萬主題，100萬帖子，3萬多會員，平均在線人數2000人的Discuz!論壇，採用 Linux2.6+Apache2+mod_php5+MySQL5，服務器配置為雙至強+4G內存，優化前，系統平均負載（load average）基本維持在10以上，MySQL的CPU佔用率基本在90%以上，優化後，系統平均負載降到0.5以下，MySQL的CPU佔用率很少有超過10%的時候。優化前YSlow得分只有35分，優化後YSlow得分86分。現將優化的過程和經驗做一個記錄：
首先，對 Apache進行優化，編輯httpd.conf，設置HostnameLookups、KeepAlive、MaxKeepAliveRequests 以及KeepAliveTimeout四個參數，調整MaxSpareServers、ServerLimit、MaxClients以及 MaxRequestsPerChild參數，還可以考慮棄用prefork而採用worker MPM。設置mod_deflate及mod_expires模塊，不過注意Discuz!不能對PHP文件開啟Expires，否則會出現問題。另外還可以考慮開啟mod_cache和mod_mem_cache模塊。另外利用cronolog按天對日誌進行輪循截斷，如果日誌特別大，也可以按小時截斷。另外再加上Awstats對日誌進行分析，並用gzip對日誌進行壓縮，自動刪除1個月前的日誌。
其次，對PHP進行優化，編輯 php.ini，調整output_buffering、zlib.output_compression及max_execution_time、 max_input_time、memory_limit等參數，並安裝Xcache和Zend Optimizer。
然後對MySQL 進行優化。首先重新靜態編譯MySQL，使其只支持MyISAM和Memory兩種引擎，並按Discuz!編碼選擇只支持UTF-8或者GBK字符集。編輯my.cnf，設置skip-locking、skip-external-locking、skip-networking和skip-name- resolve，根據內存和數據庫狀態具體調整key_buffer_size、query_cache_size、 query_cache_limit、max_allowed_packet、table_cache、thread_cache_size、 sort_buffer_size、read_buffer_size、read_rnd_buffer_size、join_buffer_size、 tmp_table_size、max_tmp_tables、back_log、max_connections、wait_timeout的參數。
對數據庫進行優化，將threads和posts表中部分未索引的字段增加索引，並將supersite數據庫表從bbs數據庫獨立出去。修改discuz!配置文件，設置開啟pconnect。
對 Discuz！設置進行優化。進入Discuz!系統設置，修改頁面緩存設置中的緩存有效期和緩存係數，修改服務器優化中的禁止瀏覽器緩衝和頁面Gzip 壓縮，修改防盜鏈設置中下載附件來路檢查，用JSMin自動對js文件進行縮減（Discuz! 6.1的common.js原文件29.3k，經JSMin縮減後為24.1k，再經deflate後為7.3k），修改attachments.php 文件，將：
//dheader(』Cache-control: max-age=31536000′);
//dheader(』Expires: 『.gmdate(』D, d M Y H:i:s', $timestamp + 31536000).』 GMT');
前的註釋去掉。修改模板目錄下adv.htm，去掉與Insenz有關的代碼。
通過查看MySQL的status，可以看出優化後，長時間運行的Key_read_ratio基本保持在0.05%以下，Threads_cache_hitrate保持在99.9%以上。個人感覺，Discuz!將Session保存在數據庫中，極大地降低了 Query Cache的命中率，如果需要進一步優化，可以考慮修改Discuz!源碼，將Session保存到Memcache中。
優化之後用Siege做並發壓力測試，在200並發下，基本沒有任何錯誤。如果將來人數更多，可以考慮將平台遷移到Ngix+PHP FastCGI上。
下面是用Siege在300並發下的測試結果：
#siege -c 300 -b -r 35 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 10500 hits
Availability: 100.00 %
Elapsed time: 52.68 secs
Data transferred: 65.67 MB
Response time: 1.27 secs
Transaction rate: 199.32 trans/sec
Throughput: 1.25 MB/sec
Concurrency: 253.07
Successful transactions: 10500
Failed transactions: 0
Longest transaction: 24.88
Shortest transaction: 0.00
500並發下的測試結果：
#siege -c 500 -b -r 20 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege.. done.
Transactions: 9979 hits
Availability: 99.79 %
Elapsed time: 86.52 secs
Data transferred: 82.66 MB
Response time: 3.30 secs
Transaction rate: 115.34 trans/sec
Throughput: 0.96 MB/sec
Concurrency: 381.07
Successful transactions: 9979
Failed transactions: 21
Longest transaction: 34.80
Shortest transaction: 0.00
摘自：http://www.dk101.com/index.php/125562/viewspace-42577.html
MySQL優化實例
在Apache, PHP, MySQL的體系架構中，MySQL對於性能的影響最大，也是關鍵的核心部分。對於Discuz!論壇程序也是如此，MySQL的設置是否合理優化，直接影響到論壇的速度和承載量！同時，MySQL也是優化難度最大的一個部分，不但需要理解一些MySQL專業知識，同時還需要長時間的觀察統計並且根據經驗進行判斷，然後設置合理的參數。
下面我們了解一下MySQL優化的一些基礎，MySQL的優化我分為兩個部分，一是服務器物理硬件的優化；二是MySQL自身(my.cnf)的優化。
服務器硬件對MySQL性能的影響
磁盤尋道能力（磁盤I/O）,以目前高轉速SCSI硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID-0+1磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快； 拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過Discuz!公司技術工程的測試，使用閃存式存儲設備可比傳統硬盤速度高出6－10倍左右。
CPU 對於MySQL應用，推薦使用SMP架構的多路對稱CPU，例如：可以使用兩顆Intel Xeon 3.6GHz的CPU。
物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
MySQL自身因素當解決了上述服務器硬件製約因素後，讓我們看看MySQL自身的優化是如何操作的。對MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。
由於my.cnf文件的優化設置是與服務器硬件配置息息相關的，因而我們指定一個假想的服務器硬件環境：
CPU : 2顆 Intel Xeon 2.4GHz
內存: 4GB DDR
硬盤: SCSI 73GB
下面，我們根據以上硬件配置結合一份已經優化好的my.cnf進行說明：
# vi /etc/my.cnf
以下只列出my.cnf文件中mysqld段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld ]
port = 3306
serverid = 1
socket = /tmp/ mysql .sock
skip - locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip - name - resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
#如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip - networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
摘自：https://code.google.com/p/scriptz/wiki/MySqlOptimize
下面我們了解一下MySQL優化的一些基礎，MySQL的優化我分為兩個部分，一是服務器物理硬件的優化；二是MySQL自身(my.cnf)的優化。
服務器硬件對MySQL性能的影響
磁盤尋道能力（磁盤I/O）,以目前高轉速SCSI硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID-0+1磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快； 拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過Discuz!公司技術工程的測試，使用閃存式存儲設備可比傳統硬盤速度高出6－10倍左右。
CPU 對於MySQL應用，推薦使用SMP架構的多路對稱CPU，例如：可以使用兩顆Intel Xeon 3.6GHz的CPU。
物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
MySQL自身因素當解決了上述服務器硬件製約因素後，讓我們看看MySQL自身的優化是如何操作的。對MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。
由於my.cnf文件的優化設置是與服務器硬件配置息息相關的，因而我們指定一個假想的服務器硬件環境：
CPU : 2顆 Intel Xeon 2.4GHz
內存: 4GB DDR
硬盤: SCSI 73GB
下面，我們根據以上硬件配置結合一份已經優化好的my.cnf進行說明：
# vi /etc/my.cnf
以下只列出my.cnf文件中mysqld段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld ]
port = 3306
serverid = 1
socket = /tmp/ mysql .sock
skip - locking
#避免MySQL的外部鎖定，減少出錯機率增強穩定性。
skip - name - resolve
禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
指定MySQL可能的連接數量。當MySQL主線程在很短的時間內接收到非常多的連接請求，該參數生效，主線程花費很短的時間檢查連接並且啟動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。
試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 256M
# key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。
對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。
read_buffer_size = 4M
讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
join_buffer_size = 8M
聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享！
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
#如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況；
如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。
tmp_table_size = 256M
max_connections = 768
指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提示，則需要增大該參數值。
max_connect_errors = 10000000
wait_timeout = 10
指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。
thread_concurrency = 8
該參數取值為服務器邏輯CPU數量×2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持HT超線程，所以實際取值為4 × 2 ＝ 8
skip - networking
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！
摘自：https://code.google.com/p/scriptz/wiki/MySqlOptimize
MySQL 編譯安裝及優化
注意： 由於我是作為數據庫服務器，所以安裝系統時，只需要基本的，其餘的都可以不安裝。
新建一個名為 mysql 的用戶組
# groupadd mysql
在mysql用戶組下新建一個名為mysql的用戶
# useradd -g mysql mysql
# tar xzf mysql-5.0.70.tar.gz
# cd mysql-5.0.70
源碼編譯 MYSQL (環境 CentOS 5.2 + Intel Pentium 4 630 3.00GHz + 4G RAM ,根據具體環境做相應的變更)
# CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -msse -msse2 -msse3 -mmmx -mfpmath=sse,387 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer -Wa, -march=prescott -finline-limit=400 -fforce-addr" CC="gcc" CXX="gcc" CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -felide-constructors -fno-exceptions -fno-rtti " LDFLAGS="-Wl,-O2 -s" ./configure --prefix=/usr/local/mysql --localstatedir=/var/lib/mysql --enable-assembler --enable-thread-safe-client - -with-big-tables --with-charset=utf8 --with-collation=utf8_general_ci --without-debug --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static - -with-comment=Source --with-server-suffix=-enterprise-gpl --with-mysqld-user=mysql --with-extra-charsets=gbk,latin1 --with-pthread --with-innodb -- without-isam
至於具體的優化參數就懶得解釋了，因為每個人的具體環境不一樣。
GCC 編譯優化可以參考
1. 英文好的看官方最新文檔
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
2. 英文不好的看
http://lamp.linux.gov.cn/Linux/optimize_guide.html
至於 MySQL 的編譯優化可參與 MySQL 5.1 Reference Manual 中編譯指南。
# make
編譯的時間可能會比較長
# make install
編譯安裝完成後執行後續操作：
# cd /usr/local/mysql
# bin/mysql_install_db --user=mysql
# chown -R root . //設置權限，注意後面有一個"."
# chown -R mysql /var/lib/mysql //設置mysql目錄權限
# chgrp -R mysql . //注意後面有一個"."，同時讓mysql組用戶有同root的權限
# cp share/mysql/my-innodb-heavy-4G.cnf /etc/my.cnf
# cp share/mysql/mysql.server /etc/init.d/mysqld //開機自動啟動mysql
# chmod 755 /etc/init.d/mysqld
# chkconfig --add mysqld //讓 MySQL 隨機啟動
# /etc/init.d/mysqld start //啟動 MySQL
# bin/mysqladmin -u root password "password_for_root"
# service mysqld stop //關閉 MySQL
由於我是把它作為獨立的數據服務器，為了數據庫系統時間的準確性，最好裝 NTP 服務。
# yum install –y ntp
# crontab -e
0 03 * * * /usr/sbin/ntpdate 1.cn.pool.ntp.org
中國及亞洲 NTP 服務器
server 1.cn.pool.ntp.org
server 1.asia.pool.ntp.org
server 3.asia.pool.ntp.org
以上命令設置好後存盤。
# /sbin/service crond reload
MySQL 的優化分為兩部分，一是服務器物理硬件的優化；二是 MySQL 自身( my.cnf )的優化。
1.服務器硬件對 MySQL 性能的影響
a.磁盤尋道能力,以目前高轉速SATA硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬 PV 以上的應用，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案。
使用 RAID-0+1 磁盤陣列 ，注意不要嘗試使用 RAID-5 ， MySQL 在 RAID-5 磁盤陣列上的效率不會像你期待的那樣快；拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過一些測試，使用閃存式存儲設備可比傳統硬盤速度高出6-10倍左右。
b. CPU對於MySQL應用，推薦使用SMP架構的多路對稱CPU。
c. 物理內存對於一台使用 MySQL 的 Database Server 來說非常重要，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
2.MySQL自身因素
當解決了上述服務器硬件製約因素後，看看 MySQL 自身的優化是如何操作的。對 MySQL 自身的優化主要是對其配置文件 my.cnf 中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
由於 my.cnf 文件的優化設置是與服務器硬件配置息息相關的，下面服務器硬件環境：
CPU: Pentium 4 630 3.00GHz Threads:2
內存: 4GB DDR2 667
硬盤: SATA 160GB
我們根據以上硬件配置結合一份已經優化好的 my.cnf 進行說明：
# vi /etc/my.cnf
以下只列出 my.cnf 文件中 [mysqld] 段落中的內容，其他段落內容對 MySQL 運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
# skip-locking
避免 MySQL 的外部鎖定，減少出錯機率增強穩定性
# skip-name-resolve
禁止 MySQL 對外部連接進行 DNS 解析使用這一選項可以消除 MySQL 進行 DNS 解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則 MySQL 將無法正常處理連接請求！
注意： 如果從數據庫服務器以外的 PC 連接到 DB Server 很慢時，很可能就是這個參數未打開。
# back_log
這個值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於你的操作系統的限制將是無效的。 當你觀察你的主機進程列表，發現大量
264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL
的待連接進程時，就要加大 back_log 的值了。默認數值是50，一般384就夠了。
# key_buffer_size
這對 MyISAM 表來說非常重要。如果只是使用 MyISAM 表，可以把它設置為可用內存的30-40% 。合理的值取決於索引大小,數據量以及負載-- 記住: MyISAM 表會使用操作系統的緩存來緩存數據，因此需要留出部分內存給它們，很多情況下數據比索引大多了。儘管如此，需要總是檢查是否所有的 key_buffer 都被利用了 。 -- .MYI 文件只有1GB，而 key_buffer 卻設置為4GB的情況是非常少的，這麼做太浪費了。如果你很少使用 MyISAM 表，那麼也保留不低於16-32MB的 key_buffer_size 以適應給予磁盤的臨時表索引所需。
# sort_buffer_size
查詢排序時所能使用的緩衝區大小。 注意 ：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB 。所以，對於內存在4GB左右的服務器推薦設置為6-8M 。
# read_buffer_size
讀查詢操作所能使用的緩衝區大小。和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# join_buffer_size
聯合查詢操作所能使用的緩衝區大小，和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# query_cache_size
指定 MySQL 查詢緩衝區的大小。可以通過在 MySQL 控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
如果 Qcache_lowmem_prunes 的值非常大，則表明經常出現緩沖不夠的情況；
如果 Qcache_hits 的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝； Qcache_free_blocks ，如果該值非常大，則表明緩衝區中碎片很多。
# max_connections
指定 MySQL 允許的最大連接進程數。如果在訪問時經常出現 Too Many Connections 的錯誤提示，則需要增大該參數值。
# wait_timeout
指定一個請求的最大連接時間，對於4GB 左右內存的服務器可以設置為5-10 。
# thread_concurrency
該參數取值為服務器邏輯CPU數量×2，在本例中，如果服務器有2顆邏輯CPU，而CPU又支持 HT 超線程，所以實際取值為4 × 2 ＝ 8
# skip-networking
開啟該選項可以徹底關閉 MySQL 的 TCP/IP 連接方式，如果 WEB 服務器是以遠程連接的方式訪問 MySQL 數據庫服務器則不要開啟該選項！否則將無法正常連接！
# innodb_buffer_pool_size
這對 Innodb 表來說非常重要。 Innodb 相比 MyISAM 表對緩衝更為敏感。 MyISAM 可以在默認的 key_buffer_size 設置下運行的可以，然而 Innodb 在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於 Innodb 把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用 Innodb 的話則可以設置它高達70-80%的可用內存。如果你的數據量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。
# innodb_additional_pool_size
這個選項對性能影響並不太多，至少在有差不多足夠內存可分配的操作系統上是這樣。不過如果你仍然想設置為20MB( 或者更大) ，就需要看一下Innodb 其他需要分配的內存有多少。
# innodb_log_file_size
在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相對越高，但是要注意到可能會增加恢復時間。我經常設置為64-512MB ，跟據服務器大小而異。
# innodb_log_buffer_size
默認的設置在中等強度寫入負載以及較短事務的情況下服務器性能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置太高了，可能會浪費內存(它每秒都會刷新一次),因此無需設置超過1 秒所需的內存空間。通常8-16MB 就足夠了。越小的系統它的值越小。
# innodb_flush_logs_at_trx_commit
Crying about Innodb being 100 times slower than MyISAM ? You probably forgot to adjust this value. Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.
# table_cache
Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. It uses some OS resources and some memory but for modern hardware it is typically not the problem. 1024 is good value for applications with couple hundreds tables (remember each connection needs its own entry) if you have many connections or many tables increase it larger. I've seen values over 100.000 used.
# thread_cache
Thread creation/destructions can be expensive, which happen at each connect/disconnect. I normally set this value to at least 16. If application has large jumps in amount of concurrent connections and I see fast growth of
Threads_Created variable I boost it higher. The goal is not to have threads created in normal operation.
# query_cache
If your application is read intensive and you do not have application level caches this can be great help. Do not set it too large as it may slow things down as its maintenance may get expensive. Values from 32M to 512M normally make sense. Check it however after a while and see if it is well used. For certain workloads cache hit ratio is lower than would justify having it enabled.
Note: as you can see all of these are global variables. These variables depend on hardware and mix of storage engines, while per session variables are typically workload specific. If you have simple queries there is no reason to increase sort_buffer_size even if you have 64GB of memory to waste. Furthermore doing so may decrease performance.
I normally leave per session variable tuning to second step after I can analyze workload.
注意： 就像你看到的上面這些全局表量，它們都是依據硬件配置以及不同的存儲引擎而不同，但是會話變量通常是根據不同的負載來設定的。如果你只有一些簡單的查詢，那麼就無需增加 sort_buffer_size 的值了，儘管你有64GB的內存。搞不好也許會降低性能。
通常在分析系統負載後才來設置會話變量。
另附：如果發現你的應用日誌裡會有 too many open files 時，應修改 linux 系統的 open file 數量，也可通過以下命令來查看那個程序打開的文件數最多。
# lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
可能出現的結果如下：
131 24204
57 24244
57 24231
56 24264
其中第一行是打開的文件句柄數量，第二行是進程號。得到進程號後，我們可以通過 ps 命令得到進程的詳細內容。
# ps -aef|grep 24204
mysql 24204 24162 99 16:15 ? 00:24:25 /usr/sbin/mysqld
修改系統默認值 ulimit -HSn 4096
以上命令中，H指定了硬性大小，S指定了軟性大小，n表示設定單個進程最大的打開文件句柄數量可以修改 /etc/profile 把上面命令加到最後，然後 source /etc/profile 再通過 ulimit -a 就可以看到修改後的結果了。
關於lsof命令的用法，詳細可參考IBM技術社區中的一篇關於 lsof 的文章。
摘自：http://janwer.javaeye.com/blog/210952
新建一個名為 mysql 的用戶組
# groupadd mysql
在mysql用戶組下新建一個名為mysql的用戶
# useradd -g mysql mysql
# tar xzf mysql-5.0.70.tar.gz
# cd mysql-5.0.70
源碼編譯 MYSQL (環境 CentOS 5.2 + Intel Pentium 4 630 3.00GHz + 4G RAM ,根據具體環境做相應的變更)
# CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -msse -msse2 -msse3 -mmmx -mfpmath=sse,387 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer -Wa, -march=prescott -finline-limit=400 -fforce-addr" CC="gcc" CXX="gcc" CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -felide-constructors -fno-exceptions -fno-rtti " LDFLAGS="-Wl,-O2 -s" ./configure --prefix=/usr/local/mysql --localstatedir=/var/lib/mysql --enable-assembler --enable-thread-safe-client - -with-big-tables --with-charset=utf8 --with-collation=utf8_general_ci --without-debug --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static - -with-comment=Source --with-server-suffix=-enterprise-gpl --with-mysqld-user=mysql --with-extra-charsets=gbk,latin1 --with-pthread --with-innodb -- without-isam
至於具體的優化參數就懶得解釋了，因為每個人的具體環境不一樣。
GCC 編譯優化可以參考
1. 英文好的看官方最新文檔
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
2. 英文不好的看
http://lamp.linux.gov.cn/Linux/optimize_guide.html
至於 MySQL 的編譯優化可參與 MySQL 5.1 Reference Manual 中編譯指南。
# make
編譯的時間可能會比較長
# make install
編譯安裝完成後執行後續操作：
# cd /usr/local/mysql
# bin/mysql_install_db --user=mysql
# chown -R root . //設置權限，注意後面有一個"."
# chown -R mysql /var/lib/mysql //設置mysql目錄權限
# chgrp -R mysql . //注意後面有一個"."，同時讓mysql組用戶有同root的權限
# cp share/mysql/my-innodb-heavy-4G.cnf /etc/my.cnf
# cp share/mysql/mysql.server /etc/init.d/mysqld //開機自動啟動mysql
# chmod 755 /etc/init.d/mysqld
# chkconfig --add mysqld //讓 MySQL 隨機啟動
# /etc/init.d/mysqld start //啟動 MySQL
# bin/mysqladmin -u root password "password_for_root"
# service mysqld stop //關閉 MySQL
由於我是把它作為獨立的數據服務器，為了數據庫系統時間的準確性，最好裝 NTP 服務。
# yum install –y ntp
# crontab -e
0 03 * * * /usr/sbin/ntpdate 1.cn.pool.ntp.org
中國及亞洲 NTP 服務器
server 1.cn.pool.ntp.org
server 1.asia.pool.ntp.org
server 3.asia.pool.ntp.org
以上命令設置好後存盤。
# /sbin/service crond reload
MySQL 的優化分為兩部分，一是服務器物理硬件的優化；二是 MySQL 自身( my.cnf )的優化。
1.服務器硬件對 MySQL 性能的影響
a.磁盤尋道能力,以目前高轉速SATA硬盤(7200轉/秒)為例，這種硬盤理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁盤I/O是製約MySQL性能的最大因素之一，對於日均訪問量在100萬 PV 以上的應用，由於磁盤I/O的製約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案。
使用 RAID-0+1 磁盤陣列 ，注意不要嘗試使用 RAID-5 ， MySQL 在 RAID-5 磁盤陣列上的效率不會像你期待的那樣快；拋棄傳統的硬盤，使用速度更快的閃存式存儲設備。經過一些測試，使用閃存式存儲設備可比傳統硬盤速度高出6-10倍左右。
b. CPU對於MySQL應用，推薦使用SMP架構的多路對稱CPU。
c. 物理內存對於一台使用 MySQL 的 Database Server 來說非常重要，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。
2.MySQL自身因素
當解決了上述服務器硬件製約因素後，看看 MySQL 自身的優化是如何操作的。對 MySQL 自身的優化主要是對其配置文件 my.cnf 中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
由於 my.cnf 文件的優化設置是與服務器硬件配置息息相關的，下面服務器硬件環境：
CPU: Pentium 4 630 3.00GHz Threads:2
內存: 4GB DDR2 667
硬盤: SATA 160GB
我們根據以上硬件配置結合一份已經優化好的 my.cnf 進行說明：
# vi /etc/my.cnf
以下只列出 my.cnf 文件中 [mysqld] 段落中的內容，其他段落內容對 MySQL 運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
# skip-locking
避免 MySQL 的外部鎖定，減少出錯機率增強穩定性
# skip-name-resolve
禁止 MySQL 對外部連接進行 DNS 解析使用這一選項可以消除 MySQL 進行 DNS 解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則 MySQL 將無法正常處理連接請求！
注意： 如果從數據庫服務器以外的 PC 連接到 DB Server 很慢時，很可能就是這個參數未打開。
# back_log
這個值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於你的操作系統的限制將是無效的。 當你觀察你的主機進程列表，發現大量
264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL
的待連接進程時，就要加大 back_log 的值了。默認數值是50，一般384就夠了。
# key_buffer_size
這對 MyISAM 表來說非常重要。如果只是使用 MyISAM 表，可以把它設置為可用內存的30-40% 。合理的值取決於索引大小,數據量以及負載-- 記住: MyISAM 表會使用操作系統的緩存來緩存數據，因此需要留出部分內存給它們，很多情況下數據比索引大多了。儘管如此，需要總是檢查是否所有的 key_buffer 都被利用了 。 -- .MYI 文件只有1GB，而 key_buffer 卻設置為4GB的情況是非常少的，這麼做太浪費了。如果你很少使用 MyISAM 表，那麼也保留不低於16-32MB的 key_buffer_size 以適應給予磁盤的臨時表索引所需。
# sort_buffer_size
查詢排序時所能使用的緩衝區大小。 注意 ：該參數對應的分配內存是每連接獨占！如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB 。所以，對於內存在4GB左右的服務器推薦設置為6-8M 。
# read_buffer_size
讀查詢操作所能使用的緩衝區大小。和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# join_buffer_size
聯合查詢操作所能使用的緩衝區大小，和 sort_buffer_size 一樣，該參數對應的分配內存也是每連接獨享！
# query_cache_size
指定 MySQL 查詢緩衝區的大小。可以通過在 MySQL 控制台執行以下命令觀察：
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
如果 Qcache_lowmem_prunes 的值非常大，則表明經常出現緩沖不夠的情況；
如果 Qcache_hits 的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝； Qcache_free_blocks ，如果該值非常大，則表明緩衝區中碎片很多。
# max_connections
指定 MySQL 允許的最大連接進程數。如果在訪問時經常出現 Too Many Connections 的錯誤提示，則需要增大該參數值。
# wait_timeout
指定一個請求的最大連接時間，對於4GB 左右內存的服務器可以設置為5-10 。
# thread_concurrency
該參數取值為服務器邏輯CPU數量×2，在本例中，如果服務器有2顆邏輯CPU，而CPU又支持 HT 超線程，所以實際取值為4 × 2 ＝ 8
# skip-networking
開啟該選項可以徹底關閉 MySQL 的 TCP/IP 連接方式，如果 WEB 服務器是以遠程連接的方式訪問 MySQL 數據庫服務器則不要開啟該選項！否則將無法正常連接！
# innodb_buffer_pool_size
這對 Innodb 表來說非常重要。 Innodb 相比 MyISAM 表對緩衝更為敏感。 MyISAM 可以在默認的 key_buffer_size 設置下運行的可以，然而 Innodb 在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於 Innodb 把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用 Innodb 的話則可以設置它高達70-80%的可用內存。如果你的數據量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。
# innodb_additional_pool_size
這個選項對性能影響並不太多，至少在有差不多足夠內存可分配的操作系統上是這樣。不過如果你仍然想設置為20MB( 或者更大) ，就需要看一下Innodb 其他需要分配的內存有多少。
# innodb_log_file_size
在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相對越高，但是要注意到可能會增加恢復時間。我經常設置為64-512MB ，跟據服務器大小而異。
# innodb_log_buffer_size
默認的設置在中等強度寫入負載以及較短事務的情況下服務器性能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置太高了，可能會浪費內存(它每秒都會刷新一次),因此無需設置超過1 秒所需的內存空間。通常8-16MB 就足夠了。越小的系統它的值越小。
# innodb_flush_logs_at_trx_commit
Crying about Innodb being 100 times slower than MyISAM ? You probably forgot to adjust this value. Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.
# table_cache
Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. It uses some OS resources and some memory but for modern hardware it is typically not the problem. 1024 is good value for applications with couple hundreds tables (remember each connection needs its own entry) if you have many connections or many tables increase it larger. I've seen values over 100.000 used.
# thread_cache
Thread creation/destructions can be expensive, which happen at each connect/disconnect. I normally set this value to at least 16. If application has large jumps in amount of concurrent connections and I see fast growth of
Threads_Created variable I boost it higher. The goal is not to have threads created in normal operation.
# query_cache
If your application is read intensive and you do not have application level caches this can be great help. Do not set it too large as it may slow things down as its maintenance may get expensive. Values from 32M to 512M normally make sense. Check it however after a while and see if it is well used. For certain workloads cache hit ratio is lower than would justify having it enabled.
Note: as you can see all of these are global variables. These variables depend on hardware and mix of storage engines, while per session variables are typically workload specific. If you have simple queries there is no reason to increase sort_buffer_size even if you have 64GB of memory to waste. Furthermore doing so may decrease performance.
I normally leave per session variable tuning to second step after I can analyze workload.
注意： 就像你看到的上面這些全局表量，它們都是依據硬件配置以及不同的存儲引擎而不同，但是會話變量通常是根據不同的負載來設定的。如果你只有一些簡單的查詢，那麼就無需增加 sort_buffer_size 的值了，儘管你有64GB的內存。搞不好也許會降低性能。
通常在分析系統負載後才來設置會話變量。
另附：如果發現你的應用日誌裡會有 too many open files 時，應修改 linux 系統的 open file 數量，也可通過以下命令來查看那個程序打開的文件數最多。
# lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
可能出現的結果如下：
131 24204
57 24244
57 24231
56 24264
其中第一行是打開的文件句柄數量，第二行是進程號。得到進程號後，我們可以通過 ps 命令得到進程的詳細內容。
# ps -aef|grep 24204
mysql 24204 24162 99 16:15 ? 00:24:25 /usr/sbin/mysqld
修改系統默認值 ulimit -HSn 4096
以上命令中，H指定了硬性大小，S指定了軟性大小，n表示設定單個進程最大的打開文件句柄數量可以修改 /etc/profile 把上面命令加到最後，然後 source /etc/profile 再通過 ulimit -a 就可以看到修改後的結果了。
關於lsof命令的用法，詳細可參考IBM技術社區中的一篇關於 lsof 的文章。
摘自：http://janwer.javaeye.com/blog/210952
2010年5月25日 星期二
CentOS 5: Eaccelerator Installation
eAccelerator is a free open-source PHP accelerator, optimizer, and dynamic content cache. It typically reduces server load and increases the speed of your PHP code by 1-10 times.
Through SSH.
yum install php-devel
yum groupinstall 'Development Tools'
Change directory.
cd /tmp
Get the file.
wget http://bart.eaccelerator.net/source/0.9.5.2/eaccelerator-0.9.5.2.tar.bz2
tar xvfj eaccelerator-0.9.5.2.tar.bz2
Change directory.
cd eaccelerator-0.9.5.2
Phpize.
phpize
./configure
Install it.
make
make install
Create the file /etc/php.d/eaccelerator.ini
vi /etc/php.d/eaccelerator.ini
Enter.
extension="eaccelerator.so"
eaccelerator.shm_size="0"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
Create /var/cache/eaccelerator ditrectory
mkdir -p /var/cache/eaccelerator
Change permission.
chmod 0777 /var/cache/eaccelerator
Restart Apache.
/etc/init.d/httpd restart
摘自：http://www.php.ph/2007/12/21/centos-5-eaccelerator-installation/
Through SSH.
yum install php-devel
yum groupinstall 'Development Tools'
Change directory.
cd /tmp
Get the file.
wget http://bart.eaccelerator.net/source/0.9.5.2/eaccelerator-0.9.5.2.tar.bz2
tar xvfj eaccelerator-0.9.5.2.tar.bz2
Change directory.
cd eaccelerator-0.9.5.2
Phpize.
phpize
./configure
Install it.
make
make install
Create the file /etc/php.d/eaccelerator.ini
vi /etc/php.d/eaccelerator.ini
Enter.
extension="eaccelerator.so"
eaccelerator.shm_size="0"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
Create /var/cache/eaccelerator ditrectory
mkdir -p /var/cache/eaccelerator
Change permission.
chmod 0777 /var/cache/eaccelerator
Restart Apache.
/etc/init.d/httpd restart
摘自：http://www.php.ph/2007/12/21/centos-5-eaccelerator-installation/
2010年5月23日 星期日
tar --exclude語法
Example
/path/to/tarFolder
/path/to/tarFolder/exclude1
/path/to/tarFolder/exclude2
/path/to/tarFolder/a/exclude3
$ cd /path/to
$ tar -cvpf tarFolder.tar tarFolder --exclude="tarFolder/exclude1/*" --exclude="tarFolder/exclude2/*" --exclude="tarFolder/a/exclude3/*"
PS : --exclude="tarFolder/exclude1/*" <--一定要是相對路徑 & 使用雙引號
/path/to/tarFolder
/path/to/tarFolder/exclude1
/path/to/tarFolder/exclude2
/path/to/tarFolder/a/exclude3
$ cd /path/to
$ tar -cvpf tarFolder.tar tarFolder --exclude="tarFolder/exclude1/*" --exclude="tarFolder/exclude2/*" --exclude="tarFolder/a/exclude3/*"
PS : --exclude="tarFolder/exclude1/*" <--一定要是相對路徑 & 使用雙引號
[Solved]phpThumb far=C 無法成功
如果linux有灌ImageMagick,phpThumb會預設使用ImageMagick來產生圖檔
如果沒有ImagMagick,才會使用php gd librabry來產生圖檔
far=C在ImageMagick無法正常運作
所以解決方法是將linux下的ImageMagick移除
$ rpm -e imageMagick
如果沒有ImagMagick,才會使用php gd librabry來產生圖檔
far=C在ImageMagick無法正常運作
所以解決方法是將linux下的ImageMagick移除
$ rpm -e imageMagick
2010年5月19日 星期三
解決Lost connection to MySQL server at 'reading initial communication packet'的方法
當通過TCP/IP連接MySQL遠程主機時，出現ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 104 。
如果是在linux shell命令行中直接打mysql命令，能夠順利連上MySQL，執行查詢語句也比較正常，但如果執行STOP SLAVE;命令時就隨機出現ERROR 2013 (HY000): Lost connection to MySQL server during query問題。而如果把操作命令寫到腳本文件再去執行該腳本文件的話，則必然出現Lost connection to MySQL server at 'reading initial communication packet', system error: 111
要是無論通過什麼途徑遠程訪問都出現錯誤可以認為是系統有防火牆之類的限制，但現在這種奇怪的抽筋現象讓人百思不得其解。最後找到的解決方法是在my.cnf裡面的[mysqld]段增加一個啟動參數
skip-name-resolve
問題消失。
摘自：http://www.goalercn.com/article/article.php?id=1796
如果是在linux shell命令行中直接打mysql命令，能夠順利連上MySQL，執行查詢語句也比較正常，但如果執行STOP SLAVE;命令時就隨機出現ERROR 2013 (HY000): Lost connection to MySQL server during query問題。而如果把操作命令寫到腳本文件再去執行該腳本文件的話，則必然出現Lost connection to MySQL server at 'reading initial communication packet', system error: 111
要是無論通過什麼途徑遠程訪問都出現錯誤可以認為是系統有防火牆之類的限制，但現在這種奇怪的抽筋現象讓人百思不得其解。最後找到的解決方法是在my.cnf裡面的[mysqld]段增加一個啟動參數
skip-name-resolve
問題消失。
摘自：http://www.goalercn.com/article/article.php?id=1796
How to set permanent ulimit
First of all, it depends on whether you want this limit changed for
all users, all users of a group, or just one user, such as a database
server's userid. I'll give you an example for a single user.
I hope you can adapt these instructions if that's not the case.
Let's suppose that user "database" needs to be able to open up to
10240 files at once.
In /etc/security/limits.conf, add the following line:
database hard nofile 10240
In /home/database/.bash_profile add the following line:
ulimit -n 10240
Now shutdown and reboot. Now, whenever "database" logs in, his
file limit will be 10240. This assumes that the login shell for
database is bash. Of course, if a daemon needs these
privileges, this won't work, since there is no interactive
login shell. You may need to modify the daemon's start-up script
in this case to add the ulimit command.
If you want the limit to apply to all users, edit /etc/profile
instead of ~/.bash_profile. And in /etc/security/limits.conf,
substitute an asterisk (*) for the userid "database". Again,
this assumes an interactive login shell of bash. Daemons, since they don't
have an interactive login shell, won't execute that ulimit
command. You'll have to find a place to put it. The startup
script in /etc/init.d might be a good place. But watch for
upgrades to the startup script which remove the modification.
If someone else has a better idea for how to implement this,
let me know.
摘自：http://linux.derkeiler.com/Mailing-Lists/Debian/2010-01/msg01906.html
all users, all users of a group, or just one user, such as a database
server's userid. I'll give you an example for a single user.
I hope you can adapt these instructions if that's not the case.
Let's suppose that user "database" needs to be able to open up to
10240 files at once.
In /etc/security/limits.conf, add the following line:
database hard nofile 10240
In /home/database/.bash_profile add the following line:
ulimit -n 10240
Now shutdown and reboot. Now, whenever "database" logs in, his
file limit will be 10240. This assumes that the login shell for
database is bash. Of course, if a daemon needs these
privileges, this won't work, since there is no interactive
login shell. You may need to modify the daemon's start-up script
in this case to add the ulimit command.
If you want the limit to apply to all users, edit /etc/profile
instead of ~/.bash_profile. And in /etc/security/limits.conf,
substitute an asterisk (*) for the userid "database". Again,
this assumes an interactive login shell of bash. Daemons, since they don't
have an interactive login shell, won't execute that ulimit
command. You'll have to find a place to put it. The startup
script in /etc/init.d might be a good place. But watch for
upgrades to the startup script which remove the modification.
If someone else has a better idea for how to implement this,
let me know.
摘自：http://linux.derkeiler.com/Mailing-Lists/Debian/2010-01/msg01906.html
2010年5月18日 星期二
RHEL5.3 Tuning-Tweaking Linux network parameters
Allow the TCP stack to reuse sockets in the TIME-WAIT state:
# Allow reuse/recycling of TIME-WAIT sockets for new connections:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Lowering the FIN Timeout value will shorten the TIME_WAIT state, freeing up resources for new connections. It is recommended when running applications that constantly create a lot of new connections – ie. a web server. The default is 60, and Sun recommends a value in the 15-30 range.
# Lower FIN timeout (default: 60):
net.ipv4.tcp_fin_timeout = 15
Tweak the TCP KeepAlive values:
# Wait time between isAlive interval probes (default: 75, recommended: 15-30):
net.ipv4.tcp_keepalive_intvl = 15
# Number of probes before timing out (default: 9, recommended: 5):
net.ipv4.tcp_keepalive_probes = 5
The default maximum for send/receive windows is 128Kb and it’s recommended to boost this to 8Mb:
# Maximum TCP Send Window:
net.core.wmem_max = 8388608
# Maximum TCP Receive Window:
net.core.rmem_max = 8388608
Also tweak the IPv4 rcv/snd buffers to use a maximum of 8Mb:
# Memory reserved for TCP rcv buffers (default: 4Kb 85Kb 4Mb):
net.ipv4.tcp_rmem = 4096 87380 8388608
# Memory reserved for TCP snd buffers (default: 4Kb 16Kb 4Mb):
net.ipv4.tcp_wmem = 4096 87380 8388608
If you’re using a lot of connections, you should make more local ports available. Default range gives a total of 28232 ports available. Increasing this range to 4096-65535 will give you 61439 local ports:
# Available local port range (default: 32768 61000):
net.ipv4.ip_local_port_range = 4096 65536
摘自：http://blog.spind.net/2008/11/28/tweaking-linux-network-parameters/
# Allow reuse/recycling of TIME-WAIT sockets for new connections:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Lowering the FIN Timeout value will shorten the TIME_WAIT state, freeing up resources for new connections. It is recommended when running applications that constantly create a lot of new connections – ie. a web server. The default is 60, and Sun recommends a value in the 15-30 range.
# Lower FIN timeout (default: 60):
net.ipv4.tcp_fin_timeout = 15
Tweak the TCP KeepAlive values:
# Wait time between isAlive interval probes (default: 75, recommended: 15-30):
net.ipv4.tcp_keepalive_intvl = 15
# Number of probes before timing out (default: 9, recommended: 5):
net.ipv4.tcp_keepalive_probes = 5
The default maximum for send/receive windows is 128Kb and it’s recommended to boost this to 8Mb:
# Maximum TCP Send Window:
net.core.wmem_max = 8388608
# Maximum TCP Receive Window:
net.core.rmem_max = 8388608
Also tweak the IPv4 rcv/snd buffers to use a maximum of 8Mb:
# Memory reserved for TCP rcv buffers (default: 4Kb 85Kb 4Mb):
net.ipv4.tcp_rmem = 4096 87380 8388608
# Memory reserved for TCP snd buffers (default: 4Kb 16Kb 4Mb):
net.ipv4.tcp_wmem = 4096 87380 8388608
If you’re using a lot of connections, you should make more local ports available. Default range gives a total of 28232 ports available. Increasing this range to 4096-65535 will give you 61439 local ports:
# Available local port range (default: 32768 61000):
net.ipv4.ip_local_port_range = 4096 65536
摘自：http://blog.spind.net/2008/11/28/tweaking-linux-network-parameters/
RHEL5 Tuning
There are a lot of differences between Linux version 2.4 and 2.6, so first we'll cover the tuning issues that are the same in both 2.4 and 2.6. To change TCP settings in, you add the entries below to the file /etc/sysctl.conf, and then run "sysctl -p".
Like all operating systems, the default maximum Linux TCP buffer sizes are way too small. I suggest changing them to the following settings:
# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
You should also verify that the following are all set to the default value of 1
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_sack
Note: you should leave tcp_mem alone. The defaults are fine.
You can achieve increases in bandwidth of up to 10x by doing this on some long, fast paths. This is only a good idea for Gigabit Ethernet connected hosts, and may have other side effects such as uneven sharing between multiple streams.
Also, I've been told that for some network paths, using the Linux 'tc' (traffic control) system to pace traffic out of the host can help improve total throughput.
參考網站：http://fasterdata.es.net/TCP-tuning/linux.html
Like all operating systems, the default maximum Linux TCP buffer sizes are way too small. I suggest changing them to the following settings:
# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
You should also verify that the following are all set to the default value of 1
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_sack
Note: you should leave tcp_mem alone. The defaults are fine.
You can achieve increases in bandwidth of up to 10x by doing this on some long, fast paths. This is only a good idea for Gigabit Ethernet connected hosts, and may have other side effects such as uneven sharing between multiple streams.
Also, I've been told that for some network paths, using the Linux 'tc' (traffic control) system to pace traffic out of the host can help improve total throughput.
參考網站：http://fasterdata.es.net/TCP-tuning/linux.html
2010年5月14日 星期五
2010年5月13日 星期四
什麼是UTF 8
以前電腦剛開始發展時，每一個國家都各自發展自己的文字系統，所以就會有中文系統日文系等，可是大家在發展的過程中並沒有相互參考文字在電腦裡的編碼方式，所以同一個碼在不同的地區文字系統裡並不代表同一個字，例如台灣使用big5碼大陸使用gb碼，所以台灣的big5編碼文件拿到大陸用gb編碼系統打開，就是一片亂碼，這個問題在有網際網路以後情況就變得更嚴重，所這時就有一個單位www.unicode.org，就提出一個構想，就是何不把全世界的文字作一個統一的編碼，讓全世界的電腦都可以用，如果這樣的話，就不會再發生中文的文件拿去日本的電腦打開是亂碼的情況，這就是unicode了，現在unicode編到第8代，就utf-8
================
為了讓軟體產品支援多種語系，就必須讓軟體認得各種語言的不同編碼表，但卻為軟體開發帶來更多的複雜性與不便。Unicode 是一套能夠解決這個問題的世界性編碼標準，它為每一個字元提供與作業平台、程式、語言相獨立的單一編碼。簡言之，Unicode 詳列了世界上所有使用到的字元，並且為它們各自編派一個獨立單一的號碼。Unicode 出現之前，有多達好幾百種不同的編碼系統，試圖分派這些編號，但沒有單獨一種編碼包含足夠的字元。舉例而言，歐盟就得需要數種不同編碼，以便廣納其所有語言。對於單一語言，如英文，也沒有單一種編碼可以充份表達其所有文字、標點，以及共通的專門符號。更糟的是，這些編碼系統彼此衝突，兩套編碼系統會在兩個完全不同的字元上，使用相同的編號，或反之亦然。對於有必要支援多種不同編碼的電腦系統，不同編碼或平台上的資料交換，都將面臨資料失真的風險。
Unicode 已受到產業的廣泛接受，如 Apple、HP、IBM、JustSystem、Microsoft、Oracle、SAP、Sun、Sybase、Unisys 等多家領導廠商都表明支援。Unicode 更受到 XML、Java、ECMAScript （JavaScript ）、LDAP、CORBA 3.0、WML 等標準的採納。支援 Unicode 的作業系統與瀏覽器等產品也為數不少。Unicode 標準的興起，加上支援工具的推波助瀾，成為全球化軟體技術趨勢中相當顯著的光芒之一。
Unicode 的最初目標是希望採用 16 位元編碼指定超過 65,000 個字元，然而要讓現存所有軟體適應 16 位元資料，必須花費可觀的重新開發成本。Unicode 於是發展出三種不同的編碼形式 UTF-8、UTF-16 和 UTF-32，這三種格式針對同樣的共同字元加以編碼，允許相同的資料以位元組、字組或雙字組形式傳送，並且可在無資料損失下轉換成其它格式。
UTF-8 最常見於 HTML 與相關協定中。此一格式有趣的地方是原先存在於 ASCII 的字元和 UTF-8 中的同一字元，擁有同樣的的字元值。例如，A 在 ASCII 和 UTF-8 中都是 0x41。大多數現有軟體不需重新撰寫，便可使用轉換成 UTF-8 的 Unicode 字元。UTF -16 使用在需要同時考量字元存取效率和儲存空間的環境。對於一些無須考慮記憶體空間，但要求字元存取必須是固定長度且佔用單一編碼單位（single code unit）的環境，UTF-32 則是最佳的選擇。
=================================
1. UTF-8 只是編碼演算法，他用來對 UNICODE 編碼規則的字及進行編碼。
2. UNICODE 的 code point 有 256*256*256*256 個字，涵蓋全世界幾乎所有國家的語言文字，中文的部分是其中 CJK 的子區段。
3. BIG-5 是台灣地區自己的標準，他是一個簡單編碼演算法，也是一個編碼規則。
4. BIG-5 使用兩個 byte 的固定長度編碼， UTF-8 使用 1 到 4 個 byte 的浮動長度編碼 ( 例如字母 C ，在 UTF-8 只會用一個 byte ，中文字大部分會有3 個 byte ， 也會有2或者4個byte的機會。 Big5 對英文字母沒有編進去 )
5. 使用 UTF-8 編碼，軟體處理文字會很方便，因為不用同時判斷到底字串哪一部分是ISO8859-1 的編碼，哪些是 Big5 ，這樣會讓軟體處理字串變的非常慢，而UTF-8 的設計，把同一個 code point 的編碼 byte stream 透過前幾個 bit的規則換算，可以讓軟體馬上知道到底這個 byte 是屬於一個 code point 編碼的第幾個 byte ，而可以很快的處理字串的單字切割，同時也讓字串的處理變的更快更有效率。 換句話說，使用 UTF-8 (應該說 UNICODE)軟體就不用在處理字串的時候去不斷的判斷，這個字是不是 Big5 或者其他編碼，這個字與其他字該怎麼切割，因為所有字都在 UNICODE 。
6. 因為顧及資料儲存體的使用要節省，同時也因為可以跟現有的電腦系統已 Byte 作為字串處理的基本單位做法相容，所以 UTF-8 目前最好的使用方法。 但是根據 ISO10646 的制定概念，如果儲存體不是考量重點的話，而且作業系統可以支援，使用UTF-16 甚至 UTF-32 是效率更好的選擇。
政府不出面整合，那是因為我們沒有能力引導， UNICODE 是國際標準，他要作到的是全世界的共同整合，而我們的 Big5 只為我們自己設計。 字碼不會混亂下去的，因為UNICODE 已經是趨勢， Windows XP 已經採用 UNICODE 作為系統的處理模式，你看到的 Big5 只是顯示的時候幫你轉的， XP 的核心根本就是使用 UNICODE 了。 現在的混亂只是因為舊的系統幾乎採用 Big5 ，為了向前相容，所以得混在一起用。 將來一定會慢慢走向 Unicode 的。
摘自:http://isochen.pixnet.net/blog/post/25668746
================
為了讓軟體產品支援多種語系，就必須讓軟體認得各種語言的不同編碼表，但卻為軟體開發帶來更多的複雜性與不便。Unicode 是一套能夠解決這個問題的世界性編碼標準，它為每一個字元提供與作業平台、程式、語言相獨立的單一編碼。簡言之，Unicode 詳列了世界上所有使用到的字元，並且為它們各自編派一個獨立單一的號碼。Unicode 出現之前，有多達好幾百種不同的編碼系統，試圖分派這些編號，但沒有單獨一種編碼包含足夠的字元。舉例而言，歐盟就得需要數種不同編碼，以便廣納其所有語言。對於單一語言，如英文，也沒有單一種編碼可以充份表達其所有文字、標點，以及共通的專門符號。更糟的是，這些編碼系統彼此衝突，兩套編碼系統會在兩個完全不同的字元上，使用相同的編號，或反之亦然。對於有必要支援多種不同編碼的電腦系統，不同編碼或平台上的資料交換，都將面臨資料失真的風險。
Unicode 已受到產業的廣泛接受，如 Apple、HP、IBM、JustSystem、Microsoft、Oracle、SAP、Sun、Sybase、Unisys 等多家領導廠商都表明支援。Unicode 更受到 XML、Java、ECMAScript （JavaScript ）、LDAP、CORBA 3.0、WML 等標準的採納。支援 Unicode 的作業系統與瀏覽器等產品也為數不少。Unicode 標準的興起，加上支援工具的推波助瀾，成為全球化軟體技術趨勢中相當顯著的光芒之一。
Unicode 的最初目標是希望採用 16 位元編碼指定超過 65,000 個字元，然而要讓現存所有軟體適應 16 位元資料，必須花費可觀的重新開發成本。Unicode 於是發展出三種不同的編碼形式 UTF-8、UTF-16 和 UTF-32，這三種格式針對同樣的共同字元加以編碼，允許相同的資料以位元組、字組或雙字組形式傳送，並且可在無資料損失下轉換成其它格式。
UTF-8 最常見於 HTML 與相關協定中。此一格式有趣的地方是原先存在於 ASCII 的字元和 UTF-8 中的同一字元，擁有同樣的的字元值。例如，A 在 ASCII 和 UTF-8 中都是 0x41。大多數現有軟體不需重新撰寫，便可使用轉換成 UTF-8 的 Unicode 字元。UTF -16 使用在需要同時考量字元存取效率和儲存空間的環境。對於一些無須考慮記憶體空間，但要求字元存取必須是固定長度且佔用單一編碼單位（single code unit）的環境，UTF-32 則是最佳的選擇。
=================================
1. UTF-8 只是編碼演算法，他用來對 UNICODE 編碼規則的字及進行編碼。
2. UNICODE 的 code point 有 256*256*256*256 個字，涵蓋全世界幾乎所有國家的語言文字，中文的部分是其中 CJK 的子區段。
3. BIG-5 是台灣地區自己的標準，他是一個簡單編碼演算法，也是一個編碼規則。
4. BIG-5 使用兩個 byte 的固定長度編碼， UTF-8 使用 1 到 4 個 byte 的浮動長度編碼 ( 例如字母 C ，在 UTF-8 只會用一個 byte ，中文字大部分會有3 個 byte ， 也會有2或者4個byte的機會。 Big5 對英文字母沒有編進去 )
5. 使用 UTF-8 編碼，軟體處理文字會很方便，因為不用同時判斷到底字串哪一部分是ISO8859-1 的編碼，哪些是 Big5 ，這樣會讓軟體處理字串變的非常慢，而UTF-8 的設計，把同一個 code point 的編碼 byte stream 透過前幾個 bit的規則換算，可以讓軟體馬上知道到底這個 byte 是屬於一個 code point 編碼的第幾個 byte ，而可以很快的處理字串的單字切割，同時也讓字串的處理變的更快更有效率。 換句話說，使用 UTF-8 (應該說 UNICODE)軟體就不用在處理字串的時候去不斷的判斷，這個字是不是 Big5 或者其他編碼，這個字與其他字該怎麼切割，因為所有字都在 UNICODE 。
6. 因為顧及資料儲存體的使用要節省，同時也因為可以跟現有的電腦系統已 Byte 作為字串處理的基本單位做法相容，所以 UTF-8 目前最好的使用方法。 但是根據 ISO10646 的制定概念，如果儲存體不是考量重點的話，而且作業系統可以支援，使用UTF-16 甚至 UTF-32 是效率更好的選擇。
政府不出面整合，那是因為我們沒有能力引導， UNICODE 是國際標準，他要作到的是全世界的共同整合，而我們的 Big5 只為我們自己設計。 字碼不會混亂下去的，因為UNICODE 已經是趨勢， Windows XP 已經採用 UNICODE 作為系統的處理模式，你看到的 Big5 只是顯示的時候幫你轉的， XP 的核心根本就是使用 UNICODE 了。 現在的混亂只是因為舊的系統幾乎採用 Big5 ，為了向前相容，所以得混在一起用。 將來一定會慢慢走向 Unicode 的。
摘自:http://isochen.pixnet.net/blog/post/25668746
2010年5月5日 星期三
訂閱：
文章 (Atom)
發表文章
