eAccelerator 是一个免费开源的PHP加速、优化、编译和动态缓存的项目,它可以通过缓存PHP代码编译后的结果来提高PHP脚本的性能,使得一向很复杂和离我们很远的PHP脚本编译问题完全得到解决。通过使用eAccelerator,可以优化你的PHP代码执行速度,降低服务器负载,可以提高PHP应用执行速度最高达10倍。
eAccelerator 项目诞生于2004年,当时它是作为 Turck MMCache 项目的一个分支提出并投入开发的。 Turck MMCache 由 Dmitry Stogov 开发,是个非常优秀的PHP内存缓存加速系统,如今仍然有很大部分 eAccelerator 的代码应用到该项目中,目前该项目有很长时间没有更新了,对于最新的PHP5.x的支持还未推出。
eAccelerator 通过把经过编译后的PHP代码缓存到共享内存中,并在用户访问的时候直接调用从而起到高效的加速作用。它的效率非常高,从创建共享内存到查找编译后的代码都在非常短的时间内完成,对于不能缓存到共享内存中的文件和代码,eAccelerator还可以把他们缓存到系统磁盘上。
eAccelerator 同样还支持PHP代码的编译和解释执行,你可以通过encoder.php脚本来对php代码进行编译达到保护代码的目的,经过编译后的代码必须运行在安装了eAccelerator的环境下。eAccelerator编译后的代码不能被反编译,它不象其他一些编译工具那样可以进行反编译,这将使得代码更加安全和高效。
参考:http://blog.lixiphp.com/centos-configuration-php-eaccelerator/
FreeBSD:(老乡的博客)
前一段时间完成了服务器从FreeBSD4.10到6.1的升级,同时把PHP也升级到了最新的PHP5.1.4,Apache也升级到了最新的Apache2.2,为了更好的提高系统的性能,考虑对PHP再进行一些优化,前两年接触过MMCache和eAccelerator,尤其对eAccelerator非常喜欢,这次优化也选择了它,下面整理一些文档和大家分享。
参考:
http://www.toplee.com/blog/100.html
我从来不写文章,是IT届里的搬运工,呵呵,农夫山泉,有点甜!!!
eAccelerator 项目诞生于2004年,当时它是作为 Turck MMCache 项目的一个分支提出并投入开发的。 Turck MMCache 由 Dmitry Stogov 开发,是个非常优秀的PHP内存缓存加速系统,如今仍然有很大部分 eAccelerator 的代码应用到该项目中,目前该项目有很长时间没有更新了,对于最新的PHP5.x的支持还未推出。
eAccelerator 通过把经过编译后的PHP代码缓存到共享内存中,并在用户访问的时候直接调用从而起到高效的加速作用。它的效率非常高,从创建共享内存到查找编译后的代码都在非常短的时间内完成,对于不能缓存到共享内存中的文件和代码,eAccelerator还可以把他们缓存到系统磁盘上。
eAccelerator 同样还支持PHP代码的编译和解释执行,你可以通过encoder.php脚本来对php代码进行编译达到保护代码的目的,经过编译后的代码必须运行在安装了eAccelerator的环境下。eAccelerator编译后的代码不能被反编译,它不象其他一些编译工具那样可以进行反编译,这将使得代码更加安全和高效。
参考:http://blog.lixiphp.com/centos-configuration-php-eaccelerator/
FreeBSD:(老乡的博客)
前一段时间完成了服务器从FreeBSD4.10到6.1的升级,同时把PHP也升级到了最新的PHP5.1.4,Apache也升级到了最新的Apache2.2,为了更好的提高系统的性能,考虑对PHP再进行一些优化,前两年接触过MMCache和eAccelerator,尤其对eAccelerator非常喜欢,这次优化也选择了它,下面整理一些文档和大家分享。
参考:
http://www.toplee.com/blog/100.html
我从来不写文章,是IT届里的搬运工,呵呵,农夫山泉,有点甜!!!
[root@localhost ~]# nmap -sT localhost
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-09-30 02:45 CST
Interesting ports on localhost.localdomain (127.0.0.1):
Not shown: 1674 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
766/tcp open unknown
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-09-30 02:45 CST
Interesting ports on localhost.localdomain (127.0.0.1):
Not shown: 1674 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
766/tcp open unknown
阅读全文
【from: Learning the bash shell】
用户主目录下的这些文件对bash有特殊含义。它们在用户登录或调用另一bash shell时给出了一种自动建立其登录帐号环境的方式,并允许退出时执行各种命令。这些文件存在于用户主目录下,其外置依赖于系统管理员对用户帐号的设置。如果这些文件不存在,用户登录使用默认系统文件/etc/profie。可以使用流行的文本编辑器轻易的创建自己的bash文件。
最重要的bash文件是.bash_profile,它在用户每次登录到系统时被读取,其中包含的命令被bash执行。如果查看一下自己的.bash_profile,可能会发现类似下面的行:
这些行定义了用户登录帐号的基本环境,在已存在行的后面可以编辑自己的.bash_profile,直到退出再次登录,该文件被重新读取后,.bash_profile中键入的内容才会生效。可以使用source命令或者匿名命令(.),如:source .bash_profile、. .bash_profile。
bash允许有.bash_profile的两个同义文件:来源于C shell的.login的.bash_login以及来源于Bourne shell和Korn shell文件的.profile的.profile。登录时三者中只有一个被读取,如果用户根目录下.bash_profile不存在,则bash查找.bash_login,如果它不存在,则查找.profile。
bash查找这些同义文件的好处是,如果曾经用过Bourne shell,你可以保留它,如果需要加入特定的bash命令,可以将它们放入.bash_profile中并在后面跟一条命令source .profile。登录时,所有特定的bash命令均被执行,然后bash将会调用.profile,执行其保留的命令。即使决定仍使用Bourne shell,也不必修改已存在的文件,类似的方法也可以用于.bash_login和C shell的.login,但由于这些shell基本语法的差异性,这不是一个好主意。
.bash_profile只被登录shell读取并执行。如果你通过在命令行上键入bash启动一个新的shell,他就会试图读取.bashrc中的命令。这种策略给出将登录是需要的启动命令和运行一个子shell所需的命令分离开的灵活性。如果你需要在登录shell和启动子shell命令是进行一样的操作,可以在.bash_profile中使用source命令执行.bashrc。如果.bashrc不存在,那么启动一个子shell时就没有命令被执行。
文件.bash_logout在每次登录shell退出时被读取并执行。它提供了定制用户环境的功能。如果要执行诸如删除帐号内临时文件或记录登录系统所花时间命令,则可将这些命令放在.bash_logout内。该文件不必一定存在与帐号内,如果不存在,退出时不再执行其他命令。
来源:http://hi.baidu.com/hongszh/blog/item/76d9885094a107618435242d.html
用户主目录下的这些文件对bash有特殊含义。它们在用户登录或调用另一bash shell时给出了一种自动建立其登录帐号环境的方式,并允许退出时执行各种命令。这些文件存在于用户主目录下,其外置依赖于系统管理员对用户帐号的设置。如果这些文件不存在,用户登录使用默认系统文件/etc/profie。可以使用流行的文本编辑器轻易的创建自己的bash文件。
最重要的bash文件是.bash_profile,它在用户每次登录到系统时被读取,其中包含的命令被bash执行。如果查看一下自己的.bash_profile,可能会发现类似下面的行:
这些行定义了用户登录帐号的基本环境,在已存在行的后面可以编辑自己的.bash_profile,直到退出再次登录,该文件被重新读取后,.bash_profile中键入的内容才会生效。可以使用source命令或者匿名命令(.),如:source .bash_profile、. .bash_profile。
bash允许有.bash_profile的两个同义文件:来源于C shell的.login的.bash_login以及来源于Bourne shell和Korn shell文件的.profile的.profile。登录时三者中只有一个被读取,如果用户根目录下.bash_profile不存在,则bash查找.bash_login,如果它不存在,则查找.profile。
bash查找这些同义文件的好处是,如果曾经用过Bourne shell,你可以保留它,如果需要加入特定的bash命令,可以将它们放入.bash_profile中并在后面跟一条命令source .profile。登录时,所有特定的bash命令均被执行,然后bash将会调用.profile,执行其保留的命令。即使决定仍使用Bourne shell,也不必修改已存在的文件,类似的方法也可以用于.bash_login和C shell的.login,但由于这些shell基本语法的差异性,这不是一个好主意。
.bash_profile只被登录shell读取并执行。如果你通过在命令行上键入bash启动一个新的shell,他就会试图读取.bashrc中的命令。这种策略给出将登录是需要的启动命令和运行一个子shell所需的命令分离开的灵活性。如果你需要在登录shell和启动子shell命令是进行一样的操作,可以在.bash_profile中使用source命令执行.bashrc。如果.bashrc不存在,那么启动一个子shell时就没有命令被执行。
文件.bash_logout在每次登录shell退出时被读取并执行。它提供了定制用户环境的功能。如果要执行诸如删除帐号内临时文件或记录登录系统所花时间命令,则可将这些命令放在.bash_logout内。该文件不必一定存在与帐号内,如果不存在,退出时不再执行其他命令。
来源:http://hi.baidu.com/hongszh/blog/item/76d9885094a107618435242d.html
如何用find命令查找目录中文件大小大于1MB日文件
find / -size +2 -print
删除当前文件夹下字节数为 37154字节的html文件
删除10天以来没有修改的文件,经常使用的短小精悍又不失效率的命令隆重出场ing:
其实这个命令中主要用到了find命令的-ctime参数和-exec。聪明的你一定能想到了使用!
参数介绍
-size N[bcwkMG] -size<文件大小> 查找符合指定的文件大小的文件。
-exec COMMAND {} + -ok COMMAND ; 假设find指令的回传值为True,就执行该指令。
转载自: 月影鹏鹏 [http://jk.scanmon.com]
-type
查找某一类型的文件,诸如:
b - 块设备文件。
d - 目录。
c - 字符设备文件。
p - 管道文件。
l - 符号链接文件。
f - 普通文件。
-size n:[c] 查找文件长度为n块的文件,带有c时表示文件长度以字节计。
-depth:在查找文件时,首先查找当前目录中的文件,然后再在其子目录中查找。
-fstype:查找位于某一类型文件系统中的文件,这些文件系统类型通常可以在配置文件/etc/fstab中找到,该配置文件中包含了本系统中有关文件系统的信息。
-mount:在查找文件时不跨越文件系统mount点。
-follow:如果find命令遇到符号链接文件,就跟踪至链接所指向的文件。
-cpio:对匹配的文件使用cpio命令,将这些文件备份到磁带设备中。
find / -size +2 -print
删除当前文件夹下字节数为 37154字节的html文件
删除10天以来没有修改的文件,经常使用的短小精悍又不失效率的命令隆重出场ing:
其实这个命令中主要用到了find命令的-ctime参数和-exec。聪明的你一定能想到了使用!
参数介绍
-size N[bcwkMG] -size<文件大小> 查找符合指定的文件大小的文件。
-exec COMMAND {} + -ok COMMAND ; 假设find指令的回传值为True,就执行该指令。
转载自: 月影鹏鹏 [http://jk.scanmon.com]
find . -type d -name "cache"
find . -type f -name "a.txt"
/home/jackxiang# find . -type f -name "*.txt"
./a.txt
./a.txt
-type
查找某一类型的文件,诸如:
b - 块设备文件。
d - 目录。
c - 字符设备文件。
p - 管道文件。
l - 符号链接文件。
f - 普通文件。
-size n:[c] 查找文件长度为n块的文件,带有c时表示文件长度以字节计。
-depth:在查找文件时,首先查找当前目录中的文件,然后再在其子目录中查找。
-fstype:查找位于某一类型文件系统中的文件,这些文件系统类型通常可以在配置文件/etc/fstab中找到,该配置文件中包含了本系统中有关文件系统的信息。
-mount:在查找文件时不跨越文件系统mount点。
-follow:如果find命令遇到符号链接文件,就跟踪至链接所指向的文件。
-cpio:对匹配的文件使用cpio命令,将这些文件备份到磁带设备中。
http://www.soft82.com/download/Windows/Zend_Studio
DownloadUrl:
http://downloads.zend.com/studio-eclipse/7.2.1/ZendStudio-7.2.1.exe
DownloadUrl:
http://downloads.zend.com/studio-eclipse/7.2.1/ZendStudio-7.2.1.exe
服务器生成的二进制日志文件写成二进制格式。要想检查这些文本格式的文件,应使用mysqlbinlog实用工具。
应这样调用mysqlbinlog:
通常情况,可以使用mysqlbinlog直接读取二进制日志文件并将它们用于本地MySQL服务器。也可以使用–read-from-remote-server选项从远程服务器读取二进制日志。
当读取远程二进制日志时,可以通过连接参数选项来指示如何连接服务器,但它们经常被忽略掉,除非你还指定了–read-from-remote-server选项。这些选项是–host、–password、–port、–protocol、–socket和–user。
还可以使用mysqlbinlog来读取在复制过程中从服务器所写的中继日志文件。中继日志格式与二进制日志文件相同。
在5.11.3节,“二进制日志”中详细讨论了二进制日志。
mysqlbinlog支持下面的选项:
· ---help,-?
显示帮助消息并退出。
· ---database=db_name,-d db_name
只列出该数据库的条目(只用本地日志)。
· --force-read,-f
使用该选项,如果mysqlbinlog读它不能识别的二进制日志事件,它会打印警告,忽略该事件并继续。没有该选项,如果mysqlbinlog读到此类事件则停止。
· --hexdump,-H
在注释中显示日志的十六进制转储。该输出可以帮助复制过程中的调试。在MySQL 5.1.2中添加了该选项。
· --host=host_name,-h host_name
获取给定主机上的MySQL服务器的二进制日志。
· --local-load=path,-l pat
为指定目录中的LOAD DATA INFILE预处理本地临时文件。
· --offset=N,-o N
跳过前N个条目。
· --password[=password],-p[password]
当连接服务器时使用的密码。如果使用短选项形式(-p),选项和 密码之间不能有空格。如果在命令行中--password或-p选项后面没有 密码值,则提示输入一个密码。
· --port=port_num,-P port_num
用于连接远程服务器的TCP/IP端口号。
· --position=N,-j N
不赞成使用,应使用--start-position。
· --protocol={TCP | SOCKET | PIPE | -position
使用的连接协议。
· --read-from-remote-server,-R
从MySQL服务器读二进制日志。如果未给出该选项,任何连接参数选项将被忽略。这些选项是--host、--password、--port、--protocol、--socket和--user。
· --result-file=name, -r name
将输出指向给定的文件。
· --short-form,-s
只显示日志中包含的语句,不显示其它信息。
· --socket=path,-S path
用于连接的套接字文件。
· --start-datetime=datetime
从二进制日志中第1个日期时间等于或晚于datetime参量的事件开始读取。datetime值相对于运行mysqlbinlog的机器上的本地时区。该值格式应符合DATETIME或TIMESTAMP数据类型。例如:
shell> mysqlbinlog --start-datetime="2004-12-25 11:25:56" binlog.000003
该选项可以帮助点对点恢复。
· --stop-datetime=datetime
从二进制日志中第1个日期时间等于或晚于datetime参量的事件起停止读。关于datetime值的描述参见--start-datetime选项。该选项可以帮助及时恢复。
· --start-position=N
从二进制日志中第1个位置等于N参量时的事件开始读。
· --stop-position=N
从二进制日志中第1个位置等于和大于N参量时的事件起停止读。
· --to-last-logs,-t
在MySQL服务器中请求的二进制日志的结尾处不停止,而是继续打印直到最后一个二进制日志的结尾。如果将输出发送给同一台MySQL服务器,会导致无限循环。该选项要求--read-from-remote-server。
· --disable-logs-bin,-D
禁用二进制日志。如果使用--to-last-logs选项将输出发送给同一台MySQL服务器,可以避免无限循环。该选项在崩溃恢复时也很有用,可以避免复制已经记录的语句。注释:该选项要求有SUPER权限。
· --user=user_name,-u user_name
连接远程服务器时使用的MySQL用户名。
· --version,-V
显示版本信息并退出。
还可以使用--var_name=value选项设置下面的变量:
· open_files_limit
指定要保留的打开的文件描述符的数量。
可以将mysqlbinlog的输出传到mysql客户端以执行包含在二进制日志中的语句。如果你有一个旧的备份,该选项在崩溃恢复时也很有用(参见5.9.1节,“数据库备份”):
shell> mysqlbinlog hostname-bin.000001 | mysql
或:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
如果你需要先修改含语句的日志,还可以将mysqlbinlog的输出重新指向一个文本文件。(例如,想删除由于某种原因而不想执行的语句)。编辑好文件后,将它输入到mysql程序并执行它包含的语句。
mysqlbinlog有一个--position选项,只打印那些在二进制日志中的偏移量大于或等于某个给定位置的语句(给出的位置必须匹配一个事件的开始)。它还有在看见给定日期和时间的事件后停止或启动的选项。这样可以使用--stop-datetime选项进行点对点恢复(例如,能够说“将数据库前滚动到今天10:30 AM的位置”)。
如果MySQL服务器上有多个要执行的二进制日志,安全的方法是在一个连接中处理它们。下面是一个说明什么是不安全的例子:
shell> mysqlbinlog hostname-bin.000001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.000002 | mysql # DANGER!!
使用与服务器的不同连接来处理二进制日志时,如果第1个日志文件包含一个CREATE TEMPORARY TABLE语句,第2个日志包含一个使用该临时表的语句,则会造成问题。当第1个mysql进程结束时,服务器撤销临时表。当第2个mysql进程想使用该表时,服务器报告 “不知道该表”。
要想避免此类问题,使用一个连接来执行想要处理的所有二进制日志中的内容。下面提供了一种方法:
shell> mysqlbinlog hostname-bin.000001 hostname-bin.000002 | mysql
另一个方法是:
shell> mysqlbinlog hostname-bin.000001 > /tmp/statements.sql
shell> mysqlbinlog hostname-bin.000002 >> /tmp/statements.sql
shell> mysql -e "source /tmp/statements.sql"
mysqlbinlog产生的输出可以不需要原数据文件即可重新生成一个LOAD DATA INFILE操作。mysqlbinlog将数据复制到一个临时文件并写一个引用该文件的LOAD DATA LOCAL INFILE语句。由系统确定写入这些文件的目录的默认位置。要想显式指定一个目录,使用--local-load选项。
因为mysqlbinlog可以将LOAD DATA INFILE语句转换为LOAD DATA LOCAL INFILE语句(也就是说,它添加了LOCAL),用于处理语句的客户端和服务器必须配置为允许LOCAL操作。参见5.6.4节,“LOAD DATA LOCAL安全问题”。
警告:为LOAD DATA LOCAL语句创建的临时文件不会自动删除,因为在实际执行完那些语句前需要它们。不再需要语句日志后应自己删除临时文件。文件位于临时文件目录中,文件名类似original_file_name-#-#。
--hexdump选项可以在注释中产生日志内容的十六进制转储:
shell> mysqlbinlog --hexdump master-bin.000001
上述命令的输出应类似:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1 end_log_pos 98
# Position Timestamp Type Master ID Size Master Pos Flags
# 00000004 9d fc 5c 43 0f 01 00 00 00 5e 00 00 00 62 00 00 00 00 00
# 00000017 04 00 35 2e 30 2e 31 35 2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43 13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b 00 04 1a |.......K...|
# Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
# at startup
ROLLBACK;
十六进制转储的输出包含下面的元素:
· Position: The byte position within the log file.
· Timestamp: The event timestamp. In the example just shown, '9d fc 5c 43' is the representation of '051024 17:24:13' in hexadecimal.
· Type: The type of the log event. '0f' means that the example event is a FORMAT_DESCRIPTION_EVENT. The types are:
· 00 UNKNOWN_EVENT
· This event should never be present in the log.
· 01 START_EVENT_V3
· This indicates the start of a log file written by MySQL 4 or earlier.
· 02 QUERY_EVENT
· The most common type of events. These contain queries executed
· on the master.
· 03 STOP_EVENT
· Indicates that master has stopped.
· 04 ROTATE_EVENT
· Written when the master switches to a new log file.
· 05 INTVAR_EVENT
· Used mainly for AUTO_INCREMENT values and if the LAST_INSERT_ID()
· function is used in the statement.
· 06 LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 3.23.
· 07 SLAVE_EVENT
· Reserved for future use.
· 08 CREATE_FILE_EVENT
· Used for LOAD DATA INFILE statements. This indicates the start
· of execution of such a statement. A temporary file is created
· on the slave. Used in MySQL 4 only.
· 09 APPEND_BLOCK_EVENT
· Contains data for use in a LOAD DATA INFILE statement. The
· data is stored in the temporary file on the slave.
· 0a EXEC_LOAD_EVENT
· Used for LOAD DATA INFILE statements. The contents of the
· temporary file is stored in the table on the slave.
· Used in MySQL 4 only.
· 0b DELETE_FILE_EVENT
· Rollback of LOAD DATA INFILE statement. The temporary file
· should be deleted on slave.
· 0c NEW_LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 4 and earlier.
· 0d RAND_EVENT
· Used to send information about random values if the RAND()
· function is used in the query.
· 0e USER_VAR_EVENT
· Used to replicate user variables.
· 0f FORMAT_DESCRIPTION_EVENT
· This indicates the start of a log file written by MySQL 5 or later.
· 10 XID_EVENT
· Event indicating commit of XA transaction
· 11 BEGIN_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 12 EXECUTE_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 13 TABLE_MAP_EVENT
· Reserved for future use
· 14 WRITE_ROWS_EVENT
· Reserved for future use
· 15 UPDATE_ROWS_EVENT
· Reserved for future use
· 16 DELETE_ROWS_EVENT
· Reserved for future use
· Master ID: The server id of the master that created the event.
· Size: The size in bytes of the event.
· Master Pos: The position of the event in the original master log file.
· Flags: 16 flags.
· 01 LOG_EVENT_BINLOG_IN_USE_F
· Log file correctly closed (Used only in FORMAT_DESCRIPTION_EVENT)
· If this flag is set (if the flags are e.g. '01 00') in an
· FORMAT_DESCRIPTION_EVENT, then the log file has not been
· properly closed. Most probably because of a master crash (for
· example, due to power failure).
· 02 Reserved for future use.
· 04 LOG_EVENT_THREAD_SPECIFIC_F
· Set if the event is dependent on the connection it was
· executed in (example '04 00'), e.g. if the event uses
· temporary tables.
· 08 LOG_EVENT_SUPPRESS_USE_F
· Set in some circumstances when the event is not dependent on
· the current database
其它标志保留用于将来使用。
应这样调用mysqlbinlog:
shell> mysqlbinlog [options] log-files...
例如,要想显示二进制日志binlog.000003的内容,使用下面的命令:
shell> mysqlbinlog binlog.0000003
输出包括在binlog.000003中包含的所有语句,以及其它信息例如每个语句花费的时间、客户发出的线程ID、发出线程时的时间戳等等。
例如,要想显示二进制日志binlog.000003的内容,使用下面的命令:
shell> mysqlbinlog binlog.0000003
输出包括在binlog.000003中包含的所有语句,以及其它信息例如每个语句花费的时间、客户发出的线程ID、发出线程时的时间戳等等。
通常情况,可以使用mysqlbinlog直接读取二进制日志文件并将它们用于本地MySQL服务器。也可以使用–read-from-remote-server选项从远程服务器读取二进制日志。
当读取远程二进制日志时,可以通过连接参数选项来指示如何连接服务器,但它们经常被忽略掉,除非你还指定了–read-from-remote-server选项。这些选项是–host、–password、–port、–protocol、–socket和–user。
还可以使用mysqlbinlog来读取在复制过程中从服务器所写的中继日志文件。中继日志格式与二进制日志文件相同。
在5.11.3节,“二进制日志”中详细讨论了二进制日志。
mysqlbinlog支持下面的选项:
· ---help,-?
显示帮助消息并退出。
· ---database=db_name,-d db_name
只列出该数据库的条目(只用本地日志)。
· --force-read,-f
使用该选项,如果mysqlbinlog读它不能识别的二进制日志事件,它会打印警告,忽略该事件并继续。没有该选项,如果mysqlbinlog读到此类事件则停止。
· --hexdump,-H
在注释中显示日志的十六进制转储。该输出可以帮助复制过程中的调试。在MySQL 5.1.2中添加了该选项。
· --host=host_name,-h host_name
获取给定主机上的MySQL服务器的二进制日志。
· --local-load=path,-l pat
为指定目录中的LOAD DATA INFILE预处理本地临时文件。
· --offset=N,-o N
跳过前N个条目。
· --password[=password],-p[password]
当连接服务器时使用的密码。如果使用短选项形式(-p),选项和 密码之间不能有空格。如果在命令行中--password或-p选项后面没有 密码值,则提示输入一个密码。
· --port=port_num,-P port_num
用于连接远程服务器的TCP/IP端口号。
· --position=N,-j N
不赞成使用,应使用--start-position。
· --protocol={TCP | SOCKET | PIPE | -position
使用的连接协议。
· --read-from-remote-server,-R
从MySQL服务器读二进制日志。如果未给出该选项,任何连接参数选项将被忽略。这些选项是--host、--password、--port、--protocol、--socket和--user。
· --result-file=name, -r name
将输出指向给定的文件。
· --short-form,-s
只显示日志中包含的语句,不显示其它信息。
· --socket=path,-S path
用于连接的套接字文件。
· --start-datetime=datetime
从二进制日志中第1个日期时间等于或晚于datetime参量的事件开始读取。datetime值相对于运行mysqlbinlog的机器上的本地时区。该值格式应符合DATETIME或TIMESTAMP数据类型。例如:
shell> mysqlbinlog --start-datetime="2004-12-25 11:25:56" binlog.000003
该选项可以帮助点对点恢复。
· --stop-datetime=datetime
从二进制日志中第1个日期时间等于或晚于datetime参量的事件起停止读。关于datetime值的描述参见--start-datetime选项。该选项可以帮助及时恢复。
· --start-position=N
从二进制日志中第1个位置等于N参量时的事件开始读。
· --stop-position=N
从二进制日志中第1个位置等于和大于N参量时的事件起停止读。
· --to-last-logs,-t
在MySQL服务器中请求的二进制日志的结尾处不停止,而是继续打印直到最后一个二进制日志的结尾。如果将输出发送给同一台MySQL服务器,会导致无限循环。该选项要求--read-from-remote-server。
· --disable-logs-bin,-D
禁用二进制日志。如果使用--to-last-logs选项将输出发送给同一台MySQL服务器,可以避免无限循环。该选项在崩溃恢复时也很有用,可以避免复制已经记录的语句。注释:该选项要求有SUPER权限。
· --user=user_name,-u user_name
连接远程服务器时使用的MySQL用户名。
· --version,-V
显示版本信息并退出。
还可以使用--var_name=value选项设置下面的变量:
· open_files_limit
指定要保留的打开的文件描述符的数量。
可以将mysqlbinlog的输出传到mysql客户端以执行包含在二进制日志中的语句。如果你有一个旧的备份,该选项在崩溃恢复时也很有用(参见5.9.1节,“数据库备份”):
shell> mysqlbinlog hostname-bin.000001 | mysql
或:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
如果你需要先修改含语句的日志,还可以将mysqlbinlog的输出重新指向一个文本文件。(例如,想删除由于某种原因而不想执行的语句)。编辑好文件后,将它输入到mysql程序并执行它包含的语句。
mysqlbinlog有一个--position选项,只打印那些在二进制日志中的偏移量大于或等于某个给定位置的语句(给出的位置必须匹配一个事件的开始)。它还有在看见给定日期和时间的事件后停止或启动的选项。这样可以使用--stop-datetime选项进行点对点恢复(例如,能够说“将数据库前滚动到今天10:30 AM的位置”)。
如果MySQL服务器上有多个要执行的二进制日志,安全的方法是在一个连接中处理它们。下面是一个说明什么是不安全的例子:
shell> mysqlbinlog hostname-bin.000001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.000002 | mysql # DANGER!!
使用与服务器的不同连接来处理二进制日志时,如果第1个日志文件包含一个CREATE TEMPORARY TABLE语句,第2个日志包含一个使用该临时表的语句,则会造成问题。当第1个mysql进程结束时,服务器撤销临时表。当第2个mysql进程想使用该表时,服务器报告 “不知道该表”。
要想避免此类问题,使用一个连接来执行想要处理的所有二进制日志中的内容。下面提供了一种方法:
shell> mysqlbinlog hostname-bin.000001 hostname-bin.000002 | mysql
另一个方法是:
shell> mysqlbinlog hostname-bin.000001 > /tmp/statements.sql
shell> mysqlbinlog hostname-bin.000002 >> /tmp/statements.sql
shell> mysql -e "source /tmp/statements.sql"
mysqlbinlog产生的输出可以不需要原数据文件即可重新生成一个LOAD DATA INFILE操作。mysqlbinlog将数据复制到一个临时文件并写一个引用该文件的LOAD DATA LOCAL INFILE语句。由系统确定写入这些文件的目录的默认位置。要想显式指定一个目录,使用--local-load选项。
因为mysqlbinlog可以将LOAD DATA INFILE语句转换为LOAD DATA LOCAL INFILE语句(也就是说,它添加了LOCAL),用于处理语句的客户端和服务器必须配置为允许LOCAL操作。参见5.6.4节,“LOAD DATA LOCAL安全问题”。
警告:为LOAD DATA LOCAL语句创建的临时文件不会自动删除,因为在实际执行完那些语句前需要它们。不再需要语句日志后应自己删除临时文件。文件位于临时文件目录中,文件名类似original_file_name-#-#。
--hexdump选项可以在注释中产生日志内容的十六进制转储:
shell> mysqlbinlog --hexdump master-bin.000001
上述命令的输出应类似:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1 end_log_pos 98
# Position Timestamp Type Master ID Size Master Pos Flags
# 00000004 9d fc 5c 43 0f 01 00 00 00 5e 00 00 00 62 00 00 00 00 00
# 00000017 04 00 35 2e 30 2e 31 35 2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43 13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b 00 04 1a |.......K...|
# Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
# at startup
ROLLBACK;
十六进制转储的输出包含下面的元素:
· Position: The byte position within the log file.
· Timestamp: The event timestamp. In the example just shown, '9d fc 5c 43' is the representation of '051024 17:24:13' in hexadecimal.
· Type: The type of the log event. '0f' means that the example event is a FORMAT_DESCRIPTION_EVENT. The types are:
· 00 UNKNOWN_EVENT
· This event should never be present in the log.
· 01 START_EVENT_V3
· This indicates the start of a log file written by MySQL 4 or earlier.
· 02 QUERY_EVENT
· The most common type of events. These contain queries executed
· on the master.
· 03 STOP_EVENT
· Indicates that master has stopped.
· 04 ROTATE_EVENT
· Written when the master switches to a new log file.
· 05 INTVAR_EVENT
· Used mainly for AUTO_INCREMENT values and if the LAST_INSERT_ID()
· function is used in the statement.
· 06 LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 3.23.
· 07 SLAVE_EVENT
· Reserved for future use.
· 08 CREATE_FILE_EVENT
· Used for LOAD DATA INFILE statements. This indicates the start
· of execution of such a statement. A temporary file is created
· on the slave. Used in MySQL 4 only.
· 09 APPEND_BLOCK_EVENT
· Contains data for use in a LOAD DATA INFILE statement. The
· data is stored in the temporary file on the slave.
· 0a EXEC_LOAD_EVENT
· Used for LOAD DATA INFILE statements. The contents of the
· temporary file is stored in the table on the slave.
· Used in MySQL 4 only.
· 0b DELETE_FILE_EVENT
· Rollback of LOAD DATA INFILE statement. The temporary file
· should be deleted on slave.
· 0c NEW_LOAD_EVENT
· Used for LOAD DATA INFILE in MySQL 4 and earlier.
· 0d RAND_EVENT
· Used to send information about random values if the RAND()
· function is used in the query.
· 0e USER_VAR_EVENT
· Used to replicate user variables.
· 0f FORMAT_DESCRIPTION_EVENT
· This indicates the start of a log file written by MySQL 5 or later.
· 10 XID_EVENT
· Event indicating commit of XA transaction
· 11 BEGIN_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 12 EXECUTE_LOAD_QUERY_EVENT
· Used for LOAD DATA statements in MySQL 5 and later.
· 13 TABLE_MAP_EVENT
· Reserved for future use
· 14 WRITE_ROWS_EVENT
· Reserved for future use
· 15 UPDATE_ROWS_EVENT
· Reserved for future use
· 16 DELETE_ROWS_EVENT
· Reserved for future use
· Master ID: The server id of the master that created the event.
· Size: The size in bytes of the event.
· Master Pos: The position of the event in the original master log file.
· Flags: 16 flags.
· 01 LOG_EVENT_BINLOG_IN_USE_F
· Log file correctly closed (Used only in FORMAT_DESCRIPTION_EVENT)
· If this flag is set (if the flags are e.g. '01 00') in an
· FORMAT_DESCRIPTION_EVENT, then the log file has not been
· properly closed. Most probably because of a master crash (for
· example, due to power failure).
· 02 Reserved for future use.
· 04 LOG_EVENT_THREAD_SPECIFIC_F
· Set if the event is dependent on the connection it was
· executed in (example '04 00'), e.g. if the event uses
· temporary tables.
· 08 LOG_EVENT_SUPPRESS_USE_F
· Set in some circumstances when the event is not dependent on
· the current database
其它标志保留用于将来使用。
root@AD38_30_sles10:/home/jackxiang/memcache_c_code# make
makefile:1: ../makefile.comm: No such file or directory
makefile:8: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
makefile:1: ../makefile.comm: No such file or directory
makefile:8: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
添加一行 set tabstop=4 "4就是你设置的TAB键的长度了,这里用的不是很多文章说的shiftwidth!
vi和vim的配置文件是同一个: /etc/vim/vimrc(或者/usr/share/vim/vimrc,其实指向同一个文件,不同的系统可能会有不同的路径,可以用find找到)
我的在:
vi /etc/vimrc
makefile缩进的问题得到解决!
<?PHP
//今天与2009年1月1日相差多少天
$Date_1=date("Y-m-d");
$Date_2="2009-1-1";
$d1=strtotime($Date_1);
$d2=strtotime($Date_2);
$Days=round(($d1-$d2)/3600/24);
echo "今天与2009年1月1日相差".$Days."天";
//今天到2009年12月31日还有多少天
$Date_1=date("Y-m-d");
$Date_2="2009-12-31";
$d1=strtotime($Date_1);
$d2=strtotime($Date_2);
$Days=round(($d2-$d1)/3600/24);
echo "今天到2009年12月31日还有".$Days."天";
?>
//今天与2009年1月1日相差多少天
$Date_1=date("Y-m-d");
$Date_2="2009-1-1";
$d1=strtotime($Date_1);
$d2=strtotime($Date_2);
$Days=round(($d1-$d2)/3600/24);
echo "今天与2009年1月1日相差".$Days."天";
//今天到2009年12月31日还有多少天
$Date_1=date("Y-m-d");
$Date_2="2009-12-31";
$d1=strtotime($Date_1);
$d2=strtotime($Date_2);
$Days=round(($d2-$d1)/3600/24);
echo "今天到2009年12月31日还有".$Days."天";
?>
一,突发神精,来把它们三儿来比较
在网上看到好多文章说nginx有多么,多么好。不管好不好,看看测试结果在说,
1,nginx+php-cgi说明
nginx我开启了11个进程,php-cgi我开启了10个进程
2,apache+php-cgi说明
httpd我开启了11个进程,php-cgi我开启了10个进程
3,apache+php-cli说明
没作任何限制
二,测试文件一test.php无逻辑文件
1. <?php
2. phpinfo();
3. ?>
<?php
phpinfo();
?>
1,nginx+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=61598 pages/min, 1524550 bytes/sec.
Requests: 30799 susceed, 0 failed.
2,apache+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=15000 pages/min, 371750 bytes/sec.
Requests: 7500 susceed, 0 failed.
3,apache+php-cli
[root@BlackGhost conf]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=54618 pages/min, 1357257 bytes/sec.
Requests: 27309 susceed, 0 failed.
三,测试文件二test1.php
查看复制打印?
1. <?php
2. $con = mysql_connect("localhost","username","password");
3. if (!$con)
4. {
5. die('Could not connect: ' . mysql_error());
6. }
7.
8. mysql_select_db("test", $con);
9. mysql_query('set names utf8');
10.
11. $result = mysql_query("SELECT id, name, sex FROM test ");
12.
13. while($row = mysql_fetch_array($result))
14. {
15. echo $row['id'] . "+" . $row['name']."+".$row['sex'];
16. echo "
17. ";
18. }
19.
20. mysql_close($con);
21. ?>
<?php
$con = mysql_connect("localhost","username","password");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("test", $con);
mysql_query('set names utf8');
$result = mysql_query("SELECT id, name, sex FROM test ");
while($row = mysql_fetch_array($result))
{
echo $row['id'] . "+" . $row['name']."+".$row['sex'];
echo "
";
}
mysql_close($con);
?>
1,nginx+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=60716 pages/min, 324830 bytes/sec.
Requests: 30358 susceed, 0 failed.
2,apache+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=12800 pages/min, 68906 bytes/sec.
Requests: 6400 susceed, 0 failed.
3,apache+php-cli
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=78844 pages/min, 575834 bytes/sec.
Requests: 39422 susceed, 0 failed.
四,个人分析
1,针对无逻辑文件,或者静态文件
在内存,cpu都没有最大化利用的情况下nginx+php-cgi效果比apache+php-cli的效果好一点,而apache+php- cli是最大化用内存和cpu,由起可见,nginx+php-cgi的对无罗辑或静态文件的解析要好很多。apache+php-cgi的效果很差,虽然php官方力挺php-cgi,但是根apache的配合效果不好。
2,针对逻辑复杂的文件
针对逻辑复杂的文件时,nginx+php-cgi对php的解析的效果下降了,但是下降的不是很厉害。而apache+php-cli对php的解析的效果去增强了,增加了很多,是原来的差不多1.5倍。nginx+php-cgi在利用部分内存和CPU的情况下根apache+php-cli对 php的解析都差不了多少,个人认为。nginx+php-cgi要比apache+php-cli要好。但是要想达到好多好多倍,我看难。
上面所做对比,不考虑11nginx,配合10php-cgi是否合理,这个就nginx来说,肯定不是很合理的。
来源:http://blog.51yip.com/apachenginx/619.html
在网上看到好多文章说nginx有多么,多么好。不管好不好,看看测试结果在说,
1,nginx+php-cgi说明
nginx我开启了11个进程,php-cgi我开启了10个进程
2,apache+php-cgi说明
httpd我开启了11个进程,php-cgi我开启了10个进程
3,apache+php-cli说明
没作任何限制
二,测试文件一test.php无逻辑文件
1. <?php
2. phpinfo();
3. ?>
<?php
phpinfo();
?>
1,nginx+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=61598 pages/min, 1524550 bytes/sec.
Requests: 30799 susceed, 0 failed.
2,apache+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=15000 pages/min, 371750 bytes/sec.
Requests: 7500 susceed, 0 failed.
3,apache+php-cli
[root@BlackGhost conf]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test.php
100 clients, running 30 sec.
Speed=54618 pages/min, 1357257 bytes/sec.
Requests: 27309 susceed, 0 failed.
三,测试文件二test1.php
查看复制打印?
1. <?php
2. $con = mysql_connect("localhost","username","password");
3. if (!$con)
4. {
5. die('Could not connect: ' . mysql_error());
6. }
7.
8. mysql_select_db("test", $con);
9. mysql_query('set names utf8');
10.
11. $result = mysql_query("SELECT id, name, sex FROM test ");
12.
13. while($row = mysql_fetch_array($result))
14. {
15. echo $row['id'] . "+" . $row['name']."+".$row['sex'];
16. echo "
17. ";
18. }
19.
20. mysql_close($con);
21. ?>
<?php
$con = mysql_connect("localhost","username","password");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("test", $con);
mysql_query('set names utf8');
$result = mysql_query("SELECT id, name, sex FROM test ");
while($row = mysql_fetch_array($result))
{
echo $row['id'] . "+" . $row['name']."+".$row['sex'];
echo "
";
}
mysql_close($con);
?>
1,nginx+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=60716 pages/min, 324830 bytes/sec.
Requests: 30358 susceed, 0 failed.
2,apache+php-cgi
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=12800 pages/min, 68906 bytes/sec.
Requests: 6400 susceed, 0 failed.
3,apache+php-cli
[root@BlackGhost zhangy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost/test1.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://localhost/test1.php
100 clients, running 30 sec.
Speed=78844 pages/min, 575834 bytes/sec.
Requests: 39422 susceed, 0 failed.
四,个人分析
1,针对无逻辑文件,或者静态文件
在内存,cpu都没有最大化利用的情况下nginx+php-cgi效果比apache+php-cli的效果好一点,而apache+php- cli是最大化用内存和cpu,由起可见,nginx+php-cgi的对无罗辑或静态文件的解析要好很多。apache+php-cgi的效果很差,虽然php官方力挺php-cgi,但是根apache的配合效果不好。
2,针对逻辑复杂的文件
针对逻辑复杂的文件时,nginx+php-cgi对php的解析的效果下降了,但是下降的不是很厉害。而apache+php-cli对php的解析的效果去增强了,增加了很多,是原来的差不多1.5倍。nginx+php-cgi在利用部分内存和CPU的情况下根apache+php-cli对 php的解析都差不了多少,个人认为。nginx+php-cgi要比apache+php-cli要好。但是要想达到好多好多倍,我看难。
上面所做对比,不考虑11nginx,配合10php-cgi是否合理,这个就nginx来说,肯定不是很合理的。
来源:http://blog.51yip.com/apachenginx/619.html
Power Usage Effectiveness的简写,是评价数据中心能源效率的指标,是数据中心消耗的所有能源与IT负载使用的能源之比,是DCIE(data center infrastructure efficiency )的反比。 PUE = 数据中心总设备能耗/IT设备能耗,PUE是一个比率,基准是2,越接近1表明能效水平越好
例如:腾讯的天津数据中心就将要把PUE控制在1.5左右。
例如:腾讯的天津数据中心就将要把PUE控制在1.5左右。
WPService.exe是招商银行的网银一网通网盾的进程,他的路径应该是C:\Program Files\CMBCHINA\WebProtect\WPService.exe,如果不是安装在这个目录下的进程,就要注意了如果出现WPService.exe遇到问题需要关闭,可以先卸载再重装试试。
网上有人说这是招行网银一网通网盾的进程。安装后成为系统服务,开机自动启动,可调成手动。把系统服务调成手动的可以用超级兔子和优化大师。
有人说可以这样清除. 开始->运行->输入:msconfig->[系统配置实用程序]选[服务]->取消[cmb WebProrect support]的勾. 重启动 OK ,需用时再勾上。
----------------------
是招商银行最近推出的网银客户端——网通网盾的进程,它的路径应该是C:\Program Files\CMBCHINA\WebProtect\WPService.exe,如果不是安装在这个目录下的进程,,那就应该是木马了。
网上有人说这是招行网银一网通网盾的进程。安装后成为系统服务,开机自动启动,可调成手动。把系统服务调成手动的可以用超级兔子和优化大师。
有人说可以这样清除. 开始->运行->输入:msconfig->[系统配置实用程序]选[服务]->取消[cmb WebProrect support]的勾. 重启动 OK ,需用时再勾上。
----------------------
是招商银行最近推出的网银客户端——网通网盾的进程,它的路径应该是C:\Program Files\CMBCHINA\WebProtect\WPService.exe,如果不是安装在这个目录下的进程,,那就应该是木马了。
最近一周游戏DB偶尔会出现异常重启的现象,观察日志发现
ersion: '5.*-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
080926 12:27:36 InnoDB: Error: cannot allocate 1064960 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 1185388986 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
080926 12:28:36 InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=402653184
read_buffer_size=2093056
max_used_connections=112
max_connections=200
threads_connected=90
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1211614 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x704a7e48, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8174663
0xc72420
0x36392d39
0x8407481
0x83d085d
0x8318798
0xb512db
0xaab12e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
起初认为是key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections 的数值小于by InnoDB 1185388986 bytes的这个
经过和yc同学的探讨后决定把read_buffer_size+sort_buffer_size的值稍微上调,让合值超过2。
今早来后我们发现昨天的判断可能是错误的!
080926 12:27:36 InnoDB: Error: cannot allocate 1064960 bytes of
InnoDB: memory with malloc! Total allocated memory
innodb_buffer_pool_size的大小才是问题的关键 4G物理内存 手册来说建议把innodb_buffer_pool_size设定到物理内存的70%-80%也就是2.8-3.0G间
但是由于我们考虑到key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections +innodb_buffer_pool_size的因素,
最好商榷把innodb_buffer_pool_size=2.0G 这样mysql占用物理内存的极限总合控制在3.2G内
目前启动了!貌似看起来没有太大问题!.
How MySQL Uses Memory才是正解哈
http://dev.mysql.com/doc/refman/5.0/en/memory-use.html
http://imysql.cn/node/97
来源:http://zhangchunyang75252.spaces.live.com/Blog/cns!4C3483B296AD4DB!738.entry
究其原因:
MySQL Innodb里面的innodb_buffer_pool_size 参数
这个参数设置buffer_pool_size也就是缓冲池大小,官方的建议是不要超过2G。经过研究发现这个限制主要来自于如下原因:
32位的Linux内核,内存的寻址范围最大只能是4GB(2^32),这4GB当中0-3GB的给用户进程(User Space)使用,3-4GB给内核使用.也就是说像MySQL这样的进程分配的内存不能超过3GB,但是为什么 innodb_buffer_pool_size 设置成3GB不行呢?很简单,因为MySQL在分配这个内存的时候不仅仅是innodb_buffer_pool_size的设置值,还加了一个 struct:(innobase/ut/ut0mem.c)
81 ret = malloc(n + sizeof(ut_mem_block_t));
这样的话,设置成3GB后,malloc的结果会超过3GB,看到这种错误:
InnoDB: Error: cannot allocate 3221241856 bytes of
cat /proc/sys/vm/overcommit_memory 的输出是多少吗?
根据错误提示的内容,google一下,发现是内核限制的缘故:
[root@yejr mysql]# cat /proc/sys/vm/nr_hugepages
6000
修改一下内核限制:
[root@yejr mysql]# echo 0 > /proc/sys/vm/nr_hugepages
innodb_data_file_path 语法如下所示:
pathtodatafile:sizespecification;pathtodatafile:sizespec;...
...;pathtodatafile:sizespec[:autoextend[:max:sizespecification]]
autoextend参数,并表空间空间不够时,最后的一个文件将自动增长,并且每次自动增长8M.
为了保护文件系统,可以设置MAX参数限制其最后一个文件的最大大小。
在my.cnf参数文件中修改参数
innodb_data_file_path=ibdata1:100M;tbs_data_00:200M;tbs_data_01:200M:autoextend:max:2000M
重新启动数据库
mysqld_safe &
查看日志
080313 15:16:22 mysqld started
080313 15:16:23 InnoDB: Data file ./tbs_data_00 did not exist: new to be created
080313 15:16:23 InnoDB: Setting file ./tbs_data_00 size to 200 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
080313 15:16:26 InnoDB: Data file ./tbs_data_01 did not exist: new to be created
080313 15:16:26 InnoDB: Setting file ./tbs_data_01 size to 200 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
080313 15:16:32 InnoDB: Started; log sequence number 0 133856992
080313 15:16:32 [Note] /opt/coolstack/mysql_32bit/bin/mysqld: ready for connections.
Version: '5.0.45-standard' socket: '/tmp/mysql.sock' port: 3306 Source distribution
添加与移除 InnoDB 数据和日志文件:
为了添加一个数据文件到表空间中,首先要关闭 MySQL 数据库,编辑 my.cnf 文件,在 innodb_data_file_path 中添加一个新文件,然后再重新启动服务。
如果,最后一个文件以关键字 autoextend 来描述,那么编辑 my.cnf 的过程如下所示。必须检查最后一个文件的尺寸,并使它向下接近于 1024 * 1024 bytes (= 1 MB) 的倍数,并在 innodb_data_file_path 中明确指定它的尺寸。然后你可以添加另一个数据文件。记住只有 innodb_data_file_path 中的最后一个文件可以被指定为 auto-extending。
一个例子:假设起先仅仅只有一个 auto-extending 数据文件 ibdata1 ,这个文件越越接近于 988 MB。下面是添加了另一个 auto-extending 数据文件后的可能示例 。
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
通常不能移除 InnoDB 的数据文件。为了减小数据文件的大小,你必须使用 mysqldump 来转储(dump)所有的数据表,再重新建立一个新的数据库,并将数据导入新的数据库中。
如果希望改变 InnoDB 的日志文件数目,必须先关闭 MySQL 并确定完全关闭而没有发生任何错误。将旧的日志文件复制到其它安全的地方,以防在关闭服务时发生了错误而需要恢复数据库。删除所有日志文件,编辑 my.cnf,再重新启动 MySQL。InnoDB 在启动时将会提示它在建立新的日志文件。
增加InnoDB表空间大小的方法是从开始配置它为自动扩展的。为表空间定义里的最后一个数据文件指定autoextend属性。然后在文件耗尽空间之时,InnoDB以8MB为 增量自动增加该文件的大小。增加的大小可以通过设置innodb_autoextend_increment值来配置,这个值以MB为单位,默认的是8。
作为替代,你可以通过添加另一个数据文件来增加表空间的尺寸。要这么做的话,你必须停止MySQL服务器,编辑my.cnf文件 ,添加一个新数据文件到innodb_data_file_path的末尾,然后再次启动服务器。
如果最后一个数据文件是用关键字autoextend定义的,编辑my.cnf文件的步骤必须考虑最后一个数据文件已经增长到多大。获取数据文件的尺寸,把它四舍五入到最接近乘积1024 × 1024bytes (= 1MB),然后在innodb_data_file_path中明确指定大致的尺寸。然后你可以添加另一个数据文件。记得只有innodb_data_file_path里最后一个数据可以被指定为自动扩展。
作为一个例子。假设表空间正好有一个自动扩展文件ibdata1:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:10M:autoextend
假设这个数据文件过一段时间已经长到988MB。下面是添加另一个总扩展数据文件之后的配置行:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
当你添加一个新文件到表空间的之后,请确信它并不存在。当你重启服务器之时,InnoDB创建并初始化这个文件。
当前,你不能从表空间删除一个数据文件。要增加表空间的大小,使用如下步骤:
1. 使用mysqldump转储所有InnoDB表。
2. 停止服务器。
3. 删除所有已存在的表空间文件。
4. 配置新表空间。
5. 重启服务器。
6. 导入转储文件。
如果你想要改变你的InnoDB日志文件的数量和大小,你必须要停止MySQL服务器,并确信它被无错误地关闭。随后复制旧日志文件到 一个安全的地方以防万一某样东西在关闭时出错而你需要用它们来恢复表空间。从日志文件目录删除所有旧日志文件,编辑my.cnf来改变日志文件配置,并再 次启动MySQL服务器。mysqld在启动之时发现没有日志文件,然后告诉你它正在创建一个新的日志文件。
InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表&索引在一个表空间中,表空间可以包含数个文件(或原始磁盘分区)。这与MyISAM表不同,比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸,即使在文件尺寸被限制为2GB的操作系统上。
InnoDB查起来比较慢,myisam较快了,MYISAM的读速度比INNODB的快!写比INNODB的慢!MYISAM的索引会采用前缀压缩,故索引比innodb要小得多(针对字符串列)。
Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错
继续参考:
http://imysql.cn/docs/innodb/1.htm ---》http://imysql.cn/docs/innodb/6.htm
ersion: '5.*-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
080926 12:27:36 InnoDB: Error: cannot allocate 1064960 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 1185388986 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
080926 12:28:36 InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=402653184
read_buffer_size=2093056
max_used_connections=112
max_connections=200
threads_connected=90
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1211614 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x704a7e48, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8174663
0xc72420
0x36392d39
0x8407481
0x83d085d
0x8318798
0xb512db
0xaab12e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
起初认为是key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections 的数值小于by InnoDB 1185388986 bytes的这个
经过和yc同学的探讨后决定把read_buffer_size+sort_buffer_size的值稍微上调,让合值超过2。
今早来后我们发现昨天的判断可能是错误的!
080926 12:27:36 InnoDB: Error: cannot allocate 1064960 bytes of
InnoDB: memory with malloc! Total allocated memory
innodb_buffer_pool_size的大小才是问题的关键 4G物理内存 手册来说建议把innodb_buffer_pool_size设定到物理内存的70%-80%也就是2.8-3.0G间
但是由于我们考虑到key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections +innodb_buffer_pool_size的因素,
最好商榷把innodb_buffer_pool_size=2.0G 这样mysql占用物理内存的极限总合控制在3.2G内
目前启动了!貌似看起来没有太大问题!.
How MySQL Uses Memory才是正解哈
http://dev.mysql.com/doc/refman/5.0/en/memory-use.html
http://imysql.cn/node/97
来源:http://zhangchunyang75252.spaces.live.com/Blog/cns!4C3483B296AD4DB!738.entry
究其原因:
MySQL Innodb里面的innodb_buffer_pool_size 参数
这个参数设置buffer_pool_size也就是缓冲池大小,官方的建议是不要超过2G。经过研究发现这个限制主要来自于如下原因:
32位的Linux内核,内存的寻址范围最大只能是4GB(2^32),这4GB当中0-3GB的给用户进程(User Space)使用,3-4GB给内核使用.也就是说像MySQL这样的进程分配的内存不能超过3GB,但是为什么 innodb_buffer_pool_size 设置成3GB不行呢?很简单,因为MySQL在分配这个内存的时候不仅仅是innodb_buffer_pool_size的设置值,还加了一个 struct:(innobase/ut/ut0mem.c)
81 ret = malloc(n + sizeof(ut_mem_block_t));
这样的话,设置成3GB后,malloc的结果会超过3GB,看到这种错误:
InnoDB: Error: cannot allocate 3221241856 bytes of
cat /proc/sys/vm/overcommit_memory 的输出是多少吗?
根据错误提示的内容,google一下,发现是内核限制的缘故:
[root@yejr mysql]# cat /proc/sys/vm/nr_hugepages
6000
修改一下内核限制:
[root@yejr mysql]# echo 0 > /proc/sys/vm/nr_hugepages
innodb_data_file_path 语法如下所示:
pathtodatafile:sizespecification;pathtodatafile:sizespec;...
...;pathtodatafile:sizespec[:autoextend[:max:sizespecification]]
autoextend参数,并表空间空间不够时,最后的一个文件将自动增长,并且每次自动增长8M.
为了保护文件系统,可以设置MAX参数限制其最后一个文件的最大大小。
在my.cnf参数文件中修改参数
innodb_data_file_path=ibdata1:100M;tbs_data_00:200M;tbs_data_01:200M:autoextend:max:2000M
重新启动数据库
mysqld_safe &
查看日志
080313 15:16:22 mysqld started
080313 15:16:23 InnoDB: Data file ./tbs_data_00 did not exist: new to be created
080313 15:16:23 InnoDB: Setting file ./tbs_data_00 size to 200 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
080313 15:16:26 InnoDB: Data file ./tbs_data_01 did not exist: new to be created
080313 15:16:26 InnoDB: Setting file ./tbs_data_01 size to 200 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
080313 15:16:32 InnoDB: Started; log sequence number 0 133856992
080313 15:16:32 [Note] /opt/coolstack/mysql_32bit/bin/mysqld: ready for connections.
Version: '5.0.45-standard' socket: '/tmp/mysql.sock' port: 3306 Source distribution
show variables like "%innodb%"
添加与移除 InnoDB 数据和日志文件:
为了添加一个数据文件到表空间中,首先要关闭 MySQL 数据库,编辑 my.cnf 文件,在 innodb_data_file_path 中添加一个新文件,然后再重新启动服务。
如果,最后一个文件以关键字 autoextend 来描述,那么编辑 my.cnf 的过程如下所示。必须检查最后一个文件的尺寸,并使它向下接近于 1024 * 1024 bytes (= 1 MB) 的倍数,并在 innodb_data_file_path 中明确指定它的尺寸。然后你可以添加另一个数据文件。记住只有 innodb_data_file_path 中的最后一个文件可以被指定为 auto-extending。
一个例子:假设起先仅仅只有一个 auto-extending 数据文件 ibdata1 ,这个文件越越接近于 988 MB。下面是添加了另一个 auto-extending 数据文件后的可能示例 。
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
通常不能移除 InnoDB 的数据文件。为了减小数据文件的大小,你必须使用 mysqldump 来转储(dump)所有的数据表,再重新建立一个新的数据库,并将数据导入新的数据库中。
如果希望改变 InnoDB 的日志文件数目,必须先关闭 MySQL 并确定完全关闭而没有发生任何错误。将旧的日志文件复制到其它安全的地方,以防在关闭服务时发生了错误而需要恢复数据库。删除所有日志文件,编辑 my.cnf,再重新启动 MySQL。InnoDB 在启动时将会提示它在建立新的日志文件。
增加InnoDB表空间大小的方法是从开始配置它为自动扩展的。为表空间定义里的最后一个数据文件指定autoextend属性。然后在文件耗尽空间之时,InnoDB以8MB为 增量自动增加该文件的大小。增加的大小可以通过设置innodb_autoextend_increment值来配置,这个值以MB为单位,默认的是8。
作为替代,你可以通过添加另一个数据文件来增加表空间的尺寸。要这么做的话,你必须停止MySQL服务器,编辑my.cnf文件 ,添加一个新数据文件到innodb_data_file_path的末尾,然后再次启动服务器。
如果最后一个数据文件是用关键字autoextend定义的,编辑my.cnf文件的步骤必须考虑最后一个数据文件已经增长到多大。获取数据文件的尺寸,把它四舍五入到最接近乘积1024 × 1024bytes (= 1MB),然后在innodb_data_file_path中明确指定大致的尺寸。然后你可以添加另一个数据文件。记得只有innodb_data_file_path里最后一个数据可以被指定为自动扩展。
作为一个例子。假设表空间正好有一个自动扩展文件ibdata1:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:10M:autoextend
假设这个数据文件过一段时间已经长到988MB。下面是添加另一个总扩展数据文件之后的配置行:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
当你添加一个新文件到表空间的之后,请确信它并不存在。当你重启服务器之时,InnoDB创建并初始化这个文件。
当前,你不能从表空间删除一个数据文件。要增加表空间的大小,使用如下步骤:
1. 使用mysqldump转储所有InnoDB表。
2. 停止服务器。
3. 删除所有已存在的表空间文件。
4. 配置新表空间。
5. 重启服务器。
6. 导入转储文件。
如果你想要改变你的InnoDB日志文件的数量和大小,你必须要停止MySQL服务器,并确信它被无错误地关闭。随后复制旧日志文件到 一个安全的地方以防万一某样东西在关闭时出错而你需要用它们来恢复表空间。从日志文件目录删除所有旧日志文件,编辑my.cnf来改变日志文件配置,并再 次启动MySQL服务器。mysqld在启动之时发现没有日志文件,然后告诉你它正在创建一个新的日志文件。
InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表&索引在一个表空间中,表空间可以包含数个文件(或原始磁盘分区)。这与MyISAM表不同,比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸,即使在文件尺寸被限制为2GB的操作系统上。
InnoDB查起来比较慢,myisam较快了,MYISAM的读速度比INNODB的快!写比INNODB的慢!MYISAM的索引会采用前缀压缩,故索引比innodb要小得多(针对字符串列)。
Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错 Innodb 去掉事务 速度也不错
继续参考:
http://imysql.cn/docs/innodb/1.htm ---》http://imysql.cn/docs/innodb/6.htm
cat hosts | sed -e'1ihello world!' > afteradd.txt
我认为最好的方法:
cat - file <<< 123
cat - hosts <<< 123 > out.txt
如在sql前面加入一行:set names utf8,其见如下:
[/home/jackxiang/sed]# vi append.txt
sql
sql2
sql3
sql
sql2
sql3
cat - append.txt <<< "set names utf8"
[/home/jackxiang/sed]# cat - append.txt <<< "set names utf8" > addfirstline.txt
[/home/jackxiang/sed]#
vi addfirstline.txt
set names utf8
sql
sql2
sql3
vi addfirstline.txt
set names utf8
sql
sql2
sql3
通常使用的 MyISAM 表可以用上面提到的恢复方法来完成。如果是索引坏了,可以用 myisamchk 工具来重建索引。而对于 Innodb 表来说,就没这么直接了,因为它把所有的表都保存在一个表空间了。不过 Innodb 有一个检查机制叫模糊检查点,只要保存了日志文件,就能根据日志文件来修复错误。可以在 my.cnf 文件中,增加以下参数,让 mysqld 在启动时自动检查日志文件:
innodb_force_recovery = 4
要保存了日志文件!!!!
100925 19:18:46 mysqld started
100925 19:18:46 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
100925 19:18:46 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 94 1409777360.
InnoDB: Doing recovery: scanned up to log sequence number 94 1409777360
100925 19:18:46 InnoDB: Error: page 4734977 log sequence number 94 1537001576
InnoDB: is in the future! Current system log sequence number 94 1409777360.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100925 19:18:46 InnoDB: Error: page 4734991 log sequence number 94 1668918230
InnoDB: is in the future! Current system log sequence number 94 1409777360.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.
100925 19:18:46 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
100925 19:18:46 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 94 1409777360.
InnoDB: Doing recovery: scanned up to log sequence number 94 1409777360
100925 19:18:46 InnoDB: Error: page 4734977 log sequence number 94 1537001576
InnoDB: is in the future! Current system log sequence number 94 1409777360.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100925 19:18:46 InnoDB: Error: page 4734991 log sequence number 94 1668918230
InnoDB: is in the future! Current system log sequence number 94 1409777360.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.
我考,没有InnoDb日志文件,彻底挂了!!!
MYSQL有不同类型的日志文件(各自存储了不同类型的日志),从它们当中可以查询到MYSQL里都做了些什么,对于MYSQL的管理工作,这些日志文件是不可缺少的。
1.错误日志(The error log):记录了数据库启动、运行以及停止过程中错误信息;
2.ISAM操作日志(The isam log):记录了所有对ISAM表的修改,该日志仅仅用于调试ISAM模式;
3.SQL执行日志(The query log):记录了客户端的连接以及所执行的SQL语句;
4.更新日志(The update log):记录了改变数据的语句,已经不建议使用,由二进制日志替代;
5.二进制日志(The binary log):记录了所有对数据库数据的修改语句;
6.超时日志(The slow log):记录所有执行时间超过最大SQL执行时间(long_query_time)或未使用索引的语句;
如果你是在用mysql的复制、备份功能,那么从服务器还提供了一种叫做relay log的日志文件。
默认情况下所有日志文件会记录在MYSQL的数据目录下,你可以通过强制mysql去关闭并重新打开一个文件进行日志记录,当然系统会自动加后缀 (如.00001, .00002),方式有在mysql环境下执行语句 mysql>flush logs; 或者通过mysqladmin管理程序执行 #mysqladmin flush-logs 或 #mysqladmin refresh
这些日志的启动方式可以在mysqld_safe方式启动数据库的时候,后面跟选项参数,也可以在配置文件里配置,推荐采用第二种方式,配置方法很简单,我只配置了三种日志:
[mysqld]
log=/var/log/mysqld_common.log
log-error=/var/log/mysqld_err.log
log-bin=/var/log/mysqld_bin.bin
日志的查看很简单,大部分都是文本,直接用vim、less、more之类的工具看就可以了,值得说明的是二进制文件的查看:
1). 首先确定是否开启了二进制文件记录功能
mysql>show variables like 'log_bin';
2). 如果你想知道现在记录二进制数据的文件具体信息,你可以通过下列语句看到现在正在记录哪个文件,以及记录的当前位置:
mysql>show master status;
3). 查看二进制数据需要借助程序mysqlbinlog,看看它支持哪些选项,根据自己需要来使用。
mysql>mysqlbinlog /var/log/mysql/mysql-bin.000040;
查询某个时间范围的可以执行下列语句,如果记录很多可以将结果定向到一个文件里自己慢慢看:-) :
mysql>mysqlbinlog --start-datetime='2008-01-01 00:00:00' --stop-datetime='2008-08-08 00:00:00' /var/log/mysql/mysql-bin.000040 > ./tmp.log
来源:http://blog.csdn.net/tsuliuchao/archive/2009/12/14/5005457.aspx
1.错误日志(The error log):记录了数据库启动、运行以及停止过程中错误信息;
2.ISAM操作日志(The isam log):记录了所有对ISAM表的修改,该日志仅仅用于调试ISAM模式;
3.SQL执行日志(The query log):记录了客户端的连接以及所执行的SQL语句;
4.更新日志(The update log):记录了改变数据的语句,已经不建议使用,由二进制日志替代;
5.二进制日志(The binary log):记录了所有对数据库数据的修改语句;
6.超时日志(The slow log):记录所有执行时间超过最大SQL执行时间(long_query_time)或未使用索引的语句;
如果你是在用mysql的复制、备份功能,那么从服务器还提供了一种叫做relay log的日志文件。
默认情况下所有日志文件会记录在MYSQL的数据目录下,你可以通过强制mysql去关闭并重新打开一个文件进行日志记录,当然系统会自动加后缀 (如.00001, .00002),方式有在mysql环境下执行语句 mysql>flush logs; 或者通过mysqladmin管理程序执行 #mysqladmin flush-logs 或 #mysqladmin refresh
这些日志的启动方式可以在mysqld_safe方式启动数据库的时候,后面跟选项参数,也可以在配置文件里配置,推荐采用第二种方式,配置方法很简单,我只配置了三种日志:
[mysqld]
log=/var/log/mysqld_common.log
log-error=/var/log/mysqld_err.log
log-bin=/var/log/mysqld_bin.bin
日志的查看很简单,大部分都是文本,直接用vim、less、more之类的工具看就可以了,值得说明的是二进制文件的查看:
1). 首先确定是否开启了二进制文件记录功能
mysql>show variables like 'log_bin';
2). 如果你想知道现在记录二进制数据的文件具体信息,你可以通过下列语句看到现在正在记录哪个文件,以及记录的当前位置:
mysql>show master status;
3). 查看二进制数据需要借助程序mysqlbinlog,看看它支持哪些选项,根据自己需要来使用。
mysql>mysqlbinlog /var/log/mysql/mysql-bin.000040;
查询某个时间范围的可以执行下列语句,如果记录很多可以将结果定向到一个文件里自己慢慢看:-) :
mysql>mysqlbinlog --start-datetime='2008-01-01 00:00:00' --stop-datetime='2008-08-08 00:00:00' /var/log/mysql/mysql-bin.000040 > ./tmp.log
来源:http://blog.csdn.net/tsuliuchao/archive/2009/12/14/5005457.aspx
因为JavaEye网站的数据库服务器搬家的时候被托管商的工作人员狠狠摔了一下,所以硬盘整个挂掉了,我重新安装数据库服务器的时候,顺手下载了 Percona patch过的MySQL5.0版本,使用MySQL自带的heavy innodb配置文件改了改,作为my.cnf启动运行。数据库服务器的物理内存有6GB,其中有4GB可以被MySQL使用,my.cnf相关配置参数如下:
buffer pool越大越好,官方推荐使用物理内存的50%-80%;log_file_size也是越大越好,官方推荐log size加起来要达到buffer pool的25%-100%。使用memlock可以避免MySQL内存进入swap,这些都是默认的推荐配置了,没有什么可以质疑的地方。但是数据库服务器启动以后,运行不太正常。表现出来的现象是:
1、操作系统内存Disk Cache使用了2.7GB
2、操作系统swap空间使用了200MB左右,一直不停进行swap in/swap out
3、CPU的IO Wait偏高,平均在10%以上
这个现象看起来非常怪异和矛盾。IO Wait偏高显然是因为频繁的使用swap进行内存换页引起的,但问题是物理内存非常空闲,操作系统明明有2.7GB空闲物理内存做Disk Cache,怎么不吐出来一点,非要去用swap呢?
想来想去只有一种可能性,就是MySQL存在非常巨大的,频繁的文件读写操作,迫使操作系统不得不分配了2.7GB的Disk Cache,从而造成了物理内存的不足,被迫使用swap。而可能造成巨大文件读写操作的就是buffer pool的flush和log file的flush操作了。因此配置文件做如下修改:
memlock
innodb_buffer_pool_size = 2G
innodb_log_file_size = 64M
innodb_log_files_in_group = 2
innodb_flush_method=O_DIRECT
减少log file size和数量,使用O_DIRECT。重启以后,数据库服务器恢复正常。操作系统Disk Cache下降到900MB,Swap使用了200多MB,但是不再进行swap in/swap out操作,CPU的IO Wait下降到2-3%。
通过这次MySQL InnoDB的调优经历,发现一些和MySQL官方推荐配置不符合的疑惑之处,值得思考和探索:
1、innodb_flush_method究竟应不应该使用O_DIRECT?
所有MySQL调优的建议都说,如果硬件没有预读功能,那么使用O_DIRECT将极大降低InnoDB的性能,因为O_DIRECT跳过了操作系统的文件系统Disk Cache,让MySQL直接读写磁盘了。
但是在我的实践中来看,如果不使用O_DIRECT,操作系统被迫开辟大量的Disk Cache用于innodb的读写缓存,不但没有提高读写性能,反而造成读写性能急剧下降。而且buffer pool的数据缓存和操作系统Disk Cache缓存造成了Double buffer的浪费,显然从我这个实践来看,浪费得非常厉害。
说O_DIRECT造成MySQL直接读写磁盘造成得性能下降问题,我觉得完全是杞人忧天。因为从JavaEye的数据库监测来看,Innodb 的buffer pool命中率非常高,有98%以上,真正的磁盘操作是微乎其微的。为了1%的磁盘操作能够得到Disk Cache,而浪费了98%的double buffer内存空间,无论从性能上看,还是从内存资源的消耗来看,都是非常不明智的。
2、innodb_log_file_size究竟应该大一点,还是小一点?
所有MySQL调优建议都说,innodb_log_file_size要越大越好,避免无谓的buffer pool的flush操作。
但是在我的实践中来看,innodb_log_file_size开得太大,会明显增加innodb的log写入操作,而且会造成操作系统需要更多的Disk Cache开销。
因此从我的经验来看,innodb_flush_method=O_DIRECT是必须的,而innodb_log_file_size也不宜太大
1. memlock
2. innodb_buffer_pool_size = 2G
3. innodb_log_file_size = 256M
4. innodb_log_files_in_group = 3
5. #innodb_flush_method=fdatasync 默认设置
2. innodb_buffer_pool_size = 2G
3. innodb_log_file_size = 256M
4. innodb_log_files_in_group = 3
5. #innodb_flush_method=fdatasync 默认设置
memlock
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
#innodb_flush_method=fdatasync 默认设置
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
#innodb_flush_method=fdatasync 默认设置
buffer pool越大越好,官方推荐使用物理内存的50%-80%;log_file_size也是越大越好,官方推荐log size加起来要达到buffer pool的25%-100%。使用memlock可以避免MySQL内存进入swap,这些都是默认的推荐配置了,没有什么可以质疑的地方。但是数据库服务器启动以后,运行不太正常。表现出来的现象是:
1、操作系统内存Disk Cache使用了2.7GB
2、操作系统swap空间使用了200MB左右,一直不停进行swap in/swap out
3、CPU的IO Wait偏高,平均在10%以上
这个现象看起来非常怪异和矛盾。IO Wait偏高显然是因为频繁的使用swap进行内存换页引起的,但问题是物理内存非常空闲,操作系统明明有2.7GB空闲物理内存做Disk Cache,怎么不吐出来一点,非要去用swap呢?
想来想去只有一种可能性,就是MySQL存在非常巨大的,频繁的文件读写操作,迫使操作系统不得不分配了2.7GB的Disk Cache,从而造成了物理内存的不足,被迫使用swap。而可能造成巨大文件读写操作的就是buffer pool的flush和log file的flush操作了。因此配置文件做如下修改:
1. memlock
2. innodb_buffer_pool_size = 2G
3. innodb_log_file_size = 64M
4. innodb_log_files_in_group = 2
5. innodb_flush_method=O_DIRECT
2. innodb_buffer_pool_size = 2G
3. innodb_log_file_size = 64M
4. innodb_log_files_in_group = 2
5. innodb_flush_method=O_DIRECT
memlock
innodb_buffer_pool_size = 2G
innodb_log_file_size = 64M
innodb_log_files_in_group = 2
innodb_flush_method=O_DIRECT
减少log file size和数量,使用O_DIRECT。重启以后,数据库服务器恢复正常。操作系统Disk Cache下降到900MB,Swap使用了200多MB,但是不再进行swap in/swap out操作,CPU的IO Wait下降到2-3%。
通过这次MySQL InnoDB的调优经历,发现一些和MySQL官方推荐配置不符合的疑惑之处,值得思考和探索:
1、innodb_flush_method究竟应不应该使用O_DIRECT?
所有MySQL调优的建议都说,如果硬件没有预读功能,那么使用O_DIRECT将极大降低InnoDB的性能,因为O_DIRECT跳过了操作系统的文件系统Disk Cache,让MySQL直接读写磁盘了。
但是在我的实践中来看,如果不使用O_DIRECT,操作系统被迫开辟大量的Disk Cache用于innodb的读写缓存,不但没有提高读写性能,反而造成读写性能急剧下降。而且buffer pool的数据缓存和操作系统Disk Cache缓存造成了Double buffer的浪费,显然从我这个实践来看,浪费得非常厉害。
说O_DIRECT造成MySQL直接读写磁盘造成得性能下降问题,我觉得完全是杞人忧天。因为从JavaEye的数据库监测来看,Innodb 的buffer pool命中率非常高,有98%以上,真正的磁盘操作是微乎其微的。为了1%的磁盘操作能够得到Disk Cache,而浪费了98%的double buffer内存空间,无论从性能上看,还是从内存资源的消耗来看,都是非常不明智的。
2、innodb_log_file_size究竟应该大一点,还是小一点?
所有MySQL调优建议都说,innodb_log_file_size要越大越好,避免无谓的buffer pool的flush操作。
但是在我的实践中来看,innodb_log_file_size开得太大,会明显增加innodb的log写入操作,而且会造成操作系统需要更多的Disk Cache开销。
因此从我的经验来看,innodb_flush_method=O_DIRECT是必须的,而innodb_log_file_size也不宜太大
mysqladmin -u root shutdown
停止:
[/usr/local/mysql/bin]# mysqladmin -u root shutdown
确定停止?:
[/usr/local/mysql/bin]# ps axu|grep mysql
root 4121 0.0 0.0 5800 2488 pts/35 S+ 16:22 0:00 mysql
gastonwu 5365 0.0 0.0 5192 2256 pts/67 S+ Aug24 0:00 mysql -u root -p
root 5844 0.0 0.0 5800 2516 pts/28 S+ 16:28 0:00 mysql -uwiki -p wiki -hlocalhost
root 11169 0.0 0.0 2768 744 pts/49 S+ 16:46 0:00 grep mysql
root 15169 0.0 0.0 5844 2712 pts/8 S+ Sep23 0:00 mysql
gastonwu 18138 0.0 0.0 5188 2276 pts/91 S+ Aug25 0:00 mysql -u root -p DB_DemoSoapp
root 23843 0.0 0.0 5800 2584 pts/27 S+ 15:40 0:00 mysql
root 27623 0.0 0.0 5800 2568 pts/99 S+ 14:08 0:00 mysql
启动:
[/usr/local/mysql/bin]# /bin/sh /usr/local/mysql/bin/mysqld_safe --user=root
Starting mysqld daemon with databases from /usr/local/mysql/data[1]+ Stopped /bin/sh /usr/local/mysql/bin/mysqld_safe --user=root
客户端登陆:
[/usr/local/mysql/bin]# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.27-max
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
如果已经连上后,重启后会出现:
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 2
Current database: *** NONE ***
No connection. Trying to reconnect...
Connection id: 2
Current database: *** NONE ***
当然,用pkill 杀mysql的进程也是也可以的,呵呵!
netstat -na|grep ESTABLISHED|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -r +0n
netstat -na|grep SYN|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -r +0n
Onecent:~ # netstat -an | grep 80 | awk '{print $6}' | sort | uniq -c | sort -rn
681 TIME_WAIT
122 ESTABLISHED
107 FIN_WAIT2
44 FIN_WAIT1
14 SYN_SENT
3 LAST_ACK
2 SYN_RECV
1 LISTEN
1 CLOSING
linux可以查看多少人连接了80端口:
Onecent:~ # netstat -na | grep ":80" | wc
1074 6444 86994
1074 6444 86994
Onecent:~ # netstat -atlunp|grep 80|grep TIME_WAIT|wc
787 5509 79487
787 5509 79487
Oncecent:~ # netstat -atlunp|grep 80|wc
1030 7210 104030
1030 7210 104030
线程数:
Onecent:/usr/local/apache2/conf # ps -ef |grep httpd |wc -l
360
360
工作模式查看:
Onecent:/usr/local/apache2/conf # /usr/local/apache2/bin/httpd -l
Compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_cache.c
mod_disk_cache.c
mod_mem_cache.c
mod_include.c
mod_deflate.c
mod_log_config.c
mod_env.c
mod_expires.c
mod_setenvif.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_so.c
Compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_cache.c
mod_disk_cache.c
mod_mem_cache.c
mod_include.c
mod_deflate.c
mod_log_config.c
mod_env.c
mod_expires.c
mod_setenvif.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_so.c
注意:prefork.c //此处为mpm工作模式,也可使用worker.c模式
netstat -n | awk '/^tcp/ {++S[$NF]};END {for(a in S) print a, S[a]}'
Onecent:/usr/local/# netstat -n | awk '/^tcp/ {++S[$NF]};END {for(a in S) print a, S[a]}'
LAST_ACK 3
SYN_RECV 5
ESTABLISHED 207
FIN_WAIT1 63
FIN_WAIT2 105
SYN_SENT 1
TIME_WAIT 912
LAST_ACK 3
SYN_RECV 5
ESTABLISHED 207
FIN_WAIT1 63
FIN_WAIT2 105
SYN_SENT 1
TIME_WAIT 912
修理修理下面的参数:
sysctl -p
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 2048 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 2048 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
修改:
1, sysctl命令的作用
在运行时配置内核参数
2,用法举例:
-w 用此选项来改变一个sysctl设置
例:sysctl -w net.ipv4.ip_forward=1
-p 载入sysctl配置文件
如-p后未指定路径,则载入 /etc/sysctl.conf
例: sysctl -p /etc/sysctl.conf
3,修改/etc/sysctl.conf可以保存设置在机器重启后仍然有效
例如:
vi /etc/sysctl.conf
修改: net.ipv4.ip_forward=0的值为1
作用:打开数据包的转发功能
如何使修改马上生效?
sysctl -p /etc/sysctl.conf // 作用:重新载入/etc/sysctl.conf文件
整个张宴的nginx的配置,如下,可以参考:
优化Linux内核参数
vi /etc/sysctl.conf
在末尾增加以下内容:
引用
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000 65000
使配置立即生效:
/sbin/sysctl -p





