Favor Soup | 反胃书屋

斯是陋室,惟吾德馨。
posts - 34, comments - 18, trackbacks - 0, articles - 0
  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2010年7月28日

Nginx: 24: Too Many Open Files Error And Solution

by Vivek Gite · 4 comments

I'm getting the following error in my nginx server error log file:

2010/04/16 13:24:16 [crit] 21974#0: *3188937 open() "/usr/local/nginx/html/50x.html" failed (24: Too many open files), client: 88.x.y.z, server: example.com, request: "GET /file/images/background.jpg HTTP/1.1", upstream: "http://10.8.4.227:81//file/images/background.jpg", host: "example.com"

How do I fix this problem under CentOS / RHEL / Fedora Linux or UNIX like operating systems?

Linux / UNIX sets soft and hard limit for the number of file handles and open files. You can use ulimit command to view those limitations:
su - nginx
To see the hard and soft values, issue the command as follows:
ulimit -Hn
ulimit -Sn

Increase Open FD Limit at Linux OS Level

Your operating system set limits on how many files can be opened by nginx server. You can easily fix this problem by setting or increasing system open file limits under Linux. Edit file /etc/sysctl.conf, enter:
# vi /etc/sysctl.conf
Append / modify the following line:
fs.file-max = 70000
Save and close the file. Edit /etc/security/limits.conf, enter:
# vi /etc/security/limits.conf
Set soft and hard limit for all users or nginx user as follows:

nginx       soft    nofile   10000
nginx hard nofile 30000

Save and close the file. Finally, reload the changes with sysctl command:
# sysctl -p

nginx worker_rlimit_nofile Option (Increase Open FD Limit at Nginx Level)

Nginx also comes with worker_rlimit_nofile directive which allows to enlarge this limit if it's not enough on fly at process level. To set the value for maximum file descriptors that can be opened by nginx process. Edit nginx.conf file, enter:
# vi /usr/local/nginx/conf/nginx.conf
Append / edit as follows:

# set open fd limit to 30000
worker_rlimit_nofile 30000;

Save and close the file. Reload nginx web server, enter:
# /usr/local/nginx/sbin/nginx -t && /usr/local/nginx/sbin/nginx -s reload
# su - nginx
$ ulimit -Hn
$ ulimit -Sn

Sample outputs:

30000
10000

posted @ 2010-07-28 17:15 D主 阅读(267) | 评论 (0)编辑 收藏

2010年7月15日

在Linux/Unix类操作系统上, DISPLAY用来设置将图形显示到何处. 直接登陆图形界面或者登陆命令行界面后使用startx启动图形, DISPLAY环境变量将自动设置为:0:0, 此时可以打开终端, 输出图形程序的名称(比如xclock)来启动程序, 图形将显示在本地窗口上, 在终端上输入printenv查看当前环境变量, 输出结果中有如下内容:

DISPLAY=:0.0

使用xdpyinfo可以查看到当前显示的更详细的信息.

DISPLAY 环境变量格式如下host:NumA.NumB, host指Xserver所在的主机主机名或者ip地址, 图形将显示在这一机器上, 可以是启动了图形界面的Linux/Unix机器, 也可以是安装了Exceed, X-Deep/32等Windows平台运行的Xserver的Windows机器. 如果Host为空, 则表示Xserver运行于本机, 并且图形程序(Xclient)使用unix socket方式连接到Xserver, 而不是TCP方式. 使用TCP方式连接时, NumA为连接的端口减去6000的值, 如果NumA为0, 则表示连接到6000端口; 使用unix socket方式连接时则表示连接的unix socket的路径, 如果为0, 则表示连接到/tmp/.X11-unix/X0 . NumB则几乎总是0.

如果使用su username或者su - username切换到别的用户, 并且使用命令

export DISPLAY=:0.0

设置DISPLAY环境变量, 运行图形程序(如xclock)时会收到如下错误:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Error: Can't open display: :0.0

这是因为Xserver默认情况下不允许别的用户的图形程序的图形显示在当前屏幕上. 如果需要别的用户的图形显示在当前屏幕上, 则应以当前登陆的用户, 也就是切换身份前的用户执行如下命令

xhost +

这个命令将允许别的用户启动的图形程序将图形显示在当前屏幕上.

在2台Linux机器之间, 如果设置服务器端配置文件/etc/ssh/sshd_config中包含

X11Forwarding no

客户端配置文件/etc/ssh/ssh_config包含

ForwardX11 yes

则从客户端ssh到服务器端后会自动设置DISPLAY环境变量, 允许在服务器端执行的图形程序将图形显示在客户端上. 在服务器上查看环境变量显示如下(这个结果不同的时候并不相同)

DISPLAY=localhost:10.0

在客户机上用netstat -lnp可以看到有程序监听了6010端口

tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     4827/1

如 果希望允许远程机器上的图形程序将图形显示在本地机器的Xserver上, 除了要设置远端机器的DISPLAY环境变量以外, 还需要设置本地机器的Xserver监听相应的TCP端口. 而现在的Linux系统出于安全的考虑, 默认情况下不再监听TCP端口. 可通过修改/etc/X11/xinit/xserverrc文件, 将

exec /usr/bin/X11/X -dpi 100 -nolisten tcp

修改为

exec /usr/bin/X11/X -dpi 100

允许在直接使用startx启动图形时启动对TCP端口的监听.

修改/etc/kde3/kdm/kdmrc, 将

ServerArgsLocal=-nolisten tcp

修改为

ServerArgsLocal=

允许kdm作为显示管理器时, 启动会话时监听相应的TCP端口.

修改/etc/gdm/gdm.conf, 在[Security]一节增加

DisallowTCP=false

或者在登陆窗口选择"Options" -> "Configure Login Manager..."的Security页面, 取消"Deny TCP connections to Xserver", 允许gdm作为显示管理器时, 启动会话时监听相应的TCP端口.

posted @ 2010-07-15 14:16 D主 阅读(201) | 评论 (0)编辑 收藏

2010年5月11日

finally 区域内的代码块在 return 之前被执行
由于 Java 程序中,所有的对象都是在堆上( Heap )分配存储空间的,这些空间完全由垃圾回收机制来对它们进行管理。因此,从这一点可以分析得出一个推论: Java 中的异常处理模型的实现,其实要比 C++ 异常处理模型简单得多。例如,它首先不需要像 C++ 异常处理模型中那样,必须要跟踪栈上的每一个“对象”的构造和析构过程(只有跟踪并掌握了这些信息,发生异常时, C++ 系统它才会知道当前应该析构销毁哪些对象呀!),这是因为 Java 程序中,栈上是绝对没有“对象”的(实际只是对堆上对象的引用)。另外,还有 Java 语言中的异常对象的传递也更为简单和容易了,它只需传递一个引用指针而已,而完全不用考虑异常对象的构造、复制和销毁过程。

当然, Java 异常处理模型较 C++ 异常处理模型复杂的地方是,它引入了 finally 机制(主要用于数据库连接的关闭、 Socket 关闭、文件流的关闭等)。其实,我们也知道 finally 语法最早是在微软的 SEH 所设计出的一种机制,虽然它功能很强大,但是实现起来却并不是很难,从表象上来理解:当代码在执行过程中,遭遇到 return 和 goto 等类似的语句所引发作用域(代码执行流)转移时,便会产生一个局部展开( Local Unwinding );而由于异常而导致的 finally 块被执行的过程,往往被称为全局展开( Global Unwinding )。由于展开( Unwinding )而导致的 finally 块被执行的过程,非常类似于一个子函数(或子过程)被调用的过程。例如,当在 try 块中最后一条语句 return 被执行到的时候,一个展开操作便发生了,可以把展开操作想象成,是编译器在 return 语句之前插入了一些代码(这些代码完成对 finally 块的调用),因此可以得出结论: finally 区域内的代码块,肯定是在 return 之前被执行。

但是,请特别注意, finally 块区域中的代码虽然在 return 语句之前被执行,但是 finally 块区域中的代码是不能够通过重新赋值的方式来改变 return 语句的返回值。请看如下的示例代码:

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

// 你认为 test 函数返回的值是多少呢?

System.out.println(\"test 的返回值为: \" + test());

}

public static int test()

{

int ret = 1;

try

{

System.out.println(\"in try block\");

// 是返回 1 ,还是返回 2 呢?

return (ret);

}

catch(Exception e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

}

finally

{

// 注意,这里重新改变了 ret 的值。

ret = 2;

System.out.println(\"in finally block!\");

}

return 0;

}

}

上面的示例程序中,本来是想在 finally 区域中通过改变 ret 的值,来影响 test 函数最终 return 的值。但是真的影响了吗?否!否!否!不信,看看运行结果吧!

in try block

in finally block!

test 的返回值为: 1

其实,在 SEH 异常处理模型中, try-finally 语句对此情况也是有相同结果的处理结果,同样是上面的那个程序,把它改称 C 语言的形式,用 VC 编译运行一把,验证一下结果,代码如下:

#include \"stdio.h\"

int test()

{

int ret = 1;

__try

{

printf(\"in try block
\");

return ret;

}

__finally

{

ret = 2;

printf(\"in finally block!
\");

}

return 0;

}

void main()

{

printf(\"test 的返回值为: %d
\", test());

}


通过调试可以很容易看出,在 return ret 之前,编译器实际上对 ret 赋值了一份临时变量,为的就是防止 finally 区域中的代码对这个 ret 值的改变。当然这只是 debug 版本的情况,实际上,在 release 版本, return ret 语句直接被编译器编译成 mov eax, 1 指令。

所以说,无论是在 SEH 异常处理模型中,还是 Java 的异常处理模型中, finally 块区域中的代码都是不能够通过重新赋值的方式来改变 try 区域中 return 语句的返回值。

强烈建议不要在 finally 内部使用 return 语句
上面刚刚说了, finally 块区域中的代码不会轻易影响 try 区域中 return 语句的返回值,但是有一种情况例外,那就是在 finally 内部使用 return 语句。示例程序如下:

// 示例程序 1 , Java 程序

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

System.out.println(\"test 的返回值为: \" + test());

}

public static int test()

{

int ret = 1;

try

{

System.out.println(\"in try block\");

return (ret);

}

catch(Exception e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

}

finally

{

ret = 2;

System.out.println(\"in finally block!\");

// 这里添加了一条 return 语句

return ret;

}

}

}

// 示例程序 2 , C 程序

#include \"stdio.h\"

int test()

{

int ret = 1;

__try

{

printf(\"in try block
\");

return ret;

}

__finally

{

ret = 2;

printf(\"in finally block!
\");

return ret;

}

printf(\" 多余的
\");

return 0;

}

void main()

{

printf(\"test 的返回值为: %d
\", test());

}

上面的程序运行结果如下:

in try block

in finally block!

test 的返回值为: 2

也许大多数朋友都估计到,上面的 test 函数返回值是 2 。也即是说, finally 内部使用 return 语句后,它影响(覆盖了) try 区域中 return 语句的返回值。这真是一种特别糟糕的情况,虽然它表面上看起来不是那么严重,但是这种程序极易给它人造成误解(使得阅读该代码的人总得担心或考虑,是否有 其它地方影响了这里的 return 的返回值)。

之所以出现这种现象的真正原因是,由于 finally 区域中的代码先于 return 语句( try 作用域中的)被执行,但是,如果此时在 finally 内部也有一个 return 语句,这将会导致该函数直接就返回了,而致使 try 作用域中的 return 语句再也得不到执行机会(实际就是无效代码,被覆盖了)。

面对上述情况,其实更合理的做法是,既不在 try block 内部中使用 return 语句,也不在 finally 内部使用 return 语句,而应该在 finally 语句之后使用 return 来表示函数的结束和返回,把上面的程序改造一下,代码如下

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

try

{

System.out.println(\"test 的返回值为: \" + test());

}

catch(Exception e)

{

e.printStackTrace();

}

}

public static int test() throws RuntimeException

{

int ret = 1;

try

{

System.out.println(\"in try block\");

}

catch(RuntimeException e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

throw e;

}

finally

{

ret = 2;

System.out.println(\"in finally block!\");

}

// 把 return 语句放在最后,这最为妥当

return ret;

}

}

另一种更糟糕的情况
上面刚刚讲到, finally 内部使用 return 语句会覆盖 try 区域中 return 语句的返回值。不仅与此, finally 内部使用 return 语句还会导致出现另外一种更为糟糕的局面。到底是何种糟糕情况呢?还是先看看下面的示例程序再说吧!代码如下:

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

try

{

System.out.println(\"test 的返回值为: \" + test());

}

catch(Exception e)

{

e.printStackTrace();

}

}

public static int test() throws RuntimeException

{

int ret = 0;

try

{

System.out.println(\"in try block\");

// 这里会导致出现一个运行态异常

int i=4,j=0;

ret = i/j;

}

catch(RuntimeException e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

// 异常被重新抛出,上层函数可以进一步处理此异常

throw e;

}

finally

{

System.out.println(\"in finally block!\");

// 注意,这里有一个 return 语句

return ret;

}

}

}

是不是觉得上面示例程序中的代码写的挺好的,挺简洁的,还挺严谨的,应该不会有什么 BUG !阿愚告诉你,错了!绝对错了!而且问题很严重!要不,朋友们在编译运行此程序前,先预期一下它的运行结果,大家是不是觉得运行流程应该是这样子的: 首先在终端输出“ in try block ”,接着,由于程序运行时出现了一个被 0 处的异常( ArithmeticException );于是,进入到 catch block 中,这里的代码将继续向终端输出了“ in catch block ”信息,以及输出异常的堆栈信息等;接着,由于异常在 catch block 中又被重新抛出了,所以控制权返回到 main 函数的 catch block 中;对了,补充一点,也许大家会觉得,由于异常的 rethrow ,使得控制权离开 test 函数作用域的时候, finally 内的代码会被执行,也即“ in finally block ”信息也会被打印到终端上了 。仅仅如此吗?不妨看一下实际的运行结果,如下:

in try block

in catch block

java.lang.ArithmeticException: / by zero

at Trans.test(Trans.java:27)

at Trans.main(Trans.java:10)

in finally block!

test 的返回值为: 0

看了实际的运行结果,是不是觉得大吃一惊!被重新抛出( rethrow )的异常居然“丢弃了”,也即 main 函数中,并没有捕获到 test 函数中的任何异常,这也许大大出乎当初写这段代码的程序员的预料吧!究竟原因何在呢?其实, 罪魁祸首就是 finally block 内部的那条 return 语句 。因为这段程序的运行流程基本如刚才我们预期描述的那样,但是有一点是不对的,那就是当 test 函数中把异常重新抛出后,这将导致又一次的 catch 的搜索和匹配过程,以及 test 函数中的 UnWinding 操作,也即 finally 被调用执行,但是由于 finally 内部的 return 语句,不仅使得它结束了 test 函数的执行(并返回一个值给上层函数),而且这还使得上面的那个对异常进行进一步的操作过程给终止了(也即控制权进入到 catch block 的过程)。瞧瞧!后果严重吧!

是呀!如果 Java 程序员不注意这种问题,养成一个严谨的、好的编程习惯,它将会导致实际的许多 Java 应用系统中出现一些莫名奇妙的现象(总感觉系统中出现了某类异常,有一些问题,但上层的模块中却总是捕获不到相关的异常,感觉一些良好!其实不然,它完全 是由于 finally 块中的 return 语句不小心把异常给屏蔽丢弃掉了)。

总结
•     finally 区域内的代码总在 return 之前被执行;

•     强烈建议不要在 finally 内部使用 return 语句。它不仅会影响函数的正确返回值,而且它可能还会导致一些异常处理过程的意外终止,最终导致某些异常的丢失。

posted @ 2010-05-11 18:38 D主 阅读(203) | 评论 (0)编辑 收藏

2008年5月12日

        有时在word、PowerPoint中使用了一些特殊的字体,非常漂亮,但是文件在其它计算机上打开,却发现那些特殊的字体变成了宋体,原因是如果本机中没有文档中定义的特殊字体,计算机会使用宋体来代替,下面来看一下解决方法。
        以office xp为例,在文档中定义好字体后,选择保存,在保存界面下打开“工具”-“保存选项”勾选“嵌入TrueType字体”和“只嵌入所用字符”,然后点“保存即可”,如果已经保存而没有选择以上两项,可以使用“另存为”来打开上述界面。

posted @ 2008-05-12 10:39 D主 阅读(749) | 评论 (0)编辑 收藏

2007年12月26日

把word另存为html格式,就会自动生成文件夹,里面有所有图片。

posted @ 2007-12-26 17:27 D主 阅读(1107) | 评论 (2)编辑 收藏

meebo
比较早的Web IM,支持AIM、ICQ、Yahoo! Messenger、Jabber、Gtalk和MSN。

ebuddy
支持MSN、Yahoo、AIM,提供Wap登陆。

Web QQ
QQ 的 Web IM,已经可以使用了。

mabber
Beta中,支持AIM、ICQ、Yahoo! Messenger、Jabber、Gtalk和MSN,速度比较慢。

AIM
AIM自己的Web IM。

MSN
Microsoft 自己的Web IM。

ICQ
ICQ开发的的ICQ Web IM。

koolim
支持AIM、ICQ、Yahoo! Messenger、Jabber、Gtalk、MSN。

imhaha
支持QQ哟,另外还支持MSN、Yahoo!Messenger,AIM。
 
radiusim
支持AIM、Yahoo messager!、MSN、Gtalk

posted @ 2007-12-26 16:58 D主 阅读(122) | 评论 (0)编辑 收藏

服务器版的pdffactory,需要在下图这个地方找注册的位置,直接利用软件打印是无法弹出注册提示的,不注册的版本在打印出的pdf文件会有pdffactory的水印滴。


对了,有个重要提示,就是在注册的时候,如果系统有防火墙的,一定要先关闭防火墙!pdfFactory在注册时是要搜索局域网的。否则,那个许可代码按钮是灰色不可用状态,切记!

posted @ 2007-12-26 16:42 D主 阅读(1633) | 评论 (0)编辑 收藏

OpenCV安装后“没有找到cxcore100.dll”的错误处理

在安装时选择“将\OpenCV\bin加入系统变量”(Add\OpenCV\bin to the systerm PATH)。 但该选项并不一定能成功添加到系统变量,如果编写的程序在运行时出现“没有找到cxcore100.dll,因为这个应用程序未能启动。重新安装应用程序可能会修复此问题。”的错误。

手动在我的电脑->属性->高级->环境变量->系统变量->path添加c:\program files\opencv\bin;

添加完成后需要重启计算机。

posted @ 2007-12-26 16:31 D主 阅读(6790) | 评论 (0)编辑 收藏

2007年10月23日

最近研究Java,发现很多有趣的事情。今天又是一例。
先看代码(注意第5行和第8行的两个”return”)

  1. public class TestClass{
  2.     public int test(){
  3.         try{
  4.             System.out.println("step1");
  5.             return 1;
  6.         }finally{
  7.             System.out.println("step2");//会执行吗?
  8.             return 2;
  9.         }
  10.     }
  11.     public static void main(String[] args){
  12.         TestClass te=new TestClass();
  13.         int t=te.test();
  14.         System.out.println(t);
  15.     }
  16. }

按理说,一个方法执行到return就应该返回,但是按照Java的规范,finally中的代码又是一定要被执行的。
先看看上面这个程序的运行结果:

step1
step2
2

可以看到,虽然在try块中遇到了return,但finally中的代码仍然被执行了。test()方法的返回值最终为2。

那么try块中的return语句没有用吗?不是的。
如果你注释掉第8行,即finally中的return语句,你会发现test方法最终会返回1。结果如下:

step1
step2
1

发散一下,如果我在catch中返回一个值,同时也在finally中加入一个return语句,结果会怎么样呢?
答案是:现象相同。catch中的return和finally中的return都会执行。有兴趣的可以试试。

posted @ 2007-10-23 17:34 D主 阅读(120) | 评论 (0)编辑 收藏

2007年5月11日

        打开电脑winrar的设置——综合选项,在“用户自定义压缩文件扩展名”项目上打上“001”,确定。
随后再去看看你下载的文件,可以正常解压了吧!如图:


posted @ 2007-05-11 10:05 D主 阅读(1831) | 评论 (2)编辑 收藏