# Infor LN Bshell Application Server Memory and CPU Sizing Calculator

> Source: https://netray.co/tools/infor-ln-bshell-application-server-memory-sizing-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate peak bshell count, RAM and CPU cores for an LN 10.x application server from your own measured bshell memory and concurrency.

## Category

infor-ln

## Erp

Infor LN

## Audience

- ERP administrator
- Infrastructure engineer
- LN technical consultant

## Tool

**Kind:** calculator

**Inputs:**

#### Named users

**Key:** users

**Type:** number

**Default:** 250

**Min:** 1

**Step:** 10

**Unit:** users

#### Peak concurrency

**Key:** conc

**Type:** slider

**Default:** 60

**Min:** 5

**Max:** 100

**Step:** 1

**Unit:** %

**Help:** Share of named users logged on at the busiest hour. Count it, do not guess: sample the bshell process list at peak for a week.

#### Bshells per concurrent user

**Key:** bpu

**Type:** number

**Default:** 1.2

**Min:** 1

**Step:** 0.1

**Unit:** bshells

**Help:** 1.0 means one bshell per user. Raise it for users with extra bshells from integrations, AFS/BOD connections or several open clients.

#### Memory per bshell

**Key:** mem

**Type:** number

**Default:** 60

**Min:** 5

**Step:** 5

**Unit:** MB

**Help:** Measure the resident memory of bshell processes with ps (Unix/Linux) or Task Manager (Windows) during normal work.

#### Background job bshells

**Key:** jobs

**Type:** number

**Default:** 10

**Min:** 0

**Step:** 1

**Unit:** bshells

**Help:** Job daemon and job queue bshells running at peak.

#### OS and services overhead

**Key:** overhead

**Type:** number

**Default:** 8

**Min:** 0

**Step:** 1

**Unit:** GB

**Help:** Operating system, LN shared memory, database client, monitoring and backup agents.

#### Bshells per CPU core

**Key:** bpc

**Type:** number

**Default:** 12

**Min:** 1

**Step:** 1

**Unit:** bshells

**Help:** Assumption. Most bshells are idle most of the time; lower this for heavy reporting or MRP-type users.

#### Headroom

**Key:** head

**Type:** slider

**Default:** 30

**Min:** 0

**Max:** 100

**Step:** 5

**Unit:** %

**Outputs:**

#### Peak bshells

**Key:** peak

**Expr:** users * conc / 100 * bpu + jobs

**Format:** integer

**Description:** Interactive bshells at the busiest hour plus background job bshells.

#### RAM required

**Key:** ram

**Expr:** (peak * mem / 1024 + overhead) * (1 + head / 100)

**Format:** decimal

**Primary:** true

**Description:** GB of memory for the application server including OS overhead and headroom.

#### CPU cores required

**Key:** cores

**Expr:** ceil(peak / bpc * (1 + head / 100))

**Format:** integer

**Primary:** true

**Description:** Physical or dedicated virtual cores, rounded up.

#### Memory used by bshells alone

**Key:** bshell_gb

**Expr:** peak * mem / 1024

**Format:** decimal

**Description:** GB, before overhead and headroom.

#### Memory per named user

**Key:** per_user

**Expr:** ram * 1024 / users

**Format:** decimal

**Description:** MB of server RAM per named user, useful for comparing against your current server.

**Chart:**

#### RAM (GB) and cores vs named users

**Type:** line

**X:** users

**From:** 50

**To:** 1000

**Steps:** 20

**Series:**

- ram
- cores

**Disclaimer:** This is a measurement-based rule of thumb, not an Infor sizing formula. Every default is an editable assumption; replace them with values measured on your own LN server, and use Infor's sizing service for contractual hardware commitments.

## Content

**Intro:** This calculator sizes memory and CPU for an on-prem Infor LN 10.x application server from the number of bshell processes you expect at peak and the memory each one really uses. It is meant for refresh, virtualisation and consolidation planning where you can measure the current system.

**Sections:**

#### How the estimate works

**Body:** In LN each logged-on user session runs in a bshell process on the application server, and background jobs run in their own bshells. The calculator multiplies named users by peak concurrency and by bshells per user, adds job bshells, then converts that peak count into memory (count times measured MB per bshell, plus OS and services overhead, plus headroom) and into cores (count divided by how many bshells one core carries, plus headroom, rounded up). Nothing here is an Infor formula: it is arithmetic over numbers you measure. Infor publishes performance and tuning guidance for LN on docs.infor.com; check it for your release and use any figure it gives in place of these defaults.

**Bullets:**

- Peak bshells = users x concurrency x bshells per user + job bshells
- RAM GB = (peak x MB per bshell / 1024 + overhead GB) x (1 + headroom)
- Cores = ceil(peak / bshells per core x (1 + headroom))

#### How to measure bshell memory and concurrency

**Body:** On Unix or Linux, list the bshell processes at the busiest hour with ps and their resident size (RSS), then average them; repeat over several days, because bshells grow while users open sessions and run large reports. On Windows use Task Manager or a performance counter on the bshell processes. Count how many bshells exist at peak: that count divided by named users gives your real concurrency times bshells per user. Count job daemon bshells separately. Shared memory and the database client libraries are counted once, in overhead, so do not double count them in the per-bshell figure.

#### Worked example

**Body:** With 250 named users, 60 percent peak concurrency and 1.2 bshells per user you get 180 interactive bshells, plus 10 job bshells, so 190 at peak. At 60 MB each that is about 11.1 GB, plus 8 GB overhead, times 1.3 headroom, so about 24.8 GB of RAM. At 12 bshells per core, 190 bshells need 15.8 cores, times 1.3 is 20.6, rounded up to 21 cores. If you move to 400 users the chart shows RAM and cores rising in a straight line, which is why measured concurrency matters more than the named-user count.

#### Session timeouts and idle bshells

**Body:** Idle bshells still hold memory. If users leave LN open all day, peak concurrency approaches 100 percent of logged-in users even when few are working. An idle session timeout reduces that, but set it with the business: a timeout that ends sessions during long data entry costs more than the RAM it saves. Before you add memory, check how many bshells at peak belong to users who have not done anything for an hour; the answer often changes the sizing more than any hardware option.

**Cta:** If you want your LN users to ask questions about orders, stock and jobs in plain English on your own servers, we can add a private AI layer next to this LN system.

**Faq:**

#### How many active users can an Infor LN application server handle?

**Answer:** There is no fixed number. It depends on how many bshells each user creates, how much memory each bshell holds, and how heavy the sessions are. Measure bshell count and resident memory at your busiest hour, then use this calculator to translate that into RAM and cores for the user count you plan to support.

#### What is a bshell in the LN session architecture?

**Answer:** The bshell is the LN runtime process on the application server that executes sessions and 4GL or 3GL logic for a user or a job. Clients such as LN UI connect to a bshell, which talks to the database through the database driver. More open bshells means more server memory, so bshell count is the main sizing driver.

#### Does the session timeout setting reduce server memory?

**Answer:** It can, because idle sessions keep their bshell alive and hold memory. Ending idle sessions after a defined period lowers the peak bshell count. Agree the timeout with users first, and measure the bshell count before and after so you size from the real effect rather than an expectation.

#### Is 60 MB per bshell an Infor number?

**Answer:** No. It is an editable starting assumption. Real values vary with LN release, sessions used, report sizes and customisations. Replace it with the average resident size you measure on your own server at peak. If Infor guidance for your release gives a figure, use that instead.

## Search terms

infor ln active users, infor ln session architecture, infor ln session timeout, infor ln bshell memory, infor ln application server sizing, ln bshell count, infor ln server cpu sizing, baan bshell memory usage

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json