Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Date: Thu, 18 Oct 2012 16:02:03 +0000 (UTC)
From: "Michal Fojtik (JIRA)" <jira@apache.org>
To: dev@deltacloud.apache.org
Message-ID: <155638465.64345.1350576123505.JavaMail.jiratomcat@arcas>
In-Reply-To: <351698185.57693.1350480724009.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (DTACLOUD-347) Deltacloud API leaking memory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DTACLOUD-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479095#comment-13479095 ] 

Michal Fojtik commented on DTACLOUD-347:
----------------------------------------

So after reading that report + doing some testing I discovered interesting thing:

for i in {1..1000}; do
  curl -X OPTIONS --user 'mockuser:mockpassword' -H 'Accept: application/xml' \
    'http://localhost:3001/api/images' > /dev/null
done

This will issue OPTIONS call that trigger Rabbit to return valid operations on images. It means it touch driver and all rack middleware we have
and there is no leak. And looking at the report the most memory hungry thing there is HAML. So I have suspicion that HAML could be the potential
memory eater here. 
                
> Deltacloud API leaking memory
> -----------------------------
>
>                 Key: DTACLOUD-347
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-347
>             Project: DeltaCloud
>          Issue Type: Bug
>          Components: Server
>         Environment: deltacloud-core, GIT adade32451815c8ee28e29be35636bd0f98473fc
>            Reporter: Michal Fojtik
>            Priority: Blocker
>              Labels: blocker-1.0.5
>
> Deltacloud API memory usage is slowly increasing after doing 100+ requests:
> Starting Deltacloud API :: mock :: http://localhost:3001/api
> >> Thin web server (v1.5.0 codename Knife)
> >> Debugging ON
> >> Maximum connections set to 1024
> >> Listening on localhost:3001, CTRL+C to stop
> 127.0.0.1 - - [17/Oct/2012 15:26:10] "GET /api/images HTTP/1.1" 200 4420 0.0308
> 127.0.0.1 - - [17/Oct/2012 15:26:17] "GET /api/images HTTP/1.1" 200 4420 0.0220
> 127.0.0.1 - - [17/Oct/2012 15:26:52] "GET /api/images HTTP/1.1" 200 4420 0.0219
> ... 1000 requests after:
> 127.0.0.1 - - [17/Oct/2012 15:27:53] "GET /api/images HTTP/1.1" 200 4420 0.1539
> 127.0.0.1 - - [17/Oct/2012 15:27:53] "GET /api/images HTTP/1.1" 200 4420 0.1554
> 127.0.0.1 - - [17/Oct/2012 15:27:53] "GET /api/images HTTP/1.1" 200 4420 0.1526
> As you can see the response time is slowly increasing and after few minutes it gets to the point where the request take like 10 seconds to complete and all your free memory is gone ;-)
> This is easy to reproduce:
> 1. Start Deltacloud API ($ deltacloudd -i mock)
> 2. $ while true; do curl -H 'Accept: application/xml' --user 'mockuser:mockpassword' http://localhost:3001/api/images > /dev/null; done
> 3. Keep it running for ~1minute and watch the console with Deltacloud API log.
> Thanks to Tomas Hrcka for reporting this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira