关于trac的diff功能的可靠性. 环境就是 uwsgi + nginx

sniperpr

unread,

Jan 21, 2011, 3:30:29 AM1/21/11

to trach...@googlegroups.com

前阵子，感谢组织对我的帮助，使我用上了高性能的 uwsgi+ nginx来发布trac.好处就不再重复了.

目前遇到的问题是：只要使用trac中的 diff功能（diff的地方很多），就会引起 uwsgi的崩溃（自动重启进程）.

说下我的环境。

nginx 0.8.54

uwsgi 0.9.6.6

发布了trac后. 代码服务器是同步一个svn库.

我先导入了一个 u-boot的源码目录.（当然有很多了）

然后又 patch了一个 9.xMB文件。

这样，再我的 timeline就有两条信息了.

我先浏览第一个提交，过了一会，就出来了信息。增加了4344个个文件.

而我再浏览打过9.xMB的那个 timeline后，就出现 nginx 502错误.

cat uwsgi.log发现如下信息

HARAKIRI ON WORKER 1 (pid: 661) ***

HARAKIRI: --- uWSGI worker 1 (pid: 661) WAS managing request /changeset/27 since Fri Jan 21 03:13:07 2011 ---

DAMN ! process 661 died :( trying respawn ...

Respawned uWSGI worker (new pid: 676)

cat nginx/error.log信息：

011/01/21 03:13:39 [error] 654#0: *7 upstream prematurely closed connection while reading response header from upstream, client: 183.17.153.168, server: , request: "GET /changeset/27 HTTP/1.1", upstream: "uwsgi://unix:///home/trac/ddnas88f6281/88f6281/tracs/cgi-bin/trac.sock:", host: "mamipokovps.3322.org", referrer: "http://mamipokovps.3322.org/timeline"

uwsgi --ini uwsgi.ini -d log --catch-exceptions -m

但是uwsgi.log没有多出来什么信息.

求指点.

MuSheng

unread,

Jan 21, 2011, 3:52:18 AM1/21/11

to trach...@googlegroups.com

tracd 正常吧.

On 2011-01-21 16:30, sniperpr wrote:

前阵子，感谢组织对我的帮助，使我用上了高性能的 uwsgi+ nginx来发布trac.好处就不再重复了.

目前遇到的问题是：只要使用trac中的 diff功能（diff的地方很多），就会引起 uwsgi的崩溃（自动重启进程）.

说下我的环境。

nginx 0.8.54

uwsgi 0.9.6.6

发布了trac后. 代码服务器是同步一个svn库.

我先导入了一个 u-boot的源码目录.（当然有很多了）

然后又 patch了一个 9.xMB文件。

这样，再我的 timeline就有两条信息了.

我先浏览第一个提交，过了一会，就出来了信息。增加了 4344个个文件.

而我再浏览打过9.xMB的那个 timeline后，就出现 nginx 502错误.

cat uwsgi.log发现如下信息

HARAKIRI ON WORKER 1 (pid: 661) ***

HARAKIRI: --- uWSGI worker 1 (pid: 661) WAS managing request /changeset/27 since Fri Jan 21 03:13:07 2011 ---

DAMN ! process 661 died :( trying respawn ...

Respawned uWSGI worker (new pid: 676)

cat nginx/error.log信息：

011/01/21 03:13:39 [error] 654#0: *7 upstream prematurely closed connection while reading response header from upstream, client: 183.17.153.168, server: , request: "GET /changeset/27 HTTP/1.1", upstream: "uwsgi://unix:///home/trac/ddnas88f6281/88f6281/tracs/cgi-bin/trac.sock:", host: "mamipokovps.3322.org", referrer: "http://mamipokovps.3322.org/timeline"

uwsgi --ini uwsgi.ini -d log --catch-exceptions -m

但是uwsgi.log没有多出来什么信息.

求指点.

--
邮件来自: Google 论坛“TraChinese”论坛。
发言: trach...@googlegroups.com
退订: trachinese-...@googlegroups.com
详细: http://groups.google.com/group/trachinese
工程: http://trac-hacks.org/wiki/TracChineseTranslation

sniperpr

unread,

Jan 22, 2011, 1:36:23 AM1/22/11

to trach...@googlegroups.com

在 2011年1月21日下午4:52，MuSheng <sheng...@gmail.com>写道：

tracd 正常吧.

tracd 刚才测试了,很正常.

sniperpr

unread,

Jan 23, 2011, 9:52:14 AM1/23/11

to trach...@googlegroups.com

我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....

准备找资料上GDB看看。

Zoom.Quiet

unread,

Jan 23, 2011, 9:59:15 AM1/23/11

to trach...@googlegroups.com

在 2011年1月23日下午10:52，sniperpr <snip...@gmail.com> 写道：
> 我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....

感觉象是 uWSGI 的默认内存有上限,超过了就自殺了,,,
所以,你用 SVN 进行巨型操作前得给uWSGI 一个心理准备...

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
开: http://code.ijinshan.com/
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
蟒: http://code.google.com/p/kcpycamp/wiki/PythoniCamp

sniperpr

unread,

Jan 23, 2011, 10:42:01 AM1/23/11

to trach...@googlegroups.com

在 2011年1月23日下午10:59，Zoom.Quiet <zoom....@gmail.com>写道：

在 2011年1月23日下午10:52，sniperpr <snip...@gmail.com> 写道：
> 我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....

感觉象是 uWSGI 的默认内存有上限,超过了就自殺了,,,
所以,你用 SVN 进行巨型操作前得给uWSGI 一个心理准备...

optimize=2

harakiri=60 (如果设置30的话，还是要crash）

这样就可以浏览巨型diff了. 但是网页有缺失， wiki,timeline那个栏，login什么都不见了，只有手动输入地址才可以进那写界面。。。。

但是如果关闭optimize 后，还是要出 nginx 504错误

log 爆出

SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /changeset/27 !!!

writev(): Broken pipe [wsgi_headers.c line 168]

再次调校，这个参数能够让巨型的 diff出来.但是看log还是有 crash的情况。只是

Zoom.Quiet

unread,

Jan 23, 2011, 11:10:55 AM1/23/11

to trach...@googlegroups.com

在 2011年1月23日下午11:42，sniperpr <snip...@gmail.com> 写道：
>
>
> 在 2011年1月23日下午10:59，Zoom.Quiet <zoom....@gmail.com>写道：
>>
>> 在 2011年1月23日下午10:52，sniperpr <snip...@gmail.com> 写道：
>> > 我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....
>>
>> 感觉象是 uWSGI 的默认内存有上限,超过了就自殺了,,,
>> 所以,你用 SVN 进行巨型操作前得给uWSGI 一个心理准备...
>>
> optimize=2
> harakiri=60 (如果设置30的话，还是要crash）
> 这样就可以浏览巨型diff了. 但是网页有缺失，
> wiki,timeline那个栏，login什么都不见了，只有手动输入地址才可以进那写界面。。。。
> 但是如果关闭optimize 后，还是要出 nginx 504错误
> log 爆出
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request /changeset/27 !!!
> writev(): Broken pipe [wsgi_headers.c line 168]

嗯嗯嗯,这个就可以怀疑是用文件型的 socket 有什么系统级的限制了...
可以换个思路再尝试:
- 切成 fcgi 来带动的形式,看是否有问题?
- 如果通过 http 端口的 fast-cgi 来带没有问题,那一定是 socket 的系统文件限制了,
- 切回 uWSGI 通过端口来绑定
- 如果一样有问题,那就是另外的问题了...

sniperpr

unread,

Jan 23, 2011, 11:23:55 AM1/23/11

to trach...@googlegroups.com

在 2011年1月24日上午12:10，Zoom.Quiet <zoom....@gmail.com>写道：

在 2011年1月23日下午11:42，sniperpr <snip...@gmail.com> 写道：

>
>
> 在 2011年1月23日下午10:59，Zoom.Quiet <zoom....@gmail.com>写道：
>>
>> 在 2011年1月23日下午10:52，sniperpr <snip...@gmail.com> 写道：
>> > 我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....
>>
>> 感觉象是 uWSGI 的默认内存有上限,超过了就自殺了,,,
>> 所以,你用 SVN 进行巨型操作前得给uWSGI 一个心理准备...
>>
> optimize=2
> harakiri=60 (如果设置30的话，还是要crash）
> 这样就可以浏览巨型diff了. 但是网页有缺失，
> wiki,timeline那个栏，login什么都不见了，只有手动输入地址才可以进那写界面。。。。
> 但是如果关闭optimize 后，还是要出 nginx 504错误
> log 爆出
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request /changeset/27 !!!
> writev(): Broken pipe [wsgi_headers.c line 168]

嗯嗯嗯,这个就可以怀疑是用文件型的 socket 有什么系统级的限制了...
可以换个思路再尝试:
- 切成 fcgi 来带动的形式,看是否有问题?
- 如果通过 http 端口的 fast-cgi 来带没有问题,那一定是 socket 的系统文件限制了,
- 切回 uWSGI 通过端口来绑定
- 如果一样有问题,那就是另外的问题了...

好主意！！

我搜索到另外的mail存档说也是这个问题。

我看看切换端口先.

--

人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
开: http://code.ijinshan.com/
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
蟒: http://code.google.com/p/kcpycamp/wiki/PythoniCamp

sniperpr

unread,

Jan 23, 2011, 11:29:39 AM1/23/11

to trach...@googlegroups.com

在 2011年1月24日上午12:23，sniperpr <snip...@gmail.com>写道：

在 2011年1月24日上午12:10，Zoom.Quiet <zoom....@gmail.com>写道：

在 2011年1月23日下午11:42，sniperpr <snip...@gmail.com> 写道：

>
>
> 在 2011年1月23日下午10:59，Zoom.Quiet <zoom....@gmail.com>写道：
>>
>> 在 2011年1月23日下午10:52，sniperpr <snip...@gmail.com> 写道：
>> > 我又调试了下uwsgi的性能参数，但是在这个问题上没有任何效果....
>>
>> 感觉象是 uWSGI 的默认内存有上限,超过了就自殺了,,,
>> 所以,你用 SVN 进行巨型操作前得给uWSGI 一个心理准备...
>>
> optimize=2
> harakiri=60 (如果设置30的话，还是要crash）
> 这样就可以浏览巨型diff了. 但是网页有缺失，
> wiki,timeline那个栏，login什么都不见了，只有手动输入地址才可以进那写界面。。。。
> 但是如果关闭optimize 后，还是要出 nginx 504错误
> log 爆出
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request /changeset/27 !!!
> writev(): Broken pipe [wsgi_headers.c line 168]

嗯嗯嗯,这个就可以怀疑是用文件型的 socket 有什么系统级的限制了...
可以换个思路再尝试:
- 切成 fcgi 来带动的形式,看是否有问题?
- 如果通过 http 端口的 fast-cgi 来带没有问题,那一定是 socket 的系统文件限制了,
- 切回 uWSGI 通过端口来绑定

good kill!good kill!

切换到端口帮顶就正常了！！

Zoom.Quiet

unread,

Jan 23, 2011, 11:54:34 AM1/23/11

to trach...@googlegroups.com

在 2011年1月24日上午12:29，sniperpr <snip...@gmail.com> 写道：
...

>>> > SIGPIPE: writing to a closed pipe/socket/fd (probably the client
>>> > disconnected) on request /changeset/27 !!!
>>> > writev(): Broken pipe [wsgi_headers.c line 168]
>>>
>>> 嗯嗯嗯,这个就可以怀疑是用文件型的 socket 有什么系统级的限制了...
>>> 可以换个思路再尝试:
>>> - 切成 fcgi 来带动的形式,看是否有问题?
>>> - 如果通过 http 端口的 fast-cgi 来带没有问题,那一定是 socket 的系统文件限制了,
>>> - 切回 uWSGI 通过端口来绑定
>
> good kill!good kill!
> 切换到端口帮顶就正常了！！
>>>

奇怪,为嘛哪!! Socket 节省网络句柄的哪,,,
嗯嗯嗯,好象见过有文档说得调节系统参数的放大什么... 嗯嗯嗯,没有到极限状态就先端口吧...

Reply all

Reply to author

Forward