Linux Container Development
 help / color / mirror / Atom feed
From: MALATTAR <mouhannad.alattar-jI/kxupzh7HSLaPbPq81kw@public.gmane.org>
To: KAMEZAWA Hiroyuki
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Fwd: Re: lxc-performance?
Date: Thu, 14 Oct 2010 15:41:53 +0200	[thread overview]
Message-ID: <4CB708A1.7000403@univ-fcomte.fr> (raw)
In-Reply-To: <20101012140509.0ab6c617.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>

  Le 12/10/2010 07:05, KAMEZAWA Hiroyuki a écrit :
> On Fri, 08 Oct 2010 10:09:51 +0200
> MALATTAR<mouhannad.alattar@univ-fcomte.fr>  wrote:
>
>> Le 07/10/2010 16:43, MALATTAR a écrit :
>>> ------------------------------------------------------------------------
>>> 06.10.2010 23:41, MALATTAR ?????:
>>>
>>>> /  the container dora1, where i launch an instance of my IDS, does not take
>>> />/  more than 70 MB as memory even though the memory limit for it is much
>>> />/  bigger than this value,
>>> /
>>> How do you measure memory usage?
>> by using the command:
>> lxc-cgroup -n dora1 memory.usage_in_bytes
>>>    What's in memory.max_usage_in_bytes of
>>> the container's cgroup?
>> executing the next command lxc-cgroup -n dora1 memory.max_usage_in_bytes
>> gave me 70193152 bytes
>>
> Hmm. what latencytop shows ?
>
> You can see this kind of output.
> ==
> Cause                                                Maximum     Percentage
> Writing a page to disk                            551.6 msec         36.8 %
> Fork() system call                                273.7 msec          1.1 %
> Page fault                                        253.9 msec         29.5 %
> Writing buffer to disk (synchronous)              225.9 msec          2.9 %
> Creating block layer request                      202.7 msec         17.1 %
> Walking directory tree                            161.5 msec          1.4 %
> [congestion_wait]                                  97.6 msec          4.4 %
> Executing a program                                97.1 msec          0.3 %
> synchronous write                                  73.9 msec          0.1 %
> ==
>
> IMHO, if memory limit is the problem, "Page Fault" tend to be big.
>
>
> Thanks,
> -Kame
>
>
executing latencytop during the execution of my program gave me:
Cause                                                                    
Maximum     Percentage
fsync() on a file (type 'F' for details)                      45.1 
msec       2.2 %
Waiting for event (poll)                                          5.0 
msec         47.9 %
Userspace lock contention                                    5.0 
msec         43.1 %
Waiting for event (select)                                      4.8 
msec          5.7 %
Throttling GPU while waiting for commands         3.4 msec          0.4 %
[i915_do_wait_request]                                         3.3 
msec          0.5 %
Waiting for data on unix socket                             0.3 
msec          0.1 %
Waiting for TTY data                                              0.2 
msec          0.1 %

Process mysqld (291)                               Total:   2.3 msec
Waiting for data on unix socket                     0.3 msec        100.0 %

It seems that there is no problem...

also memtest command was able to allocate up to 1024MB but it takes a 
long time
for one loop only ...
So, i think the problem is in my program not in the container, is not it?

a+

-- 
Mouhannad AlATTAR
Doctorant à L’UFR Sciences,Techniques et Gestion de l’Industrie
Pôle multimedia de Franche Comté - numerica
1, cours Leprince-Ringuet
25201 Montbéliard
Fixe bureau : 03 81 99 47 87
Portable : 06 16 71 05 10



_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

  parent reply	other threads:[~2010-10-14 13:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08  8:09 Fwd: Re: lxc-performance? MALATTAR
     [not found] ` <4CAED1CF.6050908-jI/kxupzh7HSLaPbPq81kw@public.gmane.org>
2010-10-08 16:41   ` Serge E. Hallyn
     [not found]     ` <20101008164122.GA16891-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2010-10-11  8:05       ` MALATTAR
2010-10-12  5:05   ` KAMEZAWA Hiroyuki
     [not found]     ` <20101012140509.0ab6c617.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-10-14 13:41       ` MALATTAR [this message]
     [not found]         ` <4CB708A1.7000403-jI/kxupzh7HSLaPbPq81kw@public.gmane.org>
2010-10-14 13:54           ` Balbir Singh
2010-10-15 14:32           ` Pavel Labushev
2010-10-12 22:47   ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CB708A1.7000403@univ-fcomte.fr \
    --to=mouhannad.alattar-ji/kxupzh7hslapbpq81kw@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox