月度归档:2015年08月

最全解决方法phpcms V9 前台和后台登陆验证码无法显示问题

首先说过下 如果问题帮您解决了 你们就回复一下 顶一下帖子 我不喜欢设置回复 因为很多人根本就没有注册论坛账号所以进来看到了自己需要的答案  而被设置了要回复才能看到的时候 他们就会去注册 但是注册了要60分钟后才能回复 所以很急人的(我亲身体验 苦苦等了60分钟)   所以 你们喜欢的 解决问题的 记得顶帖子 我会爱死你们的 呵呵

好了不废话了 下面发解决方法



1:首先第一种(我就是用这个方法解决的,很多人用的是免费空间,但是往往免费空间是没有客服的 所以我们只能靠自己来解决了。)

可以偿试通过修改”/caches/configs/system.php”当中的:



‘session_storage’ => ‘mysql’,



将其修改为



‘session_storage’ => ‘files’,



然后保存下来 上传进去的时候选择覆盖(右键-打开方式-文本文件打开)

然后清除自己浏览器的COOKS  再次登录后台(这里再提供一下  如果你首次安装的时候是乱码的    您可以通过FTP连接后找到caches这个目录下configs这个文件夹下的system.php,下载到本地,修改其中的gzip => 1,其中的1改为0保存然后上传覆盖就可以了

)_





2:如果不是路径问题 也不是CD库问题

解决办法:重启APACHE服务器





3:

找到

./phpcms/libs/classes/session_mysql.class.php
./phpsso_server/phpcms/libs/classes/session_mysql.class.php
(其实这个文件我是在Web/phpsso_server/caches/configs/ 找到的   这一个解决方法我是在百度找到的 如果有疑问可以不要试  )



phpcms/libs/classes/session_mysql.class.php



将行21:session_start();放到行20:session_set_save_handler(array(&$thi….

之前

结论:官方的代码不规范

然后清除自己浏览器的COOKS  再次登录后台













以上方法为我亲自试验过的  目前是第一个方法我成功了  如果有不对的地方还请明示  如果好 还请版主帮我加精 谢谢啦

centos下,使用postfix实现php发送mail功能

1、centos下安装postfix,执行命令:

# yum -y install postfix popa3d

如果不需要pop3服务,把popa3d去掉

2、在php.ini配置文件上,设置mail函数:
1)打开php.ini配置,下面是我的php.ini路径:

# vi /usr/local/php/etc/php.ini


2)找到:sendmail_path ,将其设置为:


sendmail_path = /usr/sbin/sendmail -t

注意:这里需要先到/usr/sbin/ 目录中,确认是否存在sendmail文件。

3、启动postfix:

# /etc/init.d/postfix start

4、重启php-fpm:

# /etc/init.d/php-fpm  restart

5、以上完成。你可以写一个发送email的php文件做测试,如下:

<?php
$send = mail(‘yourEmail@test.com’, ‘My Subject’, ‘The test mail’);
if($send){
echo ‘true’;
}else{
echo ‘false’;
}
?>
以上,运行如果显示true,则,你将会在‘yourEmail@test.com’中收到一封主题为’My Subject’的email。

 

如果要限制外来主机访问smtp服务,修改/etc/postfix/main.cf里的

inet_interfaces=all

inet_interfaces=localhost

Mysql CPU占用高原因分析及解决方法

最近发现php网站发布信息比较慢,而且同网站目录下的php经常登录后立即就重新登录,立即考虑到服务器资源占用问题,所以进服务器看到原来mysql占用率较高 25-60%左右,偶尔能跑到100%,所有导致上述问题的发生

通过以前对mysql的操作经验,先将mysql的配置问题排除了,查看msyql是否运行正常,通过查看mysql data目录里面的*.err文件(将扩展名改为.txt)记事本查看即可。如果过大不建议用记事本了,容易死掉,可以用editplus等工具



简单的分为下面几个步骤来解决这个问题:



1、mysql运行正常,也有可能是同步设置问题导致



2、如果mysql运行正常,那就是php的一些sql语句导致问题发现,用root用户进入mysql管理

mysql -u root -p

输入密码

mysql:show processlist 语句,查找负荷最重的 SQL 语句,优化该SQL,比如适当建立某字段的索引。



通过这个命令我看到原来是有人恶意刷搜索,因为dedecms搜索后面调用搜索最高的词,导致很多人用工具刷这个,而且是定时有间隔的,所以将这个php程序改名跳转都方法解决了。



当然如果你的确实是sql语句用了大量的group by等语句,union联合查询等肯定会将mysql的占用率提高。所以就需要优化sql语句,网站尽量生成静态的,一般4W ip的静态网站,mysql占用率几乎为0的。所以这对于程序员的经验是个考虑。尽量提高mysql性能 (MySQL 性能优化的最佳20多条经验分享)



下面是脚本之家收集的文章,大家都可以参考下
MYSQL CPU 占用 100% 的现象描述 



早上帮朋友一台服务器解决了 Mysql cpu 占用 100% 的问题。稍整理了一下,将经验记录在这篇文章里 

朋友主机(Windows 2003 + IIS + PHP + MYSQL )近来 MySQL 服务进程 (mysqld-nt.exe) CPU 占用率总为 100% 高居不下。此主机有10个左右的 database, 分别给十个网站调用。据朋友测试,导致 mysqld-nt.exe cpu 占用奇高的是网站A,一旦在 IIS 中将此网站停止服务,CPU 占用就降下来了。一启用,则马上上升。 



MYSQL CPU 占用 100% 的解决过程 



今天早上仔细检查了一下。目前此网站的七日平均日 IP 为2000,PageView 为 3万左右。网站A 用的 database 目前有39个表,记录数 60.1万条,占空间 45MB。按这个数据,MySQL 不可能占用这么高的资源。 



于是在服务器上运行命令,将 mysql 当前的环境变量输出到文件 output.txt: 



d:\web\mysql> mysqld.exe –help >output.txt 

发现 tmp_table_size 的值是默认的 32M,于是修改 My.ini, 将 tmp_table_size 赋值到 200M: 



d:\web\mysql> notepad c:\windows\my.ini 

[mysqld] 

tmp_table_size=200M 



然后重启 MySQL 服务。CPU 占用有轻微下降,以前的CPU 占用波形图是 100% 一根直线,现在则在 97%~100%之间起伏。这表明调整 tmp_table_size 参数对 MYSQL 性能提升有改善作用。但问题还没有完全解决。 



于是进入 mysql 的 shell 命令行,调用 show processlist, 查看当前 mysql 使用频繁的 sql 语句: 



mysql> show processlist; 

反复调用此命令,发现网站 A 的两个 SQL 语句经常在 process list 中出现,其语法如下: 



SELECT t1.pid, t2.userid, t3.count, t1.date 

FROM _mydata AS t1 

LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid 

LEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pid 

ORDER BY t1.pid 

LIMIT 0,15 

调用 show columns 检查这三个表的结构 : 



mysql> show columns from _myuser; 

mysql> show columns from _mydata; 

mysql> show columns from _mydata_body; 

终于发现了问题所在:_mydata 表,只根据 pid 建立了一个 primary key,但并没有为 userid 建立索引。而在这个 SQL 语句的第一个 LEFT JOIN ON 子句中: 



LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid 

_mydata 的 userid 被参与了条件比较运算。于是我为给 _mydata 表根据字段 userid 建立了一个索引: 



mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` ) 

建立此索引之后,CPU 马上降到了 80% 左右。看到找到了问题所在,于是检查另一个反复出现在 show processlist 中的 sql 语句: 



SELECT COUNT(*) 

FROM _mydata AS t1, _mydata_key AS t2 

WHERE t1.pid=t2.pid and t2.keywords = ‘孔雀’ 

经检查 _mydata_key 表的结构,发现它只为 pid 建了了 primary key, 没有为 keywords 建立 index。_mydata_key 目前有 33 万条记录,在没有索引的情况下对33万条记录进行文本检索匹配,不耗费大量的 cpu 时间才怪。看来就是针对这个表的检索出问题了。于是同样为 _mydata_key 表根据字段 keywords 加上索引: 



mysql> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` ) 

建立此索引之后,CPU立刻降了下来,在 50%~70%之间震荡。 



再次调用 show prosslist,网站A 的sql 调用就很少出现在结果列表中了。但发现此主机运行了几个 Discuz 的论坛程序, Discuz 论坛的好几个表也存在着这个问题。于是顺手一并解决,cpu占用再次降下来了。(2007.07.09 附注:关于 discuz 论坛的具体优化过程,我后来另写了一篇文章,详见:千万级记录的 Discuz! 论坛导致 MySQL CPU 100% 的 优化笔记 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm) 



解决 MYSQL CPU 占用 100% 的经验总结 



增加 tmp_table_size 值。mysql 的配置文件中,tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小,MySQL产生一个 The table tbl_name is full 形式的错误,如果你做很多高级 GROUP BY 查询,增加 tmp_table_size 值。 这是 mysql 官方关于此选项的解释: 

tmp_table_size 



This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory. 



对 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的条件判断中用到的字段,应该根据其建立索引 INDEX。索引被用来快速找出在一个列上用一特定值的行。没有索引,MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大,花费时间越多。如果表对于查询的列有一个索引,MySQL能快速到达一个位置去搜寻到数据文件的中间,没有必要考虑所有数据。如果一个表有1000行,这比顺序读取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。 



根据 mysql 的开发文档: 



索引 index 用于: 



快速找出匹配一个WHERE子句的行 

当执行联结(JOIN)时,从其他表检索行。 

对特定的索引列找出MAX()或MIN()值 

如果排序或分组在一个可用键的最左面前缀上进行(例如,ORDER BY key_part_1,key_part_2),排序或分组一个表。如果所有键值部分跟随DESC,键以倒序被读取。 



在一些情况中,一个查询能被优化来检索值,不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀,为了更快,值可以从索引树被检索出来。 



假定你发出下列SELECT语句: 



mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2; 

如果一个多列索引存在于col1和col2上,适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上,优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。 

MySQL 有关“InnoDB: Error: log file ib_logfile0 is of different size 0 5242880 bytes”错误

1,查看Mysqld mysql.err 日志,发现以下错误:

150811 08:51:02 mysqld_safe Starting mysqld daemon with databases from /home/mysql/var
150811  8:51:02 [Warning] The syntax ‘–log-slow-queries’ is deprecated and will be removed in a future release. Please use ‘–slow
-query-log’/’–slow-query-log-file’ instead.
150811  8:51:02 InnoDB: The InnoDB memory heap is disabled
150811  8:51:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150811  8:51:02 InnoDB: Compressed tables use zlib 1.2.3
150811  8:51:02 InnoDB: Initializing buffer pool, size = 256.0M
150811  8:51:02 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file /home/mysql/var/ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 67108864 bytes!
150811  8:51:02 [ERROR] Plugin ‘InnoDB’ init function returned error.
150811  8:51:02 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
150811  8:51:02 [ERROR] Unknown/unsupported storage engine: InnoDB
150811  8:51:02 [ERROR] Aborting
150811  8:51:02 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete
150811 08:51:02 mysqld_safe mysqld from pid file /home/mysql/var/centos.pid ended

2,解决办法

If you want to change the number or the size of your InnoDB log files, you
have to shut down MySQL and make sure that it shuts down without errors.
Then copy the old log files into a safe place just in case something went
wrong in the shutdown and you will need them to recover the database. Delete
then the old log files from the log file directory, edit my.cnf, and start
MySQL again. InnoDB will tell you at the startup that it is creating new log
files.

在你修改my.cnf的innodb_log_file_size参数前,请先停止mysql服务程序的运行(mysql的停止没有出现任何错误),并把/var/lib/mysql目录下的ib_logfile0、ib_logfile1、ib_logfile2等之类的文件移除到一个安全的地方(旧日志文件的保留是为了防止意外的出现),以便Mysql重启后可以将新的ib_logfile0之类日志文件生成到/var/lib/mysql目录下。如果没有什么意外,旧的日志文件可以删除。

让history显示详细执行时间,及linux历史命令使用技巧

history命令主要用于显示历史指令记录内容和曾经执行过的指令 。经常使用Linux命令会有助于提升你的工作效率。

当一台服务器有多人管理时,可能会出现一些误操作或者重复操作,出现问题的时侯要查询什么时间执行什么命令,由于Linux默认的history记录仅保存了命令的内容,没有具体的时间,因此,我们有必要对history历史命令的记录功能进行优化,具体分为设置保存历史命令history的文件大小,保存历史命令history的条数,保存每条历史命令history的执行时间,方法如下:

[fcbu.com@localhost ~]# vi /etc/bashrc

#未尾添加如下信息

# 设置保存历史命令的文件大小

export HISTFILESIZE=500000000

# 保存历史命令条数

export HISTSIZE=1000000

# 实时记录历史命令,默认只有在用户退出之后才会统一记录,很容易造成多个用户间的相互覆盖。

export PROMPT_COMMAND=”history -a”

# 记录每条历史命令的执行时间

export HISTTIMEFORMAT=”%Y/%m/%d %H:%M:%S ”

使更改立即生效

# source /etc/bashrc

linux历史命令使用技巧

列出所有的历史记录:

[fcbu.com@localhost ~]# history

只列出最近10条记录:

[fcbu.com@localhost ~]# history 10 (注,history和10中间有空格)

使用命令记录号码执行命令,执行历史清单中的第99条命令

[fcbu.com@localhost ~]#!99 (!和99中间没有空格)

重复执行上一个命令

[fcbu.com@localhost ~]#!!

执行最后一次以rpm开头的命令(!?  ?代表的是字符串,这个String可以随便输,Shell会从最后一条历史命令向前搜索,最先匹配的一条命令将会得到执行。)

[fcbu.com@localhost ~]#!rpm

逐屏列出所有的历史记录:

[fcbu.com@localhost ~]# history | more

立即清空history当前所有历史命令的记录

[fcbu.com@localhost ~]#history -c

通过指定关键字来执行以前的命令

在下面的例子,输入 !ps 并回车,将执行以 ps 打头的命令

history命令的用途确实很大!但需要小心安全的问题!尤其是 root 的历史纪录档案,这是黑客们的最爱!因为不小心的 root 会将很多的重要资料在执行的过程中会被纪录在 ~/.bash_history 当中,如果这个档案被解析的话,后果不堪设想!

使用 HISTFILE 更改历史文件名称

默认情况下,命令历史存储在 ~/.bash_history 文件中。添加下列内容到 .bash_profile 文件并重新登录 bash shell,将使用 .commandline_warrior 来存储命令历史:

[fcbu.com@localhost ~]# vi ~/.bash_profile

HISTFILE=/root/.commandline_log

使用 -c 选项清除所有的命令历史,如果你想清除所有的命令历史,可以执行:

[fcbu.com@localhost ~]# history -c