In a meeting earlier today and a semi-techie project manager was asking about IBM i job run priorities. He had some firm ideas that every job should run lower than priority(20) to run faster… not quite right of course… so lets give it a quick overview:

Why do batch (aka background) jobs run at 50?

On IBM i, batch jobs run at priority 50 by default because this is the standard job priority assigned to batch jobs in the system’s job scheduling mechanism. Priority 50 is considered a balanced setting within the IBM i job priority range (1 to 99, where lower numbers indicate higher priority). This default ensures that batch jobs, which are typically non-interactive and less time-sensitive, do not overly compete with interactive jobs (e.g., user sessions) that often run at higher priorities, such as 20.

The priority 50 setting originates from IBM’s design to optimize system resource allocation. Batch jobs, like those for data processing or report generation, are generally expected to run in the background, utilizing system resources without disrupting foreground tasks. The default priority can be adjusted if needed, using commands like CHGJOB or by modifying job descriptions (JOBD), but 50 provides a reasonable starting point for most batch workloads.

Interactive jobs run faster right?

On IBM i, interactive jobs run at priority 20 by default because this higher priority (lower number in the 1-99 range) ensures responsive performance for user-driven tasks, such as terminal sessions or GUI interactions, compared to batch jobs, which default to priority 50 as we just discussed.

Priority 20 allows interactive jobs to get preferential access to CPU resources, minimizing wait times for users and maintaining a smooth experience, especially on systems with mixed workloads.

But its not that simple… run priority is how quick you get processor time and timeslice is how LONG you get in there.

The timeslice is a parameter that defines the maximum CPU time (in milliseconds) a job can use before the system considers switching to another job of equal or higher priority. For interactive jobs, the default timeslice is typically set in the job description or class (e.g., 2000 ms for interactive jobs in the default QINTER subsystem). Timeslicing helps by:

1. Ensuring Responsiveness: It prevents any single interactive job from monopolizing the CPU, allowing other interactive jobs (also at priority 20) to get their share of processing time, maintaining fairness and responsiveness for multiple users.
2. Balancing Workloads: Short timeslices for interactive jobs enable quick context switching, so users experience minimal lag, even under heavy system load.
3. Optimizing Resource Use: By limiting the CPU burst for each job, timeslicing ensures that the system can efficiently juggle multiple interactive tasks without starving lower-priority batch jobs.

The combination of priority 20 and an appropriate timeslice ensures that interactive jobs are both responsive and well-managed, preventing any single job from overwhelming the system..

Most important is memory allocations and memory pool sizes!

IBM i memory pool configurations manage how system memory is allocated to different types of workloads, ensuring efficient resource use for interactive, batch, and system tasks. Here’s a brief overview:

Key Concepts

• Memory Pools: IBM i divides main memory into pools where jobs or subsystems run. Each pool is assigned a portion of memory and specific performance characteristics.
• Types of Pools:
• System Pools: Predefined pools like *MACHINE (for core system functions) and *BASE (default shared pool for most jobs).
• Subsystem Pools: Configured for specific subsystems (e.g., QINTER for interactive jobs, QBATCH for batch jobs).
• Private Pools: Dedicated to specific subsystems or job types for better isolation.
• Shared Pools: Used by multiple subsystems, like *BASE or user-defined shared pools (e.g., *SHRPOOL1).
• Priority and Activity Levels: Each pool has a priority and a maximum number of active jobs (activity level) to control resource allocation and prevent contention.

Default Pools

• *MACHINE: Reserved for OS and critical tasks, minimal user control.
• *BASE: Catches jobs not assigned to other pools, often used for miscellaneous tasks.
• *INTERACT: Typically for interactive jobs (e.g., user sessions in QINTER subsystem).
• *SPOOL: For spooling tasks, like print jobs.
• User-defined shared pools (e.g., *SHRPOOL1 to *SHRPOOL60) for custom workloads.

Configuration

• Commands:
• WRKSYSSTS: Displays memory pools, their sizes, activity levels, and performance metrics.
• CHGSHRPOOL: Adjusts shared pool sizes and activity levels.
• CHGSBSD: Assigns pools to subsystems.
• Tuning: Adjust pool sizes and activity levels based on workload. For example, allocate more memory to *INTERACT for heavy user activity or to *SHRPOOL1 for critical batch jobs.
• Dynamic Adjustments: IBM i supports dynamic memory allocation, allowing pools to grow or shrink based on demand, controlled by system values like QPFRADJ.

Best Practices

• Monitor Performance: Use WRKSYSSTS to check for high paging or wait times, indicating memory contention.
• Balance Pools: Allocate memory based on workload priority (e.g., more for interactive jobs if user response time is critical).
• Use Shared Pools: For flexibility, assign shared pools to multiple subsystems with similar needs.
• Adjust Activity Levels: Set appropriate maximum active jobs to prevent thrashing.

Example

A typical setup might have:

• *MACHINE: 10% of memory for system tasks.
• *BASE: 30% for unassigned jobs.
• *INTERACT: 40% for interactive jobs (priority 20, short timeslice).
• *SHRPOOL1: 20% for batch jobs (priority 50, longer timeslice).

For deeper insights, you can use tools like IBM Navigator for i or check IBM documentation.

If you want specific configuration examples or performance tuning tips, talk to your local IBM-i propellor head. Not me. This stuff makes my head spin 😉