All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harris, James R <james.r.harris at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Question about open files
Date: Wed, 28 Aug 2019 16:46:51 +0000	[thread overview]
Message-ID: <AADA8BCA-0347-41C2-8D5F-059CF980BD3E@intel.com> (raw)
In-Reply-To: CABnqofzQ+xXJ7Bx2+7Ys2tHOJ-fE_LmknSHG+cbcdtQ4a-5SZw@mail.gmail.com

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Hi Sudhe,

On your system, was 32768 the new limit or the old limit?  If it was the new limit, what was the old limit set as on your system?

In general if you're using this large of an IOUnitSize, it will consume more memory.  More memory will equal more huge pages, and each hugepage has a file handle associated with it.

I would expect 1GB hugepages to alleviate this problem since you'd have one file handle per 1GB instead of 512 file handles per 1GB (1GB / 2MB).

Regards,

-Jim


On 8/28/19, 9:06 AM, "SPDK on behalf of Sudheendra Sampath" <spdk-bounces(a)lists.01.org on behalf of sudheendra.sampath(a)gmail.com> wrote:

    Hello All,
    
    Resending this email as I did not see any response.
    
    Appreciate any inputs.
    
    On Wed, Aug 21, 2019 at 9:35 AM Sudhe (Sudheendra) Sampath
    <sudhe.s(a)samsung.com> wrote:
    >
    > We ran into an interesting problem yesterday where SPDK ended up running out of open files.  We determined that when we set IOUnitSize and MaxIOSize to 1 MB and use some number of cores (around 20+), we hit the open files issue below.
    >
    > EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Too many open files
    > EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Too many open files
    > EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Too many open files
    > EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Too many open files
    >
    > When using fewer core, we did not run into this issue.
    >
    >
    > We worked around this by upping the limit of open files (ulimit -r 32768), but we want to understand better going forward.  We are assuming that SPDK is grabbing more huge page memory based off the IOUnitSize and MaxIOSize * number of cores.  What is the correlation between open files and number of cores so that we can calculate or needs in the future?
    >
    > We are using 2 MB huge pages, so we are assuming that if we use 1 GB huge pages, this will not be an issue.  Do you have any other insights in order to avoid this issue when scaling up?
    >
    > Thanks,
    >
    > -Sudhe
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    
    
    
    -- 
    Regards
    
    Sudheendra Sampath
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    


             reply	other threads:[~2019-08-28 16:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 16:46 Harris, James R [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-08-28 16:05 [SPDK] Question about open files Sudheendra Sampath
2019-08-20 22:13 Sudhe Sampath

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=AADA8BCA-0347-41C2-8D5F-059CF980BD3E@intel.com \
    --to=spdk@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.