All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudhe (Sudheendra) Sampath <sudhe.s at samsung.com>
To: spdk@lists.01.org
Subject: [SPDK] Question about open files
Date: Tue, 20 Aug 2019 22:13:54 +0000	[thread overview]
Message-ID: <eab24b0df4d54791a5a30a1786cbfefe@samsung.com> (raw)
In-Reply-To: CGME20190820221355uscas1p205e413b1361e490aa93c5aa4bf665073@uscas1p2.samsung.com

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

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

             reply	other threads:[~2019-08-20 22:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 22:13 Sudhe Sampath [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-28 16:46 Harris, James R

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=eab24b0df4d54791a5a30a1786cbfefe@samsung.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.