linux 内存居高不下,小心服务器内存居高不下的元凶--WebAPI服务

内存这东西虽然便宜，白菜价，但实际在我们的互联网环境中还是非常珍贵的资源，谁叫它不能像硬盘似的，随便弄一块就有好几百G，而没内存就准备挂吧！

话说回来，这次分享的主要是我们在使用调用WebAPI 时的内存竟然居高不下，和解决方法，先上一段代码：

using System;

using System.Collections.Generic;

using System.Net;

using System.Net.Http;

using System.Net.Http.Formatting;

using System.Net.Http.Headers;

namespace EBizClient.Common

{

public

enum MediaTypeHeader

{

application_json,

application_xml

}

public

class HttpClientHelper

{

public MediaTypeHeader mediaType{

get;

set;}

public HttpClientHelper(){

this.mediaType = MediaTypeHeader.application_json;

}

public HttpResponseMessage Get(

string url)

{

var client =

new HttpClient();

var response = client.GetAsync(url).Result;

return response;

}

......

}

}

这段代码主要是做了一个简单的封装，方便前端调用WebAPI返回的rest服务,初看是没啥问题，而且挺长一段时间内我们也就这样用了！

突然有一天测试人员告诉我，程序死了，测试机器卡死了，究其原因，在做压力测试的时候内存没了，但“释压”以后，依然霸占着内存不肯放，只能硬重启。这可是个大问题，我们就这样重复试验，每次结果都一样，去“压”哪个服务，那个服务的IIS进程占用内存就只进不出了。根据这种场景，我们定位问题要么在数据访问层(可能性不大，我们用了比较成熟的框架)，要么就是在数据缓存逻辑那边出了问题(但监测下来存在缓存中的数据少的可怜啊)。

折腾了一段时间，静下心来，分析问题发觉我们根本就是找错了方向，一个同事提醒会不会是web服务一直占用着没有释放呢？在“重压”之下，有些服务无法得到及时响应，但自己又不会释放，越积越多，形成当前局面，从这个思路下手，修正一下代码：

public HttpResponseMessage Get(

string url)

{

var client =

new HttpClient();

HttpResponseMessage response =

null;

client.GetAsync(url).ContinueWith(

(requestTask) =>

{

response = requestTask.Result;

}).Wait(

60000);

return response;

}

这段代码就是在其异步调用服务的时候给一个响应时间，如果这个服务1分钟都没有响应，则自动停止释放掉，到此，这个郁闷的问题就被解决了！

这也是采用新框架尤其需要谨慎的地方，这个问题的解决虽然带有一定的偶然性，但如果真正了解http协议的本源(最基础的无非就是request和response到底是怎么一回事)，其实解决它也应该是个必然的结果