免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1617 | 回复: 5

内存问题 [复制链接]

论坛徽章:
0
发表于 2006-03-31 09:52 |显示全部楼层
$ free
             total       used       free     shared    buffers     cached
Mem:       2074932    2018592      56340          0     457232    1392928
-/+ buffers/cache:     168432    1906500
Swap:      1020116        144    1019972


有一个机群,其中服务器上的内存使用状况如上。buffers喝cached是不是太高了?

论坛徽章:
0
发表于 2006-03-31 09:53 |显示全部楼层
發生什麼問題了嗎?

论坛徽章:
0
发表于 2006-03-31 10:41 |显示全部楼层

回复 2楼 lunchan 的帖子

我在服务器上开了NFS,有一个作业要大量的存取NFS的文件,结果在服务器上的内存大部分都被buffer和cached了(2G内存,buffer了98%)。CPU,net之类的都很正常。

这么大的buffer会影响别的作业不?

请教斑竹。thx

论坛徽章:
0
发表于 2006-03-31 12:13 |显示全部楼层
请斑竹支持,我也有类似的问题要解决呢

论坛徽章:
0
发表于 2006-03-31 12:18 |显示全部楼层
相信是由於大量的信息經由UDP發送造成的
Under heavy write loads, the Linux NFS client can generate many large UDP datagrams. This can quickly exhaust output socket buffer space on the client. If this occurs many times in a short time, the client sends the server a large number of fragments, but almost never gets a whole datagram's worth of fragments to the server. This fills the server's IP reassembly queue, causing it to become unreachable via UDP until it expels the useless fragments from the queue.

Note that the same thing can occur on servers that are under a heavy read load. If the server's output socket buffers are too small, large reads will cause them to overflow during IP fragmentation. The client's IP reassembly queue then fills with worthless fragments, and little UDP traffic can get to the client.

Here are some symptoms of this problem:

You use NFS over UDP with a large wsize (relative to the network's MTU), and your application workload is write-intensive, or with a large rsize with a read-intensive application.

You may see many fragmentation errors on your server or clients (netstat -s will tell the story).

Your server may periodically become very slow or unreachable.

Increasing the number of threads on your server has no effect on performance.

One or a small number of clients seem to make the server unusable.

The network path between your client and server may have a router or switch with small port buffers, or the path may contain links that run at different speeds (100Mb/s and GbE).

The fix is to make the Linux's IP fragmentation logic continue fragmenting a datagram even when output socket buffer space is over its limit. This fix appears in kernels newer than 2.4.20. You can work around this problem in one of several ways:

Use NFS over TCP. TCP does not use fragmentation, so it does not suffer from this problem. Using TCP may not be possible with older Linux NFS clients and servers that only support NFS over UDP.

If you can't use NFS over TCP, upgrade your clients to 2.4.20 or later.

If you can't upgrade your clients, increase the default size of your client's socket buffers (see below). 2.4.20 and later kernels do this automatically for the NFS client's socket buffers. See Section 5.3ff of the NFS How-To for more information.

If your rsize or wsize is very large, reduce it. This will reduce the load on your client's and server's output socket buffers.

Reduce network congestion by ensuring your GbE links use full flow control, that your switch and router ports use adequate buffer sizes, and that all links are negotiating their fastest settings.

论坛徽章:
0
发表于 2006-03-31 14:47 |显示全部楼层
how to "increase the default size of your client's socket buffers (see below)"? where is "below"? in NFS HOW-TO???
thank you
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP